TPS Engineers Reference Manual

Implementation
Startup and Reconfiguration - 2
Engineer’s Reference
Manual
SW09-605
Release 682
11/2010
Notices and Trademarks
Copyright 2010 by Honeywell International Sárl.

Release 682 November, 2010
While this information is presented in good faith and believed to be accurate, Honeywell disclaims the implied
warranties of merchantability and fitness for a particular purpose and makes no express warranties except as may
be stated in its written agreement with and for its customers.
In no event is Honeywell liable to anyone for any indirect, special or consequential damages. The information and
specifications in this document are subject to change without notice.
Honeywell, PlantScape, Experion PKS, and TotalPlant are registered trademarks of Honeywell International Sarl.
Other brand or product names are trademarks of their respective owners.
Honeywell Process Solutions

1860 W. Rose Garden Lane
Phoenix, AZ 85027 USA
1-800 822-7673
ii Engineer’s Reference Manual 11/2010

About This Publication
This Engineer's Reference Manual provides a general guide to the process engineer's
configuration, startup, and reconfiguration efforts for TPN-based TPS systems. The
information presented defines how the various types of configuration data interact, and how
the interaction affects the system as seen by the process engineer as the system operates.
If you are unsure of the terminology used in this and other implementation publications, refer
to Section 19.
The mentions in this manual of "Universal Station" or "US" also apply to Universal Work
Stations, unless otherwise defined.
This publication supports TPS system network Release 682. TPS is the evolution of TDC
3000X.
Several sections in this manual are designated as “Reserved.” In earlier versions of this
Engineer’s Reference Manual, these sections contained information that was moved to new
publications during the R400 bookset update. The following are the sections and the new
publications:
• Sections 8 and 26 Refer to Hiway Gateway Implementation
Guidelines.
• Section 9 Refer to Data Entity Builder Manual.
• Section 16 Refer to Application Module Implementation
Guidelines.
• Sections 24, 25, and 29 Refer to LCN Guidelines - Implementation,
Troubleshooting, and Service.
11/2010 Engineer’s Reference Manual iii

Support and Other Contacts
United States and Canada
Contact: Honeywell Solution Support Center

Phone: 1-800-822-7673
Calls are answered by dispatcher between 6:00 am and 4:00 pm Mountain
Standard Time. Emergency calls outside normal working hours are
received by an answering service and returned within one hour.
Fascimile: 1-973-455-5000
Mail: Honeywell TAC, MS L17
1860 W. Garden Lane
Phoenix, AZ, 85027 USA
Europe, Middle East, and Africa (EMEA)
Contact: Honeywell TAC-EMEA

Phone: +32-2-728-2345
Fascimile: +32-2-728-2696
Mail: TAC-BE02
Hermes Plaza
Hermeslaan, 1H
B-1831 Diegem, Belgium
Pacific
Contact: Honeywell Global TAC – Pacific

Phone: 1300-364-822 (toll free within Australia)
+61-8-9362-9559 (outside Australia)
Fascimile: +61-8-9362-9564
Mail: Honeywell Limited Australia
5 Kitchener Way
Burswood 6100, Western Australia
Email: GTAC@honeywell.com
India
Contact: Honeywell Global TAC – India

Phone: +91-20- 6603-9400
Fascimile: +91-20- 6603-9800
Mail: Honeywell Automation India Ltd
56 and 57, Hadapsar Industrial Estate
Hadapsar, Pune –411 013, India
Email: Global-TAC-India@honeywell.com
Korea
Contact: Honeywell Global TAC – Korea

Phone: +82-80-782-2255 (toll free within Korea)
Fascimile: +82-2-792-9015
Mail: Honeywell Co., Ltd
4F, Sangam IT Tower
1590, DMC Sangam-dong, Mapo-gu
Seoul, 121-836, Korea
Email: Global-TAC-Korea@honeywell.com
iv Engineer’s Reference Manual 11/2010

People’s Republic of China
Contact: Honeywell Global TAC – China

Phone: +86- 21-2219-6888
800-820-0237
400-820-0386
Mail: Honeywell (China) Co., Ltd
33/F, Tower A, City Center, 100 Zunyi Rd.
Shanghai 200051, People’s Republic of China
Email: Global-TAC-China@honeywell.com
Singapore
Contact: Honeywell Global TAC – South East Asia

Phone: +65-6580-3500
Fascimile: +65-6580-3501
+65-6445-3033
Mail: Honeywell Private Limited
Honeywell Building
17, Changi Business Park Central 1
Singapore 486073
Email: GTAC-SEA@honeywell.com
Taiwan
Contact: Honeywell Global TAC – Taiwan

Phone: +886-7-536-2567
Fascimile: +886-7-536-2039
Mail: Honeywell Taiwan Ltd.
17F-1, No. 260, Jhongshan 2nd Road.
Cianjhen District
Kaohsiung, Taiwan, ROC
Email: Global-TAC-Taiwan@honeywell.com
Japan
Contact: Honeywell Global TAC – Japan

Phone: +81-3-6730-7160
Fascimile: +81-3-6730-7228
Mail: Honeywell Japan Inc.
New Pier Takeshiba, South Tower Building,
20th Floor, 1-16-1 Kaigan, Minato-ku,
Tokyo 105-0022, Japan
Email: Global-TAC-JapanJA25@honeywell.com
Elsewhere
Call your nearest Honeywell office.
World Wide Web
Honeywell Solution Support Online:
http://www.honeywell.com/ps
Training Classes
Honeywell Automation College:
http://www.automationcollege.com
11/2010 Engineer’s Reference Manual v

vi Engineer’s Reference Manual 11/2010
Table of Contents
SECTION 1 – ENGINEER’S REFERENCE MANUAL SUMMARY................................. 17

1.1 Things to Decide Before Configuring or Reconfiguring....................................... 19
1.2 Preferred Hardware Configuration ........................................................................ 22
1.3 Universal Personality & Operator Personality ...................................................... 23
1.4 Section Summaries ................................................................................................ 24
SECTION 2 – FILE SYSTEM OPERATIONS ................................................................. 31

2.0 Overview ............................................................................................................... 31
2.1 File System Pathnames .......................................................................................... 32
2.1.1 Pathname Rules ..................................................................................................... 33
2.2 Access to Volumes and Directories....................................................................... 35
2.3 System Volumes and User Volumes ..................................................................... 36
2.4 Typical File System Utility Commands................................................................. 38
2.5 File Names and Suffixes........................................................................................ 40
2.5.1 File Name Suffixes (Extensions)........................................................................... 41
2.6 Cartridge Part Numbers ......................................................................................... 44
SECTION 3 – THE &ASY SYSTEM DIRECTORY AND ITS SPECIAL

CHARACTERISTICS ................................................................................ 47
3.0 Overview ............................................................................................................... 47
3.1 &ASY’s Role in Node Loading and Startup ......................................................... 48
3.2 Tools for Maintaining Backup Copies of &ASY .................................................. 50
SECTION 4 – AREA (&D01-&D10) AND STANDARD ABSTRACT (&DSY)

DIRECTORIES .......................................................................................... 51
4.0 Overview ............................................................................................................... 51
4.1 The Role of &DSY and Other Data in Loading USs ............................................ 52
4.1.1 The Fast-Load Feature........................................................................................... 53
4.2 Changes to Area Database, Schematics, and Button Configuration...................... 54
SECTION 5 – CONSOLE ORGANIZATION.................................................................... 55

5.0 Overview ............................................................................................................... 55
5.1 Console Hints and Tips ......................................................................................... 56
5.2 Printer Failover...................................................................................................... 57
5.3 Personality Hints and Tips..................................................................................... 59
SECTION 6 – NETWORK CONFIGURATION FILE ....................................................... 61

6.0 Overview ............................................................................................................... 61
6.1 NCF Information ................................................................................................... 62
SECTION 7 – HM CONFIGURATION AND USE ............................................................ 65

7.0 Overview ............................................................................................................... 65
7.1 Introduction ........................................................................................................... 66
7.1.1 HM Options and Variations................................................................................... 66
7.1.2 Overview of HM Operation................................................................................... 68
7.2 Guidelines for Use of HM Storage Space ............................................................. 69
7.2.1 Volumes and Types of Data Stored in HMs.......................................................... 69
7.2.2 Allocating HM Functions on the LCN .................................................................. 71
7.2.3 Assigning Units to HMs ........................................................................................ 76
7.2.4 Configuring History Groups.................................................................................. 77
7.2.5 Requesting History through the LCN.................................................................... 78
7.2.6 Managing History Collection by Computers through the CG ............................... 79
11/2010 Engineer’s Reference Manual vii

Table of Contents
7.3 Continuous History Configuration .........................................................................80

7.3.1 Hourly, Shift, Daily, and Monthly Averages .........................................................81
7.3.2 Snapshots and User Averages ................................................................................82
7.3.3 Uses of Continuous History ...................................................................................85
7.3.4 Continuous History Configuration Forms and Displays ........................................86
7.3.5 Continuous History Notes and Precautions............................................................87
7.4 How to Estimate HM Volume Sizes ......................................................................89
7.4.1 Use of Tables and Charts to Estimate HM Volume Sizes......................................91
7.4.2 HM Volume Configuration Example .....................................................................95
7.4.3 Applying Volume-Size Estimates to Forms and Data Entry..................................96
7.4.4 HM Volume Size Estimator Tables and Figures....................................................98
7.5 Redundant HM Disk Option ................................................................................127
7.5.1 Configuring Redundant HM Disk Drives ............................................................130
7.5.2 Synchronizing Redundant HM Disk Drives.........................................................131
7.5.3 Setting a Redundant HM Disk Drive Off-Line ....................................................132
7.5.4 Servicing Redundant HM Disk Drives.................................................................133
7.6 HM Initialization..................................................................................................134
7.6.1 Local HM Network Volume Configuration File, Lnp_NVCF.MM.....................135
7.7 How to Save and Restore Continuous History.....................................................136
7.7.1 Prerequisites for Saving and Restoring Continuous History................................136
7.7.2 Procedure for Saving and Restoring Continuous History ....................................137
7.7.3 Restoring the HM Group Definition Files (APL) without the Continuous
History Data .........................................................................................................142
7.8 HM Backup Tool Option Using the AM..............................................................147
7.9 History Module Fragmentation ............................................................................148
SECTION 8 – ALARM MANAGEMENT ........................................................................ 151

8.0 Overview..............................................................................................................151
8.1 Introduction..........................................................................................................152
8.2 Release 500 Alarm Differences............................................................................153
8.2.1 Release 520 Alarm Enhancements .......................................................................157
8.3 Contact Cutout Basics ..........................................................................................158
8.4 Contact Cutout - R500 .........................................................................................160
8.5 Contact Cutout - Display Changes .......................................................................162
8.6 Contact Cutout - Functions for the HG, NIM, and AM .......................................167
8.7 Alarm Priorities and Alarm Actions.....................................................................175
8.8 PRIMMOD Alarm Groups...................................................................................179
8.8.1 Configure a PRIMMOD Point .............................................................................180
8.8.2 Link Points in the Alarm Group to the PRIMMOD.............................................182
8.8.3 Rules For Referencing the PRIMMOD Point ......................................................184
8.8.4 Retrieving Events for a PRIMMOD Group .........................................................186
8.8.5 Alarm Annunciation Using PRIMMOD Groups .................................................188
8.8.6 Using Multiple PRIMMODs for AM Alarms ......................................................189
8.8.7 Using Auxiliary Units ($AUXUNIT) ..................................................................190
8.8.8 Other R520 Alarm Enhancements........................................................................193
8.8.9 R610 Alarm Summary Enhancement...................................................................196
SECTION 9 – DATA ENTITY BUILDER OPERATIONS............................................... 199

9.0 Reserved...............................................................................................................199
SECTION 10 – NATIVE WINDOW SYSTEM PERFORMANCE DISPLAYS ................ 201

10.0 Overview..............................................................................................................201
10.1 Preface..................................................................................................................202
viii Engineer’s Reference Manual 11/2010

Table of Contents
10.2 How to Install the System Performance Displays ............................................... 203
10.2.1 Table of Current TLK1 Versions ........................................................................ 204
10.3 How to Call Up the System Performance Displays............................................. 206
10.4 The Displays and Their Content........................................................................ 207
10.5 How to Interpret the Information on the System Performance Displays............. 215
10.6 How to switch the clock source nodes without rebooting any LCN Nodes ........ 220
10.7 Use the Clock Display to Find Crossed LCN Cables .......................................... 226
10.8 Use the Channel Information Display to Monitor TPS/TPN Channel Activity .. 229
SECTION 11 – SCHEMATIC FILES .............................................................................. 233

11.0 Overview ............................................................................................................. 233
11.1 Picture Editor Tips............................................................................................... 234
SECTION 12 – CONTROL LANGUAGE FILES............................................................ 241

12.0 Overview ............................................................................................................. 241
12.1 File Handling Tips............................................................................................... 242
SECTION 13 – AREA DATABASE, CONTENT, AND USE ......................................... 245

13.0 Overview ............................................................................................................. 245
13.1 Database Composition......................................................................................... 246
13.2 Assigning Units to an Area.................................................................................. 248
13.3 Adding a New Volume or Directory to the Pathname Catalog ........................... 249
SECTION 14 – DATA BINDING IN THE TPS SYSTEM................................................ 253

14.0 Overview ............................................................................................................. 253
14.1 Binding of Unit, Area, and Console Names ........................................................ 257
14.2 Binding of NCF Data........................................................................................... 259
14.3 Binding of HM Local NVCF Data ...................................................................... 260
14.4 Binding of Entity Data in the Data Entity Builder............................................... 261
14.5 Binding of Schematic Data.................................................................................. 263
14.6 Binding of Data in CL Programs......................................................................... 264
14.7 Binding of Entities and Schematics into the Area Database ............................... 265
SECTION 15 – ACTORS AND PROCESS CONTROL................................................. 267

15.0 Overview ............................................................................................................. 267
15.1 Use of Actors....................................................................................................... 267
SECTION 16 – AM CONFIGURATION GUIDELINES .................................................. 269

16.0 Reserved .............................................................................................................. 269
SECTION 17 – DATA TO BE USED DURING CONFIGURATION .............................. 271

17.0 Overview ............................................................................................................. 271
17.1 Publications Defining Configuration Data .......................................................... 272
SECTION 18 – AVOIDING MISTAKES AND ERRORS................................................ 273

18.0 Overview ............................................................................................................. 273
18.1 Guidelines and Warnings .................................................................................... 273
SECTION 19 – GLOSSARY OF TPS CONFIGURATION TERMS ............................... 279

19.0 Overview ............................................................................................................. 279
19.1 Configuration Terms ........................................................................................... 279
11/2010 Engineer’s Reference Manual ix

Table of Contents
SECTION 20 – NODE LOADING AND NODE DUMPS ................................................ 285

20.0 Overview..............................................................................................................285
20.1 Node Loading Failures.........................................................................................286
20.2 Fast-Load Feature.................................................................................................289
20.2.1 Fast-Load Scenario...............................................................................................291
20.2.2 Fast-Load Implementation Considerations and Guidelines .................................293
20.2.3 Content and Maintenance of Fast-Load Cartridges..............................................296
20.2.4 How to Prepare or Update a Fast-Load Cartridge................................................299
20.3 Node Dumps ........................................................................................................308
20.3.1 Dump Failures......................................................................................................308
20.3.2 Save Error Blocks on Node Reload .....................................................................309
SECTION 21 – CHECKPOINTING ............................................................................... 313

21.0 Overview..............................................................................................................313
21.1 How to Configure for Checkpointing ..................................................................315
21.2 Checkpoint Functions...........................................................................................317
21.2.1 Demanding, Enabling, and Disabling Checkpoints..............................................317
21.2.2 Automatic Checkpointing ....................................................................................319
21.2.3 Levels of Automatic Checkpointing ....................................................................324
21.2.4 Checkpoint File Organization ..............................................................................327
21.3 Checkpoint Error Messages .................................................................................330
21.3.1 System Error Messages—Hiway Checkpoint ......................................................331
21.3.2 System Error Messages—UCN Auto Checkpoint ...............................................332
SECTION 22 – PROCESSOR STATUS DATA POINT ................................................ 333

22.0 Overview..............................................................................................................333
22.1 Purpose of Processor Status Data Points..............................................................334
22.2 PSDP Parameters in All Nodes ............................................................................335
22.3 Application Module PSDP Parameters ................................................................347
22.4 Computer Gateway PSDP Parameters .................................................................368
22.5 History Module PSDP Parameters .......................................................................373
22.6 Hiway Gateway PSDP Parameters.......................................................................377
22.7 Network Gateway PSDP Parameters ...................................................................388
22.8 Universal Station PSDP Parameters.....................................................................396
22.9 HM60 PSDP Parameters ......................................................................................423
22.10 Remote User Link Adapter (RULA) PSDP Parameters.......................................425
22.11 Network Interface Module PSDP Parameters .....................................................426
22.12 Application Processing Platform PSDP Parameters.............................................442
22.13 Global User Station PSDP Parameters.................................................................444
22.14 Unit Operations Data Point ..................................................................................445
22.15 Parameters On Every Point in the System............................................................446
SECTION 23 – CONFIGURING FOR PERFORMANCE .............................................. 453

23.0 Overview..............................................................................................................453
23.1 The Performance Cluster Concept .......................................................................454
23.1.2 Cluster Performance (68020-Based Processors) ..................................................457
23.2 The Honeywell Control Unit................................................................................460
23.3 Focused Load Concept.........................................................................................463
23.4 Factors that Affect System Performance..............................................................464
23.5 Estimating LCN Load on Your System ...............................................................466
23.6 System load calculation tool ................................................................................469
23.7 HM Performance Hints and Rules of Thumb.......................................................478
23.7.1 HM Utilization .....................................................................................................479
x Engineer’s Reference Manual 11/2010

Table of Contents
23.7.2 Continuous History Hints and Rules of Thumb .................................................. 480
23.7.3 Fast Search User Volume .................................................................................... 481
23.7.4 Directory Searches Hints and Rules of Thumb ................................................... 482
23.7.5 Event Journal Hints and Rules of Thumb............................................................ 484
SECTION 24 – NCF AND LCN STATUS DISPLAYS .................................................. 485

24.0 Reserved .............................................................................................................. 485
SECTION 25 – LCN RECONNECTION........................................................................ 487

25.0 Reserved .............................................................................................................. 487
SECTION 26 – LCN/DATA HIWAY HARDWARE COMPATIBILITY .......................... 489

26.0 Reserved .............................................................................................................. 489
SECTION 27 – HOW TO MOVE TO A NEW TPS RELEASE...................................... 491

27.0 Overview ............................................................................................................. 491
27.1 What is a Release?............................................................................................... 491
27.2 Upgrading Software ............................................................................................ 492
27.2.1 The Software Upgrade Process ........................................................................... 493
27.2.2 Preparation for a Software Upgrade .................................................................... 494
SECTION 28 – PURCHASED OPTIONS ..................................................................... 495

28.0 Overview ............................................................................................................. 495
28.1 Key File Options.................................................................................................. 497
28.1.1 AM Redundancy.................................................................................................. 498
28.1.2 HG Point Display Ranges.................................................................................... 500
28.1.3 Enhanced Trend Pens .......................................................................................... 502
28.1.4 HM Disk Redundancy ......................................................................................... 503
28.2 Hardware Options................................................................................................ 505
28.2.1 Application Module Hardware Upgrades............................................................ 507
28.2.2 Enhanced (68040) Computer Gateway................................................................ 509
28.2.3 Computer Gateway to Plant Network Module Upgrade..................................... 510
28.2.4 Programmable Logic Controller Gateway Upgrades........................................... 511
28.2.5 Enhanced (68040) Hiway Gateways ................................................................... 512
28.2.6 Universal Station and Workstation Upgrades ..................................................... 513
28.2.6.1 Cartridge Drive Upgrades.................................................................................... 514
28.2.6.2 Improved Display Screen Upgrades .................................................................... 515
28.2.6.3 Enhanced Processor or Memory Upgrades ......................................................... 516
28.2.6.4 Printer Enhancement Upgrades ........................................................................... 517
28.2.6.5 Touch Screen Upgrade ........................................................................................ 518
28.2.6.6 Keylock Switch Replacement Upgrade ............................................................... 519
28.2.6.7 Keyboard Addition Upgrades.............................................................................. 520
28.2.7 HM Upgrades ...................................................................................................... 521
28.2.8 Time-Sync Upgrades for Network Interface Module.......................................... 523
28.2.9 Precision Clock Sources ...................................................................................... 524
28.2.10 Process Manager to Advanced Process Manager Upgrades................................ 525
28.2.11 LCN Extender...................................................................................................... 526
28.2.12 Micro TDC 3000 Upgrades ................................................................................. 527
SECTION 29 – LCN CABLE DIAGNOSIS ................................................................... 529

29.0 Reserved .............................................................................................................. 529
11/2010 Engineer’s Reference Manual xi

Table of Contents
SECTION 30 – EVENT-INITIATED REPORTS—IMPLEMENTATION AND USE....... 531

30.0 Overview..............................................................................................................531
30.1 Implementation of Event-Initiated Reports ..........................................................532
30.1.1 Message-Source Considerations ..........................................................................533
30.1.2 Area Reports ........................................................................................................534
30.1.3 Event History Reports ..........................................................................................537
30.2 Operation of Event-Initiated Reports ...................................................................542
30.2.1 Error Handling .....................................................................................................543
SECTION 31 – CUSTOM SOFTWARE BACKPLANE AND GENERIC OVERLAYS .. 545

31.0 Overview..............................................................................................................545
31.1 Custom Software Installation ...............................................................................546
31.1.1 The NET>&CUS Directory .................................................................................547
31.1.2 Using the LCN Node Configuration Menu ..........................................................548
31.2 Generic Overlays..................................................................................................550
SECTION 32 – REPORT TO OUTPUT FILE ................................................................. 551

32.0 Overview..............................................................................................................551
32.1 Virtual Printer Assignments .................................................................................552
32.2 Setting Up a Configuration File ...........................................................................554
32.3 Sending Reports to a Virtual Printer File .............................................................556
32.4 Using File Descriptors to Identify Virtual Printer Files .......................................557
32.5 Displaying and Printing Reports ..........................................................................558
32.6 Status and Error Messages ...................................................................................559
32.7 Error Handling .....................................................................................................562
32.8 Purging and Protecting Virtual Printer Files ........................................................565
SECTION 33 – KEYBOARD BUTTON LED ASSIGNMENT AND CONTROL............. 567

33.0 Overview..............................................................................................................567
33.1 Implementation ....................................................................................................568
33.1.1 Message-Source Considerations ..........................................................................569
33.1.2 Button PRIMMOD Assignment...........................................................................570
33.1.3 Button LED Control.............................................................................................572
33.1.4 Error Handling .....................................................................................................574
SECTION 34 – LCN NODE VERSION REVISION LOGGING ...................................... 575

34.0 Overview..............................................................................................................575
34.1 General Functionality...........................................................................................576
34.2 Requirements........................................................................................................582
34.3 Installation Requirements.....................................................................................584
34.4 Initial (First Time) Installation .............................................................................586
34.5 Upgrade Installation .............................................................................................590
34.6 Operating the LCN Node Version/Revision Logging Function...........................592
34.7 Files Generated by the LCN Node Version/Revision Logging Function.............609
34.8 Error Conditions...................................................................................................617
34.9 Importing Report File into Spreadsheet ...............................................................620
xii Engineer’s Reference Manual 11/2010

Table of Contents
SECTION 35 – R530 TREND AND OPERATING DISPLAY FUNCTIONS .................. 621

35.0 Overview ............................................................................................................. 621
35.1 Configurable Access Levels on Parameters ........................................................ 622
35.2 One Key Call Up of Point Trend ......................................................................... 628
35.3 Save/Restore Trend Data ..................................................................................... 630
35.4 Detail Display Navigation ................................................................................... 636
35.5 SP/OP Tolerance Check ...................................................................................... 637
SECTION 36 – R610 PERIODIC PRE-DEFINED DOCUMENTATION TOOL

QUERY .................................................................................................... 639
36.0 Overview ............................................................................................................. 639
36.1 Implementation.................................................................................................... 640
36.2 Periodic Pre-Defined Query Scenarios................................................................ 646
SECTION 37 – R660 FINDING POINT INTERCONNECTIONS .................................. 649

37.0 Overview ............................................................................................................. 649
37.1 Implementation.................................................................................................... 650
37.2 Operation ............................................................................................................. 654
11/2010 Engineer’s Reference Manual xiii

Table of Contents
Figures
Figure 1-1 Representative TPS Hardware ...............................................................................22
Figure 7-1 Reducing Data Owner Load...................................................................................77
Figure 7-2 Continuous History Structure.ii.Snapshots and User Averages .............................84
Figure 7-3 Area Volume Size Estimator Chart ......................................................................117
Figure 7-4 AM Checkpoint Volume Size Estimator Chart ....................................................118
Figure 7-5 NIM/PM Checkpoint Volume Size Estimator Chart............................................119
Figure 7-6 NIM Checkpoint Volume Size Estimator Chart, 1 NIM......................................120
Figure 7-7 NIM/LM Checkpoint Volume Size Estimator Chart, 1 to 32 LMs ......................121
Figure 7-8 NIM/APM Checkpoint Volume Size Estimator Chart.........................................122
Figure 7-9 Continuous History Vol. Size, Example 1 ...........................................................123
Figure 7-10 Continuous History Vol. Size, Example 2 ...........................................................124
Figure 7-11 Journal Volume Size Chart, Example 1 ...............................................................125
Figure 7-12 Journal Volume Size Chart, Example 2 ...............................................................126
Figure 7-13 Physical Arrangement of Redundant Disk Drives ...............................................128
Figure 8-1 Primary Module Point Example ...........................................................................181
Figure 8-2 PRIMMOD Parameter in PED.............................................................................182
Figure 8-3 Point Detail Display with PRIMMOD Parameter ................................................183
Figure 8-4 Event History Retrieval by PRIMMOD...............................................................186
Figure 8-5 Example of PRIMMOD Event History ................................................................187
Figure 8-6 PRIMMOD Alarm Annunciation.........................................................................188
Figure 10-1 Parameter-access load values relationships..........................................................218
Figure 11-1 Picture Editor File Relationships..........................................................................235
Figure 13-1 Unit Assignment Picks and Unit Annunciator Picks............................................248
Figure 14-1 Quick Reference Matrix of the Effects of Data Changes .....................................255
Figure 14-2 Configuration Sequences and Data Relationships................................................256
Figure 31-1 LCN Node Configuration Menu ..........................................................................548
Figure 34-1 LCN Node Version/Revision Logging Display ...................................................592
Figure 34-2 LCN Node Version/Revision Logging Display (with Enter Site ID data entry
port) ..................................................................................................................593
Figure 34-3 LCN Node Version/Revision Logging Display (with Site ID) ............................594
Figure 34-4 LCN Node Version/Revision Logging Display (with Enter LCN ID data
entry port) .........................................................................................................595
Figure 34-5 LCN Node Version/Revision Logging Display (with LCN ID) ..........................596
Figure 34-6 LCN Node Version/Revision Logging Display (with Report Generation
Status) ...............................................................................................................600
Figure 34-7 LCN Node Version/Revision Logging Display (with Report Generation In
Progress) ...........................................................................................................601
Figure 34-8 LCN Node Version/Revision Logging Display (with Report Generation
Complete or Failure).........................................................................................602
Figure 34-9 Generated Report - Leftmost 80 Characters.........................................................603
Figure 34-10 Generated Report - Rightmost 80 Characters.......................................................604
Figure 34-11 LCN Node Version/Revision Logging Display (Printer Number data entry
port) ..................................................................................................................606
Figure 34-12 LCN Node Version/Revision Logging Display (Printer Number in the ..............607
Figure 34-13 LCN Node Version/Revision Logging Display (with a failure status) ................617
Figure 35-1 System Wide Value, Console Data Selection ......................................................625
Figure 35-2 System Wide Values, NCF Console Data PAGE 5 with Configurable Access
Level on Parameters Information .....................................................................626
Figure 35-3 Saved Trend Data File..........................................................................................631
Figure 35-4 Connection Page in Detail Display with Connection ...........................................636
Figure 37-1 $INTRCON Schematic ........................................................................................654
xiv Engineer’s Reference Manual 11/2010

Table of Contents
Tables
Table 1-1 Displays and Functions Accessed through Targets and Keys ............................... 23
Table 2-1 System Volumes .................................................................................................... 37
Table 2-2 Abbreviations ........................................................................................................ 38
Table 2-3 Suffixes.................................................................................................................. 41
Table 5-1 Format of Printer Failover Text File...................................................................... 57
Table 7-1 HM Data Types ..................................................................................................... 70
Table 7-2 Rates at which Snapshots (SS) are Collected ........................................................ 82
Table 7-3 Estimated Number of Cartridges to Fill an HM .................................................... 90
Table 7-4 Tables Used to Estimate HM Volume Size ........................................................... 93
Table 7-5 List of Volume-Size Charts in Section 7 ............................................................... 94
Table 7-6 Summary of Variable Data used in Example......................................................... 95
Table 7-7 Example Memory Required vs. Drive Capacity.................................................... 95
Table 7-8 Picks on Volume Configuration Menu.................................................................. 96
Table 7-9 HM Volume Size Estimator................................................................................... 98
Table 7-10 HM User Volume or Directory Size Estimator ................................................... 108
Table 7-11 IDF Volume or Directory Size Estimator ............................................................ 109
Table 7-12 Example—Small System, One Area, One Cluster............................................... 110
Table 7-13 Example—IDF Volume Estimate (approximately 5 HCUs) ............................... 112
Table 7-14 Example—User Volumes, Small System, One Cluster, One Dual HM .............. 113
Table 7-15 Value Sources for Volume Configuration ........................................................... 114
Table 7-16 Disk Drive Options.............................................................................................. 130
Table 7-17 NCF Configuration Items That Can’t Be Changed ............................................. 136
Table 7-18 Saving and Restoring Continuous History .......................................................... 137
Table 7-19 Restoring HM Group Configuration without History ......................................... 142
Table 7-20 Preparing to Overcoming History Module Fragmentation .................................. 148
Table 7-21 Procedure for Overcoming HM Fragmentation................................................... 149
Table 8-1 New Functionality Table ..................................................................................... 152
Table 8-2 Contact Cutout Changes in R500 ........................................................................ 159
Table 8-3 Contact Cutout Scenario Overview ..................................................................... 163
Table 8-4 Contact Cutout Alarm Summary Display Changes ............................................. 164
Table 8-5 HG Contact Cutout Functionality........................................................................ 172
Table 8-6 NIM Contact Cutout Functionality...................................................................... 173
Table 8-7 AM Contact Cutout Functionality ....................................................................... 174
Table 8-8 Alarm Priority Choices........................................................................................ 175
Table 8-9 Alarm Priority XXXXPR (E ALPRIOR) ............................................................ 175
Table 8-10 Alarm Enable State ALENBST (E ALENBST) .................................................. 176
Table 10-1 Procedures for Installing and Using the Displays ............................................... 202
Table 10-2 Procedure to Call Up a Performance Display...................................................... 206
Table 10-3 Node-Related Displays ........................................................................................ 211
Table 10-4 Quick Trend Display ........................................................................................... 212
Table 10-5 Processor Free-Time Display .............................................................................. 212
Table 10-6 Heap Displays...................................................................................................... 213
Table 10-7 Checkpoint Time and Interval Display................................................................ 213
Table 10-8 Box/Slot Verification Display ............................................................................. 213
Table 10-9 Clock (CLOCKSTAT) Displays ......................................................................... 214
Table 10-10 Memory-Use Values............................................................................................ 216
Table 10-11 Processor Load Indicator..................................................................................... 216
Table 10-12 Memory-Use Values............................................................................................ 217
Table 10-13 Procedure to switch the Clock Source Nodes...................................................... 221
Table 10-14 Procedure to switch the Clock Master and Slave ................................................ 223
Table 10-15 Procedure to switch when there is no Master node in the network ..................... 224
Table 10-16 Status of the nodes when booted/shut down when NCF is not synchronized ..... 225
Table 10-17 Checking Procedure for Crossed LCN Cables .................................................... 227
Table 10-18 Displaying Channel Information for a Node ....................................................... 230
11/2010 Engineer’s Reference Manual xv

Table of Contents
Table 10-19 CHANINFO Display Definitions.........................................................................231

Table 11-1 Color Priority .......................................................................................................236
Table 11-2 Common Abbreviations .......................................................................................238
Table 13-1 Displays Available ...............................................................................................249
Table 13-2 Methods of Accessing a Volume or Directory.....................................................250
Table 13-3 Procedure for Copying Files to an HM ................................................................250
Table 13-4 Adding a Pathname to an HM or to a Cartridge...................................................251
Table 13-5 Making an Area Change.......................................................................................252
Table 14-1 Summary of Data Binding in the TPS System .....................................................254
Table 14-2 Detailed Matrix of NCF Data Binding Relationships ..........................................259
Table 14-3 Detailed Matrix of NVCF Data Binding Relationships .......................................260
Table 14-4 Detailed Matrix of DEB Data Binding Relationships ..........................................261
Table 14-5 Detailed Matrix of NCF Schematic Data Binding Relationships.........................263
Table 14-6 Detailed Matrix of NCF CL Data Binding Relationships ....................................264
Table 14-7 Detailed Matrix of Area Data Binding Relationships ..........................................265
Table 18-1 Database Loading and Checkpointing Rules .......................................................274
Table 18-2 Procedure Used When Moving the System Volume (&ASY) .............................275
Table 20-1 Interpreting Cause of Node ..................................................................................287
Table 20-2 Clearing a LOAD FAIL (from the System Status Display) .................................287
Table 20-3 Clearing a LOAD FAIL message (from the Console, Process Network Node,
or Device Node Status Displays)......................................................................288
Table 20-4 Loading a US from Itself......................................................................................291
Table 20-5 Stages of the Cartridge Fast-Load Scenario .........................................................292
Table 20-6 Display Abstracts Loaded First ............................................................................293
Table 30-1 $AREA and $CONS Information ........................................................................534
Table 30-2 The Item Parameter ..............................................................................................537
Table 30-3 Date and Time Parameter .....................................................................................538
Table 31-1 Installation Steps ..................................................................................................546
Table 31-2 Custom Software vs. Generic Overlay Differences .............................................550
Table 31-3 Procedure to Incorporate a New Generic Overlay ...............................................550
Table 32-1 Virtual Printer Assignment One Area Example ...................................................553
Table 32-2 Virtual Printer Assignment Two Area Example ..................................................553
Table 32-3 VP CONFIG Error Messages...............................................................................561
Table 32-4 SYStem Error Handling Process ..........................................................................562
Table 32-5 USER Error Handling Process .............................................................................563
Table 32-6 SEVERE Status Handling Procedure...................................................................563
Table 34-1 LCN Node, Board Description Header Record....................................................578
Table 34-2 Data Hiway Box, Card Description Header Record.............................................579
Table 34-3 UCN Node, Card Description Header Record .....................................................579
Table 34-4 LCN Nodes Reported...........................................................................................580
Table 34-5 Data Hiway Boxes Reported ................................................................................581
Table 34-6 UCN Nodes Reported ..........................................................................................581
Table 34-7 Dedicated Custom Global DDB Indices ..............................................................583
Table 34-8 Find a Directory ...................................................................................................585
Table 34-9 Universal Station Configuration ..........................................................................587
Table 34-10 Loading the Node.................................................................................................591
Table 34-11 Call Up LCN Node Version/Revision Logging Display......................................592
Table 34-12 Open Site ID Data Entry Port...............................................................................593
Table 34-13 Open LCN ID Data Entry Port.............................................................................595
Table 34-14 LCN Node Version/Revision Logging Display ...................................................619
Table 37-1 Modifying the NCF ..............................................................................................650
xvi Engineer’s Reference Manual 11/2010

Section 1 – Engineer’s Reference Manual Summary
1.0 Overview
Introduction This section introduces you to this publication and summarizes the
content of its remaining sections.
References Detailed actions and procedures are described in other publications

and we assume that you have had some exposure to the TotalPlant
Solution (TPS) System concepts.
For overviews and summaries of the implementation processes:

• see System Overview, or
• see Implementation Overview, or
• see Configuration Data Collection Guide.
Supplement to other This publication supplements the detailed publications and is

publications intended to help you to:
PLAN AHEAD! PLAN AHEAD! PLAN AHEAD! PLAN AHEAD!
by showing interactions and relationships in the engineering activities
and the system, and the effects of configuration or configuration
changes.
Start by making a complete backup set of all disks provided with the
system. Refer to Section 2 for use of the Create Volume and FCOPY
commands that are used to do this.
System Software System software is delivered on disks or CD-ROMs. See System

Startup Guide-CD-ROM when using a GUS.
11/2010 Engineer’s Reference Manual 17

1.0 Overview, Continued
Relationship to other For startup information, refer to the System Startup Guide.
publications
For engineers who are implementing a new LCN-based system, this
publication is keyed to the startup guide by a “[TASK nn]” identifier
on several of its headings. These system startup tasks are identified
in the table of contents of the startup guide.
This publication also is directed to engineers who are redesigning and

reconfiguring LCN-based TPS systems.
18 Engineer’s Reference Manual 11/2010

1.1 Things to Decide Before Configuring or
Reconfiguring
Where to begin Before configuring or reconfiguring your system, refer to Section 14

on data binding and consider which configuration changes can be
made on-line after an NCF has been installed and is in use. You may
want to defer some inconvenient tasks to another time.
Understand concepts You should understand the following concepts:

• Organization of the plant into units and areas.
• Area assignments to consoles.
• Number and sizes of HM user volumes and directories (refer to
Section 2 and Section 7).
• Naming and numbering conventions.
Naming and For naming and numbering conventions, consult these references.
numbering
conventions
• For Units, Areas, and Consoles, see Network Form Instructions.
• For HM User Volumes, see Section 7 of this publication.
• For Logs, Groups, and Overview Displays, see Area Form
Instructions.
Parameter information Each major TPS device has an appropriate parameter reference
dictionary. For specific parameter information:
• see Hiway Gateway Parameter Reference Dictionary, or
• see PM Family Parameter Reference Dictionary, or
• see Computer Gateway Parameter Reference Dictionary, or
• see Logic Manager Parameter Reference Dictionary, or
• see Programmable Logic Controller Gateway Parameter Reference
Dictionary.

1.1 Things to Decide Before Configuring or Reconfiguring,
Continued
File conventions Consult these references for file and custom data segment
conventions.
• For IDFs (entity files) and Exception Build Files, see the Data
Entity Builder Manual.
• For Subpicture and Schematic Files, see the Picture Editor Data
Entry.
• For CL Program Source Files and Custom Data Segments:
– see Control Language/Multifunction Controller Data Entry, or
– see Control Language/Application Module Data Entry, or
– see Control Language/Process Manager Data Entry, or
– see Control Language/Advanced Process Manager Data Entry.
Recommended We recommend (and assume) that for your work you will use a
hardware and Universal Station or a Universal Workstation loaded with the
personality
Universal Personality. This Universal Personality software contains
both Engineering functions and the Operator functions.
Your Universal Station should also have two drives and a printer
connected directly to the US.
Why this This arrangement provides disk operations that are faster than if the
arrangement? drive is connected to another US in the console, and it enables screen
printing.
You can also switch quickly from Engineering functions to the

Operator functions to see the results of your work as you enter data
and load it in the nodes.
Load another US with So you can see the results of your work, it’s helpful to have another
Operator Personality US in the same console loaded with the Operator Personality
functions
functions.

Continued
Conceptual Figure 1-1 shows the conceptual organization of the hardware on a

organization TPS system. The following are special items to be noted from this
diagram:
• A process area is a portion of the process plant normally controlled
by one operator.
• A process unit is a specific section of the plant (such as a boiler,
furnace, or blender).
• A console is a logical collection of Universal Stations and their
associated peripherals for use by one operator. A console is
associated with one process area, and the area database configured
for that area is to be loaded into each US in the console when the
USs are loaded.
• Peripherals on a console are physically connected to only one
Universal Station; however, they are generally available for use by
other Universal Stations within the console, provided the Universal
Station to which they are connected is operating on the LCN.
• Mass-storage access—The LCN is connected into the HM, not
directly to the Winchester drives. Access to the Winchester disks
by the LCN is possible only when the HM is operating on the LCN.

Continued
Figure 1-1 Representative TPS Hardware

Console
CM
AM HM
CG
HG HG NIM NIM
Logic
Process-Connected Managers Process
Boxes Managers
Data Hiway Universal Control

Network
1223
1.2 Preferred Hardware Configuration
Refer to Section 23—Configuration for Performance.

1.3 Universal Personality and Operator Personality
The meaning of In the Universal Station, we refer to the Universal Personality and the
“Personality” in this Operator Personality. For Universal Stations (USs) and Universal
manual Work Stations (UWSs) operating on the Universal Personality (UP),
these mentions mean the portion of the Universal Personality that
contains all Engineering functions and all Operator functions. The
Operator Personality refers only to the Operator functions in the USs
and UWSs.
Differences between The Engineering functions are those that are activated by targets
functions (called “picks”) on the Engineering Main Menu. Most other
functions are Operator functions, however, there are several displays
and functions that are shared by both the Engineering functions and
the Operator functions. NOTE: For R500 there is no separate
Engineering Personality to load; Engineering functions are included
with Operator functions in the Universal Personality.
Access through These are the displays and functions that are accessed through the
targets and keys following targets or keys:
Table 1-1 Displays and Functions Accessed through Targets and

Keys
Engineering Main Menu Targets Operator Keyboard Keys
SYSTEM STATUS SYST STATS
SYSTEM MENU SYST MENU
CONSOLE STATUS CONS STSTS
Calling functions in At a US running the Universal Personality, to call up the Engineering

the Universal Main Menu from any display, hold CTL and press HELP (MENU).
Personality In some Engineering functions activities, you may need to do this
twice, either because of a prompter that warns you about possible loss
of data, or because you have to go through a lower-level menu to get
to the main menu. To go to an Operator function from an
Engineering functions activity, first return to the Engineering Main
Menu.
Memory requirement 6Mw of memory are required in USs functions and UWSs that are to
for Universal operate using the Universal Personality.
Personality

1.4 Section Summaries
Introduction The following are summaries of the content of each of the other
sections in this manual:
Section 2—File The file system stores software and data on disks and History
System Operations Modules (HMs). This section defines the file system concepts and
describes the most-often used Utilities commands.
Section 3—The &ASY Describes the special characteristics of system directory &ASY,
Directory and its which contains the basic description files required for the startup of
Special
Characteristics
each node, including the network configuration file (NCF.CF). You
need to know about these characteristics so that you can avoid
problems related to this directory or recover from them.
Section 4—Area and Describes the special characteristics of the area database directory
Standard Abstract and the abstract directories that define the appearance and content of
Directories
the displays in the operator's personality.
Section 5—Console Explains how a console is defined, defines special characteristics of

Organization the devices that can be connected to a Universal Station, and provides
some tips for optimum console performance and convenience.
Section 6—Network Describes the special characteristics of the Network Configuration

Configuration File File. This file contains network information that is vital for the
operation of all nodes on the LCN. The content of the NCF is
defined, as are its use in node startup. Also see Section 3—it
discusses directory &ASY, the directory that contains the NCF.
Section 7—HM Defines the requirements for configuring and starting up an HM. It
Volume Configuration also provides guidelines for use of HM storage space and for
and Initialization
estimating the size of the volumes assigned to each.
Section 8—Reserved In earlier versions of this manual, this section contained Hiway, Box,
and Slot Configuration Guidelines. For this information, you must
refer to Hiway Gateway Implementation Guidelines. This section has
been retained to direct users familiar with an earlier version of this
manual to the new location of the information and to preserve the
validity of references to other sections of this manual.

1.4 Section Summaries, Continued
Section 9—Reserved Data Entity Builder Operations—In earlier versions of this manual,
this section contained guidelines for Data Entity Builder operations.
Now you must refer to the Data Entity Builder Manual. This section
has been retained to direct users familiar with an earlier version of
this manual to the new location of the information and to preserve the
Section 10—System Explains how to monitor and evaluate system performance through
Performance Displays access to the System Performance Displays. Help in interpreting the
displays is included to aid in diagnosing the cause of the problem.
Section 11—Picture Provides tips for the use of the Picture Editor to build custom
Editor and Custom (schematic) displays.
Displays
Section 12—Control Provides tips and precautions for the use and handling of the data and
Language (CL) files used in compiling, linking, and loading CL programs.
Section 13—Area Describes the content of the area database and how the area for a
Database, Content, console is established. It also points out that changes to the area
and Use
database actually take place in a US only when the database is loaded
into that US. The relationship of the Engineering functions Unit
Assignment display to the operator's personality's alarm summary and
annunciator displays is defined.
Section 14—Data Introduces the concept of data binding and it describes the
Binding in the consequences of that binding. The effect of data binding on
TPS System
configuration and reconfiguration of the system is also discussed.
Section 15—Actors Advises that actors are not to be used for actions that are involved in
and Process Control process control.
Section 16—Reserved In earlier versions of this manual, this section contained AM

Configuration Guidelines. For this information, you must refer to
the Application Module Implementation Guidelines. This section has
been retained to direct users familiar with an earlier version of this
manual to the new location of the information and to preserve the

Section 17—Data to Relates the types of configuration data to the publications that define
be Used During each type of data and to the configuration forms used to record each
Configuration type of data.
Section 18—Avoiding Contains a collection of the significant guidelines, precautions, and

Mistakes and Errors warnings that appear in this and other publications. If you review this
section from time to time, and implement its content, you should
experience a minimal amount of rework and error correction.
Section 19—Glossary Summarizes the terms related to the configuration process. You can
of TPS Configuration also refer to the System Overview for a more extensive glossary.
Terms
Section 20—Node Provides guidelines for recovering from the failure of a node to load
Loading Guidelines properly with software and data.
Section 21— Describes how you can configure your system for automatic
Automatic checkpointing for NIMs, HGs, AMs, and CGs, how automatic
Checkpointing checkpointing functions, and what happens if an error occurs.
Section 22— Defines processor-status data points (PSDPs), discusses their use, and
Processor Status Data lists each PSDP parameter with its definition.
Point
Section 23— Defines two items that are the basis for system performance
Configuring for measurements and system integrity. These items are the
Performance performance cluster concept and the Honeywell control unit (HCU).
Guidelines for configuring LCN-based equipment for predictable
performance and for estimating AM performance are provided.
Section 24—Reserved In earlier versions of this manual, this section provided information
about displays that provided information about NCF and LCN
status. For this information, you must refer to LCN Guidelines -
Implementation, Troubleshooting, and Service. This section has been
retained to direct users to the new information.

about LCN reconnection. For this information, you must refer to
LCN Guidelines - Implementation, Troubleshooting, and Service.
This section has been retained to direct users to the new information.
about displays that provided information about NCF and LCN
status. For this information, you must refer to Hiway Gateway
Implementation Guidelines. This section has been retained to direct
users to the new information.
Section 27—How to This section defines a software release and provides general
Move to a New guidelines for upgrading to a new software release.
TPS Release
Section 28— This section describes system options available for purchase and
Purchased Options provides guidance and references for the implementation of the
options.
about diagnosing LCN cable problems. For that information, refer
to LCN Guidelines - Implementation, Troubleshooting, and Service.
Section 30—Event- This section provides information about the implementation and use
Initiated Reports— of printed reports whose printing is initiated by user-defined events.
Implementation and
Use
Section 31—Custom The Custom Software Backplane is a provision that allows the
Software Backplane addition of optional, standard, and custom software modules to a
and Generic Overlay
node without modifying the node’s original personality software.
Generic Overlays enable table-driven generation of pictures and CL
sequences based on equipment lists and a generic source. This
function enhances the system’s effectiveness and friendliness for
batch applications, and provides a useful tool for any application.
Section 32—Report to Reports can be sent to an electronic file that is a “virtual printer” to
Output File the TPS system. The user selects the number of the “printer” the data
should go to by submitting a normal printer request.

Section 33—Keyboard This section describes the implementation and use of CL messages to
Button LED assign primmod values to buttons and control the LEDs on specified
Assignment and
Control
LED buttons associated with any of the 40 configurable LED buttons
to be dynamically changed for the local Universal Station.
Section 34—LCN Node The LCN Node Version/Revision Logging function is a software
Version/Revision application package that operates on Universal Stations of the
Logging function
Honeywell TPS system. This function is a TPS “backplane”
extension of the Universal Station Operator personality and Universal
personality and is packaged as an External Load Module. The
function is a display initiated version/revision report generator.
Section 35—R530 The following R530 functions are included in this section:
Trend and Operating
Display functions
• Configurable Access Level of Parameters - Access level is
configured in the NCF for alarm limits, control limits, range limits,
and tuning parameters on the Point Detail Display.
• One Key Call Up of a Point Trend - A custom trend can be invoked
by pressing the TREND key after selecting a point from a standard
display.
• Save Trend Data - Two new actors are provided to save and restore
custom schematic trend data.
• Detail Navigation - On pages of the Detail Display which contain
input, output, and control connections, targets are added over any
point names that are displayed.
• SP/OP Tolerance Check - Manually entered SP and OP values for
AM, HG, and NIM regulatory control points and OP values for HG
and NIM analog output points are checked against a specified
magnitude of change tolerance.

Section 36— R610 This function provides the ability to initiate and cancel pre-defined
Periodic Pre-Defined Documentation Tool queries through CL or scheduled ECs and have
Documentation Tool
Query
the query results automatically sent to a file or printer.
Refer to Command Processor Operation for a discussion of

Documentation Tool Query commands.
Section 37— R660 This section describes the implementation and use of the Finding
Finding Point Point Interconnections function that can be initiated by operators to
Interconnections
Function
search for point interconnections in specified AM, UCN, and HG
checkpoints.

Section 2 – File System Operations
2.0 Overview
Description The file system stores software and data on disks and History
Modules (HMs).
This section defines the file system concepts and describes the most-
often used Utilities commands.

2.1 File System Pathnames
File usage Data in the system is collected into named files that are stored in
named volumes and directories on History Modules and on
removable media (disks).
The information in these files is transferred to memory in the nodes

on the LCN as it is needed.
Pathname format Access to the files is through a pathname that consists of a device
identifier, a volume or directory name, and a file name. The
pathname format is:
device>vdir>file
Where “>” is a delimiter that marks the boundary between the
pathname files and:
• device = the device name or physical-node identifier
(for example, $F3, NET, or PN:13)
• vdir = the volume or directory name (1 to 4 characters, e.g.,
&ASY)
• file = (1- to 8-character name) (2-character suffix) (for example,
PMREG.EB)

2.1.1 Pathname Rules
Introduction Follow these rules while using and constructing pathnames.
Drive identification Drives are referred to by their logical-device ID (LDID), which is

established during network configuration.
The LDID has the form $Fn, where “n” is a number from 1 through
20.
NET defined NET is the device name for any volume that is stored in an HM.
Only the HM with the named volume or directory responds.
Volume and directory The device can be indicated by a physical-node identifier in the form:
usage
PN:nn
Where nn is the node number established during network
configuration. The number “nn” can be the node number of an HM, or
of a US with a drive.
The US must be in the same console, not in another console and must
contain the removable medium whose name is in the “vdir” field.
The PN:nn form must be used to access an HM that is running its
initialization personality (&HMI).
Volume and directory Volume and directory names identify one of several partitions on a
names Winchester disk in an HM.
HMs can have several volumes, each of which can have up to 63
directories. Each disk has one volume, and each can have up to 63
directories. NOTE: Backup and restore operations allow you up to
2046 directories on a disk by using an extended directory (-X) option,
which is described in the section, 6.4 Create Volume, in the
Command Processor Operation manual, and section, 7.7.5 Prepare
Removable Media for Data Storage, in this document.

2.1.1 Pathname Rules, Continued
Volume and directory Each volume name and each directory name is unique. A given
hierarchy volume or directory name can exist only once in all of the HMs on an
LCN.
There is an exception—each HM has a Local Volume that is never
accessed by the device name NET. The Local Volume is accessed
through a PN:nn physical-node identifier.
Directories are subdivisions of volumes. Files can be associated with
volumes or with directories, but you can't access a file that is
associated with a directory by using its volume name—use the
directory name.

2.2 Access to Volumes and Directories
Introduction While directories are subdivisions of volumes, pathnames can include

either a volume name or a directory name in the volume/directory
field.
Example
In the following pathname: NET>VDIR>FILE.XX
the VIDR field must contain either the name of a volume in an HM on
the network (LCN) or the name of a directory in a volume on the
network. If the file is in a directory, the system can find it through the
directory name only, it doesn’t need the volume name.
In this example, assuming Volume

volume USER is a volume on USER
an HM, file USER2.XY can be
found through this pathname: USER1.XX
NET>USER>USER2.XY USER2.XY
Directory
And file AMCL.ZY can be PMPT
found through this pathname: Directory
NET>AMPT>AMCL.ZY AMPT
PMREG.EB
PMDIGIN.EB
AMREG.EB
But file AMCL.ZY cannot be AMCL.ZY
found through this pathname:
NET>USER>AMCL.ZY
3695

2.3 System Volumes and User Volumes
Description Table 2-1 lists the system volumes provided by Honeywell and the
directories those volumes contain. The “&” or “!” which begin all
system volume names are the ampersand and exclamation point.
When spoken, “&” is called the “and” character and “!” is called the
“bang” character.
All volume and directory names are unique in an LCN. Some volume
and directory names represent specific node pairs (“np” in Table 2-1)
or specific unit numbers (“un” in Table 2-1). Each volume and
directory exists only once in any HM. You can locate each volume
and its directories in any HM, but only one instance of each can exist
on the LCN. Volumes and directories are assigned to specific HM
node pairs in the Volume Configuration activity of Network
Configuration.
User volumes and user directories can have unique names that are 4-
characters or less and that do not begin with “&” or “!”. It is helpful
if you use names that convey some meaning. For example, you might
give the name PNTS to a user volume that contains point-building
information. You might name a directory in that volume AMPT to
indicate that it contains AM points.

2.3 System Volumes and User Volumes, Continued
System Volumes and System Volume names, their Directories, and the use of the volumes
Directories are listed in Table 2-1.
Table 2-1 System Volumes and Directories

Volume Directories Volume Use
&0np &ASY, &DSY, &KJF, &KFO, &LDR, & AMG, System Files
&ARG, &HGG, &NMG
&1np &OPR, &HGO, &AMO, &CIO, &NMO, &UNP, Personality load images
&OP1
&2np &AMD, &CGD, &HGD, &HMD, &MND, &OPD, Dump volume
&PMD
&3np &Dan (10) (Note 1) Area database
&4np &Ehn (20) (Notes 1 and 2) CL/MC object volume
&5np &Fun (100), &Znn (20) (Note 1) AM checkpoint
&6np &Hun (100), &Znn (20) (Note 1) CG checkpoint
&7np &Ihn (20) (Notes 1 and 3) HG checkpoint
&8np &Ihn (20) (Notes 1 and 3) NIM/PM/LM checkpoints
&9np &Ehn (20) (Notes 1 and 2) CL/PM Sequences, LM Ladder logic
!0np !Aun (100) (Notes 1 and 4) Continuous history, vol. 1
!1np !Aun (100) (Notes 1 and 4) Continuous history, vol. 2
!2np !CSY, Cun (100) (Note 1) Journal manager, journals
!4np !ESY On-proc, analysis, maint. support
!9np (20) (Note 1) HM local volume (Note 5)
Key:
np = HM node pair number an = area number un = unit number
hn = hiway number/UCN number nn = node number
Note 1: The numbers in parentheses indicate the maximum number of each type of directory per system. Each
volume can have no more than 63 directories of any type.
Note 2: The total number of &Ehn directories cannot exceed 20.
Note 3: The total number of &Ihn directories cannot exceed 20.
Note 4: The total number of &Aun directories cannot exceed 100.
Note 5: The HM personality images are not in volume &1np. They are &HMI (initialization personality) and
&HMO (on-line personality), which are provided on disks and are copied to each HM's Local Volume
(!9np). &HMI and &HMO do not exist as directories on the LCN. Only HMs use &HMI and &HMO
and only out of their own Local Volume, not across the LCN.

2.4 Typical File System Utility Commands
Introduction File-system utility commands that are often used during configuration
and startup are described below. See Command Processor Operation
for complete details.
Abbreviations The following abbreviations are used in the command examples

below:
Table 2-2 Abbreviations

Abbrev. Command
dev Disk LDID ($F1), “NET” for an on-process HM, “PN:nn” for an
HM running its initialization personality.
volm volume name (&01)
dir directory name (&ASY)
vdr volume or directory name (&01 or &ASY)
file file name and suffix (NCF.CF)
-D option: For LS command; omit list of files, list volume and
directory information only. For other commands; give the
details of the operation.
*.* do all files/all suffixes in this operation
= use the same file name for the destination-file name
Format a disk To format a disk give it a volume name and specify it will hold “x”
files
CR dev>volm> -F -MF x
Initialize a disk To initialize a disk while retaining its existing format omit the “-F”
option in the Create Volume command. Any data on the disk is
deleted.
List volumes and To list the volumes and directories in all HMs…
directories
LV NET
List files on a disk or To list files on a disk or HM…

HM
LS dev>vdr>*.*

2.4 Typical File System Utility Commands, Continued
List files if names are The files on a disk can be listed even if you don't know the volume
not known name…
LS dev>>
Copy files To copy all files from vdr1 to vdr2…

CP dev>vdr1>*.* dev>vdr2>=
To copy “filename.xx” and rename it “filname2.xx” from vdr1 to

vdr2…
CP dev>vdr1>filename.xx dev>vdr2>filname2
When copied or renamed, files retain the same suffix; therefore, when
renaming or copying files, you can't specify a suffix for the
destination file.
Delete a file To delete “filename.xx”…

DL dev>vdr>filename.xx -D
Copy a complete disk To copy a complete disk for backup purposes (including volume
name and boot record if any)…
FCOPY $Fs $Fd
Where s is the source drive number and d is the destination drive

number.
The copy takes from several seconds to a few minutes. The
destination disk must have been formatted with any name.
Honeywell recommends that you have two backup copies. Use
FCOPY to copy each cartridge to another cartridge. This will catch
any directory structure problems on the first copy.
Back up files To back up the (non-history and non-journal) content of an HM on

disks…
BACKUP PN:nn $F1
Restore files To restore a volume on an HM from disks…

RESTORE $F1 PN:nn
or
RESTORE $F1 NET>VOL

2.5 File Names and Suffixes
Introduction There are restrictions to how file names are used and the suffixes that
are attached to them. Those rules and pre-assigned suffixes are listed
in the sections that follow.
Rules Follow these rules when constructing file names:

• File names consist of one to eight alphanumeric characters. An
under bar (“_”) can be included, but no spaces. Each file name has
a 2-character suffix that identifies the type of data in the file (in
some cases, the system can assume the suffix and it's not necessary
to include it in the file name).
• The file-name suffix restricts the use of a file to the functions that
know the content and structure of the file.
• When the Utilities Copy command is used to copy a file, the
original suffix is retained.
• When you use the Utilities' Create command to format a disk the
medium is also initialized. This erases any data that may have been
stored on the medium and establishes its volume name. Directories
are then established with the Create Directory command.
• A disk that has already been formatted can be initialized (erased
and renamed) without changing its format. To do this, omit the -F
option in the command line for the Create Volume command.

2.5.1 File Name Suffixes (Extensions)
Introduction During system implementation, you will work with standard system
files that follow certain file-type standards. File types are identified
by the file-name suffix.
Example In the file name: MGPNTS.DB “DB” is the suffix that identifies this
file type as an intermediate data file (IDF) used in entity building.
Use of suffixes The following is an alphabetical list of suffixes and file types:
Table 2-3 Suffixes
Suffix File Type
— Temporary File
AG Error Aggregate
AM Noncyclic Archive Data
AO AM/CL Object
BH Batch History
BO Boot File
BU Text Editor Backup File
BR Background Results
CF Configuration File
CL CL Source
CM Journal File
CO Configuration Object
CP Checkpoint
DA Area Database
DB IDF
DC Doc Tool Query
DF User-Defined DDB File in Picture Editor
DM Dynamic Cyclic File
DO Display Abstract Object
DS Display Abstract Source
DU Memory Dump
DX Picture Editor Print File
DY DEB Error File
EB Exception Build Source

2.5.1 File Name Suffixes (Extensions), Continued
Suffix File Type

EC Execute Command File
EF DEB/Configuration Error File
EL Edited List (DEB)
EM CL Compiler Error Messages
EN Event Name File
EO Command Processor File
ER Error File
FO Free Format Log Object
FS Free Format Log Source
GD Global Descriptor File from compiling CDS
GM Group Ctrl. File, Archive/Save
HF Point Building Help File
JL Logic Block Config. Listing
JO Logic Block Config. Object
JS Logic Block Config. Source
JT Logic Block Temporary
KF Software Options Key File
KL Parameter Keylock Access Level
KN An alternate extension for button file.
KO Button Config. Object
KS Button Config. Source
LD Node Load File
LE CL Error Listing
LM CL Link Map
LO Loadable Pers. Image Object
LS CL Listing
MM Permanent HM File
MO CL/MC Object
MS Miscellaneous File
PA Printable Aggregate
PI Personality Image
PL Parameter List

2.5.1 File Name Suffixes (Extensions), Continued
Suffix File Type

PS Peer-Supplied List
QE Equipment List Error File
QL Equipment List successful compile listing
QO Equipment List object file
QS Equipment List source file
RD Output from LVRLOG and the AUDIT command
RE Same as RD, but comma separated
S CLMI Load Module
SD Data Segment Descriptor
SE Standard Enumerations
SF Include File for CL Interface
SL Successful Entity List
SP Standard Parameters
SS Saved trend from using TR_SAVE in the Picture Editor
SU Schedule EC Start Up
SV Saved trend settings from Native Window Group Trend.
TI Task Identifier
TO Trend Memory Image
TR CL Trace/Dump
UL Unsuccessful Entity List
UM Unit Control File for Save
VF NCF View File
WA Area Database Work File
WF Network Config. Work File
X User Source File (starts with X)
XI Help (information) files
Y User Source File (starts with Y)
Z User Source File (starts with Z)
ZC CLMI Configuration Modification Sample
ZI CLM Builder Input File (BIF) Samples
ZS Status Display Files (CLMI/port/device and so forth)
ZT CLM Builder Template Definition File (TDFs) or Network Definition
Table (NDT) Templates

2.6 Disk Drive and Disk Part Numbers
Introduction To assure proper operation, disk drives and disks must meet
Honeywell specifications. Order drives and disks from Honeywell
using the part numbers listed in Table 2-4.
Disk drive and disk

part numbers
Table 2-4 Disk Drives and Disks
Item Part Number Description
Disk Drive Assembly 51196929-135 3.5” internal disk drive
Disk Drive Assembly 51196933-100 3.5” internal disk drive.
Fits 5.25” space. Black
faceplate.
Disk 51196929-150 One 100MB IBM-
formatted disk
Disks 51196929-160 Pack of 10 100MB IBM-
formatted disks
Preparation for use Use the Utilities Create Volume command to prepare each disk for
use on the system. For additional information on disk care and use,
see Universal Station Service.

2.7 Disk Drive Upgrade Kits
Introduction Upgrade kits are provided for replacing floppy drives and Bernoulli
cartridge drives and with drives.
Disk drive upgrade Table 2-5 lists the six available upgrade kits and their respective
kits model numbers. These upgrade kits cover the most common upgrade
scenarios. If your upgrade scenario is not covered by any of the kits
listed in Table 2-5, contact Honeywell for guidance.
The disk drive can be paired with either the 20MB or 100MB
Bernoulli cartridge drive. This will allow the use of the FCOPY
command to transfer data from the Bernoulli cartridge to the disk.
Note: The FCOPY command will only work when copying between
removable media of the same capacity, or from a smaller capacity
media to a larger capacity media.
Upgrade kit model

numbers
Table 2-5 Disk Drive Upgrade Kits
Upgrade Scenario Upgrade Kit
Model Number
Single Bernoulli cartridge drive to single disk MP-ZIP100-100
drive (Black faceplate)
Single Bernoulli cartridge drive to dual disk MP-ZIP101-100
drives (Black faceplates)
Dual Bernoulli cartridge drives to dual disk drives MP-ZIP102-100
(Black faceplates)
Floppy drive(s) to single disk drive (Table mount) MP-ZFZIP1-100
Floppy drive(s) to dual disk drives (Table mount) MP-ZFZIP2-100
Universal Work Station floppy drive(s) to dual MP-ZFZIP3-100
disk drives, or no drives to dual disk drives (New
tower with disk drives installed)

Section 3 – The &ASY System Directory and its Special
Characteristics
3.0 Overview
Introduction This section describes the special characteristics of system directory

&ASY, which contains the basic description files required for the
startup of each node, including the network configuration file
(NCF.CF).
You need to know about these characteristics so that you can avoid
problems related to this directory or recover from them.
LOAD states When loading nodes, the states may be in PWR_ON and QUALIF
functionality state. Refer to the Process Operations Manual.

3.1 &ASY’s Role in Node Loading and Startup
Description Several of the files in directory &ASY are accessed each time a node
is reloaded and restarted. When a node is loaded, the location of the
&ASY directory to be used is either implicitly stated (the source is
the US that is initiating the load), or explicitly stated, as being on the
network (NET) or on a specific disk drive ($Fn).
Note that the HM automatically uses the &ASY on the network when
it reloads and restarts (autoboots) itself.
Configuration checks When a node starts up, the &ASY directory is accessed for
during startup information on the system configuration (NCF.CF file) by the node
administrator software. The version of the NCF.CF file should be the
same as that currently in use by other nodes on the LCN, and it will
be if no changes have been made to NCF.CF since the system was
first started up. It is possible to make changes to NCF.CF using the
configurator in the on-line mode. The configurator is activated by
selecting one of the Network Configuration picks (targets) on the
Engineering Main Menu.
Note that the NET>&ASY is added as the default pathname when

opting to print a NCF text file.
Reference When such changes are made, there is some degree of impact on
system operation. That impact and the steps you must take to resolve
it are defined by the configuration displays that you may see in the
Network Form Instructions. Also refer to Network Data Entry.
File access on startup After the node administrator has started its part of the startup checks,
the data-access software reads files on the system and parameter
names from the &ASY directory. The first node started on the LCN
sets the initial version of the data-access files; however, changes can
be made through CL (the addition of custom names) and the version
is updated in all nodes operational at the time of the CL operation.
Time to make backup It is at this point that you must be sure to make a backup disk copy of
copy of &ASY the &ASY, or you may be unable to load another node if the &ASY
directory becomes unavailable (for example, the HM with the system
volume is down or you spill something on the &ASY disk that has
the updated files).

3.1 &ASY’s Role in Node Loading and Startup, Continued
Two versions of Honeywell supplies two versions of the &ASY directory on disks.
&ASY directory The "startup" &ASY is set up with all LCN nodes as USs, and is used
only to get the first US started, before anything else has been
configured. The second version is the "empty" NCF version. It is
this second version that is used from System Startup Task 6 and on—
the version on which you build the NCF.WF and NCF.CF files for
your specific system.
Product Disks The disks provided by Honeywell have a set of "empty" data access-
name files. Their presence is required for startup and, as you add
names, you must be sure to keep your old set of Custom Name
Library and Standard Parameter Set (.SE and .SP) files when a
revised &ASY is sent or you will lose your custom names (for more
information about these files, refer to Control Language/Application
Module Data Entry).
Key to successful The key to using the &ASY directory is to be sure you keep both a
backup spare (current) and a backup (before the last change) disk copy that
allows you to reload nodes, if necessary, when a change cannot be put
on all nodes, or if it is urgent that a node be reloaded without making
a change to all the nodes currently in operation.
This could happen if you wished to quickly restore a US with the

Operator's Personality or Universal Personality.

3.2 Tools for Maintaining Backup Copies of &ASY
Description and File Two Execute Command (EC) files are provided by Honeywell in the
usage &EC directory on disk &Z1 (for 68040 and 68020 personalities) to
help maintain a current database and NCF files.
• The first command file is ASY_BKUP.EC. It is used for building a
complete &ASY from an HM.
• The second file is CLNCFBKP.EC. It allows a quick update of an
existing &ASY disk with the dynamically changed files, from the
HM, which affect the data-access names and the NCF files.
Instructions available Instructions for the use of these .EC files are available as text in file
TCO.XX in the &EC volume or directory (disk &Z1). To display the
content of that file, on the Command Processor display, key in a
command line as in this example:
PR $F1>&EC>TCO.XX
and press ENTER. The instructions appear on the display.

Section 4 – Area (&D01-&D10) and Standard Abstract
(&DSY) Directories
4.0 Overview
Introduction This section describes the special characteristics of the area database
directory and the abstract directories that define the appearance and
content of the displays in the Operator Personality.

4.1 The Role of &DSY and Other Data in Loading USs
Introduction After it is loaded, the Universal Station's Operator Personality

requires access to an area database and the standard abstracts, and
optionally to the volume directory that contains custom schematics.
The Operator's Personality accesses the area database files that have
been assigned to it in the NCF. Similarly, the standard abstracts are
accessed, as are custom schematics and configured buttons, as
indicated by the Pathname Catalog in the area database for the area
loaded.
Pathname Catalog For more information about the Pathname Catalog, refer to Area
reference Form Instructions.
When files cannot be If HMs are being used as the load source and the area database files
found cannot be found, the load fails.
If the HM is being used as the load source and the standard abstract
files cannot be found, the load fails.
If the custom schematic files cannot be found, the load completes if

you press ENTER in response to the prompter that requests the
schematic files.
Custom schematic files that are located on an HM, and that are not
found during the load, are automatically accessed once the HM is
operational and the schematic files are available over the LCN.
Picture Editor For more information about user-built schematics and user-
reference configured buttons, refer to the Picture Editor Reference Manual.

4.1.1 The Fast-Load Feature
Description To facilitate fast recovery from system interruptions, such as a

temporary loss of power, as soon as the System Status display
abstracts have been loaded into a US, but before all abstracts and files
are loaded, the System Status display appears and the US status goes
from LOAD to PARTLOAD or WARNING.
As soon as the System Status display appears, the US can be used to

load other nodes. Once all abstracts and files are loaded into the US,
its status goes to OK (Operator Personality), UNVL (Universal
Personality).
Procedure A fast-load can be performed from an HM that is still running or from

a fast-load disk. For more information about this feature, including
the preparation of fast-load disks, refer to Section 20.

4.2 Changes to Area Database, Schematics, and Button
Configuration
Description Once all USs in a console are loaded and running, changes can be
made to the area database and to schematics and button configuration
without reloading the USs with their personalities.
Summary Here is a summary of the major steps involved:

• Use the Data Entity Builder to make changes to the area database.
• Use the Picture Editor and the Button Configurator to make changes
to schematics and button configuration. Compile the resulting
source files and store the object files in &Dan or in a user volume
(or directory). Be sure that the Pathname Catalog in the area
database points to this directory.
• Use the AREA CHG target on the Console Status display at one US
to change the area database on USs that are to operate with the new
or revised area. Then, if needed, do an area change at the first US.
The system resynchronizes messages, alarms, and system status
across the area.

Section 5 – Console Organization
5.0 Overview
Introduction This section explains how a console is defined. It defines the special
characteristics of the devices that can be connected to a Universal
Station, and it provides some tips for optimum console performance
and convenience.
Description A console is a configured "soft" definition of a collection of

Universal Stations that are expected to be operated by one individual.
During on-process operation, the Universal Stations in one console
appear together on the System and Console Status displays.
Recall that Figure 1-1 illustrated a conceptual organization of

Universal Stations. The following are some “rules” about the
console’s organization.

5.1 Console Hints and Tips
Definition of a A "console" is defined by the configuration data supplied by you. A

console console is not automatically a set of furniture—it must be defined in
the NCF.
The station number Each Universal Station in a console is given a station number that is
unique only within that console. The station number is used for
functions such as cross-screen displays.
Physical location of The disk drives and printer are local (that is, physically wired) to only
console peripherals one Universal Station.
Access to console The disks can be accessed by any station in the console as long as the
media drives Universal Station node to which the disk drives are connected is
operating on the LCN.
Restriction to media The disks cannot be accessed by their logical-device ID (LDID) from
drives outside the outside the console (for example, a Universal Station in console 1
console
cannot access disk $F12 on a Universal Station in console 2 by the
$F12 name). See Section 2.
Printer availability In Release 600, A Universal Station can be configured to have the
Screen Print function even though it is not hardwired to a printer.
Before you can use the Console Status display to reassign the printer,
you must configure the station to have a printer in the NCF node
configuration. Then, from the Console Status display, reassign the
US’s printouts to a printer that is wired to another US on the console.
Now you can execute screen prints. All functions of the printer will
failover, except Real Time Journals. The Console Status display,
however, will indicate a WARNING message because the printer is
not physically wired. To overrides this message, you can attach a
hardware jumpered connector to the US’s printer port.

5.2 Printer Failover
Printer failover The printer failover file allows the US to direct printouts to another
configuration file printer in the console if the initial printer runs out of paper, jams, or
fails. Currently in the TPS system, no prebuilt printer failover
mechanism exists. Printer failover can be accomplished by creating a
file in the Text Editor that indicates the printer failover assignment.
All functions of the printer will failover, except Real Time Journals.
The printer failover file is created by the user through the Text Editor.
The name of the file must be PRFAILnn.XX, where nn is the console
number. This file must reside in the &ASY directory.
Example A typical printer failover text file looks like this:

01P0203
02P0103
03P0102
where:
01=printer 1 in console nn
If printer one fails, the functions of printer one transfer to printer two.
If printer two is not present, then printer three assumes printer one’s
functions.
Format of file Table 5-1 shows the text file columns and contents. All columns do
not have to be filled in, and “00” is a legal value.
Table 5-1 Format of Printer Failover Text File

Column Definition
1,2 Printer Number. Example: 01
3 Device type: P (P = printer)
4,5 Number of first failover device: 00 to 10
6,7 Number of second failover device: 00 to 10
• •
• •
20,21 Number of ninth failover device: 00 to 10

5.2 Printer Failover, Continued
Name and location of The name of the printer failover file created in the Text Editor should
file be named as follows (“nn” is the console number):
PRFAILnn.XX
Example:
PRFAIL01.XX is the printer failover file for console one.
After creating the file, copy it to the &ASY directory so it will load
into the Universal Stations at load time.

5.3 Personality Hints and Tips
Engineering functions In the following paragraphs, we refer to Engineering functions to

as used in this mean the Engineering functions in the Universal Personality.
manual
Engineering functions The Engineering functions require an Engineer's keyboard. If the

requirements Universal Station has the touch screen option and does not have an
Engineer's keyboard, only the on-process functions (System Menu,
System Status, Console Status) available through the Engineering
Main Menu can be used, provided the Universal Station has the
operator's panel (keyboard). If the Universal Station has neither the
Engineer's Keyboard nor the touch screen, the Engineering functions
cannot be used.
Engineering functions The Engineering functions operate most efficiently in a Universal

efficiency Station that has two disk drives and a printer directly connected. This
allows for faster disk access and allows printing of screen images
during the configuration process.
Universal Work If they are to operate with the Operator Personality, Universal Work
Station configuration Stations (UWSs) should be configured as members of the consoles
whose process data they are to operate. A supervisor can use a UWS
to monitor process data and schematic (custom, graphic) displays in
other areas, but to participate in full control of an area, it must operate
with the area database for that area. To use a UWS (or a US) to
participate fully in more than one area, the Operator Personality's
Area Change function (see Section 13 in the Process Operations
Manual, binder TPS 3050) can be used to load a new area database.
Universal Work Stations that use only the Engineering functions can
be configured as a 1-station console.

Section 6 – Network Configuration File (NCF.CF) [Task 7-9]
6.0 Overview
Introduction This section describes the special characteristics of the Network

Configuration File. This file contains network information that is
vital for the operation of all nodes on the LCN. The content of the
NCF is defined, as is its use in node startup. Also see Section 3—it
discusses directory &ASY, the directory that contains the NCF.

6.1 NCF Information
Purpose of the NCF The Network Configuration File (NCF) describes the LCN hardware
(numbers and types), the names for units, areas, and consoles,
miscellaneous system values including shifts, days, and times, the
HM volume configuration data, and so on. The NCF is used at
startup of a node to allow establishment of communication on the
LCN. The same NCF should be used by each node in the network,
but you can use the configurator in the on-line mode to change the
NCF. The configurator is activated by selecting one of the Network
Configuration picks (targets) on the Engineering Main Menu.
Changing the NCF Changes to the NCF are effective only after the revised NCF is
loaded in one or more nodes. When such changes are made, there is
some degree of impact on system operation. That impact and the
steps you must take to resolve it are defined by the configuration
displays (refer to Network Form Instructions, binder TPS 3030-1 and
see Network Data Entry). Attempts to load a node using an NCF that
is not known to the nodes already running on the LCN causes the
load to fail (the time stamp for an NCF modified in on-line network
configuration is "broadcast" to all nodes when it is installed by the
network configurator. See the following Warning).
WARNING The date/time stamp of the NCF file (NCF.CF) viewed using the
Command Processor does NOT necessarily match the date/time of the
NCF version on the System Status display. The System Status
display, accessed from the Engineering Main Menu, shows the NCF
Install Time. The date/time stamp of the NCF file is displayed on the
Console Data display, which is accessed from the Engineering Main
Menu by selecting the System Wide Values target, then selecting the
Console Data target.
Allow for expansion Plan ahead—you may want to include extra nodes and devices on
consoles when you first configure your system. This eliminates the
need to use on-line reconfiguration to add nodes, and having to shut
down and restart other nodes and USs to advise them of the added
nodes. Nodes that are configured into the system, but that don't
actually exist, show up on status displays with an OFF status and
extra devices such as disks configured on a node appear on the
console-status display with a "service" message.

6.1 NCF Information, Continued
Two &ASY directories Honeywell supplies two &ASY directories on disks, the "startup"
provided &ASY directory, and the "empty" NCF directory. The first, or
"startup," directory is set up with all LCN nodes as USs and is used
only to get the first US started, before anything else has been
configured. The second, or "empty," version contains the user's
NCF.WF and NCF.CF files in which the network data for the specific
system is built and stored in Startup Tasks 6 through 11.
Changes that affect The NCF is affected by changes or additions to any of the following:
the NCF
• Unit Names
• Area Names
• Console Names
• LCN Nodes
• System-Wide Values
• Volume Configuration
Changes that DON’T Changes to HIWAY and BOX/SLOT CONFIGURATION do not

affect the NCF affect the NCF.
Data is lost if you Changes to the volume configuration of any HM requires the HM to
change HM volume be initialized before the changes are effective. HM files must be
configuration
saved on another HM or disk before HM initialization because
initialization erases the data on the HM. Also, if continuous history or
journal volumes are changed, any existing continuous history or
journal data is lost—it cannot be copied and reloaded. See Section 7.

Section 7 – HM Configuration and Use
7.0 Overview
Description This section describes the History Module, its use, and operation. It
provides guidelines for use of HM storage space and for estimating
the size of the volumes assigned to each HM, including Continuous
History volumes. Directions are provided for configuring and
starting up an HM.

7.1 Introduction
Description History Modules (HMs) are mass storage devices that store software,
system files, system data, and user data. Most data stored in any HM
can be accessed by any node on the LCN.
HM location in the An HM is a node on the LCN. It includes LCN
TPS System an electronics kernel (the foundation Electronics

electronics package in every node), a Smart Kernel
Peripheral Controller (SPC), and from one, SPC/WDC
two, or four Winchester disk drives.

Winchester Disk
Drive
History Module
2959
7.1.1 HM Options and Variations
Types of drives Two types of Winchester drives are in use in HMs. While there are
some physical and electrical differences in these drives (refer to History
Module Service), the difference that matters to system engineers is the
storage capacity of each type, which is as follows (KB = kilobytes =
1024 bytes):
• Wren III (Type 3) 135,900 KB
• WDA 210 215,040 KB
• WDA 445 454,130 KB
• WDA 875 896,032 KB
• WDA 1.8GB 1,836,736 KB

7.1.1 HM Options and Variations, Continued
Drive usage Each HM can have more than one Winchester drive of the same type.
Twice the single-drive capacity can be obtained by operating two drives
in dual mode. Two or four drives can also be combined as Redundant
drives.
Wren III and WDA drives can operate as redundant drives, using two or
four Drives in redundant single or redundant dual mode. Each drive (or
drive pair) stores a mirror image copy, so if one drive (or drive pair)
should become unavailable, the other drive (or drive pair) is still
available and the HM remains operational (refer to 7.5 for more
information on HM Disk Redundancy).
Dual logical drives are physically one drive but are treated as two virtual
drives by the system. The drives are available in the 875MB/1.8GB
sizes. In NCF Volume Configuration, the number entered in the
NUMBER OF WINCHESTER DISKS field must be 2. If the drives are
redundant, then another dual logical drive is required, and they will
appear to the system as four virtual drives. Although there are four
virtual drives, the NUMBER OF WINCHESTER DISKS field is still
set to 2, because the HM Redundancy keyfile option implements the
redundancy.

7.1.2 Overview of HM Operation
Description An HM operates with either its initialization personality (provided in

disk directory &HMI) or with its on-line personality (provided in disk
directory &HMO).
Initialization When the HM is running its initialization personality (HMOF), the US

personality (HMOF) Engineering functions’ Network Configuration can initialize the HM,
which establishes its volume configuration. Initialization also causes
any previously stored file data to be lost.
When the initialization personality is running, user functions can

access the HM, and the files in it, only by using the node-number
pathname form. For example:
PN:43>VDIR>FILE.XX
System functions access the HM and the files in it by using the NET
pathname form, shown below.
If the System and HM Status displays show an HM's status as HMOF,

it is running the initialization personality.
On-line personality The HM's on-line personality is used for all on-process and
(OK, WARNING, implementation operations except HM initialization. When an HM is
SEVERE WARNING)
running its on-line personality, it can be accessed with the node-
number pathname form. You can also use the network (LCN)
pathname form. For example:
NET>VDIR>FILE.XX
If the System and HM Status displays show an HM's status as OK,

WARNING or SEVERE WARNING, it is running the on-line
personality.
Autobooting A functional HM that has been on-line and loses its primary ac power
source can restart itself with the on-process personality when power
returns. This function is often referred to as “rebooting” or
“autobooting.”
Changing An HM's personality can be changed by using the HM Status display

personalities to reload the HM with the required personality.

7.2 Guidelines for Use of HM Storage Space
Description Since LCN-based TotalPlant Solution (TPS) systems were first

introduced, the storage capacity of individual Winchester drives has
increased dramatically. Now it may be possible to accommodate all
of the storage requirements for a system on a single HM.
Sharing storage While it may be possible to store everything in one HM, there are
among HMs often other reasons to have more than one HM. These reasons are
explained in the following guidelines.
To make the most efficient use of your HMs, follow these guidelines
whenever possible. They are in these categories:
• See 7.2.1 for volumes and types of data stored on HMs.
• See 7.2.2 for allocating functions on the LCN.
• See 7.2.3 to assign units to HMs.
• See 7.2.4 for configuring history groups.
• See 7.2.5 for requesting history through the LCN.
• See 7.2.6 to manage history collection by computers through the
CG.
7.2.1 Volumes and Types of Data Stored in HMs
Local Volume All HMs have an HM Local Volume (!9np) that stores the HM
personality files and the local HM network configuration file
(Lnp_NVCF.nn).
Others volumes In addition, HMs can have the following numbers of volumes:
• HM with 1 drive or 2 redundant-partner drives—up to 14 volumes
plus !9np.
• HM with dual (2) drives or dual redundant (4) drives—up to 29
volumes, plus !9np.
Each HM drive can accommodate 15 volumes, but 1 is the HM Local

Volume (!9np), hence the remaining 14 or 29 volumes.

7.2.1 Volumes and Types of Data Stored in HMs, Continued
HM Data types The following is a list of all of the types of data that can be stored in
HMs. “np” is the node-pair number for a particular HM. It is defined
on the HM Node Pair Selection Menu under Volume Configuration.
Table 7-1 HM Data Types
Volume Data Type Note Description
Name Key
&0np System files √ Network configuration, standard and custom parameter
names, display abstracts, global description files (GDFs),
key file, options and loader files.
&1np Personality images # Loadable software images.
&2np Dump volume # Image (hardware memory) of an LCN node. Dump files are
used to accumulate error or failure data for later analysis.
&3np Area database Contains a directory for each area. Each directory contains
a file that defines the content of the area’s standard
operator displays and the area’s logs, journals, reports, and
so on.
&4np CL/MC object User-defined CL/MC object code.
volume
&5np AM checkpoint ## Reloadable checkpoint data for AMs.
&6np CG checkpoint ## Reloadable checkpoint data for CGs.
&7np HG checkpoint ## Reloadable checkpoint data for HGs.
&8np NIM/PM checkpoint ## Reloadable checkpoint data for NIMs/PMs.
&9np CL/PM object volume CL/PM sequences object code.
!0np Continuous History @§ First volume of continuous process history
!1np Continuous History @§ Second volume of continuous process history on second
drive (if present).
!2np Journals Æ Journal manager and journals
!4np On-process analysis √@ Maintenance support files (on the HM with the system
journals)
!9np HM local volume @ HM initialization personality, HM on-line personality, HM
support files, local HM network configuration file.
Notes: √ Indicates a volume that can exist only once on an LCN (in only one HM).
@ Indicates a volume that must be on an HM if the volume exists on the system.
# Directories for different personality images can be assigned to &1np volumes on different HMs.
Dump directories should be assigned to the same HM as the corresponding personality-image
directory, if they reside on an HM. Do not save any other files other than node dumps to the dump
directory. Storing other files will corrupt the dump data.
## Directories for different checkpoints can be assigned to &5np—&8np volumes on different HMs.
§ Directories for different continuous history units can be assigned to !0np/!1np volumes on different
HMs. Also, directories for different process units can be assigned to !2np volumes on different
HMs.
Æ Journals for different process units and the system unit can be on different HMs.

7.2.2 Allocating HM Functions on the LCN
Performance cluster To yield a more responsive system, we recommend a performance

cluster of nodes (Section 23) in which at least one HM is dedicated to
support the cluster. All nodes that cause data flow in or out of an HM
are HM resource users. These nodes are USs, NIMs, AMs, HGs, and
CGs. The nodes defined for a performance cluster are:
• 4 Universal Stations
• 1 Hiway Gateway (or NIM) pair (that is: one and only one HG pair
[primary and backup] or one and only one NIM pair)
• 1 Application Module
• 1 History Module
• 1 CG serving a CM (two or more clusters can share a CG)
At least one HM should be provided to support each performance
cluster. A cluster may support one area (small system) or an area may
need several clusters (large system).
Continuous history is The main thing to remember as you LCN

a heavy disk user decide which functions should
reside on which HM is that
continuous history is a very heavy HM HM
Winchester disk user, but it is Keep heavy And keep con-
given no special priority when it Where HM users and tinuous history
possible: convenience on (one or more
accesses the disk. This means that items on one other HMs.
all other functions that require HM.
2960
frequent disk access should be
assigned to HMs that are not used
to store continuous history.
Functions that access HM disks often include those associated with the
following volumes:
• Personality images (volume &1np).
• System volumes (volumes &0np and !9np).
• CL volumes (volume &4np).
• Volumes that contain frequently used schematic displays (schematic
object files are often stored in area volume &3np).
• Any other volumes that will have heavy (continuous) use.
The abbreviation “np” stands for the node-pair number for a particular
HM. It is defined on the HM Node Pair Selection Menu under Volume
Configuration.

7.2.2 Allocating HM Functions on the LCN, Continued
Volumes required on It’s convenient to store data on HMs because you don’t need to
an HM mount and remount several removable media (disks).
Only these files must be on an HM:
• continuous history volumes (!0np, !1np)
• journal volume (!2np)
• on-process analysis volume (!4np)
• HM local volume (!9np)
The remaining volumes can be on an HM or on removable media.
If HM storage is If HM storage space is limited, consider keeping these on removable

limited media:
• schematic and CL source files (not object files), and
• point files and IDB files.
Keep all common data If you want to keep everything, or nearly everything, on HMs, collect
on one HM all the volumes that apply equally across the LCN in one HM,
preferably an HM with no continuous history. These volumes are:
• the system volume (&0np),
• the personality image volume (&1np),
• the dump volume (&2np), and
• the on-process analysis and maintenance volume (!4np).
• user volumes for schematic object code, &CUS, &CLX, TLK1, and
so on.
These volumes typically use 20,000 KB to 40,000 KB. They reside in
one place on the LCN and have no relationship to areas, units, or any
other process grouping.

Mixing non-history Honeywell has extensively tested and verified the 50 pps
functions with (parameters-per-second) and 3000 point (150 history groups) on non-
continuous history
system HM configurations with 68040 K4LCN processor boards
using WDA 445 MB, WDA 875 MB, and WDA 1.8GB drives.
This 50 pps configuration is NOT recommended for any HMs with
the 68020 processor or drives other than WDA 445 MB, WDA 875
MB, and WDA 1.8GB.
Also, note that it may be necessary that data owners (NIMs, HGs,
PLCGs, AMs, and CGs) that the non-system HMs are collecting
history from, have 68040 processors for preventing further overload.
On the system HM with a K4LCN processor, the recommendation is

a maximum of 40 pps and 120 history groups with 445 MB/875
MB/1.8 GB WDA drives. A maximum of 40 pps history load has
been reached with 68020 processors on non-system HMs. On system
HMs, around 20 to 30 pps is more likely to be the maximum with 120
history groups (depending on drive types and other HM loads such
as: checkpoints, requests for trends and pictures, logs, bursts of
events, file access, and so on.).
If history overrun messages are received frequently, it may be

necessary to reconfigure history in the HMs to cut the number of
history groups and/or the frequency of the collection rate of the
history groups (e.g., instead of 5 second collection rates, slow it to a
10, 20, or 60 second collection rates).
NOTE:— The parameters-per-second (pps) calculations should be

done by hand. The NCF HM Checker, CTRL+F1, doesn’t give the
results, although it will give a warning if the 50 pps or the 150 history
group limits are exceeded. This warning will also appear if the 40
pps or the 140-history group limit is exceeded, but the warning can be
disregarded if the above recommendations are followed.
An example for 60-second history groups:
20 pps per history group ÷ 60 seconds = 0.333 pps per
history group x 150 history groups = 50 pps

7.2.2. Allocating HM Functions on the LCN, Continued
When an HM is If an HM is overloaded, or nearly so, this auxiliary node status

overloaded message is presented:
CHECK SYSTEM LOAD xx SEC. HISTORY COLLECTION CYCLE OVERRUN
This can be caused by two different situations:

• HM disk or processor use is heavy and the HM cannot unload its
temporary files as fast as it is filling them up.
• The HM can’t finish its entire collection cycle in the time
allowed.
(See this manual, HM Performance Hints and Rules of Thumb)
Temporary files are The first situation occurs when HM disk or processor use is heavy
full and the HM cannot unload its temporary files as fast as it is filling
them up. If the HM's requests to the file manager are blocked too
often, the HM has to stop collecting data while it clears out its
temporary files.
HM can’t complete When the second situation occurs, the cycle is always completed, but
cycle if it overruns, the HM sends the maintenance message and 1 or 2
samples of data are lost. This appears as an outage in the history files
on the HM.
This can occur because the HM load is too heavy or because the load
on the data owners (the nodes that collect history data—AMs, NIMs,
and HGs) prevents a prompt response to the HM's requests for
process data.

How alarm messages To keep from filling the journals with excessive alarms, only 1
are managed auxiliary node status message is sent out during a 1-hour period and a
maximum of 3 maintenance recommendation messages are output
during 24 hours.
Correcting the If the above messages are received regularly, either an HM is

overloaded condition overloaded or other nodes on the LCN are slowing it down by heavy
disk accesses or because their own load prevents answering requests
from the HM in a timely manner.
To relieve the situation, consider upgrading the HM and the data

owner nodes that access it so that they use high-performance (68040-
based) microprocessor boards.

7.2.3 Assigning Units to HMs
Points to keep in mind When you use Volume Configuration on the Engineering Main Menu
to assign units to HMs, keep these points in mind:
• Spread the load between HMs that collect HM HM HM
history data.
Continuous History
Data owners (AMs, NIMs, and HGs) that
are heavily loaded should not be providing NIM AM NIM
history to the same HM. 2961
History for a single process unit may not

exist on multiple HMs.
• On dual-drive HMs, many small units are
better than a few large units because
history volumes can be split only at unit
boundaries.
HM
If you run out of room for a history
volume, and all of your historical points Continuous History
are in one unit, the remaining history files
cannot be created in a volume on the other
Unit Unit Unit
disk—this can be done only if there are B2 B1 C3
convenient unit boundaries where the 2962
volume can be divided.

7.2.4 Configuring History Groups
The importance of You can use history-group configuration to do much to reduce the load on
reducing data owner the data owners (AMs, NIMs, and HGs). This could be important when
load
NIMs or HGs are so busy that they can't accommodate the extra load
caused by history-collection requests from HMs.
How to reduce data Set up your history groups so that they contain points from different
owner load data owners. For example, combine NIM (or HG) and AM points in
the same unit in one history group (History Group 001 in Figure 7-1).
Then, not all of the requests for data for this group are being sent to
one NIM or one AM at once, but are spread out between two or more
nodes.
Figure 7-1 Reducing Data Owner Load
AM 50 History Group Where possible,

Unit A1 001 combine points
from the same
NIM 54 unit in one history
Unit A1 History Group group.
002
Or spread points
AM 40 History Group for one unit among
Unit B2 003 history groups.
2963
How the HM collects The HM collects history data 3 groups at a time.

history data
If, for example, you have 3 contiguous groups that have points that
are all in one NIM or HG, that node gets a request for 60 points all at
once, but you could have spread the requests for these 60 points over
3 noncontiguous groups.
CAUTION, R510 and For R510 and later releases, if any point currently historized by a
later releases history group will be deleted as a result of loading other points into
the history group, a warning is issued: “$CHxx( y) HISTORY WILL
BE LOST – Press <F5> Overwrite To Continue If Desired”.

7.2.5 Requesting History through the LCN
Rules for requesting Here are two general rules for requesting history data for logs and
history data reports, and requests by user-written programs:
• Rule 1—When asking for Oldest Newest
Continuous
the most recent data, History Data
request it in the
“backward” direction and Forward requests Backward requests
when asking for the oldest for older to more for more recent to
data, ask for it in the recent data older data
“forward” direction. Request more
data less often. 2964
• Rule 2—Whenever
possible, ask for more data
less often.
Rule 1 explained The reason for rule 1 is that history is always retrieved from one end
of a history file to the other. Where it starts is determined by whether
history is requested from a more recent time to an older time
(backward), or from an older time to a more recent time (forward).
Controlling where the search begins, can save a lot of time. A

corollary to this rule is, “If you don't need the pre-archived data,
don't configure it.”
Rule 2 explained Rule 2 comes from the fact that there is tremendous overhead per
point in setting up each request. Once it is done, however, the
amount of data retrieved for each point has very little effect on the
time that it takes to service the request.
It is much more efficient to wait 2 hours for snapshot data, then

request the last 2 hours' worth of data for each point.
For example, retrieving 2 hours worth of snapshot data for 2400

points takes only slightly longer than it would take to retrieve an
hour's worth.

7.2.6 Managing History Collection by Computers through
the CG
Introduction It is important to limit the number of continuous-history requests

from a computer through the CG, because the HM has no way to
control the rate at which it processes requests.
Rule for managing As a general rule, never send more than two requests at a time to a
continuous-history single HM.
requests
To do so impairs operator interaction and background functions like
report generation. Also, it interferes with the collection of data.
Remember that history requests to the HM are organized by unit. If a

DDT contains points in three units and history for all of those units in
a single HM, that HM receives three separate requests for that DDT,
which causes an increase in the load on that HM.
Controlling history These are the two ways that you can control the number of history
collection requests requests:
• Run one ACP per HM on the LCN from which you are collecting
history.
– Set up all of the DDTs for that ACP so that they contain points
from two units on the HM.
– This way, two requests to the HM are generated for every DDT
for this ACP.
• Run just one ACP to collect history from the LCN.
– Each DDT for this ACP should contain points from multiple
HMs.
– Be sure to limit the number of units represented to two per HM.
Other combinations of these methods are possible, but remember:

• if you have more than one ACP accessing the same HM, or
• you have more than two units-per-HM in a DDT
you may be generating more than two history requests per HM, thus
reducing your HM’s performance.

7.3 Continuous History Configuration
Introduction Continuous history is data collected for continuous data points over a
period of time, and stored in user-configured volumes on one or more
HMs. You can configure at least 150 History Groups (and possibly
more) per HM. For each group, up to 20 point-parameters (form:
NAME.PARM) can be collected in a collection cycle.
Types of data Continuous history consists of these two types of data (see Figure 7-2):
• Snapshot data—instantaneous values from parameters that contain
a real or a digital (enumerated) value.
• Average data—average values calculated from the sum of samples
collected over a period, divided by the number of samples in the
period. Only parameters that contain real values can be used for
averages.
Common indicators All continuous history data includes a time stamp that indicates the
collection cycle in which the data was acquired. Average values are
also accompanied by a “Normal” or a “Nonstandard” status indicator.
“Normal” indicates that less than 10% of the samples during the
average period were bad and “Nonstandard” indicates that 10% or
more of the samples during the average were bad.

7.3.1 Hourly, Shift, Daily, and Monthly Averages
Description Hourly, shift, daily, and monthly averages are standard values included in
the continuous history for all systems that have continuous history
volumes.
• Hourly averages—For each point in each history group, 171
hourly average values are stored. This covers a week of 168 hours
with a margin of 3 hours.
• Shift averages—For each point in each history group, 43 shift
average values are stored. This covers a week of shifts as short as 4
hours with a margin of one shift (168/4 = 42 shifts).
• Daily averages—For each point in each history group, 33 daily
average values are stored. This covers a month of 31 days with a 2-
day margin.
• Monthly averages—For each point in each history group, 14
monthly averages are stored. This covers a year of 12 months with
a 2-month margin.

7.3.2 Snapshots and User Averages
Description Snapshots and user averages are configurable options for each history
group. In HM Volume Configuration, you select these options and
you can enter a number of pre-archived hours to be stored for each.
Save rates The rate (in seconds) at which snapshots are collected is adjustable.
This table gives the maximum prearchive snapshot hours allowed and
the recommended prearchive snapshot hours for each save rate.
Table 7-2 Rates at which Snapshots (SS) are Collected
Save Saves per Maximum 68020
Rate Minute Prearchive Recommended
(secs) (60 ÷ Rate) SS Hours Prearchive SS
Allowed Hours
(R620 & later)
5 12 240 168
10 6 480 168
20 3 960 168
60 1 1330 168
The rate (in minutes) at which User Averages are collected is

adjustable. The following table gives the maximum prearchive hours
of User Averages allowed:
Save Rate Maximum Prearchive User Average

(Minutes) Hours Allowed (Hours)
3 min. (R620 & later) 746
4 min. (R620 & later) 996
5 min. 1,246
6 min. 1,496
10 min. 2,496
12 min. 2,996
15 min. 3,746
20 min. 4,996
30 min. 7,496

7.3.2 Snapshots and User Averages, Continued
Base period values For snapshots (instantaneous values collected at the save rate), values
for a base period of 8 hours are stored.
If you enter a nonzero value for prearchiving (range 0 to 2,880 hours)

that number of additional hours is stored. As is indicated in Figure 7-
2, this can use significant amounts of HM storage.
Base average values For user averages (averages collected at a user-specified interval), a
base set of 85 values is stored (for a 6-minute interval, this would
cover 8.5 hours). If you enter a nonzero value for prearchiving (range
0 to 7,496 hours) that number of additional hours is stored. As is
indicated in Figure 7-2, this can use significant amounts of HM
storage.
Notice Because 4 hours of on-line data is included in each transfer to

prearchive files, the number of hours of on-line data added to the
number of prearchive hours, does not always equal the amount of
continuous-history storage. At times, there can be as many as 4 hours
of duplicate data.

7.3.2 Snapshots and User Averages, Continued
Figure 7-2 Continuous History Structure (R620 & Later)

Hourly, Shift, Daily, and Monthly Averages
20 40 60 80 100 120 140 160 171
Hourly Averages
1 week = 168 hours

10 20 30 40
Shift Averages
43 Shifts
10 20 30
Daily Averages
33 Days
5 10
Monthly Averages
14 Months
Snapshots and User Averages

4 8
Snapshots, Base Period Snapshots for each configured hour
8 Hours User-configured
prearchive hours,
Snapshot Snapshots per Total Base Period 0 to 2,880 hours
Rate hour Snapshots
60 60 480
20 180 1440
10 360 2880
5 720 5760
20 40 60 85
User Averages, one per
User Averages, Base Values user-configured period
85 Base Values User-configured
At user-configured prearchive hours,
intervals (periods)
0 to7,496 hours
User-average period is
configured in SYSTEM WIDE VALUES.
Period values are 3, 4, 5, 6, 10,
12, 15, 20, and 30 minutes. 11572-A

7.3.3 Uses of Continuous History
Where continuous All types of continuous history (hourly, shift, daily, and monthly
history is normally averages; snapshots; and user averages) are available through
available
• Process Variable Retrieval Display (Operator or Universal
Personality), which is available through the System Menu.
• Standard Logs, which are configured in the Area database.
• Free Format Logs, which are configured using the Free Format Log
Builder from the Engineering Main Menu, then added to an area
database.
Other places to show In addition, snapshot data is used for all trends—trend displays, trend
continuous history records, and printed trends.
NOTE: It is important to remember that historical-trend values for a

point are available only if that point is configured in a history group
that is configured for snapshot values.
HG-source (trend memory in a box) values may be available for a

point that is not in any HG group with snapshots. Of course, real-
time data (current PV value for each minute the trend is running) is
available because it does not have to be collected.

7.3.4 Continuous History Configuration Forms and
Displays
Engineering functions Continuous history is configured in these Engineering functions

activities and Activities:
continuous history
• NETWORK CONFIGURATION, SYSTEM WIDE VALUES—The user-
average interval (3, 4, 5, 6, 10, 12, 15, 20, or 30 minutes) and shift
data are configured using:
– Form SW88-515
– User Average Period Display
– Shift Data Display
• NETWORK CONFIGURATION, VOLUME CONFIGURATION—The

number of history groups per unit is defined and the save rate,
snapshot, and user-average options for each history group are
configured, using:
– Form SW88-517
– Continuous History Unit and Groups display
– Continuous History Group Options display
• HM HISTORY GROUPS—This activity builds a reserved entity for

each continuous history group. In this activity, the specific data
points and parameters to be collected for the history group are
defined using:
– Form HM88-500
– HM History Group Configuration display

7.3.5 Continuous History Notes and Precautions
Introduction The following notes and precautions result from the design of the
continuous history function.
Configured History If you assign continuous history groups to process units in Volume
Groups with no points Configuration and you don't configure any points for those groups in
HM History Groups, a null default value for these points will still be
written to disk when history is collected.
You should recognize that such empty groups cost processing time
and are not “free.”
HM Overloads If the history collection function on an HM is overloaded, a

maintenance recommendation is generated that says HM history is
overloaded.
If this recommendation occurs consistently, you should review the

section, Allocating HM Functions on the LCN, in this manual and
consider reallocating HM functions on the LCN.
If this message occurs infrequently, particularly when you are starting

up the HM, you can ignore it.
Scheduling Logs with Because hourly, shift, daily, and monthly averages are calculated just
Averages after the average interval is complete, logs that contain these averages
should not be scheduled until at least five minutes past the end of the
hour, shift, day, or month.
Copying continuous Copy continuous history to removable media or another HM only

history with the initialization personality (&HMI) running on the source HM.
Since history collection is not active when the HM is in initialization
personality, this ensures that historical data remains consistent.
Do not make the copy while the on-line personality (&HMO) is

running on the source HM.

7.3.5 Continuous History Notes and Precautions,
Continued
Starting history After a power interruption that causes the system's date and time to
collection after a be lost, historical data is not collected until the date and time are set
power interruption
to something other than January 1983 (the default date), and history
collection is explicitly enabled.
How to enable history To enable history collection, select HISTORY MODULES from the
collection
System Status display, then select the HISTORY COLLECT target.
Loss of history after After an HM is shutdown and then restarted, up to 15 minutes of

HM shutdown continuous history may be lost. The time varies depending upon the
amount of history collected and the amount of disk activity generated
from other nodes.
When snapshots are Snapshot values that are collected in a given minute are not available
available for displays, logs, and reports until shortly after the beginning of the
next minute.
If such a snapshot is requested in the minute in which it is collected,
question marks will appear as the value.
Abnormal time System time changes can occur because someone changed the time
changes through a Universal Station or because of a system clock
malfunction.
An “abnormal” time change is a time change that makes it impossible

for portions of the continuous-history data to be retrieved. In general,
an abnormal time change is a change that exceeds the normal time
change of one hour or less and then time is changed back again.
For retrieval of data for logs from the oldest data to more recent data,
the most destructive time change is one that jumps forward in time
and then backward. For retrieval of data from the most recent data to
older data, the most destructive time change is one that jumps
backward and then forward again.
Configuring We recommend that you configure the prearchive hours for storage
prearchive hours snapshots and user averages as recommended in Table 7-2, because
larger values create very large files and may cause problems in using
the Data Entity Builder to load History Group entities.
One week of storage (168 hours) is reasonable for most situations and
should cause no entity loading problems.

7.4 How to Estimate HM Volume Sizes
A tip: Make a rough Most TPS systems have more than adequate HM storage capacity.
estimate first, then
readjust volume sizes
If you are just getting started, we recommend you:
• Estimate the volume sizes required for each of your HMs, then add
from 20 to 30 percent to each of your estimates.
• Refer to the System Startup Guide, to get your system started.
• Use the command processor LS command to list the actual sectors
used in each volume. Refer to Command Processor Operation,
binder TPS 3030-1, and remember that 1 sector = 256 bytes.
• Allow your system to run for a short time (perhaps a few days) to
allow it to collect checkpoint data.
• Readjust your volume sizes, allowing a margin of 10 to 20 percent
for growth and future software releases. Make your user volumes
large enough to fill each HM to at least 90 percent of full capacity.
Use guidelines First, review the earlier section, Guidelines For Use of HM Storage
Space, to determine the minimum number of HMs the system should
have to attain good performance. Then, do one of the following:
• If the number of HMs the system will have is not already
determined, assume the system will have the minimum number
required for good performance as specified in the guidelines. Then
make a trial allocation of volumes to those HMs.
• If the number of HMs the system will have is already determined,
list each of the HMs in the system and make a trial allocation of
volumes. See 7.2 for the guidelines. You may have to make
compromises to get all required and convenience volumes allocated.
Estimate volume sizes Next refer to the section, Use of Table and Charts to Estimate HM
Volume Sizes, to make a trial estimate of the size of the volumes in
each of the HMs on your list.

7.4 How to Estimate HM Volume Sizes, Continued
Check available Once you have estimated the size of all of the volumes, add the
storage volume sizes for each HM and compare the sum to available storage
in Table 7-3 to determine how full each HM would be.
If an HM is not almost full, re-examine your estimates and increase

volume sizes or add more user volumes to fill out the HM to about 90
percent of capacity.
When HM must be The following types of changes require that the History Module be
initialized and system initialized and your system reloaded: Volume Configuration, System
reloaded
Wide Values, and off-line changes.
Remember, you cannot add user volumes to the HM, without

initializing the HM (you can create directories to partition existing
volumes). Initializing the HM causes the loss of all files, so the
backup of files to another HM or to disks is required. These are
estimates of the number of disks that are needed to back up a
completely full HM:
Table 7-3 Estimated Number of Disks to Fill an HM

HM Type Single Drive Disks Dual Drives Disks
Wren I I I 135,900 KB 2 271,800 KB 3
210 WDA 215,040 KB 3 430,080 KB 5
445 WDA 454,130 KB 5 908,260 KB 10
875 WDA 896,032 KB 10 1,792,064 KB 19
1.8GB WDA 1,836,736 KB 19 3,673,472 KB 37
Calculating number of Note that when using the WDA, the number of disks required are
disks required
approximately 1 for every 100MB of disk space (actually, it is
95.7MB per disk). This proportion continues regardless of the size of
your WDA. Also, note that the Backup command does not copy
history files for points or journals, which can be a sizeable amount in
some History Modules, thereby also saving on the number of disks
necessary to backup an HM.

7.4.1 Use of Tables and Charts to Estimate HM Volume
Sizes
Introduction Several tables and charts are provided at the back of this section to
assist you in estimating HM volume sizes and entering HM Volume
Configuration data. Find each volume in the appropriate table or
chart, estimate its size, and write it down on your list. Finally, add up
all of the storage space that will be used on each HM, and verify that
it doesn't exceed the HM's capacity, which is listed in Table 7-3.
To save time and You can save considerable time and minimize calculation errors by
calculation errors using a spreadsheet program on a personal computer to estimate your
volume sizes and total HM storage space. In your spreadsheet, enter
the equations from Table 7-9 for each type of volume, and then enter
the values for each volume you need to estimate. The calculations in
Table 7-12 and those for the volume-size charts at the back of this
section were made with Microsoft® Excel on a Macintosh™
computer. Several similar spreadsheet programs are available for
IBM™ PCs and IBM-compatible PCs. You can verify the equations
you enter in your spreadsheet by entering the values used in Table 7-
12 and comparing the results.

Sizes, Continued
Adjustment factors The following factors are built into user-volume Table 7-13 and
Table 7-14, but need further explanation:
• We suggest that instead of several HM user volumes, you use only a
few user volumes on HMs and use directories within those volumes
to identify the different types of data in the volumes. It is far easier
to create new directories in a larger user volume than to create new
volumes on an HM, which requires initialization of the HM (refer to
Command Processor Operation Manual, for a description of the
Utilities’ Create Directory command).
• We suggest that you specify the number of files for IDF volumes at
six times the number of IDF files expected because of the
supporting files generated, particularly when errors occur.
• We suggest that you specify the number of files for the schematic
volume at seven times the number of schematics expected to
support the source, object, and library files for subpictures.
• We recommend that you specify the number of files in the CL
volume at five times the number of CL programs expected. Specify
the number of files in the CL-Custom GDF volume at the number of
custom data segments, plus the number of custom parameter lists
expected.

Sizes, Continued
List of tables This is a list of the tables in subsection 7.4.4
Table 7-4 Tables Used to Estimate HM Volume Size

Table Title Description
7-9 HM Volume Size Defines the calculations and constants that
Estimator determine the size of each Honeywell-
supplied volume that can reside on HMs.
7-10 HM User Volume Defines the calculations and constants for
Size Estimator estimating user-volume sizes (except IDF
volumes).
7-11 IDF Volume Size Defines the calculations and constants for
Estimator estimating IDF-volume sizes.
7-12 Example, Small Provides a worked-out example of volume-
System size estimates.
7-13 Example of IDF Provides a worked-out example of IDF
Volume Estimate volume- size estimates.
7-14 Example, User Provides a worked-out example of user
Volume volume-size estimates.
7-15 Value Sources Provides a line-by-line description of the
for Volume Configuration source for each item to be filled
Configuration in on the HM Volume Configuration Forms.

Sizes, Continued
List of Figures Figure 7-3 through Figure 7-11 are charts of volume-size calculations
for each of the volumes that require extensive calculations to estimate
volume size.
These charts plot volume size vs. major variables that affect volume
size.
Where larger HMs are in use and, therefore, very close volume-size
estimates are not critical, you can use these charts to estimate your
volume sizes, provided you add enough margin to the value you read
off the chart to assure that the resulting volumes will be large enough.
You should consider possible future expansions.
This is a list of the volume-size charts in this section:
Table 7-5 List of Volume-Size Charts in Section 7

Figure Title Description
7-3 Area Checkpoint Plots for one, five, and ten areas
Volume
7-4 AM Checkpoint Volume Plots for AMs with 1 Mw, 2 Mw, 3 Mw,
and 4 Mw memories
7-5 NIM Checkpoint Volume Plots for 1 to 20 NIMs versus average
number of PMs per NIM
7-6 NIM Checkpoint Plot for 1 NIM versus average number
Volume, 1 NIM of PMs per NIM
7-7 NIM/LM Checkpoint Plot for 1 to 32 LMs on one NIM and
Volume, 1 to 32 LMs its UCN
7-8 NIM/APM Checkpoint Plot for 1 to 31 APMs on one NIM and
Volume, 1 to 31 LMs its UCN
7-9 Continuous History, Example of smaller history-volume
Example 1 sizes
7-10 Continuous History, Example of larger history-volume
Example 2 sizes
7-11 Journal Volume Size, Example of larger Journal-volume
Example 1 sizes
7-12 Journal Volume Size, Example of smaller journal-volume
Example 2 sizes

7.4.2 HM Volume Configuration Example
Description Tables 7-12, 7-13, and 7-14 contain examples of the HM volume
configuration for a small system with one area and one cluster. The
point mix used in this example is the approximate equivalent of the
mix of points in five Honeywell Control Units (HCUs, see 23.2). The
following is a summary of variable data used in this example:
Table 7-6 Summary of Variable Data used in Example

Variable Data History Saved
770 data points 38 continuous history groups, saved for one week
40 schematic displays 38 snapshot history groups, saved for one week
20 free format logs 38 user-average history groups, saved for one
week
10 sequence programs 1000 alarms journaled
5 units in the AM 200 operator changes journaled
One Data Hiway 200 operator messages journaled
One NIM, 5 PMs, 2 LMs Standard CL-HM-file extensions
Relationships The estimator tables and the example tables relate like this
• The values on Table 7-12 were calculated using Table 7-9
Total HM memory The total HM memory required in this example is 270,578 KB. Here
required is how this relates to each of the types of HMs in use.
Table 7-7 Example Memory Required vs. Drive Capacity

HM Type Single Drive Percentage of Dual Drives Percentage of
HM Capacity HM Capacity
Wren I I I 135,900 KB 199 % 271,800 KB 100 %
WDA 215,040 KB 126 % 430,080 KB 63%
210
WDA 445 454,130 KB 60 % 908,260 KB 30%
The data for this example won't fit on the first three HMs listed above.
For the other HM versions, you should expand the volumes that
contain variable data so that about 90% is allocated to accommodate
future expansions (see the guidelines for using HM resources in 7.2).

7.4.3 Applying Volume-Size Estimates to Forms and Data
Entry
Preparation See our examples shown in Tables 7-18 through 7-20. If you
accumulate your HM configuration data in a form similar to the way
we did for those examples, you will have the data readily available
that will be needed to fill out HM Volume Configuration Form,
SW88-517. Refer to Network Configuration Forms, which contains
SW88-517.
Value sources for Table 7-15 relates each line item on form SW88-517 to the source of
volume configuration the value for that item. Each of these items also appears on the
corresponding Network Configuration/Volume Configuration Display
(without the line numbers). Of the nine volume-configuration
displays, eight are called up only if you intend to configure the data
each display represents on the HM you are configuring. The Volume
Configuration Menu appears when you select
VOLUME CONFIGURATION on the Engineering Main Menu, so you
must fill in lines 1 through 9a on a copy of the form for each HM.
Picks on the Volume The following are the seven picks (targets) on the Volume
Configuration menu Configuration Menu that select the other displays, with the name of
the display selected:
Table 7-8 Picks on Volume Configuration Menu

Pick Display/Form-Part
PROGRAM IMAGE Program Image Volume Configuration
Area Database Volume Configuration

CHECKPOINT Physical Node for Checkpoint Node
Configuration
CONTINUOUS HISTORY Continuous History Units and Groups,
Continuous History Group Options
JOURNALS Process Unit Journal Configuration
CL STORAGE Program Image Volume Configuration
USER FILE STORAGE User File Storage Configuration

7.4.3 Applying Volume-Size Estimates to Forms and
Data Entry, Continued
Transferring data to Copy a set of the forms for each HM, fill out the Volume
the forms Configuration Menu part of the form, and then fill out only the other
parts of the forms that represent data you intend to have on the HM
you are configuring.
What calculates HM For some volumes, Form SW88-517 and the configuration displays
volume sizes require you to fill in a volume size and number of files. For other
volumes, the HM Checker (initiated by F1=CHECK) calculates the
volume size and number of files, based on other types of input
information. Table 7-15 defines the source of the input for each line
on Form SW88-517.

7.4.4 HM Volume Size Estimator Tables and Figures
Table 7-9 HM Volume Size Estimator
Volume Volume Use Size Estimate
&0np (S) System Volume (& System Directories): 6100 KB
Startup files (&ASY, &DSY, &LDR &KJF,
&KFO) 5600 KB
GDFs (&AMG, &ARG, &HGG, &NMG) 11700 KB Total
&1np (S) Personality Images other than HM HG* 2100 KB

NIM* 2100 KB 2100 KB for each NIM
personality type, plus
PM/APM/HPM/FSM/LM/SM/FB-IOPs 23750 KB 23750 KB for other UCN
devices.
AM* 2100 KB
CG* 2450 KB
US Operator Personality* 3850 KB
US Universal Personality 4550 KB
UNP Overlays 4000 KB 4550 KB per UNP
personality type, plus 4000
NG* 2100 KB KB for one set of UNP
overlays
* There may be both 68020 microprocessor Total
and 68040 microprocessor versions of these
personalities in the system (cluster). If so, Total—Use the sum of all
include both personalities (two times the node-type images to be
value given) in your estimate, for each such stored on a specific HM.]
case.
&2np (S) Dump volume Mw
CG 2.0 6500 KB
HG 2.0 6500 KB
NG 2.0 6500 KB
NIM 3.0 7000 KB
HM 3.0 7000 KB
HG 2.0 6500 KB
US 4.0 9000 KB (US with Operator Personality)
US 6.0 13500 KB (US with Universal Personality)
US 8.0 18000 KB (US with Universal Personality)
AM 3.0 7000 KB
AM 4.0 9000 KB
AM 5.0 11250 KB
AM 6.0 13500 KB
AM 7.0 15750 KB
AM 8.0 18000 KB
AM 16.0 36000 KB
Make the Dump Volume large enough to If the Dump Volume for a node type is
accommodate the total number of nodes you used, it must be on the same HM as the
plan to dump at one time. The minimum corresponding Personality Image (&1np).
allowable Dump Volume size is 7000 KB. NOTE: All K4 LCNs are at least 4 Mw.
The estimated number of KB is arrived at
by multiplying 2250K by the number of
Mw(Megaword) for the node type.

7.4.4 HM Volume Size Estimator Tables and Figures,
Continued
Table 7-9 HM Volume Size Estimator, continued

&3np (C/A) Area Total size estimate = (1198 KB * (no. of areas + 1))
+ (150 KB * number of schematic source files)
+ (12 KB * number of schematic object files)
+ (80 KB * number of free format log source files)
+ (5 KB * number of free format log object files)
These file size estimates are rules of thumb; your files may be larger
than the estimates given here. Increase your estimates accordingly.
Configuration considerations: For quicker access to schematics and
free format logs, Honeywell recommends that you put these object files
into the Fast Access User Volume on an HM. See section 23.5.3, Fast
Access User Volume. NOTE: these files will not automatically be
copied by FST_VOLZ.EC. IF you move to Fast Access User Volume,
you must edit your FST_VOLZ.EC to copy the required schematics to
the Fast Access User Volume disk.
You can also build your area database using the pathname catalog to
have schematics and free format log object files, to ensure availability
in the event that the primary HM goes down. You can also put these
object files on removable media to ensure availability of the files.
Some users put their schematics in User volumes as system-wide
object files, to make them available to all the users on the system. If
you do this, apply the size estimates to the User volumes, not the Area
volume.
If HM space is limited, keep the object files on an HM and store the
source files on removable media. See Note 2, Table 7 -10.
&4np (C/A) CL/MC Object Total size estimate = (4.5 KB * number of sequences)
Files This figure assumes an average of 300 statements per sequence. If
your average is different, use 0.015 KB per statement and multiply by
the average number of statements per sequence.
If HM space is limited, you can store CL source files and listings on
another HM volume or on disks.
Configuration consideration: Like the note in &3np, if you choose to put
your CL/MC object files in a different volume, do not estimate space for
this volume.
&5np (C/A) AM Checkpoint See “AM Checkpoint Values” in the notes at the end of this table.
&6np (C/A) CG Checkpoint See “CG Checkpoint Values” in the notes at the end of this table.
&7np (C/A) HG Checkpoint 2146 KB used by each Data Hiway. This size is fixed; you can’t alter it.
Notes: (S) System (LCN wide) data, mostly of fixed size. Volume &0np can only be stored in one HM. We
also recommend that each of the other system data volumes be stored in only one HM.
(C/A) Cluster/Area-related data, all vary in size. All are candidates for splitting between HMs. All
K4LCN boards contain at least 4 Mw of memory.
To get the estimated number of KB, multiply 2250 K by the number of Mw for the node type.
K = 1024; KB = 1024 bytes; 1 MB (megabyte) = 1024 KB; 1 Mw (megaword) = 2 MB.

Continued

&8np (C/A) NIM/PM/APM/HPM/LM/SM
Checkpoint
Sectors per NIM SecPerNim = 11575 + (# of PMs * 2212) + (# of LMs *
2074)
+ (# of APMs * 7712) + (# of HPMs * 16012)
+ (# of SMs * 4012) + (# of FSM * 4012)
+ (4 future UCN nodes * 4012)
+ (# of FBIOPs * 1410)
Calculate KB per NIM KBPerNIM = Sectors * 0.25
Calculate final KB estimate Final_KB = KB per NIM * # of NIMs * 1.2
Where:
# of PMs = Maximum planned number of PMs per NIM
# of LMs = Maximum planned number of LMs per NIM
# of APMs = Maximum planned number of APMs per NIM
# of HPMs = Maximum planned number of HPMs per NIM
# of SMs = Maximum planned number of SMs per NIM
[Total of 31 PMs, LMs, APMs, HPMs, and SMs per UCN
(per NIM)]
# of NIMs = Number of NIMs on this LCN
(20 NIMs max.; combined NIMs and HGs ≤ 20)
Redundancy example:
If the system has a redundant NIM, 4 redundant
PMM, 4 redundant APM, 2 redundant LMM, 4
redundant HPM, 2 non-redundant SMM, and 4
FB IOPs.
The equation would be:

1 NIM checkpoint size (=11575) + (4 PMM *
2212) + (2 LMM * 2074) + (4 APM * 7712) + (4
HPM * 16012) + (2 SMM * 4012) + (4 future *
4012) * (4 FBIOPs * 1410)

Continued

&9np (C/A) PM Seq (in all PMs) 1 Seq (prog). = Avg. of ~300 statements @ 0.03 KB/statmt
Therefore, estimate = 9.0 KB per sequence.
APM/HPM Seq (in all 1 Seq (prog). = Avg. of ~300 statements @ 0.038 KB/stat.
APMs and HPMs) Therefore, estimate = 11.4 KB per sequence.
LM Ladder Logic prog. Ladder Logic prog. = (Mem. size of all LMs * 4) + (9.6 * #
of LL programs) = Estimated KB per LM.
Total LMs + 100 = Volume Size in KB.
Total for &9np =(amt. from PM seq + amt. from APM seq +
amt. from HPM seq + amt. from Ladder Logic prog. + amt.
from FSC SM Control program). Also see note.
Note: Count each redundant LM pair as one LM.
SM-Tricon Ladder Logic prog. = N/A. Safety Manager

SM-Tricon Ladder Logic does not support LCN checkpointing of its Control
prog. Program.
Control program = 1000 KB * # of Control programs.
FSC SM Control program
Notes: Available LM Memory Size
(in K words [24 bits])
620-035 32 Kw If memory size is unknown or there is a possibility of a future
expansion, you can use the maximum size shown here.
We recommend that you store CL source files and listings on
another HM user volume or on removable media.
(C/A) Cluster/Area-related data, all vary in size. All are candidates for splitting between HMs.

Continued

!0np Continuous History Volume Size = Online files size + Prearchive files size + Reserve file
!1np space
Base Sectors NCCR * 314

+ 276 * (FCHSG + TCHSG + TWCHSG + SCHSG)
+ 278 * CHG
Snapshot Sectors (2580 * FSSG) + (1290 * TSSG) + (645 * TWSSG) + (215 * SSSG)
sectors
86 sectors * UAG
User Averages
Snapshot Pre-Archive (Total number of groups for this rate) (6000/X + 25 * X)
+ (1500/X) * (total hours for this rate)
5 second 1205 * FSSG + 300 * (Total 5 sec. snapshot hours configured)
10 second 605 * TSSG + 150 * (Total 10 sec. snapshot hours configured)
20 second 305 * TWSSG + 75 * (Total 20 sec. snapshot hours configured)
60 second 105 * TWSSG + 25 * (Total 60 sec. snapshot hours configured)
User Averages [ (60/UA * PAU (1) + 4) + 1) +
Pre-Archive (60/UA * PAU (2) +4) + 1) +
(60/UA * PAU (n) +4) + 1) ] sectors
Reserve file space for R500 300 KB and 6 extra files
Where: Is Defined As:

x Collection rate (5, 10, 20, or 60 seconds)
y Number of records per minute (5 sec. = 12, 10 sec = 6, 20 sec = 3, 60 sec =1)
CHG Total number of Continuous History groups
FCHG Total number of 5 second Continuous History groups
TCHG Total number of 10 second Continuous History groups
TWCHG Total number of 20 second Continuous History groups
SCHG Total number of 60 second Continuous History groups
FCHSG (FCHG/15) rounded up
TCHSG (TCHG/15) rounded up
TWCHSG (TWCHG/15) rounded up
SCHSG (SCHG/15) rounded up
FSSG Number of 5 second CH groups configured for snapshots
TSSG Number of 10 second CH groups configured for snapshots
TWSSG Number of 20 second CH groups configured for snapshots
SSSG Number of 60 second CH groups configured for snapshots
PASS (n) Hours configured for pre-archiving for snapshots in group n
NCCR Number of configured collection rates (1- 4)
UAG Number of CH groups configured for user averages
UA Number of minutes configured in the user average interval
PAU (n) Number of hours of pre-archiving for user averages in group n
Note: To Calculate the optional Pre-Archive values

• Use a spreadsheet and perform the calculation once for each group, or
• Multiply the average number of hours per group by the number of groups. Add in an error factor.
If all history groups have the same number of prearchive hours and the same Save Data Rate (5, 10, 20, 60
sec. intervals), simply calculate once and multiply by the number of snapshots and user average groups.
Otherwise, make individual calculations for each group and add up the total number of sectors.

Continued

!2np Journals
(S) (note 1)
Burst events Sectors = ((BurstEvnts * 61 * 1.5 + 122)/123) + 1
(S) (note 2)
System status changes Sectors = ((StatChg * 61 * 1.2 + 122)/123) + 1
(S) (note 2)
System errors Sectors = ((Errors * 61 + 122)/123) + 1
(S) (note 2)
System maintenance events Sectors = ((MaintEvnts * 61 + 122)/123) + 1
(C/A)
Alarms (per process unit) Sectors = ((Alarms * 82 + 122)/123) + 1
(C/A)
Process chgs. (per proc. unit) Sectors = ((ProcChgs * 61 * 1.5 + 122)/123) + 1
(C/A)
Operator msgs (per proc unit) Sectors = ((OprMsgs * 61 * 3 + 122)/123) + 1
(C/A)
Area Sequence of Events (per area) Sectors = ((Area SOE Msg * 61 +122)/123) +1
Calculate total sectors Add up the system sectors (burst events, status
changes, system errors, maintenance events).
Next, add the per-process-unit sectors (alarms,
process changes, operator messages, SOE
messages) to the system-sectors total. You can
either calculate and add up the sectors for each
individual unit, or you can use the average
number of events for each of the three types and
multiply the sectors for all three by the number of
process units in each HM.
NOTE: SOE messages must be on the same
HM as the process chgs.
NOTE: If the AM/CL Process Change events are
to be stored (Release 650 and later), care
should be taken in deciding the number of
Process Change events (ProcChgs).
For more information on Journal AM/CL Process
Changes, see Appendix J in AM/CL Reference
Manual.
Calculate final KB estimate KB = Total sectors * 0.25

Continued

!4np Maintenance-support software 310 KB
(S) (note 2)
!9np HM Local Volume (Image)
(S) (note 3) without &HMI 3486 KB (See the notes at the end of this table.)
with &HMI 4886 KB
User See Table 7-10 If HM space is limited, the number and size of
Volumes HM user volumes can be kept small by keeping
(C/A) only current data in them and storing long-term
data on removable media.

Continued

Notes: (S) System (LCN wide) data, mostly of fixed size. Volume &0np can only be stored in one HM. We
also recommend that each of the other system data volumes be stored in only one HM .
Note 1: System data that resides on all journal HMs.

Note 2: System data that can only be stored in one HM.
Note 3: System data that resides in all HMs.
Total configuration and data space available (K = 1024)
HM with One drive Two drives
WREN III 135,900 KB 271,800 KB
WDA 210 MB 215,040 KB 430,080 KB
WDA 445 MB 454,130 KB 908,260 KB
WDA 1.8 GB 1,836,736 KB 3,673,472 KB
To estimate the system-file space in each HM, consider which of the system (S) volumes you assigned
to which HM in the Volume Configuration portion of Network Configuration (System Startup Task 10).
If HM space is limited, you can choose not to store all files mentioned in this table in HMs. For example,
files not required for “on process” operations, such as schematic source files in volume &3np, could be
stored only on disks. It is possible to omit the HM Initialization Personality (&HMI) in volume !9np, but we
strongly recommend that you include this space on all HMs, so that the HMs can automatically switch to
off-line if a startup problem occurs.
AM Checkpoint Values
Checkpoint volume space for each AM = UM + UOH - UCPBS + MCDS + CL where:
UM = User Memory = 1986 KB for a 3.0 Mw AM
3948 KB for a 4.0 Mw AM
UOH = Unit Overhead = 28.7 KB * (number of units in this AM + 1)
UCPBS = Uncheckpointed Buffer Size = MEMCVBNX*0.034 KB
MEMCVBNX = Current-value-buffer memory size (for more information, see Section 6 in
Application Module Implementation Guidelines, binder TPS 2035-1). A user-adjustable value
with a default value = 4000 words.
MCDS = Multiple CDS Size; if this AM doesn't have any CDSs attached to points in two or more
units, use 0; otherwise use 104.8 KB, unless you have a very clear understanding of your use of
Custom Data Segments and you need a very accurate estimate of the checkpoint volume size.
If you need to calculate it:
MCDS = [(MCD*0.026 KB) + (MCDP*0.04 KB)]*(AUWCSD - 1)]
MCD = number of CDSs attached to points in different units
MCDP = total number of parameters in all the MCD CDSs attached to points in different units.
AUWCDS = Average number of units that have the same CDSs. For example, if a CDS is
attached to four points, each of which is in a different unit in this AM, and another CDS is
attached to two points, each of which is in a different unit in this AM, then:
4+2
AUWCDS = 2 =3

Continued

Notes: AM Checkpoint Values (Continued)
This is how the recommended MCDS value, 104.8 KB, is calculated:
MCD = 100 CDSs
MCDP = 4000 parameters
AUWCDS = 2 units
MCDS = [(100*0.048) + (4000*0.05)]*(2 - 1) = 104.8 KB
CL = the size of the CL object code, in KB, in the unit with the largest number of CL object words.
no_words * 2
To convert words to KB: KB = 1024
S) System (LCN wide) data, mostly of fixed size. Volume &0np can only be stored in one HM. We also
recommend that each of the other system data volumes be stored in only one HM .
The estimated number of KB is arrived at by multiplying 2250 K by the number of Mw for the node
type.
The size of the CLs cannot be determined until after they are compiled. This requires the AM to be
up and running, which in turn requires the checkpoint to be loaded. Therefore, to determine the size
to allocate for the checkpoint, use the formula CL=(User Memory * 2). This is the maximum allowed
size. This size may be adjusted later when the CL sizes are known.
Note: Where a calculation results in a fraction of a KB, round up to the next KB. Then, to assure plenty
of space for your CLs, add the size of your largest unit a second time.
AM checkpoint volume size example: one 4.0 Mw AM, five units, MEMCVBNX = 2000, no CLs
UM = 3436 KB UCPBS = 2000 * 0.034 KB = 68 KB
UOH = 28.7 KB * (5 +1) = 172.2 KB MCDS = 104.8 KB
Checkpoint volume space for this AM = 3436 + 172 KB - 68 KB + 105 KB + 6872 KB = 10517 KB
CG Checkpoint Values
Checkpoint volume space for each CG = UM + UOH + MCDS + 44 KB
Where:
UM = User Memory = 1716 KB
UOH = Unit Overhead = 2 KB*(number of units in this CG/CM +1) + TCDSPFU
MCDS = Multiple CDS Size = [(MCD*0.041 KB) + (MCDP*0.04 KB)]*(AUWSCD-1)
And where:
TCDSPFU (for each unit) = Total CDS parameters for the unit = (0.054 KB*CDSs)+(0.042 KB
*PARAMS)
PARAMS = number of unique parameters in all CDSs for this unit, that is, count each parameter
used in one CDS and each parameter used in more than one CDS as a unique parameter.
MCD = Number of CDSs attached to points that are in more than one unit.
MCDP = Number of parameters on all of the CDSs included in MCD.
AUWCDS = Average number of units with the same CDSs.
For example, if one CDS is attached to four points, each of which is in a different unit, and one
other CDS is attached to two points, each of which is in a different unit, then:
4+2
AUWCDS = 2 =3

Continued

CG Checkpoint Values Continued)
Note: Where a calculation results in a fraction of a KB, round up to the next KB.
Example: for a CG with 4 units, 3 CDSs attached to points in more than one unit, 8 unique
parameters in the CDSs in each unit, and the average number of units with the same CDSs is 3:
UM = 1716 KB
UOH = 2 KB*(4 + 1) + TCDSPFU(1, 2, 3, 4) = 10 KB + 2 KB = 12 KB
MCDS = [(3*0.041 KB) + (17*0.04 KB)]*(3-1) = 1.616 KB, round up to 2 KB
PARAMS = 8
MCD = 3
MCDP = 17
AUWCDS = 3
TCDSPFU (1) = (0.054 KB*3) + (0.042 KB*8) =0.498 KB
TCDSPFU (2) = (0.054 KB*3) + (0.042 KB*8) =0.498 KB
TCDSPFU (3) = (0.054 KB*3) + (0.042 KB*8) =0.498 KB
TCDSPFU (4) = (0.054 KB*3) + (0.042 KB*8) =0.498 KB
Sum of the four TCDSPFU values = 1.992 KB — round up to 2 KB
Checkpoint volume space for this CG = 1716 KB + 6 KB + 2 KB + 44 KB = 1768 KB

Continued
User Volume Size The following table allows you to estimate the size of your user
volume or directory, based on the files you plan to allocate to this
area of the History Module:
Table 7-10 HM User Volume or Directory Size Estimator
Recommended Minimum Estimated Function Size Number of Files
User Volumes or Directories
Data Entity Builder IDFs (Note 1) See Table 7-11 See Table 7-11
Exception-building source 225 KB per each 1000 entities (points) 35 per each 1000 entities
Schematics and Free-Format 162 KB per schematic 7 * number of schematics
Logs (Note 2) 85 KB per Free Format Log 7 * number of Free Format
(includes support files) Logs
Execute Command (EC) files Approx. 0.05 KB per text line, per file. The maximum number of
For example, 50 lines, 20 files = 50 * .EC files you expect to use
0.05 * 20 = 50 KB
CL/AM source, object, and 14.4 KB per 60-statement CL program 5 * number of CL programs
listing files
(Optional) CL/MC source, 90 KB * number of sequences 3 * number of sequences
object, and listing files (assumes an average of 300
statements per sequence)
(Optional) CL/PM source, 108 KB * number of sequences 3 * number of sequences
object, and listing files (assumes average of 300 statements
per sequence)
Std. AM/CL-HM-file ext’ns 125 KB, minimum (Note 3) 3, minimum (Note 3)
Notes:
1. You may need more than one directory for IDFs. See Table 7-11.
2. This is a workspace directory for approximately 10% of all of your schematics and Free Format logs. If HM
space is limited, you can create a permanent HM directory in a User volume or Area volume (&3np) and
copy the object files there for on-line use. The space needed is shown at &3np on Table 7-9. You can tell
the system where to find these directories when you configure the Path Name Catalog in Area Database
Configuration. After copying the object files to this permanent directory, copy the source files to a disk, and
delete the files from the workspace directory.
3. If optional CL extensions, AM custom software, or Background CL blocks are purchased, you must allow
additional user-volume space. Typically, an additional 10 to 50 KB is adequate, but refer to the special
documentation provided with these products for further information.

Continued
Table 7-11 IDF Volume or Directory Size Estimator

Points per Number of
Point Type Floppy Memory Size in KB Files Needed
(Note 2) (Note 2)
HG Points
CB 72 5.25 * number of CB points (number of CB points/72) * 6
DHP 85 4.5 * number of DHP points (number of DHP points/85) * 6
EC 56 6.75 * number of EC points (number of EC points/56) * 6
PIU 100 3.75 * number of PIU points (number of PIU points/100) * 6
MC 72 5.25 * number of MC points (number of MC points/72) * 6
AM Points
AM (Note 3) 45 8.25 * number of AM points (number of CIU points/45) * 6
CG Points
CG 175 2 * number of CIU points (number of CIU points/175) * 6
PM/NIM Points
Analog Input 110 9 * number of points (number of points/110) * 6
Analog Output 110 9 * number of points (number of points/110) * 6
Digital Input 105 9.5 * number of points (number of points/105) * 6
Digital Output 105 9.5 * number of points (number of points/105) * 6
Digital Composite 140 7 * number of points (number of points/140) * 6
Regulatory PV 105 9.5 * number of points (number of points/105) * 6
Regulatory Cntl. 95 10.5 * number of points (number of points/95) * 6
Logic 50 20 * number of points (number of points/50) * 6
Flag 110 9 * number of points (number of points/110) * 6
Timer 120 8 * number of points (number of points/120) * 6
Numeric 120 8 * number of points (number of points/120) * 6
Proc. Module 130 7.5 * number of points (number of points/130) * 6
Floppy volumes needed = Sum of All Files from “Files Needed” Column/500 (see note 4)
Directory (HM) or Volume (Disk) Size: Add the values from the “Memory Size” column for each
set of files that you assign to a directory or volume.
Notes:
1. It's convenient to store IDFs on an HM, but they can be stored on disks if you need the space for
something else.
2. The sizes in these columns are set up so that you can copy HM IDFs for each point type to a disk
backup. The sizes allow the IDFs and support files to fit on one disk.
3. In AM IDFs, include all points referenced by the AM points and calculate the IDF size accordingly.

Continued
Table 7-12 Example—Small System, One Area, One Cluster

Volume Data Type Size Estimate Notes
&001 System volume; 11700 KB One &0np volume per system.
system-wide data (“np” is the node-pair number of
the HM this volume is stored in.)
&101 Personality Load 66250 KB This system has space reserved
Image volume; for all possible LCN nodes.
system-wide data
&201 Dump volume; 36000 KB Largest node memory in this
system-wide data system is a 16 Mw AM.
&301 Area volume; 1198 KB One area
area-related data 15000 KB 100 schematic source files
1200 KB 100 schematic object files
32000 KB 400 free format log source files
2000 KB 400 free format log object files
Total = 51398 KB Total (with directory space for
1010 files)
&401 CL/MC object 4.5 KB * 10 = 45 KB 10 sequence programs in MCs
volume; cluster-
related data
&501 AM checkpoint UM+UOH-UCPBS+MCDS + CL= One 4.0 Mw AM, 5 units,
volume; cluster- 3948 + 173 - 68 + 105 + 7896 = MEMCVBNX = 2000, default
related data 12054KB value for MCDS, max. size for
CL
(CL= UM * 2)
&601 CG checkpoint 0 KB No CG in this system (cluster)
volume; cluster-
related data
&701 HG checkpoint 2146 KB One Data Hiway in this system
volume; cluster- (cluster)
related data
&801 NIM checkpoint SecPerNIM = 11,367 + One NIM with 5 PMs and 2 LMs
volume; cluster- (5 * 2212)+ (2 * 2072) = 24819
related data KBPerNIM = 24819 * 0.25 =
6204.75 KB
Final KB est. = 6205 * 1.2 =
7,971 KB
&901 CL/PM obj/LL 9.0 * A + ((C*4) + (9.6 * B))*D + A = 10 sequence programs in
volume; 100 = 787.2 KB PMs
B = 1 ladder prog. per LM
C = Memory size of 96.0 KB
D = 2 LMs

Continued
Table 7-12 Example—Small System, One Area, One Cluster, continued

!001 Continuous Refer to Table 7-9 Total 5 sec. hist groups = 1
!101 history volumes; Total 10 sec. hist groups = 9
cluster-related Base sectors = 2686 Total 20 sec. hist groups = 10
data Snapshot sectors = 23485 Total 60 sec. hist groups = 15
User avg. sectors = 3010
Hourly Averages 6020 5 sec. hist grps config as snapshots = 1
Shift Averages 1540 10 sec. hist grps config as snapshots = 9
Daily Averages 1190 20 sec. hist grps config as snapshots = 10
Monthly Averages 525 60 sec. hist grps config as snapshots = 15
Pre-arch user avg sectors 60235
Total pre-arch sectors 477475 Total of al 5 sec. grps config as pre-arch
5 sec snapshot sectors 51005 snapshots = 4
10 sec snapshot sectors 232245 Total of al 10sec. grps config as pre-arch
20 sec snapshot sectors 129050 snapshots = 9
60 sec snapshot sectors 64575 Total of al 20 sec. grps config as pre-arch
Total sectors = 604974 snapshots = 10
Calculated tracks = 18906 Total of all 60 sec. grps config as pre-arch
Final KB est. = 151248 snapshots = 15
Point per second = 37 Number of configured collection rates = 4
All Groups: Total cont hist grps this HM = 35
Prearchive hrs. for snapshots = 168 User average interval config in System
Prearch. hrs. for user averages = 168 ‘Wide Values = 6 min.
!201 Journal volume; Refer to Table 7-9 16 process units, 16-char. tag names
cluster/area-
related data Burst event sectors = 5581 7500 burst events
Sys.status chg.sectors = 4169 9999 system status changes
System errors sectors = 3335 9999 system errors
Sys.Maint.vent sectors = 3335 9999 system maint. events
Process alarm sectors = 80002 7500 process alarms per unit (16 units)
Process chg. sectors = 80002 7500 process changes per unit (16 units)
Operator msg sectors = 80002 3000 operator msgs per unit (16 units)
SOE event sectors = 5002 7500 SOE events
Total sectors (+ 3-5 %) = 261428
261428 * 0.25 = 65357 KB
Final KB est. = 65357 KB
!401 Maintenance-
support 310 KB
software,
system-wide
!901 HM Local 4886 KB Includes the HM initialization image, &HMI

Volume;
contains the
software for this
HM.

Continued
Table 7-12 Example—Small System, One Area, One Cluster, continued

Total HM Space Needed:
&001 = 1170 KB &401 = 45 KB &901 = 977 KB !901 = 4886 KB

&101 = 62050 KB &501 = 12054 KB !001/!101= 151248 KB User volumes
(Table 7-14) = 154575 KB
&201 = 36000 KB &601 = 0 KB !201 = 68473 KB
&301 = 51497 KB &701 = 2146 KB !401 = 310 KB Grand total = 552877 KB
&801 = 7446 KB
Total System Data (S) = 120257 KB
Total Cluster/Area Data (C/A) = 432620 KB
Notes:
The maximum size of NCF.XX and ERRBK.XX files is 500 KB each.
Table 7-13 Example—IDF Volume Estimate (approximately 5 HCUs)

IDF Type Number of Points Memory Size Number of Files Needed (Note 1)
CB 70 5.25 * 70 = 367.5 70/72 * 6 = 5.8 6 Files
EC 45 6.75 * 45 = 303.75 45/65 * 6 = 4.8 5 Files
PIU 330 3.75 * 330 = 1237.5 330/100 * 6 = 19.8 20 Files
AM 325 8.25 * 325 = 2681.25 325/45 * 6 = 43.3 44 Files
Total Points = 770 Pts. Total for IDFs = 4590 KB Total Files = 75 Files
Volumes needed = 66/500 < 1, but for convenience in volume naming,
we'll use four volumes (CB, EC, PIU, and AM).
Notes (from “Adjustment factors,” in 7.4.1):
1. We suggest that you specify the number of files for IDF volumes at size times the number of IDF files
expected because of the supporting files generated, particularly when errors occur.

Continued
Table 7-14 Example—User Volumes, Small System, One Cluster, One Dual HM
User Volume Volume Size Number of Files
Data Entity Builder From Table 7-13; 4 volumes= 4590 KB From Table 7-13; Total of 75 Files
IDFs
Exception Building 770 < 1000, so estimate 225 KB 770 < 1000, so use: 35 Files.
source files (.EB)
Schematics and Free 132 KB * 1000 schematics = 132000 KB 1000 * 7 (Note 2) = 7000 Files
Format Logs 55 KB * 300 FF logs = 16500 KB 300 * 7 (Note 2) = 2100 Files
Execute commands 50 KB 20 Files

CL/AM Files (Note 3) 14.4 KB * 10 CL programs = 144 KB 10 * 5 (Note 3) = 50 Files
CL/MC Files 90 KB * 10 CL sequences = 900 KB 10 * 3 = 30 Files
CL/AM Custom 8.2 KB * 5 CDSs = 41 KB 3 * 5 = 15 + 5 (Note 4) = 20 Files

GDFs
Std CL/AM-HM-file 125 KB 3 (directories &CUS and &CLX)
extensions
User Volumes Total: 154575 KB
Notes (from “Adjustment factors,” in 7.4.1):
2. We suggest that you specify the number of files for the schematic volume at seven times the number of
schematics expected to support the source, object, and library files for subpictures.
3. We recommend that you specify the number of files in the CL volume at five times the number of CL
programs expected.
4. Specify the number of files in the CL-Custom GDF volume at the number of custom data segments, plus the
number of custom parameter lists expected.

Continued
Volume configuration This info. is needed for form SW88-517 It is entered into the Volume
Configuration display. Line No. in the table is the line on the form.
Table 7-15 Value Sources for Volume Configuration
Line
No. Item Volume Value Source
Volume Configuration Menu Display

1 Node Pair Number - Network Configuration, LCN Nodes
2 Number of Winchester Disks - 1 or 2 from system documents
3 Disk Type/Size - 3 or size of WDA in KB (that is 215040 or
454130; see Table 7-7)
4 HM Init Personality !9np “Yes” if included in !9np estimate
5 System Volume &0np “Yes” if included in &0np estimate
6 GDF Files Included &0np “Yes” if included in &0np estimate
7 File Manager Descriptors? &0np “Yes” if you want system volume file descriptors
8 Area SOE Journal Size !2np “Yes” if area SOE configured for journals
9 Burst Buffer Size… !2np !2np estimate for Burst Buffer
10 System Unit Journals? !2np “Yes” if included in &!2np estimate
10a Status Change, Error, Maint !2np Enter the values used for your !2np estimate
Program Image Volume Configuration—Select Node Display
31 Select All Node Types that apply !1np Select all node types on this LCN. “II” means
nodes that have 68040 microprocessors
33 Hist. Mod. Dump Volume &2np Select if dump volume is to be on this HM
33 Dump Volume Size (KB) &2np Enter value selected for &2np from Table 7-9
Area Data Volume Configuration Display
41 File Manager Descriptors? &3np “Yes” if you want area volume file descriptors
42 Area Name &3np Network Config., Area Names
42 Volume Size &3np &3np estimate partitioned for each area on this
HM (normally one)
42 Number of Files &3np No. of files in &3np estimate, partitioned for
each area, plus approx. 10%

Continued
Table 7-15 Value Sources for Volume Configuration, continued

Line
Physical Node for Checkpoint Configuration Display

51 Node Number &5np-&9np Enter node number for each node to be
checkpointed
51 Volume Size &5np-&8np &5np-&8np estimate for each node
51 Number of Files &5np-&8np Enter 0 for HGs; each AM needs (5 * no. of units +2)
files; each CG needs (no. of units + 1) * 4 files; each
NIM needs (4 * no. of UCN nodes) + 4 files
Continuous History Unit and Groups Display

61 Unit ID !0np, !1np Net. Config., Unit Names
61 Number of Groups !0np, !1np Enter same number for each unit as it is/will be
configured in HM History Group Configuration (1 to
120)
Continuous History HM/Unit Options
66/67 Save Rate !0np, !1np Select 5, 10, 20, or 60 sec. collection frequency
66/67 Save Options !0np, !1np Select SNAPSHOTS, USER AVERAGE, or both for
each history group
66/67 Prearchive Hours— !0np, !1np Enter hours used for each group in your estimate for
Snapshots !0np and !1np (0 to 2,880)
66/67 Prearchive Hours— !0np, !1np Enter hours used for each group in your estimate for
User Average !0np and !1np (0 to 7,496)
66/67 Archive? - (not implemented)

Continued

Continuous History Group Options
Line

71 Unit ID !0np, !1np Network Configuration, Unit Names
71 Group Number !0np, !1np No entry required
71 Save Rate !0np, !1np Select 5, 10, 20, or 60 sec. collection frequency
71 Save Options !0np, !1np Select SNAPSHOTS, USER AVERAGE, or both for
each history group
71 Prearchive Hours— !0np, !1np Enter hours used for each group in your estimate for
Snapshots !0np and !1np (0 to 2,880)
71 Prearchive Hours— !0np, !1np Enter hours used for each group in your estimate for
User Average !0np and !1np (0 to 7,496)
71 Archive - Select NO (not available)
Process Unit Journal Configuration
81 Unit ID !2np Network Config., Unit Names
81 Process Alarm !2np No of process alarms in !2np estimate
81 Process Change !2np No of process changes in !2np estimate
81 Operator Message !2np No of operator messages in !2np estimate
CL Storage Volume Configuration (Sequences)
111 Hiway/Network &4np (Hwy), Data Hiway the MC is on, or UCN the PM is on, (0-20)
&9np (UCN)
111 Hiway File Manager &4np “Yes” if you want to enter descriptors for Hiway CL files
Descriptors
112 Network File &9np “Yes” if you want to enter descriptors for UCN CL files
Manager
Descriptors
113 Number of files &4np (Hwy), Enter the number of sequences used in the &4np or
&9np (UCN) &9np sequence estimates, plus the number of LM (or
ALM) ladder logic programs
113 Volume Size (KB) &4np (Hwy), &4np or &9np estimate
&9np (UCN)

Continued

User File Storage Configuration
131 Virtual Volume ID (user name) 4-character user name
Number of files (user name) Table 7-10 (1-9995)
Volume Size (KB) (user name) Table 7-10
131 File Manager &4np “Yes” if you want user volume file descriptors
Descriptors
Figure 7-3 Area Volume Size Estimator Chart
Area Chpnt. Vol. Size, add at least a 10% margin.
8000
7000
6000
5000 1 area
kb 4000 5 areas
3000 10 areas
2000
1000
0
0 50 100 150 200 250 300
Schematic Object Files
FF Log Obj. files = 100 15043
Notes: These values were calculated with the number of Free Format Log object files fixed at 100. If you have
significantly more or fewer Free Format Log object files, add or subtract the different at 5 KB per object file.
We recommend that you add at least 10% safety margin to the values you read off this chart. You should also
consider adding even more space for possible future expansion.

Continued
Figure 7-4 AM Checkpoint Volume Size Estimator Chart

80K
16Mw
70K
Legend
60K
16 Mw 71,700 - 72,700 Kb
50K 8 Mw 31,000 - 32,000 Kb
Kb 7 Mw 25,800 - 26,800 Kb
40K
6 Mw 20,700 - 21,700 Kb
8Mw 5 Mw 15,600 - 16,600 Kb
30K
7Mw
4 Mw 10,500 - 11,500 Kb
6Mw
20K 3 Mw 5,400 - 6,400 Kb
5Mw
4Mw
10K
3Mw
0
5 10 15 20 25 30 35 40
Units
Notes:
These values were calculated for one AM with the niumber of units indicated.
The recommended default value for MCDS, 104.8 Kb, is included.
We recommend that you add at least a 10% safety margin to the values yuou read off this
chart. You should also consider adding even more space for possible future expansion.
3702

Continued
Figure 7-5 NIM/PM Checkpoint Volume Size Estimator Chart
500000
450000
400000 1 NIM
350000
273,800 kb = Capacity of largest available HM 5 NIMs
300000
kb
250000 10 NIMs
200000 15 NIMs
150000
20 NIMs
100000
50000
0
0 5 10 15 20 25 30 35
Average No. of PMs per NIM
Notes:
These values were calculated using an average number of PMs for each NIM. If your
UCNs have widely different numbers of PMs, you may need to make an individual
calculation for each NIM and its UCN, rather than using this chart.
We recommend that you add at least a 10% safety margin to the values you read off this
chart. You should also consider adding even more space for possible future expansion.
See Figure 7-5 for a volume-size chart for PMs on one NIM and its UCN.
If you have a mix of PMs and LMs, using the "Average No. of PMs per NIM" axis
on this chart results in a somewhat larger volume size than is required. Figure 7-7
is a chart that shows volumes sizes for LMs, only, on a NIM and its UCN.
3703

Continued
Figure 7-6 NIM Checkpoint Volume Size Estimator Chart, 1 NIM

25000
20000
15000
kb
10000
5000
0
0 5 10 15 20 25 30 35
Average no. of PMs per NIM
Notes:
We recommend that you add at least a 10% safety margin to the values you read off this chart.
You should also consider adding even more space for possible future expansion.
See Figure 7-4 for a volume-size chart for up-to-32 PMs and up to 20 NIMs.
3704

Continued
Figure 7-7 NIM/LM Checkpoint Volume Size Estimator Chart, 1 to 32 LMs
18000
16000
14000
12000
kb
10000
8000
6000
4000
2000
0 5 10 15 20 25 30 35
Number of LMs per NIM
Notes:
We recommend that you add at least a 10% safety margin to the values you read off this chart.
You should also consider adding even more space for possible future expansion.
See Figures 7-4 and 7-5 for volume-size charts for NIMs with PMs on the
3705

Continued
NIM/APM Checkpoint The NIM/APM Checkpoint Volume Size Estimator Chart that
Volume Size follows reflects the following considerations:
• Values are calculated using an average number of APMs per NIM
• The base values are 1000 KB per APM and 1202 KB per NIM
• For the estimated APM KB size per NIM, the Y = MX + B formula
is used (B is always 0), that is:
(#APMs * 1000KB + 1 NIM *1202KB) * #NIMs = APM KB size
Example: for 10 APM per NIM for 20 NIMS:
(10 * 1000 KB + 1 * 1202 KB) * 20 = 224040 KB
If number of APMs If your UCNs have widely different numbers of APMs, you may need
varies to make an individual calculation for each NIM and its UCN, rather
than use this chart.
ATTENTION We recommend that you add at least 10% safety margin to the values
you read off this chart. You can add even more for future expansion.
Figure 7-8 NIM/APM Checkpoint Volume Size Estimator Chart
500000 KB
400000
1 APM
300000
10 APMs
20 APMs
200000
100000 KB
0
1 NIM 10 NIMs 20 NIMs
15044

Continued
Figure 7-9 Continuous History Vol. Size, Example 1

35000
30000
25000
No ssg/uag
20000 0 ssg, 20 uag

kb
15000 10 ssg, 10 uag
20 ssg, 0 uag
10000
5000
0
20 30 40 50 60 70 80 90 100 110 120
Total History Groups
Notes:
ssg = snap-shot grougs, uag = user-average groups.
All calculations are with fixed values of 168 prearchive hours, and a 5-minute user average period. Unless
the continuous-history values for this HM are quite similar to those used for these calculations, we
recommend that you use this chart only as a guide to the effect of configuration values on volume size.
2800

Continued
Figure 7-10 Continuous History Vol. Size, Example 2

100000
90000
80000
0 ssg, 80 uag
kb 70000 40 ssg, 40 uag
80 ssg, 0 uag
60000
50000
40000
80 85 90 95 100 105 110 115 120
Total History Groups
Notes:
ssg = snap-shot groups, uag = user-average groups
All calculations are with fixed values of 168 prearchive hours, and a 5-minute user average period. Unless
the continuous-history values for this HM are quite similar to those used for these calculations, we
2801

Continued
Figure 7-11 Journal Volume Size Chart, Example 1

140000
120000
100000 200
80000 2000
kb
60000 5000
9999
40000
20000
0
0 5 10 15 20 25 30 35 40
Process Units
Notes: This table lists the number of events of each type used to calculate each of the four value series:
200 2000 5000 9999
Burst events 400 2000 5000 9999
Syst status chgs 200 2000 5000 9999
System errors 200 2000 5000 9999
Syst maint events 200 2000 5000 9999
Alarms 200 2000 5000 9999
Process chgs 200 2000 5000 7500
Operator msgs 200 2000 3000 3000
Unless the journal values for this HM are quite similar to those used for these calculations, we
2802

Continued
Figure 7-12 Journal Volume Size Chart, Example 2

5500
5000
4500
4000
3500
3000
kb
2500
2000
1500
1000
500
0
0 5 10 15 20 25 30 35 40
Process Units
Notes: The number of events of each type used in the calculations for this chart are as follows:
Burst events 400
Syst status chgs 200
System errors 200
Syst maint events 200
Alarms 200
Process chgs 200
Operator msgs 200
Unless the journal values for this HM are quite similar to those used for these calculations, we
2803

7.5 Redundant HM Disk Option
Redundant disk drive HMs with Wren III or WDA disk drives can be configured with
configurations redundant Winchester disk drives, if the HM Disk Redundancy
Software option is purchased. When so configured, a failure or other
interruption of the operation of one disk drive is reported but does not
cause the HM to fail.
Synchronized “redundant partner” disk drives hold the same data
because, once synchronized, each write operation writes identical
data into both disk drives. A read operation is taken from only one of
the drives. If the read is unsuccessful, data is read from its redundant
partner and an alarm is raised.
Physical location of Two types of redundant disk drives are used with the HM. They are
redundant disk drives the physically larger Wren III drives and the new, large capacity
WDA drives. For redundant operation, the Wren III drives are
housed on large slide trays in two separate modules above the five-
slot HM electronics module.
The smaller WDA drives are located in small slide trays inside the
five-slot HM electronics module. The physical location of the slide
trays and their addresses for both designs are shown in Figure 7-13.

7.5 Redundant HM Disk Option, Continued
Figure 7-13 Physical Arrangement of Redundant Disk Drives
Drive 4
Address = 4
Drive A-2
Address = 5
Power
Supplies
Drive A-1
Address = 4 Drive 5
Address = 5
Redundant Single Drive HM (Wren III) Redundant Single Drive HM (WDA)
Drive B-2 Drive 4 Drive 2

Address = 3 Address = 4 Address = 2
Drive A-2
Power Address = 5
Supplies
Drive B-1
Drive 3
Address = 2
Address = 3
Drive A-1 Drive 5
Address = 4 Address = 5
Redundant Dual Drive HM (Wren III) Redundant Dual Drive HM (WDA) 11573
How the HM Redundant disk drives are recognized as such only if power is applied
recognizes redundant to both partners while the HM is started up. To prevent a single
disk drives
power supply failure from disrupting both redundant partners, each
drive in a redundant pair has its own power supply. Where four
drives are set up as redundant partners, each pair of drives has its own
power supply.
Fall-back operation Should one of the drives in a redundant pair need service, it can be
taken off-line (if it has not already failed), repaired or replaced, and
resynchronized, after which normal operation resumes. During the
time one of the disk drives is off-line, the HM continues to operate by
writing to and reading from the remaining drive.

7.5 Redundant HM Disk Option, Continued
WARNING WARNING—R400 (or later) software does not rebuild the entire
disk file structure after a redundant drive has been off-line. Instead,
volumes are checked for the latest undamaged files and those files are
restored on the redundant partner, regardless of its failed status.
DO NOT TURN POWER OFF ON A FAILED REDUNDANT

DRIVE WITHOUT INSURING EITHER IT OR ITS
REPLACEMENT HAS BEEN INITIALIZED BEFORE IT IS
RETURNED TO OPERATION.
Resynchronizing after For resynchronizing information, see Command Processor Operation

shutdown Manual.
Resynchronizing after If a History Module running HMO has been loaded with the HMI
change from HMI to personality, its redundant drive must be synchronized after HMO is
HMO
reloaded.

7.5.1 Configuring Redundant HM Disk Drives
Description HM disk drives can be redundant only if the HM Disk Redundancy

Software option is purchased. If so, that option is displayed in the
System Wide Values activity under Network Configuration.
Disk drive options are defined below. Whether a drive is a redundant

partner or not is determined by its SCSI-bus address, which is
selected by pinning in the HM (see History Module Service).
Table 7-16 Disk Drive Options

Address Address of
Options of Initial Redundant
Drive Partner Drive
One drive, no redundancy 5 None
Two drives, no redundancy 5 None
(twice the storage of one drive) 3 None
Two redundant drives 5 4
(same storage as one, nonredundant drive)
Four drives, two redundant pairs 5 4
(same storage as two, nonredundant drives) 3 2
Startup after The HM volumes for the drives (redundant or not) are established
configuration after Network Configuration is complete, when the HM is initialized
(refer to the System Startup Guide, Task 15 ). Software and data can
then be loaded into the HM, but the Initialization Personality (&HMI)
makes only the initial drive(s) on-line to receive this information.
The partner drive(s) receives its copy during synchronization.

7.5.2 Synchronizing Redundant HM Disk Drives
WARNING WARNING—R400 or later software does not rebuild the entire disk
file structure after a redundant drive has been off-line. Instead,

References For synchronizing information, see Command Processor Operation

manual:
• Get HM disk drive status
• Synchronize HM disk drive

7.5.3 Setting a Redundant HM Disk Drive Off-Line
Procedure A disk drive that needs service normally has FAILED status. If not,
you can use the Utilities' OFF command to set an HM disk drive off-
line for service or some other purpose. The OFF command is valid
only if the specified disk drive's status is OK (see 7.5.2 in this
manual) and it has a redundant partner whose status is OK.

References For more information, see Command Processor Operation manual:

• Set HM disk drive off-line

7.5.4 Servicing Redundant HM Disk Drives
Procedure Do not attempt to service a redundant HM disk drive unless the

system has issued a maintenance recommendation to do so. If so, use
the Utilities STA command to run the Command Processor and verify
that the affected drive's status is OFFLINE, WARNING, or
SEVERE. Use the Sector Reassignment feature to do this. If in
HMO, the drive must be offline. If in HMI, the drive may be online.
Sector reassignment You can use the SMCC (the System Maintenance Control Center) in
using R400 or later your TPS for online sector reassignment of redundant disk drives
running under release 400 (or later). This allows repair of the disk
without physically disconnecting the drive.
Sector reassignment For instructions on reassigning sectors, refer to History Module

reference Service, binder TPS 3060-2.
WARNING WARNING—Before you turn power off, disconnect, or remove a

disk drive in an operating HM (OK or DISKPROB status on the Node
Status display), be sure that it is the correct drive. When four drives
are in an HM, each pair of drives is served by a separate power
supply. If you are servicing one of the redundant pairs, both drives in
that side of the pair must be placed off-line before turning the drives'
power off.
The drive addresses range from 2 through 5 and correspond to the

address of the port on the SCSI bus that serves them. A label with the
port number should have been affixed to each drive as the port was
assigned. If you can't find such a label, refer to the system
documentation and local records to determine for sure which physical
drive is to be serviced. If you inadvertently shut down an on-line
drive, severe disruption to the process and the system could result.

7.6 HM Initialization
Description HM initialization is the process through which the volume

configuration is established on an HM. After the NETWORK
CONFIGURATION activity on the Engineer's Main Menu and other
related tasks are completed (refer to the System Startup Guide, Task 1
through Task 14, then proceed with HM initialization (Task 15).
Procedure HM initialization can be performed only when the HM is loaded with

its initialization personality (directory &HMI is the load source). The
actual initialization is triggered by using the F6 (INITIALIZE)
function button when doing volume configuration from the volume-
configuration display for a specific node pair.
When the HM is loaded with the initialization personality, files

located on the HM can be accessed by only the physical node path
form (PN:n>vdr>filename.sx where “n” is a node number,
“vdr” is a volume or directory name, and “sx” is the file type or
suffix).
It is essential that files you want to save be copied to another HM, or

on disks, before HM initialization is performed. If the configuration
of continuous history or journal volumes is changed, existing volumes
of those types that were copied before the volume changes cannot be
restored afterward. Doing so destroys the new configuration. If you
need to preserve continuous history or journals, you must defer those
types of volume-configuration changes. Refer to 7.7 in this manual
for required procedures for saving and restoring continuous history.
CAUTION—When the HM is initialized, the file data it contains is

CAUTION .
lost regardless of whether a change was made to the volume

configuration.

7.6.1 Local HM Network Volume Configuration File,
Lnp_NVCF.MM
Description Loading the &HMI does not in itself initialize the HM; only the F6
(INITIALIZE) operation from the volume-configuration display for
that node pair starts the actual initialization. When the HM is
initialized, it creates a local Network Volume Configuration File
(Lnp_ NVCF.MM) that describes the partitioning of the Winchester
drives based on the volume-configuration data installed in the current
NCF file. The Lnp_NVCF.MM file is locally held in each HM's local
volume (see Section 2) and the data it contains is also on the &ASY
directory as part of the NCF data.
Procedure When an HM reloads and restarts itself (autoboots), it checks the

local Lnp NVCF.MM (it contains a record of which NCF was used)
against the NCF on the &ASY directory and if the NCF has changed,
the HM loads the initialization personality, not the normal on-process
personality, and the configuration mismatch error is recorded on the
real-time journal. If the initialization personality (&HMI) has not
been placed on the local volume, the HM fails.

7.7 How to Save and Restore Continuous History
Introduction When it is necessary to initialize an HM that has stored continuous

history, you must use the guidelines presented here to assure that the
history data is kept intact and useable. You may need to initialize an
HM because it has been repaired or because you are changing volume
configuration to change volumes other than continuous-history
volumes. Continuous history cannot be restored to HMs with
reconfigured continuous-history volumes.
7.7.1 Prerequisites for Saving and Restoring Continuous

History
Conditions To save and restore continuous history, the following must be true :
• The NCF configuration items related to continuous history cannot
be changed at all from those that existed at the time the history data
was saved. This means you cannot change any of the following:
Table 7-17 NCF Configuration Items That Can’t Be Changed
Under Volume Configuration Under System Wide Values
Continuous History User Average Period

Units and Groups Shift Data
Group Options
• No file in the HM continuous-history volumes can be too large to fit

on one removable medium (disk). This will generally not be a
problem if you use disks, but if the configured prearchive hours
exceed 168, it may be a problem if you still use floppies. If so, use
the following Utilities' LS command to catalog the files to see if any
of the files is too large to fit on a floppy (larger than 3988 sectors,
as shown in the #BLKS column):
LS NET>!Auu>AG*.*
LS NET>!Auu>AH*.*
where uu is the continuous-history unit number.
• The HM to be initialized must be running with the initialization
personality (&HMI) when the continuous history is saved on
removable media and when the history data is restored. If you
attempt to save continuous history while the HM is running its on-
process personality (&HMO), the history data will be inconsistent
and the HM will fail after it is initialized and put back on process.

7.7.2 Procedure for Saving and Restoring Continuous
History
Description If you want to save the history group definition files (APL)
configuration on the HM, but don't care to save the history data itself,
refer to 7.7.3 in this manual for a shorter procedure.
This procedure (7.7.2) saves and restores the continuous history
definition files (APL) configuration and history data only. Other HM
volumes with their directories and files also need to be saved. For the
other volumes, use either the Backup command or the Copy Volume
command (see Command Processor Operation). These commands
work with either HM personality (HM status = SEVERE or
WARNING or OK). If the HM is in SEVERE or WARNING, make
sure that the disc drives are OK. Otherwise, correct or replace them.
CAUTION .
CAUTION— You cannot restore Continuous History or Continuous
History Group Definitions if the Continuous History has been
modified on this HM (like, adding Groups, modifying History
Collection, and so on). EB files must be used to restore History
Group Definitions.
Procedure
Follow this procedure:
Table 7-18 Saving and Restoring Continuous History
Step Action
1 Get a new disk, label it BACKUP NCF and create a volume in it with
&ASY. Copy all the files in the &ASY from NET to this disk. Set this
disk aside for later use.
Examples:
CR $F1>&ASY -F -MF 3000 -BS 1700
CP NET>&ASY>*.* $F1>&ASY>= -D
2 Use the Backup Command (or similar) to save all HM information to
disks (except history). Example: BACKUP PN:10 $F1
3 After the Backup command is finished, and while the HM is running,
load the HM with its initialization personality. On the History Module
Status display, select the HM's node number, select LOAD/DUMP,
select MANUAL LOAD and then INIT PROGRAM. Follow the
prompters to initiate loading from the HM (if HMOFF files are in
!9np, where np is for node pair). Or do a SHUTDOWN of the HM,
wait for the QUALIF status and load the INIT Program from the &Z1
disk and the Data (NCF) from NET or the BACKUP NCF disk. When
loading is complete, the HM status will be HMOFF OK.

History, Continued
Procedure, continued
Table 7-18 Saving and Restoring Continuous History, continued
Step Action
4 From the Engineering Main Menu, select COMMAND PROCESSOR,
create a volume in a disk and use a Copy Volume command to
copy the continuous history volumes from this HM to disks. These
are examples of the command lines that would be needed to
create and copy two history volumes (see Command Processor
Operation):
CR $F1>HST1 -F -MF 3000 -BS 1700
CPV PN:40>!001> $F1>HST1 -A -D
CPV PN:40>!101> $F1>HST2 -A -D
Note: A dual-disk HM can have two history volumes, !0np and
!1np. If so, be sure to copy both volumes.
5 Print out (DO $P#, where # is the printer number) the List Volumes
command (LSV PN:nn, where nn is HM node number) to use the
printout to create user directories later on.
6 Verify that all of the files in the HM history volume have been
copied correctly on the removable media. Use the List File
Attributes (LS) command with the -A option (LS $F1 -A) to see
that the number of files in the HM volume and the number of files
on the removable media are the same. Copy all of the files (with
the $FCOPY command) on the removable media to other
removable media to verify that they can be copied without errors. It
is risky not to do this verification now—once the HM is initialized, it
will be too late.
7 From the Engineering Main Menu select SUPPORT UTILITIES,
then MODIFY VOLUME PATHS, then SET DEVICE PATH TO
REM. MEDIA and put in &Z1 in $F1 (or lower drive number) and
BACKUP NCF in $F2 (or higher drive number). Select MAIN
MENU. Do not make changes to the VOLUME CONFIGURATION in
the continuous history section, but it is OK to make changes to
other items in the VOLUME CONFIGURATION. (Refer to the System
Startup Guide or the Network Data Entry for more information on
editing and making NCF changes to the VOLUME
CONFIGURATION.)
Note: The following step destroys all data on the HM:
Initialize the HM. (On the Engineering Main Menu, select VOLUME
CONFIGURATION, select the node-pair target for this HM, hold CTL
and press F6, and wait for the HM INITIALIZATION COMPLETE
message.)

History, Continued
Table 7-18 Saving and Restoring Continuous History, continued
Step Action
8 Shut down, wait for QUALIF, and Manual Load the HM with the
Operator (Online) Personality from the &Z1 and BACKUP NCF
disks. HM should go to HMON OK. Allow it to run for 5 minutes
(to initialize the history files) then shut it back down, wait for
QUALIF, and load the initialization program from the &Z1 and
BACKUP NCF disks. HM should go to HMOFF OK.
9 Delete all continuous history files on the HM. If there are two
continuous history volumes, be sure to delete all files in both of
them (!0np and !1np). These are examples of the command lines:
DL PN:40>!001>*.*
DL PN:40>!101>*.*
For volumes with directories, each directory must also have its files
deleted:
DL PN:nn>!Auu>*.* (nn = node number, uu = hist group
no.)
10 Note: This is a mandatory step that prevents fragmentation.

Once again, shut down, wait for QUALIF, and load the HM with its
initialization personality from the &Z1 and BACKUP NCF disks,
then continue with step 8. HM should go to HMOFF OK.
11 Copy the continuous history files you saved in step 2 to the
appropriate HM volumes. These are examples of the command
lines:
CPV $F1>HST1> PN:40>!001> -A -D
CPV $F1>HST2> PN:40>!101> -A -D
or run this EC in &Z1:
EC $F1>&EC>RSCONTHS.EC
Be sure all of the history copy operations completed correctly,
without any errors.

History, Continued
Table 7-18 Saving and Restoring Continuous History, (continued)
Step Action
12 COPY the BACKUP NCF and .SE & .SP files:
1. Copy the &ASY directory from removable media to the HM (for
System HM only):
CP $Fs>&ASY>*.* PN:nn>&ASY>= -D
where s is the source disk number and nn is the HM
physical node number.
2. Insert the &Z1 disk appropriate for your system in Drive s
(source). Run this EC for all HMs:
EC $Fs>&EC>LOC_VOL.EC $Fs nn np
where nn is the HM physical node and np is the HM node pair

number. Follow the screen instructions.
Loading the INIT files is optional but recommended (if HM
INIT Personality? has YES on the first page of the Volume
Configuration menu). Wait for “EC Complete”.
13 Autoboot the HM. The system HM has to be online for these
steps to work for non-system HMs:
1. Call up the System Status Display.

2. Select HISTORY MODULES.
3. Select SHUTDOWN; then press ENTER. Wait for QUALIF.
4. Turn node power OFF to the HM for at least 5 seconds.
5. Turn the power ON to the node.
6. HM status should go to HMON OK (may take up to 1 hour)
Redundant HM drives may have a status = SEVERE
until synchronized in Step 18.
Note: Nodes can be loaded while the HM is in the READY state.

14 Verify that the system date and time are correct. If not, refer to the
Process Operations Manual and correct them.
15 Use the History Module Status display to enable history collection
(select this HM's node number, select HIST COLLECT, and select
ENABLE COLLECT. Current state becomes ENABLE). Wait a few
minutes, then call up trends or other history displays to make sure
it is working properly.

History, Continued
Table 7-18 Saving and Restoring Continuous History, (continued)
Step Action
16 Recreate missing directories:
Use the LSV NETcommand to determine which directories are on
the HM. Compare them to the printout you obtained earlier. If any
directories are not present, use the CD command to create them.
17 Restore Saved data to the HM:
Use the Restore command to reload volumes saved with the
Backup command.
18 After the Restore command is complete, (don’t do a Synch
command while the Restore is still running since it can cause disc
errors) synchronize the HM disks if redundant drives:
SYNCH PN:nn
where nn is the HM physical node number

7.7.3 Restoring the HM Group Definition Files (APL)
without the Continuous History Data
Description This procedure saves and restores continuous history group definition
files (APL) and other volumes in the HM but not the history data.
Other HM volumes with their directories and files also need to be
saved. To save them, use either the Backup command or the Copy
Volume command (see Command Processor Operation). These
commands work with either HM personality (HM status = SEVERE
or WARNING or OK). If HM is in SEVERE or WARNING, make
sure that the disc drives are OK; otherwise, correct or replace them.
You will restore these other volumes at the appropriate point in the
following procedure.
After release 230, the Backup command automatically saves the
HM history group definition files (APL).
CAUTION .
CAUTION—You cannot restore the Continuous History Group
Definitions (APL) if the Continuous History groups have been
modified on this HM (that is, adding Units and/or Groups). EB files
must be used to restore History Group Definitions.
Procedure Follow this procedure:
Table 7-19 Restoring HM Group Configuration without History

Step Action
1 Get a new disk, label it BACKUP NCF and create a volume in it
with &ASY. Copy all the files in the &ASY from NET to this disk.
Set this disk aside for later use.
Examples:
CR $F1>&ASY -F -MF 3000 -BS 1700
CP NET>&ASY>*.* $F1>&ASY>= -D
2 Use the Backup Command (or similar) to save all HM information
to disks (except history). Example:
BACKUP PN:10 $F1

without the Continuous History Data, Continued
Table 7-19 Restoring HM Group Configuration, continued
Step Action
3 After the Backup command is finished, and while the HM is
running, load the HM with its initialization personality. On the
History Module Status display, select the HM's node number,
select LOAD/DUMP, select MANUAL LOAD and then INIT
PROGRAM. Follow the prompters to initiate loading from the HM
(if HMOFF files are in !9np, where np is for node pair). Or do a
SHUTDOWN of the HM, wait for the QUALIF status and load the
INIT Program from the &Z1 disk and the Data (NCF) from NET or
the BACKUP NCF disk. When loading is complete, the HM
status will be HMOFF OK.
4 Print out (DO $P#, where # is the printer number) the List
Volumes command (LSV PN:nn, where nn is HM node
number) to use the printout to create user directories later on.
5 Verify that all of the files in the HM history volume have been
copied correctly on the removable media. Use the List File
Attributes (LS) command with the -A option (LS $F1 -A) to
see that the number of files in the HM volume and the number of
files on the removable media are the same. Copy all of the files
(with the $FCOPY command) on the removable media to other
removable media to verify that they can be copied without errors.
It is risky not to do this verification now—once the HM is
initialized, it will be too late.
6 From the Engineering Main Menu select SUPPORT UTILITIES,
then MODIFY VOLUME PATHS, then SET DEVICE PATH TO
REM. MEDIA and put in &Z1 in $F1 (or lower drive number) and
BACKUP NCF in $F2 (or higher drive number). Select MAIN
MENU. Do not make changes to the VOLUME CONFIGURATION
in the Continuous History Unit and Group page, but it is OK to
make changes to other items in the VOLUME CONFIGURATION.
(Refer to the System Startup Guide or the Network Data Entry for
more information on editing and making NCF changes to the
VOLUME CONFIGURATION.)
Note: The following step destroys all data on the HM:
Initialize the HM. (On the Engineering Main Menu, select

VOLUME CONFIGURATION, select the node-pair target for this
HM, hold CTL and press F6, and wait for the HM
INITIALIZATION COMPLETE message.)

Step Action
Operator (Online) Personality from the &Z1 and Backup NCF
disks. HM should go to HMON OK. Allow it to run for 5 minutes
(to initialize the history files) then shut it back down, wait for
QUALIF, and load the initialization program from the &Z1 and
Backup NCF disks. HM should go to HMOFF OK.
8 As a safety measure, save for possible future use:
DO NOT overwrite the files in the HM Backup disks. Use a
different disk.
1. COPY the APL files from the HM to a temporary disk.
EXAMPLE SYNTAX:
CP PN:nn>!0np>APL*.MM $Fd>!0np>= -D
where nn = HM node number
np = node pair number
d = destination drive number
2. UNPROTECT the files.
UNPT PN:nn>!0np>APL*.MM
3. DELETE the default history group, point definition files.
EXAMPLE SYNTAX:
DL PN:nn>!0np>APL*.MM –D
9 Note: This is a mandatory step that prevents fragmentation.
Once again, shut down, wait for QUALIF, and load the HM with
its initialization personality from the &Z1 and Backup NCF disks,
then continue with step 10. HM should go to HMOFF OK.
10 COPY the two APL*.MM files you saved in step 2 in the first disk
of the HM Backup disk:
CP $Fs>!0np>APL*.MM PN:nn>!0np>= -D
where s = source drive number
np = node pair number
nn = HM node number
or run this EC in &Z1:
EC $F1>&EC>RSHSDEF.EC
Be sure all of the history copy operations completed correctly
without errors.

Step Action
11 COPY the BACKUP NCF and .SE & .SP files:
1. Copy the &ASY directory from removable media to the HM (for
System HM only):
CP $Fs>&ASY>*.* PN:nn>&ASY>= -D
where s is the source disk number and nn is the HM
physical node number.
2. Insert the &Z1 disk appropriate for your system in Drive s
(source). Run this EC for all HMs:
EC $Fs>&EC>LOC_VOLZ.EC $Fs nn np
where nn is the HM physical node and np is the HM node pair

number. Follow the screen instructions.
Loading the INIT files is optional but recommended (if HM

INIT Personality? has YES on the first page of the Volume
Configuration menu). Wait for “EC Complete”.
12 Autoboot the HM. The system HM has to be online for these
steps to work for non-system HMs:
1. Call up the System Status Display.

2. Select HISTORY MODULES.
3. Select SHUTDOWN; then press ENTER. Wait for QUALIF.
4. Turn node power OFF to the HM for at least 5 seconds.
5. Turn the power ON to the node.
6. HM status should go to HMON OK (may take up to 1 hour)
Redundant HM drives may have a status = SEVERE
until synchronized in Step 17.
NOTE: Nodes can be loaded while the HM is in the READY

state.
13 Verify that the system date and time are correct. If not, refer to
the Process Operations Manual and correct them.

Step Action
14 Use the History Module Status display to enable history
collection (select this HM's node number, select HIST COLLECT,
and select ENABLE COLLECT. Current state becomes ENABLE).
Wait a few minutes, then call up trends or other history displays
to make sure it is working properly.
15 Recreate missing directories:
Use the LSV NETcommand to determine which directories are
on the HM. Compare them to the printout you obtained earlier.
If any directories are not present, use the CD command to create
them.
16 Restore Saved data to the HM:
Use the Restore command to reload volumes saved with the
Backup command.
17 After the Restore command is complete, (don’t do a Synch
command while the Restore is still running since it can cause
disc errors) synchronize the HM disks if redundant drives:
SYNCH PN:nn
where nn is the HM physical node number.

7.8 HM Backup Tool Option Using the AM
Description Included with the Release 510 software is a History Module backup
tool with features that give you greater flexibility in performing HM
backups:
• Easy-to-configure, easy-to-monitor graphical interface
• Automatic scheduling of HM backups
• Configure full or incremental backups
• Back up to 55 source HM volumes or directories
• Back up to 55 associated PINs (local or remote LCN IDs)
• AM CL program backs up files to removable media
• Ability to pause, resume, or abort backup
• Online help displays to assist the user
Requirements The optionally installed HM backup tool runs with R430 and later
software. It requires an Application Module (AM) in order to use.
Tool location The tool is found on the &Z3 disk in the TLK2 directory.
Installation Installation instructions are included as an electronic file

(HMBACKUP.XI) in the tool software.
ATTENTION This tool does not format the media. For more information, read the
help file GHLP.XH.
Schematic The main schematic for HM backups is $HMBKSTS.0

7.9 History Module Fragmentation
Description It is possible to get messages that indicate an HM is full while it

actually has adequate storage space, but is not using that space
effectively because of file fragmentation. This occurs over time with
high HM usage, where files that are transferred to disk are
fragmented (broken into pieces) as the HM finds available space to
store them.
Procedure If this has happened, you can overcome it by copying files from the
HM to removable media, deleting the files from the HM, and then
copying them back to the HM. To do so, use the following steps.
For brevity, these instructions are generalized rather than detailed.

Each Utility’s commands mentioned is accompanied by a reference to
the paragraph number in the Command Processor Operation manual
where a detailed description of the command is provided (see
Command Processor Operation).
Preparing your HM for Follow the steps in Table 7-20 to prepare to defragment your HM.
defragmentation
Table 7-20 Preparing to Overcoming History Module
Fragmentation
Step Action
1 If you don’t already have a list of all volumes and directories on
all HMs on your system, use the List Volumes command (LV
NET, 5.16) to obtain such a list.
2 Identify volumes and directories from your list of volumes and
directories that have had long and frequent usage. Then use the
LS command (5.15) to obtain information about the total sectors
for each such volume and the number of sectors in use.
Read the warning that follows, then defragment your HM using the
procedure in Table 7-21.

7.9 History Module Fragmentation, Continued
WARNING WARNING—After the first two steps in Table 7-21, the volume and
perhaps the HM will be temporarily unavailable to the network.
You will have to find a way to get along without that volume or
History Module—or make its files available from removable media.
If you don’t fully understand the consequences of this, defer any
further steps in this procedure until you do or until you get proficient
help.
Defragmenting your Use the procedure in Table 7-21 to defragment your HM.
HM
Table 7-21 Procedure for Overcoming HM Fragmentation
Step Action
1 Copy (CPV, 5.4, or CP, 5.3) all of the files in this volume and all of its
directories in the volume to a removable medium or to removable
media.
2 To help ensure that you have a valid copy and to provide an extra
backup copy, copy everything you copied in step 3a to another
removable medium (or media).
3 If this volume is !0np, !1np, or !2np, use the History Modules Status
display to twice SHUT DOWN the HM, and thus cause it to restart
(autoboot) itself.
4 Unprotect (5.23) each protected file in this volume and all of its
directories [protected files are noted by a * in the P column of the
file listing (catalog)].
5 Delete (5.9) all files in this volume and all of its directories.
6 If this volume is !1np, !4np, or !9np, use the History Modules Status
display to twice SHUT DOWN the HM, and thus cause it to restart
(autoboot) itself.
7 Copy (CPV, 5.4, or CP, 5.3) all of the files in this volume and all of its
directories back to the volume on the HM. If files in the volume
were fragmented, the number of sectors used will now be less than
before.

Section 8 — Alarm Management
8.0 Overview
Description This section provides information about Alarm Management

functionality.

8.1 Introduction
Functionality Alarm features include Emergency, High, and Low priority alarming
on the Area Alarm Summary display and the Unit Alarm Summary
display; colors, symbols, and characters for alarm priorities; audible
alarm suppression; alarm management by selective display, and
display freezing.
Function Differences The following table shows functions that have been added in Release
500:
Table 8-1 New Functionality Table
Function R410 R500
ALARM FILTERING ----- View alarms by selected priority
ALARM SORTING Sort by chronology Sort by chronology or priority
THREE COLOR ALARMS 2-Color 2- or 3-Color configuration with seven
colors to choose from
PRIORITY INDICATORS E, H, L Box, triangle, and inverted triangle; E,
H, and L
ALARM WINDOW ----- Alarm window bordered by box
DISPLAY FREEZING ----- Freeze target with configurable timer
or ramp key temporary freeze
HORN SUPPRESSION ----- Low or high priority alarms
HORN ANNUNCIATION Steady Steady or Momentary
SINGLE POINT ALARM ----- Select and disable/inhibit single point
DISABLE/INHIBIT from Alarm Summary Display
CONFIGURABLE ACCESS LEVELS ----- Keylock configurable in NCF
(FILTER, SORT, FREEZE, HORN
SUPPRESSION)
UNIT TARGETS ----- Larger
ALARM COUNT Total alarms Alarm counts displayed for each
displayed priority
CONTACT CUTOUT See Contact Cutout See Contact Cutout
Display Differences The following alarm displays are different in R500:

• Area Alarm Summary Display
• Unit Alarm Summary Display
• Alarm Annunciator Display

8.2 Release 500 Alarm Differences
Access level Access levels for alarm management functions are configured
configuration through the NCF. These features can be restricted to Engineer,
Supervisor, or Operator keylock access levels.
Low priority alarms The NCF can be configured to include low priority alarms on the
Area Alarm Summary.
Alarm display filtered The user may select three different filtering options by selecting one
by priority of the filtering targets located on the Area Alarm Summary or Unit
Alarm Summary displays. The filtering options enable display of
alarms with priority EMERGENCY, HIGH, LOW, EMERGENCY,
HIGH, and EMERGENCY.
By using the filter the user has the option of seeing emergency only,
emergency and high, or if the NCF is configured for low alarms on the
Area Alarm Summary, all three alarm priority levels. The filter will
only occur on the station where the filtering is selected. The filter will
remain set even if another display is called up. All target actions are
journaled and keylock access can be configured in the NCF.
Alarm sorting Alarms may be sorted by alarm priority or by chronological order.

The [SORT] target is located on both the Area Alarm Summary and
the Unit Alarm Summary display. The current sort selection is
displayed to the right of the “SORT:” text. When the sort option
displays “CHRON” all alarms displayed are sorted in descending
chronological order, with the newest alarm on the first page and the
oldest on the last. If the sort option displays “PRIORITY”, all alarms
are displayed by alarm priority and within each priority in reverse
chronological order. The sort affects only the current station and
remains in effect until the sort target is reselected. All target actions
are journaled and the initial sort mode and keylock access can be
configured in the NCF.
Alarm symbols Alarm symbols or characters can be selected during the NCF
configuration. If characters are selected for reporting the alarm
priority levels, “E” will be used for emergency, “H” will be used for
high, and “L” will be used for low-level alarms. If symbols are
selected, a square will be used for emergency, a triangle will be used
for high, and an inverted triangle will be used for low.

8.2 Release 500 Alarm Differences, Continued
Alarm colors Alarm colors are configurable through the NCF. The configuration
allows the user to select one color for each of the three alarm levels.
The alarm colors are used throughout the system. Seven colors are
available:
• RED • BLUE
• YELLOW • CYAN
• MAGENTA • WHITE
• GREEN
Alarm count Area alarm count is displayed on the Area Alarm Summary, the Unit
Alarm Summary and the Alarm Annunciator display for each alarm
priority. The Unit Alarm Summary also displays a separate alarm
count for unit alarms.
Alarm window The alarm window is located at the top of the first page of the Area
and Unit Alarm Summary display screens. It contains a listing of the
five most recent alarms in reverse chronological order. When the
window is full (five alarms) and a new alarm appears in the alarm
window, all five alarms in the window are sorted into the alarm
listing.
Freeze alarm screen The freeze function prevents new alarms from scrolling down into the
alarm display once the alarm window is full, but does not prevent the
alarm database from being updated. The page-forward and page-back
keys allow the user to display all of the alarm pages while in the
freeze mode. New alarms continue to be displayed in and cleared
from the alarm window, and point values in the alarm lines continue
to be updated. Normal deletions from the alarm display continue
during the freeze, leaving spaces in the list. When the display is
unfrozen, alarms that have occurred since the freeze began are
inserted into the alarm lines and the list is resorted.

Freeze alarm screen, There are two methods of freezing the alarm screen:
two methods
• Select any of the four ramp keys on the Operator keyboard to

initiate a momentary freeze. When any one of the four ramp keys is
selected and held, the display freezes and the FREEZE DISPLAY
text is highlighted in red indicating that a freeze is in progress.
When the key is released the display resumes normal updating.
• Select the FREEZE DISPLAY target. The alarm display freezes in
the same manner as when the ramp keys are used, but the alarm
display remains frozen until the FREEZE DISPLAY target is
selected a second time or until a timeout occurs. The timeout is
configurable in the NCF. A timeout of zero seconds disables the
freeze function so the freeze target will not appear on the summary
display.
Freeze alarm rules The FREEZE DISPLAY feature is reset if another display is called
up and removes the alarm display. The freeze only occurs on the
station where the FREEZE DISPLAY target or ramp keys are
selected. All freeze/scroll target actions are journaled. Keylock access
can be configured in the NCF.
Horn suppression This can be accomplished by selecting a target on the Area Alarm
Summary, Unit Alarm Summary, or the Alarm Annunciator display.
To suppress horns based on alarm priority, the user selects the
[AUDIBLE] target then selects one of the suppression options. All
target actions are journaled and keylock access can be configured in
the NCF. Horn suppression operates on a timeout which can be
configured to zero seconds, in which case the target does not appear
on the display.

Horn annunciation The user has the option of selecting “MOMENTARY” or “STEADY”
state for each of the three contact output states. Each contact output
state can be assigned to one or more of the following event types:
• Console Status Event
• System Status Event
• Operator Acknowledged Event
• Operator Confirm Event
• Low Priority Alarm
• High Priority Alarm
• Emergency Priority Alarm
Single point alarm A single point selected from the Area Alarm Summary or the Unit
disable/inhibit Alarm Summary can be disabled or inhibited by selecting the
[ALARM DISABLE/INHIBIT] target. Disabled alarms are detected
and stored in the HM journal but otherwise suppressed. They are not
reported to the alarm summary displays. Inhibited alarms are not
detected or distributed to the US or the HM. All target actions are
journaled and keylock access can be configured in the NCF.

8.2.1 Release 520 Alarm Enhancements
Introduction The R520 alarm enhancements allow the site engineer to configure
batch alarming, using the existing TPS continuous process alarm
system, and add flexibility to overall alarming functions. These
functions, plus other general alarm enhancements, are monitored by
an operator who can modify the functions, with the proper site
security access level.
Product description The R520 alarm functions used for batch alarming include:
• AM multiple PRIMMOD (MPROD) alarms—this option allows
a single alarm on an AM point to be reflected in four Multiple
PRIMMOD alarm groups or the standard PRIMMOD parameter
group to be used for alarm displays and event history.
• Auxiliary Unit (AUXUNIT)—allows all process alarms on a point
to be dynamically redirected from the point primary unit to an
alternate unit for alarm displays.
• Button PRIMMOD or MPROD assignment—allows runtime
assignment of a new PRIMMOD/Multiple PRIMMOD name to any
of the 40 configurable LED buttons (allowing button assignments to
be changed on the fly).
• Button LED control—allows the red and yellow LEDs on each of
the 40 configurable LED buttons to be set to three possible modes
(ON,OFF, or BLINK) using a CL program.
• Area Database change actor—a new actor that allows Area
Database changes to be done from custom schematics and
configurable buttons (allows operators to move easily from one area
to another).
• Silence horns on console—an NCF configurable option that causes
the silence button to silence all horns on the same console (across
all areas if more than one area is on a console).
• RTJ color alarms—an NCF configurable option that allows all
process alarms (SOE, process and sequence alarms) and return to
normal events to be printed in color on the Real-Time Journal.
• Keylevel Change Journal Suppression function—allows the user
to suppress the journaling of keylevel change events by actors.
• PRIMMOD Status and Count actors—are available for reading
the composite alarm status and alarm count of a specified
PRIMMOD or Multiple PRIMMOD. These are actor equivalents of
the $PRIMSTS and $PRIMCNT collectors.

8.3 Contact Cutout Basics
Overview This section will review the basic concept of contact cutout, including
how this function is configured in the HG, AM, and NIM
environments. It will then cover the detailed functionality with
emphasis on what is new or changed for R500.
Review of contact Contact cutout is a state in an alarmable point in which alarms are
cutout “cut out” (not distributed). One use for this function might be in a
hierarchical alarm situation where a failure (with resulting alarm) in
one (primary) point causes failures in related (secondary) points. The
alarm from the primary point might be of major importance, whereas
the related alarms in the secondary points are of lesser importance,
and might, in fact, constitute a nuisance for this particular scenario. In
the HG, the contact cutout feature allows you to configure a primary
point which, if in alarm, will cause alarms to be “cut out” in one or
more points configured as secondary (to that primary). In the AM and
NIM, contact cutout is implemented slightly differently, as we shall
cover, but the same effect can be achieved.
Configuring contact In the HG, a contact cutout chain is configured using the parameter
cutout in the HG CCRANK, which has three possible states:
• NEITHER - This point is not part of a contact cutout chain
• PRIMARY - This point is a primary in a contact cutout chain
• SECONDARY - This point is a secondary in a contact cutout chain
To set up a chain, configure a point as a primary. Then configure one
or more points as secondary points. When you configure an HG point
as a secondary in the PED, a data entry box appears (for parameter
CCPRIPNT) in which you must enter the tag name of the primary
point. A primary point may have multiple secondary points.

8.3 Contact Cutout Basics, Continued
Contact cutout in NIM AM and NIM points cannot be directly configured as primary or
and AM points secondary as is the case in the HG. AM and NIM points that are
alarmable have a CONTCUT (Contact Cutout) parameter that is a
logical (Boolean) type parameter with value of On or Off. This
parameter is used to turn the contact cutout state on or off from CL.
In the AM, the CONTCUT parameter can be used with any point
except numeric, which is not alarmable and does not have the
parameter. Also, AM regulatory, counter, and timer points have
another mechanism to implement contact cutout—the CCINPT and
CCSRC parameters. This is covered in the next heading.
Another way to do AM regulatory, counter, and timer points have another way to
contact cutout implement contact cutout. A hierarchical structure can be configured
directly using the parameters CCINPT and CCSRC. CCINPT
(Contact Cutout Input required) is a Yes/No enumeration, which, if
set to Yes, causes a data entry box to appear in the PED requiring
entry of the point.parameter CCSRC (Contact Cutout Source). The
source point.parameter entered here must be of type Boolean
(On/Off). As an example, the Point-in-Alarm parameter (PTINAL) of
a point (primary) could be entered as the Contact Cutout Source
(CCSRC) in one or more other points (secondaries), thus achieving a
primary/secondary chain analogous to the HG implementation.
Basic changes In R500, alarm events that occur in a point that is in the cutout state
introduced in R500 are ignored. This behavior is the same as inhibited alarms. Alarm
events include both going into the alarm state, and going out of the
alarm state (return-to-normal). Prior to R500, cutout alarms behaved
the same as disabled alarms. Table 8-2 lists the basic differences.
Table 8-2 Contact Cutout Changes in R500

Point State Prior to R500 In R500
A point is in the contact Alarms were not distributed to the US but were Alarms are not distributed
cutout state journaled in the HM. to the US or HM.
Return-to-normal events were distributed to the Return-to-normal events
US and HM (this differs from disabled alarms— are not distributed to the
return-to-normal events are not distributed for US or HM.
points that have alarms disabled).
A point goes out of the Existing alarms are not distributed until the Alarms that exist are
contact cutout state point returns to normal and goes into alarm distributed again.
again.

8.4 Contact Cutout - R500
New NCF option A new contact cutout option is added to the NCF in R500. This
option allows the user to select how existing unacknowledged alarms
are handled when a point goes into the contact cutout state. To access
this option:
• Go to the Engineering Main Menu
• Select [SYSTEM WIDE VALUES]
• Select [CONSOLE DATA]
Figure 8-1 shows the option that is available. There are two choices:
• CLEAR IMMEDIATELY—Clears all of the point’s
unacknowledged alarms from the Alarm Summary.
• CLEAR WHEN ACK’D—Leaves the point’s unacknowledged
alarms on the Alarm Summary, but backlights the time stamp.
Clears the alarms when they are acknowledged by the operator.
This is the default condition.
Note: If you make any changes to the NCF from the Console Data
menus, you must reload all US nodes.
Contact Cutout
NCF Change
CONTACT CUTOUT ALARMS
ON ALARM SUMM CLEAR IMMEDIATELY CLEAR WHEN ACKED
When contact cutout In R500, when a point goes into the contact cutout state, the
is applied following actions take place:
• All of the point’s acknowledged alarms are cleared from the Alarm
Summary Display.
• Depending on the contact cutout NCF option described above:
– All of the point’s unacknowledged alarms are cleared, or
– The time stamps on all of the point’s unacknowledged alarms are
backlighted, and the alarms are cleared when they are
acknowledged by the operator.
• The event is printed on the Real Time Journal (RTJ).

8.4 Contact Cutout - R500, Continued
When contact cutout In R500, when a point goes out of the contact cutout state and the
is removed and the point has an alarm condition existing, the node will redistribute the
point is in alarm
alarm with the following results:
• If the alarm is on the Alarm Summary display, the backlighting is
removed from the time stamp of the alarm, and the time stamp is
changed to the time that contact cutout was removed. If the alarm is
not displayed on the Alarm Summary, a new alarm message is
displayed.
When an alarm In R500, when a point returns to normal from an alarm while in the
returns to normal cutout state, and then goes out of the contact cutout state, the
while in the cutout
state, and contact
following actions take place:
cutout is removed
• Backlighting is removed from the time stamps of the point’s
unacknowledged alarms on the Alarm Summary, and the priority
indicator is backlit indicating that the point returned to normal. The
alarms will be cleared when acknowledged by the operator. (The
priority indicator is a single character (E, H, or L), or optionally a
symbol, that indicates whether the alarm was Emergency, High, or
Low. It is located in the column just to the right of the time stamp.)

8.5 Contact Cutout - Display Changes
Contact cutout Refer to Tables 8-3 and 8-4 for contact cutout display information.
scenarios
Primary alarm first When the primary point goes into alarm and then the secondary point
goes into alarm, the secondary point is cut out and does not appear on
the display.
Secondary alarm first If the primary point goes into alarm while the secondary point is in
alarm, the unacknowledged secondary point goes from a normal
alarm condition into contact cutout. In this case, instead of
disappearing from the screen, the secondary point remains on the
screen with a backlit time stamp. Primary point return-to-normal
status removes contact cutout and the secondary point is re-alarmed.
Secondary re- When the secondary point is cut out, then the primary point returns to
alarming normal, the secondary point goes out of contact cutout.
If the secondary point has been acknowledged before the primary
point returns to normal, when the primary point returns to normal the
data owner re-alarms the secondary point and it appears in the alarm
window with a current time stamp and a flashing priority indicator. It
then behaves like a normal point in alarm and is not cut out unless the
primary goes back into alarm.
If the secondary point has not been acknowledged before the primary
point returns to normal, it displays on the screen with a backlit
timestamp. After the primary point returns to normal, the old
secondary alarm line with the backlit timestamp is deleted. The
secondary point is then re-alarmed and appears in the alarm window
with a current time stamp and a flashing priority indicator.
RTJ messages Cutout status is distributed to the RTJ as “CUTOUT TRUE” only
when the primary point goes into alarm after the secondary point has
gone into alarm. In that scenario, when the primary point returns to
normal after the secondary point has returned to normal, the RTJ
receives the message “CUTOUT FALSE.”

8.5 Contact Cutout - Display Changes, Continued
CLEAR IMMEDIATELY When CONTACT CUTOUT ALARMS is configured in the NCF to

[CLEAR IMMEDIATELY], secondary alarms are automatically
acknowledged. When this configuration is in effect, the display
changes according to the ACK’D selections in the following table:
Table 8-3 Contact Cutout Scenario Overview

SCENARIO PRIMARY POINT SECONDARY POINT
A (1) ALARM 1ST (2) ALARM 2ND
(3) RETURN TO NORMAL 1ST (4) RETURN TO NORMAL 2ND
B (1) ALARM 1ST (2) ALARM 2ND
(4) RETURN TO NORMAL 2ND (3) RETURN TO NORMAL 1ST
C (2) ALARM 2ND (1) ALARM 1ST
(3) RETURN TO NORMAL 1ST (4) RETURN TO NORMAL 2ND
D (2) ALARM 2ND (1) ALARM 1ST
(4) RETURN TO NORMAL 2ND (3) RETURN TO NORMAL 1ST

Table 8-4 Contact Cutout Alarm Summary Display Changes

ALARM EVENT ALARM
SCENARIO STATE ORDER/ ACK DISPLAY CHANGES
POINT STATE*
A ALARM (1) PRIMARY UNACK’D PRIMARY: Point appears on the display.
1ST SECONDARY: N/A
ACK’D PRIMARY: Priority indicator stops flashing.
SECONDARY: N/A
(2) ---- PRIMARY: No change
SECONDARY SECONDARY: Point is cutout and does not
2ND appear.
RETURN (3) PRIMARY UNACK’D PRIMARY: Priority indicator is backlit.
TO 1ST SECONDARY: Point is alarmed and appears
NORMAL with current time stamp; priority indicator
flashes.
ACK’D PRIMARY: Point is cleared.
SECONDARY: Point is alarmed and appears
with current time stamp; priority indicator
flashes.
(4)SECOND- UNACK’D PRIMARY: No change
ARY 2ND SECONDARY: Priority indicator is backlit.
ACK’D PRIMARY: Point was cleared.
SECONDARY: Point is cleared.
B ALARM: (1) and (2) Same as Scenario A
RETURN (3) UNACK’D PRIMARY: No change.
TO SECONDARY SECONDARY: No change. (Point is still cut
NORMAL 1ST out.)
ACK’D PRIMARY: N/A
SECONDARY: Point never appears.
(4) PRIMARY UNACK’D PRIMARY: Priority indicator is backlit.
2ND** SECONDARY: N/A
SECONDARY: N/A

Table 8-4, Continued

ALARM EVENT ALARM
POINT STATE*
C ALARM (1) PRIMARY: N/A
SECONDARY SECONDARY: Point appears on the display.
1ST
(2) UNACK’D PRIMARY: Point appears on display.
PRIMARY SECONDARY: Point is cutout and remains
2ND*** on screen with backlit timestamp. Message
“CUTOUT TRUE” is distributed to the RTJ.
ACK’D PRIMARY: Point appears on display.
SECONDARY: Secondary point is cleared.
RETURN (3) UNACK’D PRIMARY: Priority indicator is backlit.
TO PRIMARY SECONDARY: Secondary point goes out of
NORMAL 1ST contact cutout and is cleared from display.
Point is re-alarmed and appears in alarm
window with a new time stamp.
SECONDARY: Secondary point goes out of
contact cutout. Point is re-alarmed and
appears in alarm window with current time
stamp and flashing priority indicator.
Acknowledged secondary point is still in
alarm.
(4) UNACK’D PRIMARY: N/A
SECONDARY SECONDARY: Priority indicator is backlit.
2ND
ACK’D PRIMARY: N/A
SECONDARY: Point is cleared.
* at the time of alarm state change
** message “CUTOUT FALSE” is distributed to RTJ
*** message “CUTOUT TRUE” is distributed to RTJ

Table 8-4, Continued

ALARM EVENT ALARM
POINT STATE*
D ALARM: Same as Scenario C
RETURN (3) UNACK’D PRIMARY: No change.
TO SECONDARY SECONDARY: No change. (Point is still cut
NORMAL 1ST out.)
ACK’D PRIMARY: No change.
SECONDARY: N/A
(4) UNACK’D PRIMARY: Priority indicator is backlit.
PRIMARY SECONDARY: Backlighting on timestamp is
2ND** removed; priority indicator is backlit.
SECONDARY: N/A
* at the time of alarm state change
** message “CUTOUT FALSE” is distributed to RTJ
*** message “CUTOUT TRUE” is distributed to RTJ

8.6 Contact Cutout - Functions for the HG, NIM, and AM
Overview This section contains tables showing the contact cutout functionality
for the HG, NIM, and AM in R500. These tables use the term
“distribute” in connection with alarm and return-to-normal events.
When an alarm or return-to-normal event is distributed, the
destination is determined by alarm priority. Choices include US
Alarm Summary displays, Real - Time Journal, and History Module
journal.
With R681, the Selective Cutout feature allows the alarms of a point
to pass through, though the secondary point is in the cutout state. The
AM regulatory, counter, and flag points can be configured with the
new parameters to enable selective cutout. In the HG, analog input,
regulatory, digital input, analog composite, and digital composite
points can be configured similarly. In the NIM, flag, numeric,
regulatory control, regulatory PV, digital input, analog input, digital
composite, and device control points can be configured with the new
parameters. The alarm parameters are named $DHSELCT,
$DISELCT, $HISELCT, $HHSELCT and so on. Selective Cutout
operates in conjunction with the contact cutout feature.
When the parameter is set to ALLOW, the respective alarm passes

through, even though the point is in the cutout state. When the
parameter is set to CUTOUT, the particular alarm is blocked if the
point is in the cutout state.
Backlighting For contact cutout, backlighting of fields on the Unit and Area Alarm
Summary displays is used for two purposes:
• The priority indicator is backlighted to indicate a return-to-normal
event.
• The time stamp field is backlighted to indicate that the alarm will be
cleared from the alarm summary when it is acknowledged because
the point is no longer in an alarmable state. A backlit timestamp can
result from alarm disable or inhibit, point inactive, or contact
cutout.

8.6 Contact Cutout - Functions for the HG, NIM, and AM,
Continued
Canceling a The tables that follow use the phrase “cancel the secondary point’s
secondary point’s alarm.” This involves the following steps:
alarm
• Clear acknowledged alarms
• Depending on the new NCF option CONTACT CUTOUT
ALARMS ON ALARM SUMM:
– Clear unacknowledged alarms, or
– Backlight time stamp
• Send to RTJ
With R681, you can enable Selective Cutout in HG only if the parameter, CCRANK, is
secondary. In AM and NIM, the new parameters are always available.
The following table shows the record on the Alarm Summary when an alarm is configured on a
secondary point and cutout enabled later.
R681 Functionality
NCF option
(Selective Cutout)
ALLOW CUTOUT
Clear The alarm on a secondary point for The alarm on a secondary point for
Immediately which the selective cutout which the selective cutout parameter is
parameter is set to ALLOW, is not set to CUTOUT, is removed from the
removed from the alarm summary alarm summary.
even if acknowledged.
When the alarm returns to normal,

it is removed from the alarm
summary.
Clear When The timestamp of an alarm on a The timestamp of an alarm on a
Acknowledged secondary point is not backlit. It is secondary point is backlit if it is not
not removed from the alarm acknowledged.
summary even if it is Acknowledged alarms are removed
acknowledged. from alarm summary.
When the alarm returns to normal,

it is removed from the alarm
summary on acknowledgement.

Continued
The following section describes certain conditions and the corresponding behavior of alarms
(in HG, AM, and NIM) when selective cutout is set to Allow/Cutout.
If Then
• A cutout secondary point is already in • The alarms remain.
alarm
• on the screen irrespective of whether they
AND have been acknowledged or not.
• Selective cutout is set to Allow • on the alarm summary without having
their time stamps backlit.
AND
• New alarms are also reported to the alarm
• Primary point reports an alarm. summary page and RTJ. The alarms
behave like any other alarm.
• A cutout secondary point is already in • The alarms remain.

alarm
• on the screen irrespective of whether they
AND have been acknowledged or not.
• Selective cutout is set to Allow. • on the alarm summary without having
their time stamps backlit.
• New alarms are also reported to the alarm
summary page and RTJ. The alarms
behave like any other alarm.

Continued
A secondary point is in cutout and the alarm

value of $xxSELCT parameter is changed.
Initially $HISELCT and $HHSELCT is Initially only the PVHI and PVHH alarms are
allowed and later on at 17:45:00 $RPSELCT reported at 17:30:00. When $RPSELCT is
is allowed. allowed, PVROCP is also reported on the
alarm summary and the RTJ. The time
stamp of this alarm is 17:45:00.
Initially $HISELCT, $HHSELCT and Initially PVHI, PVHH and PVROCP alarms
$RPSELCT is allowed. Later $RPSELCT is are reported. When $RPSELCT is cutout,
cutout. the PVROCP alarm behaves according to
the NCF option selected.
Option 1: CLEAR WHEN ACKD If this

option is selected, the PVROCP alarm, if
unacknowledged remains on the alarm
summary with its time stamp backlit. The
alarm is removed from the summary when it
is acknowledged.
Option 2: CLEAR IMMEDIATELY

If this option is selected, the PVROCP
alarm is removed from the alarm summary
irrespective of whether it is acknowledged
or not.

Continued
A point is in alarm and cutout. Selective

cutout is allowed for a particular alarm type
and the point is reconstituted.
Secondary point is in cutout and alarms on PVHI alarm is cut out and is present on the
PVHI and PVHH at 17:30:00. PVHI is also alarm summary with the time stamp
selectively cutout. The secondary point is 17:30:00. PVHH is cutout and is not shown
changed to inactive and PVHH is also on the alarm summary. When the
selectively cutout and reconstituted. The secondary point is made inactive, PVHI
point is later made active at 17:45:00. alarm disappears from the summary if
already acknowledged. At 17:45:00, when
the point is active, PVHI and PVHH alarms
of the secondary point appear on the alarm
summary with the time stamp 17:45:00.
Secondary point is in cutout and alarms on PVHI alarm is selectively cutout and is
PVHI and PVHH at 17:30:00. PVHI is also present on the alarm summary with the
selectively cutout. The node is shutdown and timestamp 17:30:00. PVHH is cutout and
later restarted at 17:45:00. does not appear on the alarm summary.
When the node is shutdown, the secondary
point is backlit. When restarted at 17:45:00,
PVHI and PVHH alarms of the secondary
point appear on the summary with the
revised time stamp.
Alarm Delay (applicable to HG only)
A primary point is configured with an alarm The alarm of the primary point is reported
on delay of 15 seconds and the secondary after a lapse of 15 seconds. Therefore, the
point is configured with an alarm on delay of secondary point is cutout immediately.
22 seconds. The secondary point goes into However, the PVHI alarm of the secondary
alarm on PVHI and the primary point is point is reported after the delay of 22
already in alarm. The selective cutout for the seconds.
PVHI alarm of the secondary point is set to
Allow.
A secondary point in AM has the primary The secondary point is cutout when PVHI
point in HG. The primary point goes to alarm alarms are annunciated for the primary
on PVHI. At this point, the HG is shutdown. point. The PVHI alarm of the secondary
The secondary point’s PVHI is set to allow. point is passed through as the selective
The PVHI alarms are annunciated for the cutout is set to allow. The PVHI alarm of the
secondary point. The alarm returns to secondary point is not reported as the point
normal. The PVHI alarms are annunciated is cutout. The RTN is also reported.
again for the secondary point.
Note: Even though the HG is shut down, the
secondary point remains in cutout.

Continued
HG functionality
Table 8-5 HG Contact Cutout Functionality
If the primary point... And the secondary is... Then the HG will...
(In R500)
Goes into alarm from a Not in alarm Distribute the primary point’s alarm.
non-alarm state
Goes into alarm from a Already in alarm Distribute the primary point’s alarm,
non-alarm state then instruct the US to cancel the
secondary point’s alarm.
Returns to normal from an Not in alarm, and did not return to Distribute a return-to-normal event for
alarm state normal while it was in cutout the primary point.
Returns to normal from an Not in alarm, and did return to Distribute a return-to-normal event for
alarm state normal while it was in cutout the primary point, and instruct the US
to remove the backlighting from the
time stamps of the secondary point’s
unacknowledged alarms on the
Alarm Summary, and backlight the
point’s priority indicator.
Returns to normal from an Still in alarm Distribute a return-to-normal event for
alarm state the primary point, and then distribute
the secondary point’s alarm.

Continued
NIM Functionality
Table 8-6 NIM Contact Cutout Functionality
If the secondary point... And the cutout condition... Then the NIM will...
(In R500)
Has gone into alarm Is false Distribute the secondary point’s alarm.
Has gone into alarm Is true Do nothing.
Is still in alarm Has changed from true to false Distribute the secondary point’s
alarms*.
Is still in alarm Has changed from false to true Instruct the US to cancel the secondary
point’s alarms.
Has returned to normal Has remained false Distribute a return-to-normal event for
the secondary point*.
Has returned to normal Has remained true Do nothing.
Has returned to normal Has changed from false to true Distribute a return-to-normal event for
the secondary point*.
Has returned to normal Has changed from true to false Instruct the US to remove the
while the point was cutout backlighting from the time stamps of
the secondary point’s unacknowledged
alarms on the Alarm Summary,
backlight the point’s priority indicator,
and send to RTJ.
* Note: Digital Input points that are configured for Change of State (COS) reporting generate an alarm
each time the point changes state, never generate return-to-normal events, and do not regenerate
alarms when contact cutout is removed.

Continued
AM functionality
Table 8-7 AM Contact Cutout Functionality
If the secondary point... And the cutout condition... Then the AM will...(In R500)
Has gone into alarm Is false Distribute the secondary point’s alarm.
Has gone into alarm Is true Do nothing.
Is still in alarm Has changed from true to false Distribute the secondary point’s alarm.
Is still in alarm Has changed from false to true Instruct the US to cancel the
secondary point’s alarm.
Has returned to normal Has remained false Distribute a return-to-normal event for
the secondary point.
Has returned to normal Has remained true Do nothing.
Has returned to normal Has changed from false to true Distribute a return-to-normal event for
the secondary point.
Has returned to normal Has changed from true to false Instruct the US to remove the
while the point was cutout backlighting from the time stamps of
the secondary point’s
unacknowledged alarms on the Alarm
Summary, backlight the point’s priority
indicator, and send to RTJ.

8.7 Alarm Priorities and Alarm Actions
Alarm priorities The following table describes the functionality for the different alarm
priority choices:
Table 8-8 Alarm Priority Choices
Priority Value Action
NOACTION Alarm is not displayed, printed, or journaled.
JOURNAL Alarm is recorded in the Process Alarm Journal. It is not displayed or
printed.
LOW Alarm is recorded in the Process Alarm Journal, printed on the Real
Time Journal (RTJ), and displayed on the Alarm Summary display.
HIGH Alarm is recorded in the Process Alarm Journal, printed on the RTJ,
and displayed on the Alarm Summary displays.
EMERGENCY Alarm is recorded in the Process Alarm Journal, printed on the RTJ,
and displayed on the Alarm Summary displays.
PRINTER (New for R500) Alarm is printed on the RTJ. It is not displayed or journaled.
JNLPRINT (New for R500) Alarm is recorded in the Process Alarm Journal and printed on the
RTJ. It is not displayed.
Alarm actions The following tables show alarm actions for different alarm priorities
and the alarm enable states:
Alarm priority All of these actions are based on an Alarm Enable State (ALENBST)
of ENABLE.
Table 8-9 Alarm Priority XXXXPR (E:ALPRIOR)
Backlit Trip Point Alarm Indicator Alarm Indicator Alarm at RTJ printer
Parameter in Det in Overview in Grp/Det
NO ACTION Yes
JOURNAL Yes Yes Yes Yes
PRINTER Yes Yes Yes Yes
JNLPRINT Yes Yes Yes Yes
LOW Yes Yes Yes Yes
HIGH Yes Yes Yes Yes
EMERGENCY Yes Yes Yes Yes

8.7 Alarm Priorities and Alarm Actions, Continued
Alarm priority, more

actions
Table 8-9 Alarm Priority XXXXPR (E:ALPRIOR), more actions
Recorded in Displayed in Displayed in Displayed in
Event History Unit Alarm Area Alarm Alarm Annunciator
Summary Summary Display
NO ACTION
JOURNAL Yes
PRINTER
JNLPRINT Yes
LOW Yes Yes *
HIGH Yes Yes Yes
EMERGENCY Yes Yes Yes Yes
* Default is no. The system can be configured to display LOW priority alarms in the Area Alarm
Summary. This is done in the NCF, System Wide Values/Console Data.
Alarm enable states The alarm enable states for each alarm action is listed in the
following two tables:
Table 8-10 Alarm Enable State ALENBST (E:ALENBST)
Backlit Trip Point Alarm Indicator Alarm Indicator Alarm at RTJ
Parameter in Det in Overview in Grp/Det printer
INHIBIT No No No No
DISABLE Yes Yes Yes No
ENABLE Yes Yes Yes Yes
Table 8-10 Alarm Enable State ALENBST (E:ALENBST), more

actions
Recorded in Displayed in Displayed in Displayed in
Event History Unit Alarm Summary Area Alarm Alarm Annunciator
Summary Display
INHIBIT No No No No
DISABLE Yes (see NOTE) No No No
ENABLE ** ** ** **

** This action depends on the individual Alarm Priority (E:ALPRIOR)

NOTE: With R680, the Process Alarm Journal can optionally display the ALENBST for Disabled
alarms. The journal will indicate the letter ‘D’ in the 127th column, between PRIMMOD and Event
ID/Type entries (for an example, see the Process Operations Manual). The journal includes the ‘D’
indication for the RTN/ALM events of process alarms (event type 21) and HG generated SOE events
only (event type 27). Both the Event History Retrieval display and the System Documentation tool
include the ‘D’ indication in the retrieved journals.
By default the Process Alarm Journal does not denote disabled alarms. To select this option, you
must make a change in the NCF – change the value of the following item in the System wide values -
> Console data: ALENBST INDICATION IN JOURNAL FOR DISABLED ALARMS. For more
information See Network Form Instructions.

Change of Alarm If an operator or a user application changes the alarm priority of a

priority while in alarm point when the point is in alarm, the data-owning node will
rebroadcast the alarm.
The HM Alarm Journal records the alarm rebroadcast. When the HM
Alarm Journal is retrieved, it displays the alarm events as though the
point went into alarm multiple times with no return-to-normal
condition in between alarms.
The US/GUS filters the alarms that are rebroadcast. If the alarm
condition is already known to the US/GUS, the Real Time Journal is
not printed again.

8.8 PRIMMOD Alarm Groups
Purpose The following subsections describe PRIMMOD alarm groups,

multiple PRIMMOD (MPROD), and Auxiliary Unit (AUXUNIT)
functions that can be used to enhance and add flexibility to your
alarm management configuration.
• The PRIMMOD function, described below, is available in R500.
• The multiple PRIMMOD, described later in this section, is
available in R520.
PRIMMOD point A PRIMMOD (primary module) point is a single point to which other
points are linked. The PRIMMOD point provides a mechanism for
grouping related points to create alarm groups to support more
flexible and customized alarm annunciation. In batch operations,
PRIMMOD parameters can be used to identify a set of points as
belonging to a batch equipment unit or batch ID, or to identify the
PRIMOD point responsible for manipulating the group of points.
PRIMMOD alarm A PRIMMOD alarm group is simply any number of points linked to a
groups single PRIMMOD point.
All points with matching PRIMMOD parameters are considered to be
in the same group.
Benefits of PRIMMOD The benefits of PRIMMOD groups include:

groups
• When a process alarm, operator change, or operator message is
journaled, the PRIMMOD parameter goes to the journal along with
the point name and descriptor; consequently, all events are “tagged”
with the PRIMMOD name. To make use of this feature, you can
retrieve journal events for a PRIMMOD group by using the Event
History Retrieval display or the Documentation Tool.
• The US alarm manager maintains the composite alarm status (the
highest alarm condition) for a PRIMMOD group. The status can be
displayed to the operator by assigning the PRIMMOD group to an
annunciator box on the Area Annunciator display, or assigning it to
a button with LEDs.
• You can create customized schematics that reflect the alarm status
of a PRIMMOD group. You can simply display the alarm status, or
you can use Variants and Conditions to change the display
appearance based on the alarm status.

8.8.1 Configure a PRIMMOD Point
Point configuration To implement PRIMMOD groups, first you build or choose a point to
be the “primary module” point. The primary module point can be a
“low cost” point, such as a Numeric or Flag.
DIST841
“primary module” point
FIC21841 TI21841
PRIMMOD=DIST841 PRIMMOD=DIST841
All LCN points have a PRIMMOD parameter except UCN

component points and Computer Gateway (CG) points. In R500,
PRIMMOD was added to all FULL form UCN points.
Example Figure 8-1 shows a Numeric point type configured as the primary
module point, because it is only to be used for alarm grouping. You
can use a Basic Controller RV point or some other “low cost” point.

8.8.1 Configure a PRIMMOD Point, Continued
Figure 8-1 Primary Module Point Example
33455

8.8.2 Link Points in the Alarm Group to the PRIMMOD
Identify points in the When the PRIMMOD point has been created or identified, then
alarm group identify the points that you will link to the PRIMMOD point.
Link points to alarm Next, for each point to be linked to the PRIMMOD alarm group,
group enter the PRIMMOD point name in the PRIMMOD parameter field
of that point. Do this for all the points to be included in the
PRIMMOD’s alarm group. When linked, these points are “related”
to the PRIMMOD’s alarm group.
Example Figure 8-2 shows the PED configuration display and Figure 8-3
shows the point detail display of FIC21841. The PRIMMOD
parameter contains the name of the primary module point, DIST841,
to which FIC21841 is “linked.”
Figure 8-2 PRIMMOD Parameter in PED
33453

8.8.2 Link Points in the Alarm Group to the PRIMMOD,
Continued
Figure 8-3 Point Detail Display with PRIMMOD Parameter
33454

8.8.3 Rules For Referencing the PRIMMOD Point
Point rules The following point rules apply when configuring alarm groups using
PRIMMOD parameters:
• All points on the LCN have PRIMMOD parameters in their point
structure, except Computer Gateway points and component UCN
points.
• There is no limit to the number of points that can be grouped under
a PRIMMOD point.
• Any type of LCN point can be used as a PRIMMOD point;
however, the following restrictions apply when assigning points to
a primary module:
– The PRIMMOD value of an Application Module point can be
any valid local LCN point.
– The PRIMMOD value of a UCN point must be a point in the
local gateway (NIM).
– The PRIMMOD value of a hiway point must be a point in the
local gateway (HG or PLCG).
• The error message “ENTITY ID ERROR” appears during point
build if the PRIMMOD value of a NIM, HG, or PLCG point is not
located in its local LCN node.
PRIMMOD parameter The PRIMMOD parameter Help displays are in the PED. The
Help displays parameter has the same functionality for all LCN point types.

8.8.3 Rules For Referencing the PRIMMOD Point,
Continued
Summary of Table 8-11 summarizes the point restrictions when using PRIMMOD
PRIMMOD restrictions parameters.
Table 8-11 Summary of PRIMMOD Restrictions

If the PRIMMOD point is a... These Points Can Reference It in their
PRIMMOD parameter...
NIM Point Local NIM Points
AM Points
HG/PLCG Point Local HG/PLCG Points
AM Points
AM Point AM Points
ATTENTION .
Attention—These restrictions apply only to the modification of the
PRIMMOD parameter on AM points. If a user is changing the value
AM PRIMMOD of a PRIMMOD parameter on an AM point, the following restrictions
restrictions apply:
• AM PRIMMOD parameter changes from CL foreground programs
is NOT allowed. An attempt to do so will result in a CL runtime
error. AM PRIMMOD parameter changes from CL background
programs is allowed.
• If an AM PRIMMOD parameter is being changed from a schematic,
the new value must be an “on-node” point, that is, a point that is on
the same AM node as the point being changed.

8.8.4 Retrieving Events for a PRIMMOD Group
Purpose The PRIMMOD parameter can be used to tie events together for
event history retrieval.
In R500, after selecting PROCESS ALARMS, PROCESS
CHANGES, or OPERATOR MESSAGES on the Event History
Retrieval display, a PRIMMOD target appears.
You can retrieve events for up to eight PRIMMOD groups.
Before R500, a MODULE target appeared instead of PRIMMOD ,
and only a Process Module type of point could be entered.
Procedure Figure 8-4 shows how to retrieve events related to one or more
PRIMMOD groups. (See the Process Operations Manual, SW11-
601, for changes to the Event History Retrieval display in R600.)
Figure 8-4 Event History Retrieval by PRIMMOD

1. Select the 2. Select 3. Select PRIMMODn,
journal type. PRIMMOD then enter the name of
a primary module point
or the $MPRODn
string.
4. To retrieve events for points in specific units, select SELECT UNIT, then enter the units.
To retrieve events for all points in the local Area, select UNITS IN LOCAL AREA. 33457.1

8.8.4 Retrieving Events for a PRIMMOD Group, Continued
Example In Figure 8-5, events were retrieved for points with DIST841 or
FLAG1 in their PRIMMOD parameter in units 01 and 97.
Figure 8-5 Example of PRIMMOD Event History
33458
33459

8.8.5 Alarm Annunciation Using PRIMMOD Groups
Description Figure 8-6 shows, after the PRIMMOD point configuration is done,
you can do the following to make use of the PRIMMOD group:
• assign PRIMMOD group to a button LED,
• assign PRIMMOD group to a box on the Area Annunciator display,
• build a custom schematic display that shows the alarm status of the
PRIMMOD group.
If you build a point specifically to use as a primary module for alarm
grouping, you may want to consider giving the primary module point
the same name as the Schematic assigned to the button.
Figure 8-6 PRIMMOD Alarm Annunciation
Process Schematic
Alarm Schematic Annunciator Display

Button
Display the
PRIMMOD
- Alarm Status
- Alarm Count
DIST841
Primary Module Point
FIC100 FIC200
TI100 TI200
Unit 1 Unit 2
33460

8.8.6 Using Multiple PRIMMODs for AM Alarms
MPRODs In R520, the Multiple PRIMMOD (MPROD) alarms option allows a

single alarm on an AM point to be reflected in four alarm groups in
addition to the standard PRIMMOD parameter group to be used for
alarm displays and event history.
Background The four additional alarm groups are identified by four string-type
parameters, $MPROD1–$MPROD4. All AM alarmable points have
these four $MPROD parameters. The PRIMMOD and $MPROD
groups may be referenced from displays, and button LEDs, and used
for event history retrieval.
Reference Reference these publications for more information:

Publication Section
Engineer’s Reference Manual (this document) 8.8, PRIMMOD Alarm Groups
Application Module Control Functions 2.3.15 Process Alarms
Application Module Parameter Reference Dictionary
Application Module Forms
Application Module Form Instructions
System Control Functions 4.3 Alarming

8.8.7 Using Auxiliary Units ($AUXUNIT)
Auxiliary unit In R520, all alarmable AM, NIM, HG point types have an Auxiliary
Unit ($AUXUNIT) parameter that allows all process alarms on a
point to be dynamically redirected from the point’s primary unit to an
alternate unit for alarm displays.
Background On the US, process alarms that have an $AUXUNIT parameter are
directed to the Auxiliary Unit instead of the primary unit for unit
alarm counters and alarm summaries. All other event types received
at the US belong to the primary unit only.
If a point has an $AUXUNIT parameter, then both the primary and
auxiliary units must be configured to the US’s local area database in
order to change a parameter value on that point.
A point’s $AUXUNIT can be changed on a US by a schematic, DEB,
ALTER PARAMS, or detail display. When an $AUXUNIT is
changed, alarms from the prior Auxiliary Unit are cleared and alarms
on the new Auxiliary Unit are displayed. The key level access can
limit who is permitted to change this value.
Process Alarm The alarm enable status of a point’s assigned unit, not the auxiliary
Behavior unit, determines the annunciation behavior of the point. Here is an
example:
Assume that point TIC200 is assigned to unit A1 and has an

$AUXUNIT of B2.
• If the Console alarm state for unit A1 is DISABLED, process

alarms for point TIC200 will not be annunciated to this console
regardless of the Console alarm state of unit B2.
• If the Console Alarm State for unit A1 is ENABLED, process
alarms for point TIC200 will be annunciated to this console
regardless of the Console Alarm State of unit B2.
Of course, individual alarm priority levels continue to apply.
The following tables show how the Console and System Alarm states
affect the display of Auxiliary Unit alarms on the US Alarm displays.

8.8.7 Using Auxiliary Units ($AUXUNIT), Continued
Behavior of Console Console Alarm State

and System Alarms
A process alarm that occurs while the CONSOLE ALARM STATE
for the primary unit is DISABLED will be filtered out at the US. The
alarm will not appear on any of the alarm displays and will not be
printed in the RTJ.
A process alarm that occurs while the CONSOLE ALARM state for
the auxiliary unit is DISABLED will NOT be filtered out at the US.
CONSOLE ALARM Primary Unit Primary Unit
STATE Enable Disable
Auxiliary Unit Yes No
Enable
Auxiliary Unit Yes No
Disable
Yes – Alarm WILL appear on the Alarm Summary displays
No – Alarm WILL NOT appear on the Alarm Summary displays
System Alarm State
A process alarm that occurs while the SYSTEM ALARM STATE for
the primary unit is INHIBITED or DISABLED is not distributed by
the data owners to the US. This means the alarm will not appear at
any of the alarm displays and will not be printed in the RTJ (for
DISABLED state) or sent to the HM (for the INHIBITED state).
SYSTEM ALARM Primary Unit Primary Unit Primary Unit
STATE Enable Disable Inhibit
Auxiliary Unit Yes No No
Enable
Disable
Inhibit
Yes – Alarm WILL appear on the Alarm Summary displays
No – Alarm WILL NOT appear on the Alarm Summary displays

8.8.7 Using Auxiliary Units ($AUXUNIT), Continued
Reference Refer to the following publications for more information:

Publication Section
Application Module Control Functions
Application Module Parameter Reference
Dictionary
Application Module Forms
Application Module Form Instructions
Data Hiway Box/Slot, and Data Point Forms HG Point Forms
Process Manager Configuration Forms PM Point Forms
Advanced Process Manager Configuration Forms APM Point Forms
High-Performance Process Manager Configuration HPM Point Forms
Forms
Hiway Gateway Parameter Reference Dictionary
Process Manager Parameter Reference Dictionary
Network Forms
Network Form Instructions
Process Operations Manual Section 7, Alarm and Message
Annunciation

8.8.8 Other R520 Alarm Enhancements
Introduction Other R520 alarm functions, some of which can be used for batch
alarming, are briefly described in this subsection and references to
more complete information are given.
Button LED control For R520, Button LED control function allows user written CL
applications to control (on/off/blink) the red and yellow LEDs on the
40 configurable LED buttons.
Reference these publications for more information:
Publication Section
Engineer’s Reference Manual (this document) Keyboard Button LED Assignment and Control
Control Language/Application Module Reference
Manual
Configuration Data Collection Guide Button Configuration Forms
Button Configuration Data Entry
Area Form Instructions
Button PRIMMOD or For R520, Button PRIMMOD or MPROD assignment allows runtime
MPROD assignment assignment of a new PRIMMOD name to any of the 40 configurable
LED buttons (allowing button assignments to be changed on the fly).
Publication Section
Engineer’s Reference Manual (this document) 33.0, Keyboard Button LED Assignment and
Control
Control Language/Application Module
Reference Manual
Actor’s Manual
Configuration Data Collection Guide Button Configuration Forms
Button Configuration Data Entry

8.8.8 Other R520 Alarm Enhancements, Continued
Detail/Group access For R520, Detail/Group access level option—parameter modification

level and control actions on the detail and group displays can be restricted
by NCF keylevel configuration. Reference these publications for
more information:
Publication Section
Control Language/Application Module Reference Manual
Network Forms
Area Database For R520, Area Database change actor—a new actor that allows Area
change actor Database changes to be done from custom schematics and
configurable buttons (allows operators to move easily from one area
to another).
Publication Section
System Startup Guide–Zip Drive
Picture Editor Data Entry
Picture Editor Reference Manual
Actor’s Manual
Silence horns on For R520, the silence horns on console function is an NCF
console configurable option that causes the silence button to silence all horns
on the same console (all areas assigned to that console). The horn
silence button on one console will not silence the horn generated for
another console, even if that console is on the same area.
WARNING If there was one set of horns on a Universal Station within the
console and that station had the Engineering Main Menu on display,
when an alarm was detected, there would NOT be any audible
annunciation. (The Alarm Summary LED would start to blink so
there would be some visual clue.) Wire all annunciator blocks in a
console together to a single set of horns so that if at least one station
is not in Engineering function, the horns will still go off.

8.8.8 Other R520 Alarm Enhancements, Continued
Silence horns on
console,
continued
Publication Section
Process Operations Manual “Silencing the Horn”
Section 8
Network Forms
RTJ color alarms For R520, RTJ color alarms function is an NCF configurable option
that allows all process alarms (SOE, process and sequence alarms)
and return-to-normal events to be printed in color on the Real-Time
Journal. Reference these publications for more information:
Publication Section
Process Operations Manual Printer Appendix
Network Forms
System Startup Guide–Zip Drive
Keylevel change For R520, keylevel change journal suppression function allows the
journal suppression user to suppress the journaling of keylevel change events by actors.
Configure this option from the Engineering Main Menu by selecting
System Wide Values, then selecting Console Data. Reference the
Actors Manual, Section 3.3, 3.4 for more information:
PRIMMOD Status and For R520, two actors are available for reading the composite alarm
Count actors status and alarm count of a specified PRIMMOD or Multiple
PRIMMOD. These are actor equivalents of the $PRIMSTS and
$PRIMCNT collectors. Reference the Actors Manual for more
information.

8.8.9 R610 Alarm Summary Enhancement
DATE Added to In Release 610 the DATE of occurrence of each alarm has been
Process Alarm added to the already existing TIME field in the process alarm
Displays in R610
displays – Area Alarm Summary, Unit Alarm Summary and Alarm
Annunciator Display.
Description When either process alarm display is called up, the TIME/DATE
mode defaults to TIME and the text in the target is set to TIME. Each
alarm entry displays the time that the corresponding alarm occurred.
By repeatedly selecting the TIME/DATE target, three modes toggle

in the order of TIME, DATE or BOTH DATE & TIME. There is no
timer associated with this target so the selected mode will remain in
force as long as the display is not selected again. When another
alarm display (any other display or PRIOR DISP) is selected, the
mode defaults back to TIME regardless of its last mode state.
To accommodate the new target, the existing target “FREEZE

DISPLAY” is shortened to “FREEZE DISP.” When the display is
frozen the text will read “DISP FROZEN.” The time/date mode may
be changed while the FREEZE display is engaged. Although the
freeze mode remains in effect, the time/date field itself will be
modified accordingly.
The “SORT : PRIORITY” target is also shortened and now reads

“SORT: PRIORTY.”
Reference See Process Operations Manual for additional information about

these displays.

8.8.10 R681 Alarm Summary Enhancement
System Alarm With TPN R681/TPS R410, a system alarm is generated whenever a
generated to indicate Honeywell software component (running on Windows environment)
the change in the
auxiliary status of the
fails in a GUS/APP/ES-T/ESVT/ACE-T node.
node in R681
Description The state of the HCI components configured on the GUS/APP/ES-

T/ESVT/ACE-T nodes change on error conditions. The composite
status of the HCI components is indicated in the auxiliary status of
the node. When an HCI component fails and the auxiliary status of
the node changes to SEVERE, a system alarm is generated. The
System status display LED blinks to annunciate the change.
With all the HCI components on the node running, the auxiliary
status shows OK. When the composite status of the HCI components
changes to WARNING, the auxiliary status of the node changes to
WARNING. If any of the HCI components fail, the auxiliary status of
the node changes to SEVERE.
Reference For more information about these displays, see TPS System
Implementation Guide for Windows 2003/XP and System Components
Configuration Utility User’s Guide.

Section 9 – Data Entity Builder Operations
9.0 Reserved
In earlier versions of this manual, this section contained guidelines for Data Entity Builder
Operations. Refer to Data Entity Builder Manual. This section has been retained to direct
users familiar with an earlier version of this manual to the new location of the information and
to preserve the validity of references to other sections of this manual.

Section 10 – Native Window System Performance Displays
(Toolkit)
10.0 Overview
Purpose of the Native These Native-Window displays are provided to facilitate your access
Window system to TPS system performance and loading data that you can use for the
performance displays
following purposes:
• To allow you to evaluate your present system performance and
system loading to find opportunities to improve its performance or
to add system load by adding additional functions or activities.
• To monitor system performance and system loading so that you
become aware of deteriorating performance or increased system
load before either causes a problem.
• To diagnose the cause of poor performance or high system loading
so that you can make adjustments to correct the problem.
Some of the information on these displays may not be meaningful

except to the most technically competent and experienced users. Such
information is provided because it can be very useful to Honeywell
technical people when you call them for assistance.
The “Toolkit” Honeywell TPS system maintenance and service personnel often refer
to these displays as the Toolkit displays. Although the term is not
used in this document, it is considered synonymous with Native
Window System Performance displays.
CAUTION CAUTION—Honeywell makes no claim to the accuracy or

usefulness of these displays. They are intended to assist a trained
technician in diagnosing system problems.
Any value changes made from these displays are subject to the
normal key switch and access lock restrictions.

10.1 Preface
Where these displays In all but a few cases, the information on the Native-Window system
find performance performance displays is read from the Processor Status Data Points
information
(PSDPs) in one or more nodes on the LCN. Every node has a PSDP
and each node shares a common set of PSDP parameters. Each node
type (AM, NIM, US, etc.) also has a unique set of PSDP parameters
for its type.
For more information on PSDPs, refer to Section 22 in this manual.
How the displays are These displays are contained in volume or directory TLK1 on the
delivered Honeywell-provided media. The following are the media that contain
TLK1:
Disk &Z1 - TLK1 is a directory on this disk.

The content of TLK1 can be automatically loaded when you install the
system software. See 10.2 in this manual for the directory’s size
requirements.
Refer to 13.3 in this manual for detailed instructions for installing any
volume or directory.
What you must do to The following are the major steps for installing and using the System
install and use the Performance displays:
displays
Table 10-1 Procedures for Installing and Using the Displays
Step Action Reference
1 Install the displays in a volume or directory that the 10.2
Pathname Catalog points to.
2 Call up the System Performance Display Menu, 10.3
PERFMENU.
3 Select targets on the menu to call up the other 10.4
displays.
4 Review the description of the content of the 10.4
displays.
5 Follow the guidelines for using and interpreting the 10.5
information on the displays.
6 Follow the instructions for using the clock display to 10.6
check cables.

10.2 How to Install the System Performance Displays
TLK1 files are For R500 and beyond, the TLK1 volume or directory is automatically
installed loaded in an HM when you load the system software. For the R400
automatically in R500
version, the TLK1 volume or directory is not automatically loaded in
an HM when you load the system software; you must find space for
its content and manually load it.
Memory space In R400 and later, the approximate memory space occupied by TLK1
files is 180 KB.
Making performance If you have enough space in any volume or directory that a Pathname
displays available to Catalog points to, you can copy the contents of TLK1 into such a
your Universal
Stations
volume or directory. This makes the system performance displays
accessible in any US that is running with the area database that
contains that Pathname Catalog.
Providing for updates TLK1 displays are updated with major maintenance releases.
For this reason, we suggest you make TLK1 a net directory and have
each area’s pathname catalog point to TLK1.
Detailed installation For the detailed procedure for installing a volume or directory that,
procedure like TLK1, is not automatically loaded in an HM when you load the
system, refer to 13.3 in this manual.

10.2.1 Table of Current TLK1 Versions
DISPLAY R400 R430 R431 R500 R520 R600 R620 R640 R650 R651 R660 R680 R681 R682
PERFMEN R400 R430 R431 R500 R520 R600 R620 R640 R650 R651 R660 R680 R680 R680
U
NODEPER NONE R411 R411 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
F
DATACHN R232 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
G
QUIKTRND R400 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
CPUCHKR R400 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410
HEAPCHK R400 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
R
HEAPMIN R400 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
PARCHKR R400 R400 R400 R400 R400 R400 R400 R400 R400 R400 R400 R400 R400 R400
AMDETAIL R400 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410
AMTREND R400 R420 R420 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
SLTCONFG R232 R420 R431 R431 T431 R431 R431 R431 R431 R431 R431 R431 R431 R431
HEAPFRAG R400 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
CHKPTIME R300 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
CLOKMOD R400 DELE-
E TED
CLOKSYNC R400 DELE-
TED
CLOKTRAN R400 DELE-
TED
CLOKCABL R320 DELE-
TED
UCNCOMM R321 R411 R411 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
UCNEVENT R321 R411 R411 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
NIMTREND R322 R322 R322 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
NGDETAIL R400 R410 R410 R500 R500 R510 R510 R510 R510 R510 R510 R510 R510 R510
NGTREND R400 R410 R410 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
HMDETAIL R400 R410 R410 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
HMTREND R400 R410 R410 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
HGTREND R322 R322 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
UCNSUMM R411 R411 R411 R411 R411 R411 R411 R411 R411 R4z1 R411 R411 R411
1
NODESTA1 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
NODESTA2 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
CNAMERE R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
V
DRVSTS R420 R420 R420 R510 R510 R510 R510 R510 R510 R510 R510 R510 R510
CBREV R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410 R410

10.2.1 Table of Current TLK1 Versions, Continued
DISPLAY R400 R430 R431 R500 R520 R600 R620 R640 R650 R651 R660 R680 R681 R682
IOPMDATA R322 R322 R322 R322 R322 R322 R322 R322 R322 R322 R322 R322 R322
RULASTAT R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411 R411
HWYPERF R323 R323 R323 R323 R323 R323 R323 R323 R323 R323 R323 R323 R323
SISF R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420
UCNVERSN R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420 R420
PLCGCOMM R430 R430 R430 R510 R510 R510 R510 R510 R510 R510 R510 R510 R510
CALCULTR R420 R431 R431 R431 R431 R431 R431 R431 R431 R431 R431 R431 R431
CLOKSTAT R430 R431 R431 R431 R431 R431 R431 R431 R431 R431 R431 R431 R682
AXMPERF R431 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500 R500
HISGRPS R430 R430 R531 R531 R531 R531 R531 R531 R531 R531 R531
AMDIAGNS R510 R510 R510 R510 R510 R510 R510 R510 R510 R510
ARCFGALM R510 R510 R510 R510 R510 R510 R510 R510 R510 R510
EPLCGCOM R510 R510 R510 R510 R510 R510 R510 R510 R510 R510
LCNVIEWR R520 R520 R520 R520 R520 R520 R520 R520 R520 R520
LVRLOG R430 R430 R430 R430 R430 R430 R430 R430 R430
HOLDBRTH R530 R530 R530 R530 R530 R530 R530 R530 R530
CDET_CLR R620 R620 R620 R620 R620 R620 R620 R620
AMCLDBUG R650 R650 R650 R650 R650 R650
AMCLDSPL R650 R650 R650 R650 R650 R650
CHANINFO R651 R651 R651 R651 R651
HGDETAIL R660 R660 R660 R660
NMDETAIL R660 R660 R660 R660
UCNDEVUT R680 R681 R681
CLSNODE R680 R681 R681
LCNPERF R680 R681 R681
CLKSWTCH R682
Note: The .DS file is provided for the CLSNODE display.

DIA1
MRGLTHR R681 R681
LNDGCBL R681 R681
LNDGNST R681 R681
LNDGERS R681 R681
LNDGERA R681 R681
LNDGPNG R681 R681
ATTENTION .
ATTENTION—Local database corruption fixes from R411 were
backed into R410 before volume distribution. Uninitialized values
cause an error on the first call up of a display using TLK1 DDB
values after node load. Errors will not reoccur after the first display
use.

10.3 How to Call Up the System Performance Displays
To call up the System If you have configured a button to call up the PERFMENU display,
Performance Displays on a station with any operator display on the screen, press that button.
Menu
The menu appears.
If you do not have a button to call up the menu, call up any operator
display and follow these steps:
Table 10-2 Procedure to Call Up a Performance Display

Step Action Result
1 Press the [SCHEM] key. A port appears in the upper-
left region on the display.
2 In the port, enter PERFMENU and The first page of the System
press the [ENTER] key. Performance Displays Menu
appears.
3 On the menu, select any target. The selected display
To see the targets on menu page appears.
pages two or three, select the
PAGE 2 or PAGE 3 target.

10.4 The Displays and Their Content
Performance Displays Below are pages 1, 2 and 3 of the Performance Displays Menu. To
Menu see any of the remaining displays, just select one of the targets on this
display.
To see the second page, select the PAGE 2 target.
To see the third page, select the PAGE 3 target.
Performance Displays Menu (Page 1 of 3)

10.4 The Displays and Their Content, Continued


Display descriptions A brief description of the function of each display is beside each
target and is generally self-explanatory. The explanations that follow
describe the use of some displays for functions that may not be
readily apparent. (For function LCN Node Version Revision
Logging, R520, see Engineer’s Reference Manual—this manual).
Current Display In R600 a new read only parameter, CURRDSP, is implemented to

Parameter enable the user to determine what display is on the Universal Station
screen. The parameter allows the user to:
• Track which displays are most used.
• Determine which displays are no longer used.
• Determine the sequence of displays invoked by the operator.
• Find the name of the schematic that is currently on display.
• Put the schematic source filename on each schematic.
The contents of this PSDP can be queried by the same method as any
current PSDP. This includes using a custom schematic, AM CL, etc.
Checker Target Some displays have a Checker Target that allow you to set a test
value for the parameter being displayed. For example, CPUCHKR
uses a default value of 25 and compares all node CPUFREE values
against that value. Any value less than or equal to the check value is
reverse highlighted. Another example is the PARCHKR display with
a default check value of 100. All values larger than or equal to the
value are reverse highlighted. It depends on the specific parameter
whether the test is "up" or "down" significant. The Checker Target
allows setting a specific value for test and easy use since in some
cases sorting out numbers is inconvenient.
Parameter Access The DATACHNG display can be used to read up to 10 parameter

and Value Change values at once. You can also change one or more parameter values.
display You do this by selecting one of the parameter/value lines on this
display. Then enter the entity name and parameter in the left port and
the new value in the right port and press [ENTER]. Enter the entity
name (tag name or reserved entity name) and parameter in the
NAME.PARAM form.
You do not need an Engineer’s Keyboard to use this display; when it
first appears, “$”, “(”, and “)” appear in the name/parameter port.
You can use them or strike over them, as necessary. Value changes
from this display are subject to the normal key switch and access lock
rules.

Node-related displays The following displays contain information from a user-specified

node or from all nodes on the LCN:
Table 10-3 Node-Related Displays

Display Description
NODEPERF Node performance display. Displays the values for key

performance parameters in the PSDP for the node you
select. Six of the values are shown as bar charts, as well
as digital values.
LCNPERF LCN Load Information. Displays the selected load

parameters for individual LCN nodes, estimated % of LCN
load and the selected LCN load parameters.
CLSNODE The CLSNODE display is used for assigning segment

numbers to the LCN nodes.
PARCHKR Displays the average parameter access rate per second

from PSDP parameter PARSEC for each node on the LCN.
Values for nodes not installed or not operating are blank.
AMTREND Display a trend for each of several key PSDP parameter
HMTREND
values for the node you select.
NGTREND
AMDETAIL Display the values for a large number of significant PSDP
HGDETAIL
parameters for the node you select.
HMDETAIL
NGDETAIL
NMDETAIL
UCNDEVUT
HOLDBRTH HOLDBRTH for a node increment when a data request is
not provided within 2.5 seconds.
AMCLDBUG Allows user to define the filter options for finding process
changes caused by AM/CL, and for starting and stopping
the collection of AM/CL process changes.
AMCLDSPL Buffer that contains up to 100 of the last process changes

caused by AM/CL. It lists the point names and the
parameters changed, the values stored, and the names of
the AM points and the AM/CL blocks that are performing the
stores.
CHANINFO Shows the names of applications that have been allocated

channels in the applicable GUS or APP node.

Quick Trend display Table 10-4 Quick Trend Display

for user-selected
values
Display Description
QUIKTRND Provides up to four trend traces for parameter values you
enter. Enter the entity name (tag name or reserved entity
name) and parameter in the NAME.PARAM form.
Instructions for the use of this display are built in.

SELECT
To see them, select FOR HELP .
LCN cable The $LNMENU target presents an LCN cable diagnostics menu.
diagnostics
Refer to LCN Guidelines - Implementation, Troubleshooting, and
Service for LCN cable diagnostics instructions.
Processor free-time Table 10-5 Processor Free-Time Display

display
Display Description
CPUCHKR For each node on the LCN, shows the average of the
percentage of time the processor was idle or free over the
last fifteen seconds. For each node, this value is read
from PSDP parameter CPUFREE. Values for nodes not
installed or not operating are blank.
Heap displays The following displays contain heap memory information from all
nodes on the LCN. Values for nodes not installed or not operating
are blank. Heap memory is memory in a node that is reserved for use
by the node software. The software uses and releases the heap
memory dynamically, reducing the overall amount of memory needed
to run the software.

Table 10-6 Heap Displays

Display Description
HEAPCHKR Displays the value in the nodes’ PSDP HEAPFREE
parameter. The HEAPFREE value is the number of heap
words currently not in use.
HEAPMIN Displays the value in the nodes’ PSDP HEAPMIN
parameter. The HEAPMIN value is the minimum number of
heap words left free since the node was started.
HEAPFRAG Checks each node’s HEAPFRAG against an entered check
value.
Checkpoint Time and Table 10-7 Checkpoint Time and Interval Display
Interval display
Display Description
CHKPTIME Shows period, offset, duration, and starting time values for
the HM you select. These values are read from the node’s
PSDP TIMEBASE(n) value array. You can change the
checkpoint period and offset from this display, but before
you do, refer to 21.2.2 in this manual and heed the
CAUTION about creating system performance problems.
Box/slot verification Table 10-8 Box/Slot Verification Display

display
Display Description
SLTCONFG Allows convenient verification of the box/slot configuration
in the HG against the actual hardware in the box.
Only HLPIU, LLPIU, LEPIU, DHP and the MCs are
supported.
To use, enter the two-digit hiway and box data.
Mismatches in the configuration are marked in red.
Incorrect entries generate an error display and a reset
target.

Clock displays The clock status (CLOKSTAT) display contains system clock
(CLOKSTAT) information from all nodes on the LCN. Values for nodes not installed or
not operating are blank.
Table 10-9 Clock (CLOKSTAT) Displays

Display Description
CLOKMODE Displays the clock operating mode for each LCN node:
• MASTER—The node supplying the primary hardware clock.
• SLAVE—The node supplying the backup hardware clock.
• LISTENER—All other nodes using the LCN broadcast
clock.
• LOCAL—Any node using an internal precision reference.
CLOKCABL Displays the clock operating mode for each LCN node:
• ALTCABLA or ALTCABLB—Clocks are being received
alternately on both cables. This is proper operation.
• CBLA or CBLB—Clock received only on cable A or cable B.
• NOUPDATE—No clock received on either cable.
CLOKSYNC Displays the clock synchronization status for each LCN node.
• PRECREF—Synchronized to an internal or ac precision
reference.
• SUBSYNCH—Synchronized to a time-frame received from
the subchannel clock system.
• DIGSYNCH—Synchronized to a time-frame received from
the digital clock system.
• NOTSYNC—Clock not synchronized.
CLOKTRAN Displays the clock translation state for each LCN node.
• TRNSLTR—Identifies which K2LCN/K4LCN-based node on
the network is translating a subchannel clock to a digital
clock.
• NONTRNS—Identifies the other K2LCN/K4LCN nodes and
all other non- K2LCN/K4LCN nodes.
Clock translation is required in a system that mixes nodes
using some K2LCN/K4LCN processor boards and some other
processor boards. In a system using either all or no
K2LCN/K4LCN processor boards, every node’s status is
NONTRNS.
See 10.6 in this manual for information on switching the clock source
nodes.
See 10.7 in this manual for information on using the clock displays.

10.5 How to Interpret the Information on the System
Performance Displays
A general We recommend that you use these displays during normal operation
recommendation to view and record key PSDP values when the system is running well
as a “baseline.” Then, from time to time or when there is evidence of
overloading or poor performance, you can compare your baseline
values with the new values to determine what has changed.
If you wait until there is evidence of trouble before you use these
displays, it may be too late to take preventive measures. Even then,
you will likely find these displays helpful, if not essential, for
analyzing poor performance or overloading.
One way you can record the data on these displays is to use the Print
Screen function.
The Processor Status Except for some user-defined parameters, all parameters shown on
Data Point the System Performance displays are read from processor status data
points (PSDPs) in the LCN nodes. Every node has a PSDP and each
PSDP has several hundred parameters and parameter values. For
more information about PSDPs, including definitions of all PSDP
parameters accessible by users, refer to Section 22 in this manual.

10.5 How to Interpret the Information on the Performance
Displays, Continued
Guidelines for key The following tables list PSDP parameters that are especially useful
parameter values in monitoring the performance and loading. All nodes have these
parameters.
Memory-Use Values The following parameters contain memory-use values:
Table 10-10 Memory-Use Values

Parameter Display Guidelines
HEAPFREE NODEPERF This value typically exceeds 10,000 words.
However, experience has shown that AMs
can have HEAPFREE values in the range
of 20,000 to 30,000 words and still operate
properly.
HEAPMIN NODEPERF Except for AMs, this value should be
75,000 words or more.
HEAPFRAG NODEPERF This heap fragmentation value is normally 0
or 1. Values of 3 or 4 are rare, and can
indicate impending node failure.
HEAPFRA2 NODEPERF This heap fragmentation value is normally 0
or 1. Values of 3 or 4 are rare, and can
indicate impending node failure.
Processor Load CPUFREE indicates the load on the node’s processor:

Indicator
Table 10-11 Processor Load Indicators
CPUFREE CPUCHKR Except for short intervals (a few seconds),
this value should not go below 15%. Nodes
that use the 68020 microprocessor have
significantly less processor-free time than
those that use the 68040 microprocessor. In
Release 500, CPUFREE calculations are
based on clock time, not instruction loop
times. Do not compare R500 values with
previous release values.

Displays, Continued
Parameter-Access The following parameters contain parameter-access load values:
Load Values
Table 10-12 Memory-Use Values
PARSEC PARCHKR This is the average number of parameters-per-
second requested from this node by other
nodes. Normally it should not exceed the
following values:
• 68020 HG—630 parm./sec. + 90 points/sec.
AM load (1200 parm./sec. with no AM load)
• 68040 HG—960 parm./sec. + 120 points/sec.
• 68020 NIM—750 parm./sec. + 90 points/sec.
• 68040 NIM—1400 parm./sec. + 120
points/sec.(2000 parm./sec. with no AM load)
• 68020 AM—90 points/sec. + 410
parameters/sec. support for other nodes
• 68040 AM—120 points/sec. + 615
parameters/sec. support for other nodes
• CG—100 parm./sec. + 500 points/sec. due to
array access
RPARSEC NODEPER Indicates this node’s parameter-per-second read
F access rate on other nodes.
SPARSEC NODEPER Indicates this node’s parameter-per-second
F store access rate on other nodes.
RPARSEC and SPARSEC can help you to determine which nodes are
causing a PARSEC load on this node.
ATTENTION This note is to clarify the values that should not be exceeded, in the
“Guidelines” column of PARSEC in the Memory-Use Values table,
above. For example, for “68020 HG—630 parm./sec. + 90 points per
second AM load” the 90 points per second AM load, based on the
cluster model, implies an AM read/store access on the HG of
approximately 2 reads to 1 write per point.

Displays, Continued
CAUTION CAUTION— Parameters-per-second counts can be misleading

because certain parameter requests count as one, but cause a heavy
load on the data owner. Examples of parameter requests that create a
heavy load are.
• accesses into value arrays
• requests by Group displays
• requests by Detail displays
Parameter-access The following conceptual figure shows the relationship of the

load values, figure parameter-access load values: PARSEC, RPARSEC, SPARSEC,
REQUESTS, and RREQUESTS.
Figure 10-1 Parameter-access load values relationships
LCN
RREQUEST
REQUESTS
PARSEC RPARSEC
NODE SPARSEC
Read Responder
Store (server)
Read
Requestor Store
(client)
15045

Displays, Continued
Trend displays Below are some guidelines for interpreting the data on the trend
displays provided in volume or directory TLK1. These apply to all
the trend displays except QUIKTRND.
• When the display first appears, select SELECT & SPECIFY xx and
enter the node number for a node of the type served by the display.
START
• Start the trend by selecting TREND . In a few seconds, the trend
traces should begin to appear at the right edge of the trend.
• The default trend scale (rate) is 24 hours. To change it, select
CHANGE
RATE and enter a new rate code. Available rate codes are on
the second line on the display.
• Each of the trended parameter values is presented in digital form
below the trend. The color of the parameter name and value
indicates the color of the corresponding trace. The X axis range is
also indicated by a number of the same color.
• To learn the meaning of the parameter values, refer to Section 22.
Using QUIKTRND To use QUIKTRND, see its built-in help displays.

10.6 How to switch the clock-source nodes without
rebooting any LCN Nodes
Introduction With TPN R682, the clock master and slave nodes can be switched
online and does not require reboot of any node in the network. During
the clock mastership transition, the nodes go to Local mode. After the
Master / Slave transition is complete all the nodes become Listeners
to the new Master. This feature provides the following options:
• Swap the Master and Slave nodes
• Switch the clock Mastership and Slave to User specified nodes
• Switch only the Master node and keep the existing Slave with out
any change
• Switch only the Slave node and keep the existing Master with out
any change
CAUTION In case of any unsuccessful switching analyze the status of the nodes
and network.
To switch the clock To switch the clock source nodes, the CLOKSTAT schematic is to be
source nodes invoked by selecting the target from the PERFMENU display. To
switch the clock source nodes, follow the procedures mentioned in
Table 10-13.

rebooting any LCN Nodes Continued
Table 10-13 Procedure to switch the Clock Source Nodes

Step Action Result
1 From the PERFMENU CLOKSTAT schematic is displayed.
display invoke the
CLOKSTAT schematic.
2 Note down the current clock The display gives the node number in which the display
sources. Invoke the is being invoked. The option to enter the node numbers
CLKSWTCH schematic by for the proposed clock master / slave is provided.
selecting the CLKSWTCH
target.
Note: This display can be

invoked directly by using
the SCHEM key.

Table 10-13 Procedure to switch the Clock Source Nodes continued

3 Note down the new clock The entries in these ports are retained during the
sources / reported errors. operation.
Enter the proposed clock
source node numbers by
selecting the ports.
Note: By default, the

ports are blank.
4 Select the SWITCH target. The SWITCH target initiates the switching by intimating
Note down the new clock the nodes that need to take up the Mastership and
sources / reported errors. Slave.
OR
5 Select the SWAP target The SWAP target on the right swaps the Master node
and the Slave node. The Master becomes the Slave and
the Slave becomes the Master. This is active only when
the network has a Master and a Slave node.
Note: Entering the values on the ports shall disable the

SWAP option.
ATTENTION The CLOKSTAT display also contains the information about the existing
clock Master and Slave nodes in the network. Incase of multiple existences
of the clock Master / Slave nodes in the network, the nodes are backlit in
Red and also the multiple entries are displayed. The first occurrence is
taken as the current Master node for further operations by the schematic.
Status Indication The status of the operation is reported at the bottom of the schematic. On
invocation, the status of the last performed operation, initiated from that
node is displayed. The status is displayed in different colors as follows:
Status Color
In Progress Cyan
Completed Green
Error / Warning (High severity) Red
Error / Warning (Low severity) Yellow

Switching the Clock To switch the Clock Master and Slave, perform the Steps 1 through 4
Master and Slave mentioned in Table 10-13 and proceed with the other steps in the
following procedure.
Table 10-14 Procedure to switch the Clock Master and Slave

Step Action
1 through 4 Refer to Table 10-13.
5 To update NCF with new clock sources, refer to the Section, EDIT
CLOCK SOURCE On-Line Network Reconfiguration Procedure in
Network Data Entry manual.
Notes:
1. The NCF need not be updated for swapping the Master / Slave
nodes. The NCF is to be updated, when one or both of the clock
sources are changed.
2. When the node is selected from the NCF Status display, the node
continues to display the NCF time stamp it is currently loaded
with and displays the current NCF version.
3. To switch only the Master, select the Slave as the current Slave
node number. To switch only the Slave node, select the Master as
the current Master node number.
Switching when no When there is no Master node in the network, all the nodes follow the
Master node in the local clock mode. To assign Mastership to a node when there is no
network
Master node in the network, perform the following procedure.

Table 10-15 Procedure to switch when there is no Master node in the

network
Step Action
1 Invoke the CLOKSTAT schematic
2 Verify that no clock nodes exist
3 Invoke the CLKSWTCH schematic by selecting the CLKSWTCH target

Note: There is no Master / Slave in the network
4 Enter the new node numbers by selecting the ports
5 Select the SWITCH target
6 Note down the new clock nodes if no errors are reported
7 Change the NCF to synchronize the clock node information
ATTENTION When there is only a Clock Master on the network and a Slave has to be
assigned, then enter the Slave node first and then the Master node.
Selecting the Master node first displays the error message “EXISTING
CLOCK NODES SELECTED.”
Booting a node when There is a change in the behavior of a node, if it is booted or

NCF is not shutdown when the NCF is not synchronized with the new clock node
synchronized with
new clock node
information.
information
Example: Node 10 and 11 are the current Master and Slave nodes as
defined in NCF. These nodes are switched to Node 20 and 30 as
Master and Slave and the NCF is not synchronized with the changes.
The following table lists the behavior of the existing nodes and the
new nodes in different scenarios.

Table 10-16 Status of the nodes when booted/shut down when NCF is
not synchronized
If Then
Node 10 is booted The old Master node (Node 10) reads the NCF and tries to assign the
Mastership. As the Mastership is taken only in the absence of a Master, the
node comes up in the Listener mode. (Node 20 is the current Master).
Node 11 is booted The old Slave node (Node 11) comes up as a Listener. (Node 20 is the
current Master and 30 is the Slave).
Booting a node that is The node shall listen to the New master and shall take up the Listener
not defined as a clock mode.
node
Shutting down and On shutting down Node 20 which is the current Master, Node 30 takes up
booting Node 20 the Mastership. Other nodes shall continue to listen to the Master node
which is Node 30. On rebooting Node 20, the node shall take up the
Listener mode as it is not a clock source defined in NCF.
NOTE: As Node 20 is not a clock source in NCF, booting the node does not
make the node a Master. Node 20 becomes a Listener to the Master node
that is Node 30.
Booting Node 10 or 11 When the Nodes 20 and 30 are down, all the nodes rely on the local clock.
when Node 20 and 30 When Node 10 or 11 is booted, the node takes up the Mastership as it is
are down defined as the clock node in the NCF and there is no Master in the network.

10.7 Use the Clock Display to Find Crossed LCN Cables
Introduction For an LCN segment where the clock signals from the clock master
and slave nodes are provided by CS/R boards, you can use the
CLOKCABL display to verify that the segment does not have crossed
LCN cables.
Here, we discuss a procedure you can use to check for crossed LCN
cables.
LCN cable checks that This method of checking for crossed LCN cables:
can’t be made
• Can only be used on segments that use CS/R boards.
• It cannot detect crossed fiber-optic cables.
The LCNI tests in HVTS (Hardware Verification Test System) can be
used to check crossed cables not covered by this method. Refer to
Hardware Verification Test System for this information.
Normal clock On systems using normally operating clocks, the CLOKCABL

operation display should show each node using either ALTCBLA or
ALTCBLB.
• The clock alternates between the A and B cables every 50
milliseconds.
• All nodes probably won’t report using the same cable at the same
instant.
Crossed cables can Operating with crossed LCN cables (coaxial or fiber optic) can cause
cause system failures a system failure if a cable malfunctions.
WARNING WARNING—If you find crossed LCN cables when you make the
check described below, you cannot safely reconnect the crossed
cables while the system is controlling the process. This is because
you will have to remove both the A and the B cables at the same time.
If the system is controlling the process, defer reconnecting the
crossed cables until the system can be taken off control, but do not
defer for a long time.
False indications When the clock subsystem is damaged, the CLOKCABL display cannot
dependably show which cable is receiving clock signals.
If the following checking procedure does not give predictable results, your
clock system may require maintenance.

10.7 Use the Clock Display to Find Crossed LCN Cables,
Continued
Clock checking This procedure checks for crossed cables. Remember, it can’t find
procedure crossed fiber-optic cables and is only for LCN segments that use
CS/R boards.
Table 10-17 Checking Procedure for Crossed LCN Cables
Step Action
1 Call up the CLOKCABL display.
Result: Every active node displays either ALTCBLA or ALTCBLB.
All nodes don’t have to show the same cable, but all must indicate
“ALT” (alternating). This means an A and a B cable are connected
to each node and all nodes are receiving the alternating clock
messages.
Note: You may still have crossed cables, but the electronics are OK.
If this step fails, check for bad cables or faulty electronics.
2 Determine the two clock source nodes software has assigned:
• Use the CLOKMODE display to determine MASTER and SLAVE.
• If it doesn’t show them, use SYSTEM WIDE VALUES and
CLOCK SOURCE targets from the ENGINEERING MAIN
MENU.
Each of these nodes must have a CS/R board in its I/O slot. One
supplies the cable A clock and the other supplies the cable B clock.
3 Remember any nodes containing K2LCN processors:
• Use the CLOKTRAN display to note a node marked TRNSLTR.
• Use the CLOKSYNC display to note nodes marked DIGSYNCH.
Ignore these nodes containing K2LCNs in steps 4 through 7.
4 Physically locate a master or slave node. Remove the coaxial T-
connector from its CS/R board (leave the LCN cables connected).
Result: If there are no crossed cables, the CLOKCABL display
shows either all CBLA or all CBLB at all active nodes on the
system.
5 If the result of step 4 is not true, you probably have a crossed cable.
Trace the cables and analyze the physical cable system. Example,
if all but one node shows CBLA, the cables may be crossed
between that node (CBLB) and the node that precedes it on the way
from a CS/R board.
6 Uncross cables at the suspected node (remember the WARNING
on the previous page).
Result: If the display shows either all CBLA or all CBLB at all active
nodes, the problem is solved. Reconnect the T-connector you
removed in step 4 and continue to step 7.

10.7 Use the Clock Display to Find Crossed LCN
Cables, Continued
Clock Checking
Procedure, continued Table 10-13 Checking Procedure for Crossed LCN Cables,
continued
Step Action
7 Check the CLOKCABL display again after a few moments. Note: It
might take up to five minutes for a system to show all nodes
operating properly, although the reaction is usually much quicker.
Result: ALTCBLA or ALTCBLB at all nodes is proper operation.
Operator (Online) Personality from the &Z1 and BACKUP NCF
disks. HM should go to HMON OK. Allow it to run for 5 minutes (to
initialize the history files) then shut it back down, wait for QUALIF,
and load the initialization program from the &Z1 and BACKUP NCF
disks. HM should go to HMOFF OK.
ATTENTION .
ATTENTION—Another method to find crossed LCN cables is by
using the $LMENU display, part of the LCN Cable Diagnostics
displays, which provides a count of single cable transmissions
received by each LCN node. If an LCN cable is crossed, the display
shows a smaller number for any node that does not receive the single
cable transmission. All nodes must have R420 (or later) software
loaded and the master LCN node must have a Revision D firmware
K2LCN board. For more information, refer to the LCN Cable
Statistics section of the LCN Guidelines - Implementation,
Troubleshooting, and Service manual.

10.8 Use the Channel Information Display to Monitor
TPS/TPN Channel Activity
Channel Information With R651, Information for each TPS channel in a GUS node or in an
Display description APP node is collected in PSDPs and then shown on the Channel
(R651)
Information Display (CHANINFO) below. The PSDPs contain
information such as the task associated with each channel, and
whether the channel is configured as a high-priority data access
channel. Refer to section 22 for the list of GUS and APP node
PSDPs, and the PSDP definitions.
There are a maximum of 30 configurable channels that are shown on

the display. The channels are allocated during node start-up.
However, there are applications that request a channel when the
application is started. In this case, a channel is allocated to the
application if there is an available channel.

TPS/TPN Channel Activity, Continued
Displaying channel Perform the procedure in Table 10-14 to view channel information
information for a node for a particular GUS or APP node.
Table 10-18 Displaying Channel Information for a Node
Step Action
1 Select the Select for Node target on the CHANINFO display.
Result: An entry port appears.
2 Enter the node number of the GUS or APP node.
3 Press ENTER key.
Result: CHANINFO display for the requested node appears.
4 For more information about the items shown on the CHANINFO display,
press the HELP key to view the help display.
Definitions of Definitions of the terms that can appear in the CHANINFO display
CHANINFO display are contained in Table 10-15. The table also lists the applicable
items
external load module for each software application that is allocated a
TPS/TPN channel.

TPS/TPN Channel Activity, Continued
Table 10-19 CHANINFO Display Definitions

Application External Application Description*
Name Load
Module
MS_SERVER_1 MSCHEM GUS actors and parameter access
MS_SERVER_2 MSCHEM GUS alarm collectors
MS_SERVER_3 MSCHEM GUS trend support
MS_SERVER_4 MSCHEM GUS PMK Support (raise/lower keys)
X$OKBAS MSCHEM GUS operator keyboard support
YH_ALARM_SR GUSALG GUS alarm summary
V
YH_SERVER_1 YGOCX Faceplate data collection
YH_SERVER_2 YGOCX Faceplate data store
$$CDS_SERVER AMCL06 Custom Data Segments
RESERVED N/A Channels are reserved for internal use and
are not available to any application
The applications listed are standard applications. When optional
applications are used, the name of the optional application is displayed
instead of the standard application.

Section 11 – Schematic Files
11.0 Overview
Introduction The Picture Editor is used to build the custom schematics (graphic
displays) that describe the customer's process.
The Picture Editor allows you to interactively create a graphic

representation of portions of the process for the operator to use. The
schematic is written to a source file, using subpictures as desired.
Figure 11-1 illustrates the picture editor-file relationships.
References Refer to Picture Editor Data Entry.

11.1 Picture Editor Tips
Introduction The following tips may be useful for building schematics with the
Picture Editor.
Text versus Graphic Alpha (Text) versus Graphic—Each character is a distinct object and
its text (alpha) has two levels: Foreground and Background. The
priority scheme (where G is graphic, F is foreground text, and B is
background text) is as follows:
• GFB—Graphic object obliterates the portion of the alpha object

under it.
• FBG—Alpha object obliterates the portion of the graphic object

under it at a character-resolution level (that is, a space "blanks" a
character position of the graphic, 8x16 pixels in size).
• FGB—Alpha object obliterates only the portion of the graphic

object under the character lines of the alpha object (that is, graphic
shows between and within open areas of characters). This can also
provide more flexible color priorities.
Line optimization If a line with text on top is desired, draw one line and set priority
FBG so text shows on top.
You can draw lines with up to 50 segments. You can more efficiently
draw complex images with lines and segments by retracing segments
instead of drawing multiple lines.
For example, you could more 11 14 4

efficiently build, store, and
invoke this apparent 5-line
3
image by drawing it as 1 2
12 13
fourteen segments, retracing as
indicated by the dashed 9 6
8 7
curves, than you could by
drawing the image as five
individual, one-segment lines.
10 15 5
2972

11.1 Picture Editor Tips, Continued
Relationships The figure below shows the relationships between Picture Editor
files.
Figure 11-1 Picture Editor File Relationships
SCHEMATIC SCHEMATIC AREA

SOURCE OBJECT DATABASE
.DA FILE
.DS FILE .DO FILE
EDIT COMPILE
SCHEMATICS LOADED
INTO US WITH ON—
US
PROCESS PERSONALITY
with
AT NODE STARTUP
ENGINEERING
USING AREA DATABASE
PERSONALITY
PATHNAME
C OG
US
with
OPERATOR
PERSONALITY
Note:
The US Operator Personality is loaded as shown below. The room remaining for
schematics depends on the size of the various components and the number of
schematics depends on the size of the schematics load.
1. PERSONALITY IMAGE
2. NCF DATA
3. AREA DATABASE
4. STANDARD DISPLAY ABSTRACTS
5. BUTTON CONFIGURATION
6. SCHEMATICS (in order of pathname catalog)
1232

Color Priority Remember that colors of graphic objects have a priority similar to
that for alpha and graphic. The priority (and color "number") for the
highest to lowest (highest covers or overwrites lower) color are the
following:
Table 11-1 Color Priority

WHITE 7 MAGENTA 5 YELLOW 3 RED 1
CYAN 6 BLUE 4 GREEN 2
Also remember that subpictures are added to the schematic using the
current color. This affects the priority of the subpicture.
Text Optimization As the number of text objects increases, the size of the source and
object files and the invocation time increase. The following
characteristics of text objects should be understood to help keep text
objects at a minimum:
• Characters added to a picture in separate ADD TEXT commands
are held as separate text objects.
• Characters added on different lines of the picture are held as
separate text objects.
• Horizontally contiguous characters are added as one text object if
no behavior change occurs.
• A space created by the SPACE BAR is a legitimate character and
takes room in the source and object files (see illustration below).
WATER CHILLER #1 = WATER CHILLER #1

Space
1
One Text Object
16781

Text Optimization,
continued
• A space created by the CURSOR controls is not a legitimate
character. It acts as a delimiter for determining a new object (see
illustration below).
WATER CHILLER #2 = WATER CHILLER #2

Right Cursor
1 2 3
Three Text Objects
16786
NOTE: In this instance, the cursor does not save space because it
causes the creation of another text object in the Picture Editor.
Subpictures Performance of the display is always decreased by using subpictures.

The primary purpose is to simplify schematic building by establishing
a library of frequently used subpictures on the schematic volume or
directory on an HM, if available, or on a special, library disk. A
complex subpicture must be used three times before the overall size
of the source files for schematics is reduced. A simple subpicture
may have to be used 20 times before the overall size of the source is
reduced; however, subpictures always reduce the size of the object
file.

Common The following common abbreviations are used in the Picture Editor:
Abbreviations
Table 11-2 Common Abbreviations
Commands Colors
ADD A BLACK BLK
DELETE DEL or D BLUE BLU
LINE L CYAN CY or C
MODIFY MOD or GREEN GR or G
M MAGENTA MAG or M
MOVE MOV RED R
NEW N WHITE WH or W
READ R YELLOW YEL or Y
SCALE SC
SELECT SEL
SET PATH SP
Intensity
SOLID S
SUBPICTURE SUB FULL FUL or F
TEXT T HALF H
TRANSLATE TR
WRITE W
Changing behavior When changing behavior, first select the behavior to be changed, then
add the new behavior.
Editing keys The primary keys on the engineering keyboard for editing are:
CANCEL—Used to recover from the last command entered. Cancels
and restores the schematic as it existed before last command.
ERASE—Used to erase last coordinates entered. The command is
terminated if all coordinates for the command are erased.
Use separate Using separate disk directories for Files and Subpictures—When
removable media for building a schematic that uses many subpictures from a disk library,
files and subpictures
build the schematic on the library medium, then copy it to the display
medium when complete. This prevents transferring large numbers of
subpicture files to the build disk.
Building Displays Enter text first, then subpictures, lines, and so on. There is less
flexibility with text than with subpictures and lines. Enter lines in text
mode as much as possible. This allows for faster build time and even
lines and spaces.

Entities are bound to Remember that the entities are bound into the schematic as they are
schematic when compiled. The entities referenced in the schematic must be built and
compiled
loaded, and the owning node must be operating on the LCN when the
schematic is compiled.
Deleting entity from Remember that deleting an entity from the owning node does not
node does not delete automatically delete the entity from references in schematics, CL
entity
programs, groups, and so on. If an entity is being removed from the
system, the schematics, CL programs, groups, logs, and so on., must
be rebuilt and recompiled with the entity reference removed.
Use layout forms The schematic layout forms (SW88-551 to -559) help to make the
build process more efficient.
Schematic loading Remember that the schematics are loaded into a US at startup, based
order on the order listed in the pathname catalog, and the number of
schematics loaded depends on the space available after loading the
other data in the US, and the size of the schematics being loaded from
the catalog.
CAUTION .
CAUTION—"Semireserved" Entity Names—Several entity names
are reserved for use by the Picture Editor and the Button
Configurator. In many cases, if you happen to use one of these names
for a data point name (tag name), there will be no conflict. If you do
use one of these names as a tag name, that data point can't be
accessed by the Picture Editor nor the Button Configurator.
Therefore, if you are, or will be, using the Picture Editor or the
Button Configurator, you must refer to Appendix C of the Picture
Editor Reference Manual, to see the list of "semi-reserved" names,
and to make sure that you don't use any of them as a tag name.

Section 12 – Control Language Files [Task 28]
12.0 Overview
Introduction This section provides tips and precautions for the use and handling of
the data and files used in compiling, linking, and loading CL
programs.
Keep the following principles in mind during CL operations.
CAUTION CAUTION—These items are extremely important because, if, for

some reason, you are unable to use data from the HM to restart a
node, you will need the backup &ASY medium to restart that node.
The latest .SE , .SP files must be available to reload USs and CGs,
and if they are not, you may have to go through a major rebuild of
your CL functions. The .GD files must be available to rebuild and
reload data points.
• Remember to copy your .SE and .SP files to any new &ASY
medium provided with a software update.
– The custom names you have built are saved only if you replace
the empty .SE and .SP files on the Honeywell-supplied &ASY
with the .SE and .SP files from your operating &ASY.
– Execute-Command files ASY_BKUP.EC and CLNCFBKUP.EC
are provided on the Honeywell &ASY disk to help maintain
these files (see your latest Customer Release Guide).
Immediately after copying these files, use the Utilities' Protect
command to protect them from being accidentally overwritten or
deleted (of course, you will need to unprotect them the next time
you make such a backup copy).
• Also remember to make a backup copy of your custom GDF (.GD)
files on a disk, so that if those files become unavailable from the
HM you still have GDFs to use in rebuilding or reloading points
with CDSs.
These backup files should also be protected.

12.1 File Handling Tips
File name consistency Remember that a US or CG cannot start up unless the &ASY
directory used by that node contains the version of the name files
that is consistent with the other USs and CGs in operation on the
LCN.
Make backup copy Be sure to make a backup copy when you update your parameter-list
(.PL) files on your CL Parameter List volume or directory (through
the Compiler's -UL option).
Use of two floppies When using two disk drives for CL operations, the first disk drive has
the disk with the source that contains the object, listing, GDFs, and
parameter list and the second disk drive has the &ASY disk.
Entity not Remember that deleting an entity from the owning node does not
automatically deleted automatically delete the entity from CL references.
from CL reference
Deleting points Once a number of CL slots is established on an AM point, that

number can't be reduced except by using the DEB to delete the point,
then rebuilding the point. If the point is deleted and rebuilt, and CL
is to be used with it again, CLSLOTS must be set to at least the
number of blocks to be linked to the point, and the CL structures must
then be relinked to the point.

12.1 File Handling Tips, Continued
File relationships The figure below shows the relationships between CL files.
Figure 12-1 CL File Relationships

Custom CL Source CL Object CL Listing Parameter
GDFs, File (AM or MC) .LS or .LE List
.GD .CL .AO or .MO (Normal or Error) .PL
Source Compile
Definition
US with
Engineering Custom
Custom Personality Segment/
Enumeration Parameter
Names Names
Link Custom
Enm-Sets.SE SEGMENTS.SP
Parameter List
(name1).SE Names PARAMTER.SP
(name2).SE LCN Node Par_List.SE
Note: There is a separate suffix for AM and MC object and listing files for normal
listings or listings with errors.
The custom name files and standard parameter lists exist on the &ASY volume.

Section 13 – Area Database, Content, and Use
13.0 Overview
Introduction This section describes the content of the area database and how the
area for a console is established. It also points out that changes to the
area database actually take place in a US only when the database is
loaded into that US. The relationship of the Engineering functions’
Unit Assignment display to the Operator's functions’ alarm summary
and annunciator displays is defined.

13.1 Database Composition
Description The area database is a collection of standard display definitions,

custom graphic displays (schematics), unit assignments, reports, and
logs that are used by an operator to control his area of plant
responsibility. The area database is loaded into each US and
normally each US in a console is loaded with the same area database.
Each area database contains information on the following:
Units Assignable to Area Annunciator Display
Overview Display for Area Real-Time Journaling
Configuration for Area
Group Displays for Area
Report and Log Definitions for
Area and Unit Trend Displays for Area Area
Module Summary Definition Button Configuration for Area
Custom Displays Pathname Catalog Display Set Definitions for Area
for Area
Hiway/Node Annunciation Policy
The area database contains pathnames for files that define custom
schematics, free-format logs (FFLs) and button configuration (see
Section 2 on file system operation). Any number of areas can refer to
the same files.
Plan ahead Plan ahead! Have the pathnames established, particularly those for
button configuration, schematics, and free format logs, before
building the area database.
Where database Displays for any area can contain data from anywhere (any unit or
entries are used node) in the system. Also any number of areas can access the same
data.
Limits of unit Unit assignment for an area only designates which units and data
assignment points the operator can interact with and which alarms are reported to
that operator.
When changes Changes can be made to an area at any time; however, the changes do
become effective not become effective until a US is reloaded with the new area. Note
that if any US is on a newly changed area, all USs on the same
area must be reloaded to ensure consistent operation.

13.1 Database Composition, Continued
Making changes Once all USs in a console are loaded and running, changes can be
made to the area database and to schematics and button configuration
without reloading the USs with their personalities. Here is a
summary of the major steps involved.
• Use the Data Entity Builder to make changes to the area database.
• Use the Picture Editor and the Button Configurator to make changes
to schematics and button configuration. Compile the resulting
source files and store the object files in &Dan (where an is area
number) or in a user volume in the HM. Be sure that the Pathname
Catalog in the area database points to this volume.
• Use the Console Status display on one US to change the area
database in all USs that are to operate with the new or revised area.
Then, if needed, also change it in the first US. The system
resynchronizes messages, alarms, and system status across the area.

13.2 Assigning Units to an Area
Description Area database configuration includes the assignment of up to 36

process units to an area. The order in which the units are assigned
can be used to determine the position of the unit-annunciator picks
(targets) on the Area Alarm Summary Display, the Unit Alarm
Summary Display, and the Alarm Annunciator Display.
Database assignment In Area Database Configuration, the Unit Assignment Display has 36
picks—one for each possible unit. These picks have a one-for-one
relationship to the unit-annunciator picks on the alarm summary
displays and on the Alarm Annunciator Display, as shown on Figure
13-1. Unit picks that are not selected on the Unit Assignment
Display remove the corresponding unit-annunciator pick from the
alarm displays. Thus, you can leave space between the unit-
annunciator picks and make them easier to use.
Figure 13-1 Unit Assignment Picks and Unit Annunciator Picks

Engineering Personality Process Operator Personality
AREA DATA BASE
Area Alarm Summary, Unit Alarm
Unit Assignment Display Summary, or Alarm Annunciator Display
01 02 17 18
19 20 35 35
If not selected, 01 02 17 18
19 20 35 36
this unit annunciator

50883
won't appear.

13.3 Adding a New Volume or Directory to the Pathname
Catalog
Introduction Honeywell provides several displays that are used to investigate the
system operation and performance of your TotalPlant Solution (TPS)
system equipment.
In a few cases, the information on these displays may not be

meaningful to customer personnel, but this information can be
invaluable to Honeywell personnel who help to analyze difficult
situations. If you contact our Technical Assistance Center (TAC) or
the technical service facility in your region for help in diagnosing
LCN problems, they may ask you for information from one or more
of these displays.
Displays available Table 13-1 is a list of the directory names containing the displays
(files) currently available, their contents, and the top menus used to
access them.
• For instructions for performing LCN Cable Diagnosis, refer to LCN
Guidelines - Implementation, Troubleshooting, and Service.
• For instructions for performing System Performance Checks, refer
to Section 10 in this document.
Table 13-1 Displays Available

Name Contents Top Menu
DIA1 LCN Cable Diagnostic Displays $LNMENU
TLK1 System Performance Displays PERFMENU

Catalog, Continued
Methods of accessing There are two methods by which your system can call up these
a volume or directory displays in a volume or directory:
Table 13-2 Methods of Accessing a Volume or Directory

Method Requirements
1 By calling files in • You must have room in an existing

volumes or directories directory on the HM.
on an HM (already • You can check currently assigned
listed in your pathnames in the SCHEMATIC TITLES
pathname catalog). display in the Operator Personality’s
ORGANIZATIONAL SUMMARY from the
SYSTEM MENU.
2 By calling files in • Use this method if you don’t have enough

volumes or directories room on an HM.
on a disk. • This method adds a pathname to the
pathname catalog directory pointing to
the disk.
Copy directories on a If you choose to install these files on an HM, first use the following
Honeywell disk to procedure. If you choose to use disks (removable media), skip this
your HM
procedure.
Table 13-3 Procedure for Copying Files to an HM

Step Action
1 Place the Honeywell-supplied disk in an appropriate drive. You
must be in Universal Personality.
2 Select COMMAND PROCESSOR from the Engineering Main
Menu.
3 Type in the Utilities Copy command (CP) in a similar manner to
the example shown below, then press [ENTER].
In this example, directory DIA1 is being copied from Drive 1 to
the NET directory on the HM.
CP $F1>DIA1>*.DO NET>DIA1>= -D
Result: The directory is copied from the disk to the HM.

Catalog, Continued
Directory We recommend adding directories TLK1 and DIA1 to a user volume

recommendation and copying the files that correspond to each directory from the disk
to the NET. During upgrades, Command EC files write to these
directories.
Adding a pathname to Follow these steps to add the directory’s pathname to the area’s
either an HM or to a pathname catalog. Use a US in the Universal Personality.
disk
Table 13-4 Adding a Pathname to an HM or to a disk
Step Action
1 Select BUILDER COMMANDS from the Engineering Main Menu.
2 Select SELECT AREA from the Command Display.
3 Select the pick for the area served by the US, then press [ENTER].
Result: The Data Entity Builder now knows the area database you
want to change.
4 Select RECONSTITUTE from the Command Display.
Result: New ports appear.
5 In the ENTITY NAME port, type $0ABSTRT and press [ENTER].
Result: After a few seconds, the reconstituted Parameter Entry
display for your pathname catalog appears.
6 In a spare SCHEMATIC PATHNAME port, type the pathname for
your directory on either the HM or disk and press [ENTER].
Examples: $F1>DIA1 or NET>DIA1
7 Hold the [CTL] key and press the [F12] key to LOAD.
Result: This loads the pathname catalog into the workfile.
8 Press the [COMND] on the keyboard.
Result: The Command Display appears.
9 Select INSTALL AREA and press [ENTER].
Result: This installs the modified area database in directory &Dnn
(where “nn” represents the area number) and gets rid of the area
workfile (.WF).

13.3 Adding a New Volume or Directory to the
Pathname Catalog, Continued
Doing an area change You may want these displays to always appear on a certain Universal
on each US Station or on several Universal Stations in several areas. If you want
more than one station to access these displays, repeat this procedure
for each Universal Station.
Follow these steps to do an area change. Use a US that is running the

Operator functions. If you’re using a disk, the disk containing the
volume or directory in step 6 above must be mounted.
Table 13-5 Making an Area Change

Step Action
1 Select the Universal Station whose database you want to change.
2 Select AREA CHG from the Console Status Display.
3 Select the target for the area whose database you just modified,
then follow the prompters to complete the area change.
4 To check your work, press the [SCHEM] key, type in the display
name, and press [ENTER]. Example: type $LNMENU [ENTER].
Area change Upon completion of an Area change in R520 and later systems, the
schematic US that changed areas will attempt to call up a custom built
schematic. The schematic must be stored by the file name
AREACHnn (nn = area changed to by US).
The schematic’s object file (AREACHnn.DO) must reside in the

same directory as the Area Data Base file AREAnn.DA. If the
schematic is found, prior display information is deleted. This means
that pressing the Prior Display key is ineffective after an area change
(until some other display has been called). If an AREACHnn
schematic is not found, the Console Status is called up.

Section 14 – Data Binding in the TPS System
14.0 Overview
Introduction This section introduces the concept of data binding and describes the
consequences of that binding. The effect of data binding on
configuration and reconfiguration of the system are also discussed.

What is Data Binding? The conversion of external references, such as entity and parameter
names, files, and such, into the internal IDs, actual file use, and data
is called binding. This process occurs at different times for different
types of data in the NCF, NVCF, entities, schematics, CL, area
database, and so on. First let's discuss the configuration-time
binding.
When does it occur? A summary of data-binding times for the TPS system is given in the
following table. A detailed matrix of binding relationships is given
for each of the discussion areas in the tables in this section.
Table 14-1 Summary of Data Binding in the TPS System

Type of Data Binding Time When Effective
NETWORK CONFIGURATION NCF Installed First Node Load
NETWORK VOLUME NCF Installed HM Initialize
CONFIGURATION
UNIT/AREA/CONSOLE NAMES NCF Installed Node Load
AREA UNIT ASSIGNMENT Area Install Area Database Load
INTERENTITY REFERENCE Entity Load Entity Load
GROUPS/LOGS/TRENDS Area Install Area Database Load
SCHEMATICS Compile Area DB Load/Invoke
BUTTON CONFIGURATION Compile Area Database Load
CL DIRECT REFERENCE Compile & Link Link to Entity &
Activate
CL INDIRECT REFERENCE Link Link to Entity &
Activate
AREA PATHNAME LIBRARY Invoked Area Database Load
Effects of changes The figure below provides a quick cross-reference of the effects of
changes in each of the engineering activities. The matrix is set up to
indicate that, if a change is made in the data listed on the left, the data
listed at the top is affected and must be rebuilt or modified.

Effects of changes,
continued
Figure 14-1 Quick Reference Matrix of the Effects of Data Changes
Effect of Changes: Type of Data Change
X = Up to severe impact if certain nodes not reloaded
I = HM must be initialized
U = US(s) must be reloaded
NCF
NYCF
Area Data
Node Data
Schematics
Groups, Trends
CL Programs
Logs, Reports
O = Affects only owning node, or file change
Unit Names X I
Area Names X
Console Names X
System Wide Values X
System or User Volumes X I
Entity Data U O O O O O
Delete Entity References U O O O O O
Groups, Trends, Logs, Reports U O O
Area Pathname Catalog U
Schematics U O
Button Configuration U
CL Programs O
Node data is the owning node's database.

1235
Sequence and Figure 14-2 is a "bubble chart" that indicates the sequence and
relationship of data relationship of data changes. The special "on-line reconfigure"
changes bubbles indicate that changes to that data affect the NCF and require
certain nodes on the LCN to be reset and then reloaded with the new
NCF in the data that is loaded. For the "on-line reconfigure" bubbles,
the nodes that must be reloaded and the order in which they must be
reloaded is indicated by the "on-line" Network Configuration
displays. Refer to Network Form Instructions and Network Data
Entry for more details. Where an “on-line reconfigure” bubble leads
to a regular bubble (that is, “Build/Add/Delete AMs” leads to “Build/
Reconstitute Entities and Store in .EBs or IDFs”), the appropriate
nodes must be reloaded BEFORE performing the second type of data
change (“Build/Reconstitute Entities and Store in .EBs or IDFs”).

Figure 14-2 Configuration Sequences and Data Relationships
On-Line On-Line On-Line On-Line

Build/Edit Build/Edit Build/Add/ Build/Add/
System Wide Console Unit Names Delete HMs
Values Names
Reconfigure Reconfigure Reconfigure
Reconfigure
On-Line On-Line On-Line On-Line On-Line

Build/Add/ Build/Add/ Build/Add/ Build/Edit Build/Edit
Delete HGs Delete AMs Delete CM60s HM Volumes Area Names
Reconfigure Reconfigure Reconfigure Reconfigure Reconfigure
On-Line
Build/
Build/Add/
Reconstitute
Delete USs
Entities and
Store in IDFS Reconfigure
GDF Copy HM
Revisions Content to
by Honeywell Floppies
Load Entities
in Owning
Build/Edit
Delete Node Initialize
Area
Entity Database HM
Compile and
Build/Edit
Link CL/AM, Build/Edit
Free Format Reload
Compile and Schematics
Logs HM
Load CL/MC and Buttons
Reload
USs

14.1 Binding of Unit, Area, and Console Names
Description At configuration time, the unit, area, and console name lists that were
created are used in various engineering activities. The position of a name
in a list is retained for later use, and if you reconfigure the names by
rearranging them, not just adding on the end of the list, the external name
that appears, when used by the system, will be different from what you
intended. The system maintains the list position as originally configured,
which affects external name conversions as well as many file-system
volume and directory names that use the unit and area number (internal
list position, not external name) as part of the volume or directory name.
It isn't just the NCF that refers to these names, data points also do. To
change the position in the lists you have to rebuild all the data points.
An example For example, in this sketch, the first unit configured is AC. The system
knows this unit by its index number 1. "AC" and "Air Conditioner" are
external names. Most of the system knows the unit as "the unit with
index 1," not by the external names. Once you get this configuration
loaded in the NCF.CF file and the nodes begin to use it, the unit IDs and
names can get hopelessly confused if you make subsequent changes
except by adding units at the next-higher indexes.
3697
Entries for Unit Unit-Names configuration includes configuring unit IDs. The unit ID
IDs consists of two characters. If only numbers are used, you can enter a
single digit in either position or you can enter two digits, but you can't
enter a single digit and two digits that amount to the same number. For
example, you can enter "1" and "02," but you can't enter "1" and "01."
You can enter "03" and "4," but you can't enter "03" and "3."

14.1 Binding of Unit, Area, and Console Names, Continued
Plan ahead Rearranging the area, unit, and console name lists has widespread effects
that must be understood. Basically, do it correctly the first time and only
add to the lists thereafter. Table 14-8 in paragraph 14.8 details the area
database binding. Unit names have wide-spread effects because they are
embedded in IDFs and other structures. Area names affect only the USs
in which the affected area database is loaded.

14.2 Binding of NCF Data
Description The details of data binding in the NCF are shown in Table 14-2.
Changes can be made to the working NCF, but they do not become
"known" until the working NCF is installed by the configurator. At
the time the NCF is installed, you must be aware that the new NCF
will not be usable until all nodes that are affected by the change have
been shut down and reloaded with data that includes the new NCF.
The time stamp is changed every time the NCF is installed (F2
operation is performed on the NCF), whether or not any data
changes occurred.
Table 14-2 Detailed Matrix of NCF Data Binding Relationships

BINDING TIME
TYPE OF DATA CONFIG INSTALL LOA AREA NOTES
D LOAD
Unit Names xx xx Position in list at area load time.
Area Names xx xx Position in list at area load time.
Console Names xx xx Position in list at area load time.
US Node Configuration xx Node configuration only, no data.
HG Node Configuration xx Node configuration only, no data.
AM Node Configuration xx Node configuration only, no data.
HM Node Configuration xx Node configuration only, no data.
CG Node Configuration xx Node configuration only, no data.
System Wide Values xx System values for paper size,
jogs, % increments, shift
definition, batch, and so on.
HM Volume xx NVCF is used to setup the HM
Configuration configuration during HM
initialization. If volume
configuration is changed, the
affected HMs must be initialized.

14.3 Binding of HM Local NVCF Data
Description Table 14-3 gives the detailed data-binding relationships for the
NVCF. The NVCF is created (as file Lnp_NVCF.MM) in the HM's
local volume when the HM is initialized (F6 Initialize function in
Volume Configuration). If an HM is reloaded or autoboots for any
reason, and the NVCF in the local volume and the NVCF data in the
NCF on the &ASY directory being used do not match, the HM comes
up in its initialization personality, not in its normal operational
personality. Remember that before initializing the HM, you must first
save critical files (to another HM or to a removable medium) or the
data in the files on the HM being initialized will be lost.
Table 14-3 Detailed Matrix of NVCF Data Binding Relationships

BINDING TIME
TYPE OF DATA CONFIG INSTALL HM INIT NOTES
Volume Selections xx NVCF changed at install time, but
data not effective until HM
initialized.
Volume Sizes/Allocation xx
User Volume Assignment xx
History Assignment xx
Checkpoint Assignment xx
Journal Assignment xx
Archiving Assignment xx
CL/D Storage Assignment xx

14.4 Binding of Entity Data in the Data Entity Builder
Description The binding of entity-build data by the DEB occurs at several

different times, depending upon the type of data and the operation
being performed. The following discussion explains the binding time
for entities, parameters, and values. Table 14-4 gives detailed data-
binding relationships for the data handled by the DEB.
Table 14-4 Detailed Matrix of DEB Data Binding Relationships

BINDING TIME
TYPE OF DATA BUILD LOAD RECON- NOTES
STRUCT
Entity Name xx Name used in IDF and error files as

external form.
Parameter Name xx xx(1) xx(2) 1. For entity references.
2. If GDFs are revised.
ASCII Data xx
Custom State Names xx Not automatically updated when
changes to custom name
parameter occur.
Value Range Checks xx(1) xx(2) xx(3) 1. Not for HG parameters.
2. For entity references.
Default Values xx(1) xx(2) xx(3) 1. Initially at build.
2. PED reset to defaults after F12
load command.

14.4 Binding of Entity Data in the Data Entity Builder,
Continued
When names and Parameter names and enumeration values are bound at the time
values are bound ENTER is pressed. This means parameter names and enumeration
values are held in internal form in the IDF.
Steps that occur As an entity is loaded, two steps occur: first the entity ID is
when an entity is established in the node and then the parameter data is loaded to the
loaded
entity. If the data owner fails the load because of bad data, or any
other condition, the entity has still been established and future load
operations must use the overwrite option.
Owning node must be Entity IDs (tag names) are bound at load time. This means reference
running when entity is entities (entity names referred to by the entity being loaded) must be
built and loaded
built and loaded, and the owning node must be running on the LCN.
Prevent load-time Entities that reference each other (for example, A110 references A200
errors by loading and A200 references A110) must be loaded from the same IDF, using
entities that reference
each other from the
the multiple-load command, to prevent load-time errors. This
same IDF command establishes all entities before loading so that such cross-
references are correctly satisfied. If the entities do reside in different
IDFs, load the entities, check the error files after all IDFs have been
loaded, and then reload the entities that had a reference error.
If the cross-referenced entity does not exist in the same IDF than it
must have been previous loaded thereby prevented load time errors
from occurring.
External names can’t Parameters that allow you to set the external name of a state or value
change after load time (self-defining enumerations), are bound at load time. The DEB
prevents modification of the external names once the entity has been
loaded. The entity must be deleted and rebuilt if you want to change
the external names.

14.5 Binding of Schematic Data
Description Schematics cannot be used until they are compiled into object files
used by the area database. The compilation of the schematic cannot
be done until all entities referred to in the schematic are built and
loaded in the owning nodes, and the owning nodes are running on the
LCN. The compilation requires obtaining the internal IDs of the
entities and their parameters that are held in the owning node.
This means that there is no way to see the final schematic, as it will
appear in the Operator's Personality, until called from an Operator's
Personality. Table 14-5 provides detailed data-binding relationships
for schematic variable data, either values or conditions used for
behavior control.
Remember that deleted entities require that schematics that used them
be rebuilt, recompiled, and replaced in the volume or directory
pointed to by the Pathname Catalog.
Table 14-5 Detailed Matrix of NCF Schematic Data Binding

Relationships
BINDING TIME
TYPE OF DATA BUILD/ COMPILE AREA INVOKE NOTES
EDIT LOAD
Subpictures xx
Entity Name xx
Parameter Name xx
ASCII Data xx
Custom State names xx
Schematic Object File xx(1) xx(2) 1. If configured to reside in
memory database.
2. If on removable medium
or HM file.

14.6 Binding of Data in CL Programs
Description At CL program COMPILE time, direct references (use of

EXTERNAL statement on a block or point name in block header)
require the entities to be built and loaded, and the owning node to be
running on the network. Indirect references are resolved at link time.
As a CL program is linked, direct- and indirect-entity references

require the entities to be built and loaded, and the owning node to be
running on the network.
Table 14-6 Detailed Matrix of NCF CL Data Binding Relationships

BINDING TIME
TYPE OF DATA EDIT COMPILE LINK NOTES
Entity Name (Direct) xx Rechecked at Link time.
Entity Name (Indirect) xx
Parameter Name xx Rechecked at Link time.
Custom State Names xx
Custom GDFs xx Rechecked at Link time.
ASCII Data xx
Default Data xx

14.7 Binding of Entities and Schematics into the Area
Database
Description In order for the area to be configured, the unit and area names must
be defined. Additionally, all references to process or system-entity
names and parameters require the owning node to be loaded with the
data and operating on the LCN. This means that configuration of
groups, trends, and logs cannot be completed until the entities used in
them are built and loaded. Schematics are referred to by only
pathname at configuration time, so schematic object files do not need
to exist during configuration.
The second binding step occurs when the US is loaded (with the
appropriate NCF) and the assigned area database is loaded. At that
time, the pathnames for schematics are used to access the compiled
object files and the files must exist. Note that the schematic object
files can exist only if the entities referred to are built and loaded
before the compile step in the Picture Editor.
Table 14-7 Detailed Matrix of Area Data Binding Relationships

BINDING TIME
TYPE OF DATA EDIT AREA AREA INVOKE NOTES
INSTALL LOAD
Entity Name (Direct) xx
Parameter Name Groups xx
Overviews xx
Process Module Group xx
Trends xx
Logs xx
Journals and Reports xx
Alarm Annunciation Policy xx
Unit/Area/Console Names xx
Custom State Names xx
Schematic Object xx xx(1) 1. When invoked, if not in memory.
Help/Associated/ xx Area database

Related Display

Section 15 – Actors and Process Control
15.0 Overview
Introduction This section advises that actors are not to be used for actions that are
involved in process control.
15.1 Use of Actors
What actors do In Universal Stations, actors are used to assign actions to targets
(picks) on schematic (custom/graphic) display and to the configurable
buttons on the Operator's Keyboard. An actor is executed one time,
each time its target is selected, or each time its configurable button is
pressed.
Actors can call up a specific display, create text-input ports (TIPS)

for data entry by an operator, read the data entered, and store the data
in a display or in the system database. Actors are very useful for
defining relationships between schematic displays and for making it
easy for operators to use and move between displays.
Actors can be very useful to operators for setting up conditions in the

control system; for example, for setting up initial control conditions
for a sequential operation, starting a sequence or initiating an
abnormal-condition handler. While an actor can initiate control
actions, it does not have the feedback mechanisms nor continuous
monitoring capability that is required for process control; therefore,
actors are not suitable for implementation of control strategies.
Control strategies must reside in AMs, CMs, NIMs, CGs, PMs, LMs,
and process-connected boxes.

Section 16 – AM Configuration Guidelines
16.0 Reserved
In earlier versions of this manual, this section contained AM Configuration Guidelines.

Refer to Application Module Implementation Guidelines for that information. This section has
been retained to direct users familiar with an earlier version of this manual to the new location
of the information and to preserve the validity of references to other sections of this manual.

Section 17 – Data To Be Used During Configuration
17.0 Overview
Introduction This section relates the types of configuration data to the publications
that define each type of data and to the configuration forms used to
record each type of data.

17.1 Publications Defining Configuration Data
References For information about the overall configuration-data collection

process, refer to the Configuration Data Collection Guide. Also,
refer to the System Startup Guide for the System Startup Task
Record.
Before configuring The following forms should be completed and referenced data should
the system be available before starting to configure the system. Doing this paper
work first will help to prepare you for efficient configuration of your
system.
This list does not include the various hiway-related publications.
Refer to the Application binder in the Basic System bookset.
Data to be Configured Publication Form Used

Unit Configuration Network Form Instructions Network Forms
Area Names Configuration Network Form Instructions Network Forms
Console Configuration Network Form Instructions Network Forms
LCN Nodes Network Form Instructions Network Forms
System Wide Values Network Form Instructions Network Forms
Volume Configuration Network Form Instructions Network Forms
Hiway Configuration Network Form Instructions Network Forms
Box/Slot Configuration HG Parameter Reference Dictionary HG Data Point Forms
Hiway Gateway Points HG Parameter Reference Dictionary HG Data Point Forms
Process Manager Points PM Parameter Reference Dictionary PM Configuration Forms
Advanced Process Manager Points APM Parameter Reference APM Configuration
Dictionary Forms
Logic Manager Points LM Parameter Reference Dictionary Logic Manager Forms
PLC Gateway Points PLCG Parameter Reference PLCG Forms
Dictionary
Application Module Points AM Parameter Reference Dictionary AM Data Point Forms
Computing Module Points CM Parameter Reference Dictionary CM Data Point Forms
Picture Editor Picture Editor Form Instructions Picture Editor Forms
Button Configuration Button Configuration Form Button Configuration
Instructions Forms
Area Database Configuration Area Form Instructions Area Forms
HM History Groups Configuration HM History Group Form Instructions HM History Group Forms

Section 18 – Avoiding Mistakes and Errors
18.0 Overview
Introduction Notes in this section may help you avoid mistakes and errors.
18.1 Guidelines and Warnings
Introduction This section contains a collection of the significant guidelines,

precautions, and warnings that appear in this and other publications.
If you review this section from time to time, and implement its
content, you should experience a minimal amount of rework and error
correction.
Make a backup set Start by making a complete backup set of all removable media (disks)
supplied by Honeywell.
Write protect Remember to write protect the removable media used to store your
configuration.

18.1 Guidelines and Warnings, Continued
Follow the DEB- Remember to follow the DEB-loading and system-checkpointing

loading and rules to keep the database consistent:
checkpointing rules
Table 18-1 Database Loading and Checkpointing Rules
Rules Description
1 The order in which entities are loaded to a node is significant.
For all references to properly work, always load from the most
current checkpoint medium, or if using the DEB, always use the
same files in the same order to ensure that the sequence of point
loading is consistent and the internal entity IDs remain the same.
For more information, refer to the Data Entity Builder Manual.
2 Always make changes to the existing database.
Do not delete an entity and reload it to make a simple change.
Be sure to reload the last, correct, checkpoint data to reloaded
nodes before doing any operation that loads or links to entities in
the nodes.
3 The "directory" of external entity names is distributed among the
owning nodes; there is no central directory.
Thus, all nodes must be running in the normal on-process
personality to ensure that points are not duplicated.
4 Remember that deleting a point and reloading it changes its
internal ID and that all references have been broken by the delete.
Follow a sequence Follow the sequence of the tasks in the system-loading and startup
guide. This provides for the most efficient startup scenario.
Make a backup of the Always make a backup copy on a removable medium of the old NCF
old NCF before (directory &ASY) before installing a new one. This allows recovery
making a new one
of the system without restarting nodes, if the changed NCF causes
problems in loading nodes or the HM autoboots because of a power
interruption.
If you do not have a removable copy of the NCF in use on the LCN
and the HM NCF has been changed from what other operating nodes
are using, then certain nodes must be reset and loaded from the HM,
including the new copy of NCF in the data that is loaded. See the on-
line Network Configuration displays and also refer to Network Data
Entry.

Precautions when Moving the system volume from one HM to another requires special
moving the system considerations. This is because the system volume contains the
volume (&ASY)
network configuration file NCF.CF and uses the network pathform
for access.
Before making configuration changes, load both HMs with the HM
INIT personality and perform the required changes in the order given
below:
Table 18-2 Procedure Used When Moving the System Volume

(&ASY)
Step Action
1 Install the new HM configuration.
2 Reload both HMs with the HM INIT personality.
3 Initialize the HM that previously held the system volume.
4 Initialize the HM that will contain the system volume.
5 Copy the HM’s personality image files to both HM’s local
volumes.
6 Reboot the HM that previously held the system volume.
7 Reboot the HM that now contains the system volume.
Limitations of the Remember, "NET" cannot be used to access files in an HM loaded

“NET” command with its initialization personality.
The physical-node pathname (PN:n>volm>file.sx) is the only
type of pathname you are allowed to use for an HM during
initialization. This includes the initial loading of the system files to
the HM (&ASY, &HMO, and optionally, &HMI).
Check for errors Always check the Data Entity Builder error files.
The errors listed may indicate that references to other entities were
not satisfied because the entities had not been loaded.
Use of multiple-load If two entities reference each other, the entities must be
command simultaneously loaded by using the multiple-load command.
Write the two entities to the same IDF and multiple load them. The
multiple-load command is a 2-pass operation that allows establishing
the entities, then loading the data, so that references are satisfied.

Entities must exist Remember that groups, trends, and logs cannot be built unless the
entities used are built and loaded.
The owning node for entities must be running on the LCN to allow
access and external/internal conversions to occur. Group Edit in the
Operator function allows some flexibility in this area.
You can’t overwrite Remember that you cannot change an entity's location, unit, or build
an entity’s location to type by loading with overwrite.
change it
You must delete the entity and load it again to change these
characteristics.
Deleting an entity Remember that deleting an entity does not delete references to that
does not delete entity in schematics, logs, groups, and so on.
references to it
Each reference to the entity must be deleted in the specific function
that used it.
Internal IDs are Remember that if an entity is deleted, changed, or loaded again with
different the same name, it is a different entity and references built before the
delete will not connect to the entity when it is loaded again.
The internal ID is unique for each entity loaded, even if it has a name
that previously appeared in the node, only so long as the database is
kept consistent by following the DEB-loading and the checkpointing-
operation rules.
CL compiling caution Always make a copy of the HM files *.SE and *.SP to a current disk
copy of &ASY when CL has compiled new custom parameter names.
The new parameter names are propagated across the LCN and the
data-access function prevents startup of any node when the &ASY
directory (removable medium or HM) does not contain the same list
of parameter names as is currently in use by the operating nodes.
Also, always make a backup copy of any updates you make to the
custom parameter-list (.PL) files on your Custom Parameter List
volume or directory.
After you make these copies, use the Utilities' Protect command to
prevent overwriting or deletion of these files.

Know when binding Remember when binding occurs for the type of data you are working
occurs with. Refer to Figure 14-1.
Names must be the Remember that the NCF, NVCF for the HM, and parameter name
same files (.SE, .SP) for data access must be the same as any operating
nodes on the LCN at the time a node is loaded and started up.
The loaded node will not be allowed to start up on the LCN if there is
a mismatch of critical data in these files.
Copy .SE and .SP files Remember to copy your .SE and .SP files to any new &ASY disk
volume provided in a software update.
The custom names you have built are saved only if you replace the
empty .SE and .SP files provided on the standard &ASY medium
with the .SE and .SP files from your operating &ASY.
After you make these copies, use the Utilities' Protect command to
prevent overwriting or deletion of these files.
Backup your custom Remember to make a backup copy of your custom GDF (.GD) files
GDF files on a disk.
Use the Utilities' Protect command to prevent overwriting or deletion

of these files.
Know how adding and Remember that adding or deleting points can affect group and
deleting points affect overview display definitions, schematics, and reports.
files
Group and overview display definitions must be reloaded if points
they contain are added or deleted.
Report definitions must be reloaded if points they refer to are added

or deleted.
Schematics must be recompiled if points they contain are added or

deleted.

Section 19 – Glossary of TPS Configuration Terms
19.0 Overview
Introduction This is a glossary that summarizes the terms related to the

configuration process. You may also wish to refer to System
Overview, which contains a more extensive glossary.
19.1 Configuration Terms
Alias Alternative name for a given disk or HM volume in Release 200 and
earlier releases. It has no meaning in R210 and later releases.
Alias point An HG data point that uses the same box and slot on a Data Hiway as
another point in the same HG, but has a different tag name—an alias.
Alias points are created by building and loading only the HG-resident
parameters for a point that already exists in the box and slot, and then
loading the point in the HG. This new point in the HG then has access
to the data in the designated box and slot. Alias points usually have
virtually identical data, but different unit assignments. This allows
alarms for such points to be generated for more than one unit.
Autoboot A History Module that has been through System Startup Tasks 14,
15, and 16 can reload and restart itself, if its power has been
interrupted or if its power was turned off and then back on. This is
referred to as "an autoboot" or "autobooting."
Bind The conversion of external entity and parameter names to the internal
entity ID and parameter ID, as used for LCN communications. The
external/internal conversion can be performed by only the owning
node of the external entity. This means the entity to be bound must
be built and loaded, and the owning node must be running on the
LCN, at the binding time.

19.1 Configuration Terms, Continued
Bootload The loading of a program or data into a node or device directly

without intervention through some other node or device. This term
arises out of the notion that such an operation is like “pulling itself up
by its bootstraps.” In the TotalPlant Solution (TPS) system, loading
a Universal Station by itself and not through the Console Status
display at another US is referred to as “bootloading” the US. Also, a
History Module can bootload itself (also see “Autoboot”).
Build Entities are built by interacting with the Data Entity Builder's
Parameter Entry Displays (PEDs) or by exception building. The
entities can then be stored into an IDF for future loading to the
owning node. Building does not include loading in the owning node.
Checkpoint Storing of the process database from a module or gateway in files

from which the data can be reloaded into the module or gateway,
should it be necessary to restart it. Where a gateway serves process
devices, such as the boxes on a Data Hiway, their process data can be
included in the checkpoint files, and reloaded. The term "checkpoint"
refers to a "snapshot" of the data is acquired at some point in time.
Compile Custom (schematic or graphic) displays, CL programs, free format

logs, and button configurations are compiled from source data (either
stored, edited images, or textual source programs) into final object
"code" that is actually used at runtime, by the appropriate function.
In general, direct references to entities in the system must be bound at
compile time. This means the entity must be built and loaded, and
the owning node must be running on the LCN, at compile time.
Crash The unexpected failure of a node that is caused by a situation the

software or firmware in that node cannot manage or under which it
cannot continue to operate. For example, as a node is loaded, the
software checks for proper hardware revision levels, and if they are
not proper, loading stops and the node crashes.
Directory A named subdivision of a volume to which one or more files is

assigned. Each disk is a volume. HMs can have several volumes.
Each volume can have up to 63 directories. System-reserved directory
names begin with "&" or "!".

Directory A named subdivision of a volume to which one or more files is

assigned. Each disk is a volume. HMs can have several volumes.
Each volume can have up to 63 directories. System-reserved directory
names begin with "&" or "!".
Entity Entities are named collections of data that can be accessed across the
LCN. There are two major entity categories: process data points and
reserved entities. Reserved entities are treated differently than process
data points (see the Data Entity Builder Manual).
Error A misoperation from which the hardware or software can recover.

For example, memory errors that are corrected by the memory’s
EDAC feature, and errors in data transfers that are detected and
recovered by repeating the transfer.
Establish Entity IDs are established on the LCN at load time. This means the
entity can be referenced by its external name, provided the owning
node is running on the LCN. The owning node performs the external
to internal name conversion to allow access to data within the entity.
An entity can be established but remain "not loaded" because of
errors or failures that prevent access to parameter data within the
entity.
Exception Build Use of a prebuilt entity as a template and building a number of new
entities, based on a text file of source data. Exception-built entities
are always stored in an IDF. The template entity must reside in an
IDF, either the IDF being built if the &M control line is used or
another IDF if the &X control line is used, in the exception-build
source code.
Format Typical use of this term is for the operation of formatting disks or
HMs. Formatting consists of writing track headers, establishing the
volume name for a disk, and building the bad-sector table for the HM.
Formatting destroys any previous data on the medium.
HM Load The operation of loading the system software to the HM(s).

IDF (Intermediate Data The IDF is a file used by the Data Entity Builder to store the build
File) information for an entity. It is not the complete entity description,
but contains the data necessary to support loading to the destination
node.
Initialize For an HM, initialize is establishing the volumes that exist on the
HM. The volume directories are cleared, so all data previously
available can no longer be accessed and must be restored. This term
is sometimes used in place of "format" when referring to disks. The
utilities support initializing the removable media (clearing the
directory and renaming the volume) without "formatting" (writing
track headers).
Invoke This is the action of calling up a specific function or display on the

US. Typically used for describing the action of calling up a
schematic display.
Kilobyte (KB) Kilobyte—1024 bytes
LCN (Local Control The link through which all the nodes communicate. The term is often
Network) used to generically name the link with the nodes attached—the
system.
LDID (Logical Device This is a "name" by which disk and printer devices can be accessed
Identifier) on a console through the utilities. The LDID is of the form $Fn for
disks, and $Pn for the printer (n is 1-20).
Link The operation of binding final components into the system.

Typically, this is used to describe the CL-link operation where a CL-
object program is linked to the entity(s) that uses it. Any indirect
entity reference, which was not bound at compile time, must be
bound at link time. This means the entity must be built and loaded,
and the owning node must be running on the LCN, at compile time.

Load “Load” is used for several operations in the system:

• Loading a specific node's memory with a personality image from a
removable medium or HM.
• Loading an entity, using the DEB, to its destination node (or file in
the case of the area database).
• Loading an area database from its file to memory when a US is
loaded and started up.
• Loading a checkpointed database from the checkpoint file to the
memory in an HG or AM.
Megabyte (MB) 1024 KB (kilobytes)
Megaword (Mw) 1 Mw = 2 MB
NCF (Network The NCF contains the description of the system, so that each node is
Configuration File) aware of the system structure.
Node The individual components connected to the LCN are called nodes,
and sometimes modules. Generally, nodes are logical and modules
are physical. The node types are
• US —Universal Station
• HG —Hiway Gateway
• AM —Application Module
• HM —History Module
• CM —Computing Module (DPS6 through the CG)
• CG —Computer Gateway
np Notation used to represent an HM node pair number. In LCN Node

Configuration, a node pair number is assigned to each single HM, and
to each primary/secondary HM node pair.

On-Line Changes to Network Configuration that are made with the

Reconfiguration configurator in the on-line mode. Such changes require that specified
nodes be shutdown and reloaded with data that includes the revised
network configuration file (NCF).
Owning Node The node on the LCN in which an entity resides. This node contains
the external/internal entity ID-conversion capability, knows whether
a parameter exists on the entity and, ultimately, contains the data for
the entity.
PED (Parameter Entry The information on an entity being built by the Data Entity Builder
Display) that is displayed on the US screen. The information consists of
multiple displays, called the PED set, and the status of the data in
each display is available in the PED Set Status Display.
Personality A specific software image in a node on the LCN. Nodes typically

have multiple personalities but they don't coexist. For example, the
US has the Operator's Personality and the Universal Personality.
Each requires complete memory load to put the personality in
operation. Other nodes have an on-line personality and an off-line
personality.
Reconfigure See On-Line Reconfiguration
Removable Media disks. Such a medium can be removed from its drive and replaced by
another medium of the same type.
Reconstitute The "back-building" operation—reconstituting an entity from its

owning node or area database file to the Data Entity Builder for
display. In a batch or multiple reconstitute operation, the data is
placed directly into an IDF.
Volume The name by which a disk or a section of an HM is known. Refer to

"directory." System-reserved volume names begin with "!" or "&".

Section 20 – Node Loading and Node Dumps
20.0 Overview
Description The first part of this section provides guidelines for recovering from
the failure of a node to properly load with software and data.
Next, this section provides guidelines and instructions for

implementation of fast-load Emulated disk(s) for quick recovery from
interrupted operation, such as a power failure.
Finally, this section provides guidelines for dumping the memory

contents of failed node for analysis.

20.1 Node Loading Failures
Why a node fails or As each node on the LCN (including USs) is loaded with software
crashes and data, the system checks for proper hardware and software
revision levels and for adequate memory in the node. If an incorrect
revision level is detected or the node is found to have inadequate
memory, the node may fail (“crash”).
Do not try to concurrently load both HGs in an HG pair, nor both

NIMs in a NIM pair—one of the gateways may fail. First, finish the
loading of one of the gateways as the primary, then load the other
node as the secondary.
Information about the Information about such “crashes” is available through the Real-Time
crash Journal, so one of the first nodes to be loaded should be a US (with a
physical printer) with the Operator Personality. Once that US is
loaded, the Real-Time Journal should be enabled so that any errors
detected will be reported in the journal (on the printer).
Revision or memory If a node “crashes” because of a revision or a memory error, the node
error crash goes to the FAIL state and “-190” may appear in the LED display
on the module. The journal message (all on one line) is in this form:
hh:mm:ss nnnn $$NODE ADMIN CRASH DET- NODE ADMIN
42
OFF- NODE ADMIN x y 60001
Where:
• hh:mm:ss is the hour, minute, and second when the “crash”
occurred.
• nnnn is the module type and number, and interpret the meaning of
X and Y by using Table 20-1.

20.1 Node Loading Failures, Continued
Revision or memory
error crash, continued
Table 20-1 Interpreting Cause of Node “Crash”
IF … THEN …
X=1 A board revision-level mismatch was detected and
Y is the board's slot number.
X=2 A required board type is missing and Y contains an
indication of the type of board.
X=3 Inadequate memory was detected and Y = the
amount of missing memory in KB.
X = 4 and Y = 0 A software-revision mismatch was detected.
X=5 A board firmware-revision-level mismatch was
detected and Y = the board's slot number.
If any of these errors are reported, a hardware technician should check
all boards in the node to determine if any are missing, if any are the
wrong type, or if any have incorrect option selections (by jumper
pins). Also, ensure there are no more than TWO empty slots between
boards. Having more than TWO empty slots between boards
disallows the Back Plane Integrity Check.
Other errors Other types of loading errors can also be reported in the journal.
Most of these are described elsewhere in this manual.
Clearing a To determine the cause of the error message and to clear a LOAD
LOAD FAIL message FAIL message, follow one of the procedures below:
Table 20-2 Clearing a LOAD FAIL (from the System Status

Display)
Step Action
1 Select the “RETURN” target.
2 All error messages will disappear.

20.1 Node Loading Failures, Continued
The following table applies to AM, PM, CG, etc. displays:
Table 20-3 Clearing a LOAD FAIL Message (from the Console,

Process Network Node; or Device Node Status Displays
Step Action
1 Select the failed node number.
2 AUTOLOAD NET, AUTOLOAD LOCAL, MANUAL LOAD, and
DUMP NODE targets appear.
3 Select one of the LOAD targets.
4 Red/Yellow message with cause of failure appears.
5 Select error message on top of the screen (see Note).
Result: The error message is cleared and you can try to reload the
node.
NOTE If after reading the “reason for failure” message, a different screen is
invoked, the error on top of the screen will disappear.
If a different screen is on the US, other than where the LOAD FAIL
was caused, then the error message on top of the screen MUST be
selected to take you to the displays listed above to clear the message.

20.2 Fast-Load Feature
Description In the event of a system disruption, such as a power failure, once the
required nodes have power reapplied and are ready to be reloaded,
then a “path to the system” can be quickly restored through the use of
a user-prepared fast-load disk, or from an HM that is running and has
the right volumes and data.
A thorough understanding of the design of your system is invaluable.
If, for instance, the power failure affected all HMs, recovery can be
accomplished by using the latest fast-load disk is probably the
quickest method. In the case where some of the HMs cannot be
accessed, will not “autoboot” (see below), you should use the fast-
load disk using one of the HMs instead of ALL data coming from
disk.
Each fast-load disk (or HM) contains the software and data required
to reload one Universal Station; and to reload one NIM or one HG.
Prior to R650, APP nodes could not be loaded without a system HM.
With R650, the APP node can be loaded with the APP or AM
personality using a fast-load disk mounted in a US/GUS. The fast-
load disk can be used if the system HM fails or if the APP node’s
communication with the HM is lost.
GUS nodes can be loaded manually from a fast-load disk mounted on
a different US/GUS (not the local node) without requiring the system
HM to be on-line.
You can prepare more than one fast-load disk to restore other paths to
the system.
References See the Process Operations Manual for instructions on the use of a
fast-load disk to reload a US and a NIM or HG to reestablish a path to
the system, in the Fast Load Procedure section. For additional
reloading options available on a System Status display, see the LCN
Node Reloading and Status Information section.
See the TPS System Operations Guide for instructions on loading an
APP node without using the HM.

20.2 Fast-Load Feature, Continued
Necessity of updating Effective use of the fast-load procedure requires careful use of the
checkpoint files guidelines presented later in this section, especially the regular
updating of checkpoint files and other data on your fast-load disks.
AUTOLOAD targets To facilitate the quick restoration of paths to the system of a single
node, AUTOLOAD LOCAL and AUTOLOAD NET targets (picks) appear
on the Console Status display, the Gateways Status display, and the
node status displays for other nodes.
These targets simplify the single node loading process by

automatically searching disk drives on the US (AUTOLOAD LOCAL)
or HMs (AUTOLOAD NET) for the directories that contain the files
and data to be loaded.
NOTE To speed the restoration of paths to the system for multiple nodes,
loading requests should be initiated from the System Status display.
See the LCN Node Reloading and Status Information section of the
Process Operations Manual.
History Module When power is first applied to all nodes on an LCN, the HMs load
“Autoboot” feature themselves, or “autoboot.”
If the necessary files are available on HMs, you can load the first
Universal Station quickly using the procedure shown in Table 20-3 in
“Fast-Load Scenario” which follows.
These files are stored on the HMs in the system volume (&0np),
personality images (&1np), area database (&3np), and the HG or
NIM checkpoint (&7np, &8np) volumes. If all these files are not
provided, the startup procedure will go as far as it can, then it will ask
for you to supply the missing files.

20.2.1 Fast-Load Scenario
Introduction When power returns, all modules self-test and the HMs autoboot. You
must start an US quickly so you can load the remainder of the system.
Loading a US from This procedure allows a Universal Station to be loaded from a running
itself HM that has the correct volumes (&1np and &3np) required for fast-
load.
Table 20-4 Loading a US from Itself
Step Action
1 Push back the upper part of the black frame enclosing the
operator’s keyboard and push the [RESET] button.
Result: The screen will clear.
2 After the “>” prompt is displayed on the screen, press [LOAD].
Result: N,1,2,3,4,X? is displayed.
3 Type N and press [ENTER].
Result: OPR,UNP? is displayed.
4 Choose Operator or Universal personality by typing O or U.
Then press [ENTER].
Result: Loading begins. Wait for the System Status Display to
appear. At this time, not everything has been loaded into the US,
however, the standard abstracts have been loaded.
Continue on without waiting for the button configuration, external
load modules, and memory-resident schematics to be loaded.
NOTE: If loading external load modules, and using backplane
packages (XYPLOT, OPBASE, and OPEQLT, for example) you
must have sufficient memory to load them. Reference the
optional package documentation for memory requirements.
5 Press [CONS STATS] to choose the Console Status display.
6 From the Console Status display, select the node to be loaded
and then select the LOAD/DUMP target.
7 Press the AUTOLOAD NET target if you want to fast load from
your History Module. Press ENTER and the load will start from
the network.
Press the AUTOLOAD LOCAL target if you want to fast load

from a disk. Press ENTER and the load will start using the
LOCAL removable media.
Node loading If all the files needed are on an HM or disk, the node loading procedure is
automatic from this point. If all the files are not available, the procedure
will go as far as it can, then it will ask for you to supply the missing files.
The stages of the fast-load scenario that follow will aid you in analyzing
the process and determining what files might be needed.

20.2.1 Fast-Load Scenario, Continued
Stages of the Disk If you don’t have all the files on an HM from which you can load the
Fast-Load scenario rest of the nodes, or if the HM did not autoboot, you may want to
load from a disk. The following steps can take place at more than one
console, using more than one fast-load disk:
Table 20-5 Stages of the Disk Fast-Load Scenario

Stage Description
1 The fast-load disk is used to “bootload” one US in a console.
The node status display abstracts are among the first to be brought
into the US memory, and when they are available for a user to
initiate loading of the NIM or HG. The US status goes from LOAD
(or READY) to OK.
2 The status remains OK unless one or more files could not be
loaded into the US, at which time the status normally becomes OK.
3 As soon as the System Status display appears on the US, the user
selects the NIM or HG and uses the AUTO LOCAL LOAD target to
start the loading of that NIM or HG.
4 When the UCN Status display or Hiway Status display is available,
the user restores the database(s) to the Devices on the UCN and
Data Hiway boxes.
5 When it is convenient, the HM or HMs that contain system files are
restarted and all other nodes on the LCN are reloaded, using the
HM(s) as the source of the files and data. To restore full operation
of USs that were started from fast-load disks, but may be using
out-of-date custom names or schematics, they must be shutdown
and reloaded from the network (HMs). ALL nodes displaying
WARNING MUST ALL be shutdown at the same time before
loading ANY AM, U/GUS/EST, CG, and or NG.

20.2.2 Fast-Load Implementation Considerations and
Guidelines
Introduction This section presents considerations and guidelines you should be

aware of while conducting Fast-Load operations.
Access to Display When a US is reloaded or begins an area change, the following

Abstracts critical, standard, display abstracts and the button-configuration file,
are brought into the US memory first, to hasten access to them:
Table 20-6 Display Abstracts Loaded First

Title Abstract Name
Top 2 Lines TOP2LINE
Console Status CON_ASGN
System Status SYS_STAT
Gateway Status NODE_STS
Mount Display FLOPPYH
Group Display GROUP
Module Group Display MOD_GRP
Area database After the standard displays are in the US memory, the schematic
displays named by the user in the Area Database Pathname Catalog to
be memory resident are brought into US/GUS/ES-T memory.
Access is not available to US memory displays until the stations

memory displays are available.
Access is not available to displays that do not reside in the US

memory, until after all of the memory-resident displays are in the US
memory.
An Area Change is not allowed until the US is completely loaded (all

memory-resident displays are in the US memory).

Guidelines, Continued
All schematics should If, during a US load or Area Change, a memory-resident schematic
be available display cannot be found, a prompter appears that asks that the volume
that contains the schematic be mounted; therefore, it is important to
be sure that the fast-load disk contains all the schematics that are
configured in the Pathname Catalog in the Area Database are memory
resident, so that such prompts will not slow the loading process. In
the operator's personality, you can examine the Schematic Titles
display to determine which schematics were copied into memory (the
names of these schematics are yellow). If they are CYAN, they are
NOT memory resident.
The information above means that you should consider the paths you
need to quickly reestablish access, and carefully plan which displays
you name in the Pathname Catalog to be memory resident and in what
order. You should also consider the order in which you name volumes
and directories that contain displays, because the US searches those
volumes and directories in the order you name them. For more
information, refer to the Area Form Instructions.

Guidelines, Continued
Loading “Offnet” A node that was failed but now has power applied and has not yet
nodes and the NCF been seen by the US that is being used to reestablish a path to the
issues
system, can NOT be loaded from that US until THIS node sees
THAT node. As a consequence of this feature, it is impossible to load
a node that is running on a portion of the LCN that is separated (a
different logical network) from the LCN portion the US is on. Thus,
it is impossible for the US and the node that is loaded to be running
on a different version of the Network Configuration File (NCF). You
can determine if this has happened through the NCF Status display.
To recover from this situation, the separated LCN portions must be
reconnected. Refer to LCN Guidelines - Implementation,
Troubleshooting, and Service for assistance.
Directory &ASY, A successful load of any node requires that the NCF, standard
impact of missing enumerations (.SE) and standard parameter files (.SP) in directory
files or files with
incorrect revisions
&ASY be found and be at the correct revision level. To avoid
difficulty in the quick restoration of paths to the system or to
determine the reason for a problem in restoring one or more paths to
the system, consider the following (if you are not familiar with the
terms “bootload” or “autoboot,” refer to Section 19):
• Bootloading a US from removable media—The disk is searched
to find the &ASY directory. If it is not found, or if the NCF it
contains is at an incompatible revision level, prompter NCF, 1, 2, 3,
4, X? appears, requesting that you mount a disk with a valid NCF
and indicate its location.
• Autobooting an HM—The disc drive(s) on the HM being loaded
and all operating HMs are searched to find the &ASY directory. If
not found, retries continue for up to 30 minutes. If &ASY is not
found, or if one of the files is at an incompatible revision level, the
HM fails (crashes).
• Loading a node from a Universal Station—The network (all
operating HMs) is searched to find the &ASY directory. If it is not
found, and the program and the data sources were both on the
(HMs), the node being loaded fails (crashes). If the &ASY is found
but it contains files at an incompatible revision level, the node being
loaded crashes. If the &ASY is not found on any HM, and the
sources of both the program and data were on removable media, the
load proceeds. If one of the removable media is found to contain the
&ASY, or if in response to a prompter, you mount a disk that
contains the &ASY.

20.2.3 Content and Maintenance of Fast-Load Disks
Contents of the A Honeywell-provided .EC file is used to prepare a fast-load disk, as

Fast-Load disk for all described in 20.2.4. The disk is given a user-specified volume name and
nodes other than
APP/ESVT nodes
contains the following software and data:
• Volume &OPR—contains the US Operator function (.PI) files and boot
loader if US personality is loaded.
• Directory &ASY—contains system files; including the Network
Configuration File, NCF.CF, *.SE, *.SP, ERRBK.xx, VPCONF??.XX,
SCHEDxx.BR, KEYLEVEL.KL, *.LD.
• Directory &LDR—contains boot loader, quality-logic test, and off-line
test files.
• Directory &DSY—contains standard display-abstract object files and
may contain user-built schematic-display object files.
• Directory &Daa—contains the area database for area aa where “aa”
represents an area number from 01 to 10.
• Directory &NMO (present only if the path to the system is through a
NIM with a UCN)—contains the NIM on-line personality (.PI) files.
• Directory &UCN (present only if the path to the sytem is through a NIM
with a UCN)—contains the PM/APM/HPM/SMM/SM/LMM on-line
personality (.PI) files.
• Directory &HGO (present only if the path to the system is through an
HG and Data Hiway)—contains the HG on-line personality (.PI) files.
• Directory &Ixx—contains the checkpoint files for the Data Hiway
number (01 to 20) or the Universal Control Network number (01 to 20).
• Directory &UXS—contains the GUS/UxS/EST personality (.PI) files and
boot loader if GUS/UxS/EST personality is loaded.
ATTENTION .
With release R650, a GUS node can be loaded with the GUS personality or
Operator personality using a fast-load cartridge (containing the GUS
personality files or Operator personality files) mounted in a different
US/GUSEST.
The fast-load cartridge that is used to load the GUS/UxS/EST node with the
GUS/UxS/EST personality will contain &UXS directory. The fast-load
cartridge that is used to load the GUS/EST node with the operator
personality will contain &OPR directory. A fast-load cartridge can contain
either the operator personality files or GUS personality files but not both.

20.2.3 Content and Maintenance of Fast-Load disks,
Continued
WARNING WARNING—When you add or modify Custom Data Segments

(CDSs) or custom packages, you must copy the resulting updated .SE
and .SP files (in the &ASY directory) to your fast load disks. If you
do not, the nodes (US, UxS, EST, GUS, AM, APP, ESVT, CG, NG)
that are loaded will not match the other RUNNING nodes.
Contents of the The Honeywell provided FAST_APP.EC file is used to prepare a fast-load
Fast-Load disk for disk for loading the APP/AM/ESVT personality without using the HM.
APP nodes
The disk contains the following software and data:
• Volume nnn—contains the personality (.PI) files, boot loader and

so on (n is the volume specified while creating the fast-load
cartridge).
• Directory &AXM—contains the APP/ESVT personality (.PI) files
if you select the APP/ESVT personality to be loaded.
• Directory &AMO—contains the AM personality (.PI) files if you
select the AM personality to be loaded.
• Directory &LDR—contains the boot loader, quality-logic test, and
off-line test files.
• Directory &ASY—contains system files; including the Network
Configuration File, NCF.CF.
• Directory &CUS—contains external load modules for custom
software and CL extension files.
• Directory &CLX—contains the set-definition files for AM custom
software.
• Directory &Fn—contains checkpoint files.
Keep your fast-load It is possible to create additional directories on a fast-load disk and to
disk convenient for copy to them, the US’s Universal Personality for convenience in
the user loading a US with those personalities, as allowed under Honeywell’s
software licensing policy. We do not recommend this for fast-load
disks intended for actual fast restoration of a path to the system,
because the presence of additional personalities causes an additional
step in the loading procedure, and it is possible that an operator could
select the wrong personality. Additionally, should an operator select
the Universal Personality, it takes longer to load than the operator's
personality, because there are more files to load.

20.2.3 Content and Maintenance of Fast-Load disks,
Continued
Checkpoints and Initial checkpoints and NCF are established when you prepare a fast-
NCFs established load disk. The disks should be regularly updated with new checkpoint
data and if NCF changes are installed, the NCF should be updated, or
any CDS updates.
Checkpoint frequently NIM or HG checkpoints should be saved frequently. To update

checkpoint data, request a demand checkpoint (SAVE DATA) for the
appropriate process network and specify the appropriate fast-load
disk as the checkpoint destination.
You may wish to use the CLNCFBKP.EC command file to update

your NCFs on fast-load disks. User instructions are provided in that
command file. The CLNCFBKP.EC file is also provided on the disk
&Z1 (for 68040 and 68020).

20.2.4 How to Prepare or Update a Fast-Load Disk
Preparation Use command file FST_VOLZ.EC to prepare a fast-load disk to

update selected directories on the disk. This .EC file is provided by
Honeywell on disks &Z1. If you need to reestablish more than one
path to the system, you may need to prepare more than one fast-load
disk. Figure 20.1 is a high-level flow chart of FST_VOLZ.EC. The
command file asks several questions that you answer by keying in
“y” or “yes”, or “n” or “no”. Other questions ask you to key in a few
characters. Press ENTER after each answer. Note this command file
is applicable for US/GUS/EST/APP/NIM/HG/CG/AM/ESVT and all
UCN devices.
Table 20-7 Procedure for Preparing a Fast-Load Disk

Step Action
1 Place the disk with EC files in a drive.
2 Place a new disk or one with data you no longer need in a drive, or
place an existing fast-load disk that is to be updated in a drive.
3 This step is optional, but is recommended to help you to verify that
the fast-load disk was built correctly.
Execute a Prompt Data On command followed by a Data Out
command to direct the command file's prompter and messages to a
printer. To do this, enter the following commands and press ENTER
after each command is entered:
PD ON
DO $Pn (n is the printer number)
4 On the Command Processor display, key in the following command
line and press ENTER:
EC $Fn>&EC>FST_VOLZ.EC $Fd aa hu NET PTH1
Where Is the…
n number of the drive with the .EC files disk
d number of the drive with the destination (fast
load) disk
aa area number (00 to 10) for the fast-load US.
hu process network number (hiway or UCN
number; 01 to 20).
NET source of the software and data to be placed
on the fast-load (destination) disk. If the
source is not an HM(s), use a disk
drive number ($Fs).
PTH1 name you wish to give the fast-load disk.

20.2.4 How to Prepare or Update a Fast-Load Disk,
Continued
Preparation of Fast- Use command file FAST_APP.EC to prepare a fast-load disk. This
Load disk for .EC file is provided by Honeywell along with the software upgrade.
APP/ESVT nodes
Figure 20-2 is a high-level flow chart of the FAST_APP.EC. The
command file asks several questions that you answer by keying in
“y” or “yes”, or “n” or “no”. Other questions ask you to key in a few
characters. Press ENTER after each answer.
Table 20-8 Procedure for Preparing a Fast-Load Disk

Step Action
1 Place the disk with EC files in a drive.
2 Place a new disk or one with data you no longer need in a drive.
3 This step is optional, but is recommended to help you to verify that
the fast-load disk was built correctly.
Execute a Prompt Data On command followed by a Data Out
command to direct the command file's prompter and messages to
a printer. To do this, enter the following commands and press
ENTER after each command is entered:
PD ON
DO $Pn (n is the printer number)
4 On the Command Processor display, key in the following command
line and press ENTER:
EC $Fn>&EC>FAST_APP.EC $Fd FAST
Where Is the…
n number of the drive with the .EC files disk
d number of the drive with the destination (fast
load) disk
FAST name you wish to give the fast-load disk.

Continued
Construction of Fast- The command file asks questions to verify the information on the
Load disk for APP command line or to give you opportunities to change that
nodes
information. The flow chart in Figure 20-2 shows the types of
questions that are asked, according to your responses to preceding
questions.
If you need to stop building the fast-load disk, hold [CTL] and press
[COMND] (the BREAK key). When the command file reaches the
next pause, its operation terminates. After you do this, you may have
a disk that is of little or no use.
Preparation or updating of a fast-load disk is relatively easy will take
several minutes to complete. Once the FAST APP disk has been
created, you should verify that it is operational. you can use the disk
on a GUS/EST to reload and restart an APP/ESVT but ONLY if the
HM is not available. To test this, the HM(s) would have to be non-
operational.
Refer to the AM Implementation Guidelines Manual for detailed
instructions for such a load.

Continued
Figure 20-1 FST_VOLZ .EC Flow

Destination Area Number
Cartridge Hiway or UCN Number
Start EC $Fn>&EC>FST_VOLZ.EC $Fd aa hu NET PTH1
Data Destination
Source Cartridge Name
Continue (yes/no)? EC Complete
N
Y
This EC will expect the fast-load destination

cartridge to be in $Fd. Is this correct (Yes/No)? What drive will contain the fast-load Key-in
N
destination cartridge ($F1-$F20)? entry.
Y
This EC will expect the area to be Key-in

N What is the area number? entry.
number aa. Is this correct (yes/no)?
Y Key-in What is the UCN
entry. Number (01-20)?
This EC will expect the Universal Control
Is the gateway a HG (yes/no)? Network number to be hu. Is this correct N
N (yes/no)?
Y Y
This EC will expect the hiway number to be What is the Key-in

hu. Is this correct (yes/no)? N hiway entry.
number?
Y
Is the HG a 68000 (yes/no)?

N EC knows it is
Y a 68020 HG.
Is the US?GUS a 68000 (yes/no)? EC knows it is

N a 68020 US.
Y
User answers prompters

Will all source data be from NET (yes/no)?
N to define where source data
Y comes from.
Do you want GUS Personality files instead of OPR (yes/no)?

N
Y
Yes, update the
next directory on the
Skip initialization of the directories (yes/no)? EC asks about copying or destination cartridge.
Y skipping each individual
N directory.
Copy files for this directory
from source to destination
EC verifies with user that correct destination cartridge.
cartridge is mounted in the correct drive.
All directories
Create volume and directories, have been checked.
and copy files and data to those EC Complete
directories on the destination cartridge.
EC Complete
2794

Continued
FAST_APP.EC
FAST_APP.EC is a template that you can customize (for specific nodes)
according to your requirements. You can create your own EC file to create
fast-load cartridges to load APP nodes. You can also make your own
customized versions of this file if all AM checkpoints cannot fit into a
single removable media. The fast-load cartridge created by the unmodified
FAST_APP.EC file has all possible AM/APP checkpoints and related
files. Therefore, the fast-load cartridge can load all of the system APP
nodes or AM nodes (depending on the personality files included).
The FAST_APP.EC file:
• creates the fast-load volume and directories
• copies either the AM (&AMO) or APP (&AXM) personality files

from HM or &Z3 disk to fast-load media
• copies &LDR, &ASY, &CUS and &CLX from NET to fast-load

media
• copies all AM/APP checkpoint data on the net to the fast-load

media
FAST_APP.EC optionally allows you to update any of the directories on
the APP/AM Fast-Load cartridge without having to re-create the volume.
ATTENTION .
Honeywell recommends that you disable the auto

checkpointing before executing this EC file.
Note: The fast-load cartridge can contain either the AM or APP

personality files, but not both. If both personality files are present in the
fast-load cartridge, the AM personality files will be loaded by default.

Continued
FAST_APP.EC Procedure for creating the AM/APP Fast-load cartridge:
1. Click Access Æ Mount/Dismount Emulated Disks.

2. In the Mount/Dismount Emulated Disks dialog box, Mount &Z3
on the drive.
3. Create a cartridge and specify the emulated disk information.
4. Mount the emulated/physical disk on the drive.
5. From the Engineering Menu, select Command Processor.
6. Type EC $FS>&EC>FAST_APP.EC $FD
where $FS represents the source drive and $FD represents destination
drive.
Press ENTER. The command file asks several questions that you answer
by keying in “y” or “yes”, or “n” or “no”. Other questions ask you to key
in a few characters. Press ENTER after each answer.

Continued
Figure 20-2 FAST_APP.EC Flow Chart
Start EC $Fn>&EC>FAST_APP.EC $FD
CONTINUE (YES/NO)?
EC TERMINATED EC Complete
N BY USER
Y
THIS EC WILL EXPECT FAST-LOAD WHAT DRIVE WILL CONTAIN

DESTINATION CARTRIDGE IN $Fd. N THE FAST-LOAD DESTINATION Key-in entry
IS THIS CORRECT (YES/NO)? CARTRIDGE ($F1 - $F20)?
DO YOU WANT TO CREATE A NEW THIS EC WILL UPDATE DESTINATION WHAT IS THE
APP/AM FAST-LOAD MEDIA N CARTRIDGE X. IS THIS CORRECT N DESTINATION Key-in entry
(YES/NO)? (YES/NO)? CARTRIDGE TO BE
UPDATED (NNNN)?
Y Y
THIS EC WILL NAME

THE FOLLOWING CARTRIDGE IS MOUNT THE DESTINATION
THE DESTINATION N WHAT IS THE MOUNTED. CATALOG COMPLETE IS N CARTRIDGE ON DRIVE,
CARTRIDGE &N. IS DESTINATION THIS CORRECT (YES/NO)? THEN PRESS “ENTER”
THIS CORRECT CARTRIDGE Key-in entry
(YES/NO)? TO BE NAMED
(NNNN)? Y
Y
THE FOLLOWING CARTRIDGE IS

MOUNTED. IS THIS CORRECT (YES/NO)? N
CREATE VOLUME COMPLETE
DO YOU WANT TO COPY AM

DO YOU WANT TO COPY APP
PERSONALITY FILES (YES/NO)? N FATS-LOAD MEDIA NOT CREATED –
PERSONALITY FILES (YES/NO)? N
NO PERSONALITY FILES SPECIFIED
Y Y
DO YOU WANT TO COPY APP/AM PERSONALITY

FILES FROM THE NET (YES/NO)? N WHAT DRIVE WILL CONTAIN THE APP/AM
PERSONALITY FILES ($F1-$F20)? Key-in entry
Y
THIS EC WILL EXPECT APP/AM PERSONALITY

FILES IN $FN. IS THIS CORRECT (YES/NO)? N
MOUNT DIRECTORY &AXM/&AMO ON DRIVE

$Fn, THEN PRESS “ENTER”
CREATE VOLUME AND DIRECTORIES, AND COPY

FAST-LOAD VOLUME
FILES AND DATA TO THOSE DIRECTORIES ON
CREATED
THE DESTINATION CARTRIDGE.

Continued
Verifying a Fast-Load You can use any or all of the following activities to help to verify that
disk for all nodes a fast-load disk has been built or updated correctly. For the best
other than APP node
assurance, do all of them.
• Use optional step 3, above, to print the results of execution of the
FST_VOLZ.ECcommand file, then after the disk is built or
updated, examine the printout for any reported errors. If any were
reported, try to eliminate the cause of the error and repeat steps 1
through 4, above. As an alternative to printing, you can use a DO
command to direct the output to a user file and then use the Text
Editor to examine the user file for reported errors.
• Use the Copy Volume command to copy a new or updated fast-load
disk to another disk. This verifies that all directories and files on the
new or updated fast-load disk can be read. The disk that accepts the
copy must have been initialized with a format that can accept the
content of the fast-load disk. These are examples of command lines
that
– Initializes the disk to accept the copy,
– Copy all directories and files from the fast-load disk to the
second disk, and
– Include an optional Write Boot command that, if used, enables
the second disk to also be used as a fast-load disk.
CV $F2>PTH1> -F -MF 600 -MD
CPV $F1>PTH1> $F2>PTH1 -A -D
WB $F2>&LDR
For more information about these commands, see Command
Processor Operation.
• In a test situation, rather than after an actual disruption, use the new
or updated fast-load disk to startup a reset or shut down the
Universal Station and the NIM or HG on the valve path it serves.
Refer to the Process Operations Manual for more information
about using such a disk to start up and load notes.

Continued
Verifying a Fast-Load You can use any or all of the following activities to help verify that a
disk for APP nodes fast-load disk has been built or updated correctly. For the best
assurance, do all of them.
• Use optional step 3 in Table 20-8 Procedure for preparing a Fast-

Load disk, to print the results of execution of the FAST_APP.EC
command file. After the disk is built or updated, examine the
printout for any reported errors. If any errors were reported, try to
eliminate the cause of the error and repeat steps 1 through 4. As an
alternative to printing, you can use a DO command to direct the
output to a user file and then use the Text Editor to examine the
user file for reported errors.
• Use the Copy Volume command to copy a new or updated fast-load
disk to another disk. This verifies that all directories and files on the
new or updated fast-load disk can be read. The disk that accepts the
copy must have been initialized with a format that can accept the
content of the fast-load disk.

20.3 Node Dumps
Introduction When a node fails, useful or vital information about the cause of the
failure is often contained in the information retained in the node’s
memory. If this information is dumped on (stored on) an HM or a
disk before the node is restarted, if requested, the information can be
sent to Honeywell for analysis.
Configure a Dump It is recommended you configure a Dump volume (&2np) on an HM

volume (for more information, refer to Section 7 or see Tables 7-1 and 7-9)
and keep each node’s dump state as ENABLE (on the Console Status
or node status display, select a node, select ENABLE LD/DUMP, then
select ENABLE DUMP). With R4xx and above a NODE DUMP target
appears when the node is selected. If a node has failed (was not
intentionally shut down), proceed with the dump before initiating a
load.
If Honeywell requests a copy of the dump information, you can use

the Command Processor to copy the dump data from the HM to a disk
to Honeywell.
20.3.1 Dump Failures
Introduction If a node dump is unsuccessful for some reason, such as inadequate

dump volume space or a transfer error, you can usually repeat the
dump (of course, if the dump did not complete because of inadequate
space on the dump medium, you must resolve that problem). To retry
the dump, shut down the node to force it to fail again (on the Console
Status or node status display, select the node whose dump failed,
select SHUT DOWN, and press ENTER). Then you can retry the dump.
Overwritten data In this situation, some of the data in the node’s lower memory can be
overwritten. This is better than no dump data at all. Should you use
this technique, be sure to mark the disk used to store the dump data,
to indicate that the data was obtained after a “forced failure.”

20.3.2 Save Error Blocks on Node Reload
Introduction With R681, the System HM is enhanced to retrieve the following

information of a failed node:
• Valid error blocks
• Register information
• Node attributes such as node number, version, node type,
personality type, and processor type
When a node fails, the System HM retrieves and saves the
information to a file in the system HM.
NOTE: The System HM can save the error block information for
multiple failed nodes.
ATTENTION You can analyze the node failure using the error block information
saved in the system HM and/or the node dumps. Honeywell
recommends collecting node dumps, as the node dumps provide a
more detailed description about the node failure.
LCN node support The new feature supports the failure of the following LCN node
types:
• AM • NG
• Non-System HM • US
• HG • GUS
• NIM • APP
• CG
Experion support The new feature supports the failure of the following node types in
Experion:
• ES-T
• ESVT
• ACE-T
Information from a The System HM retrieves the valid error blocks of a failed node and
failed node converts them to ASCII format. The converted error blocks
information is saved in a text file in HM. The format of the text file
corresponds to the SMCC Detailed Module Error block display. You
can open the text file using the text editor for analyzing the error
block information. This file can be transferred through File Transfer.
Similarly, the register information and the node attributes of a failed

node are saved in the text file.

20.3.2 Save Error Blocks on Node Reload, Continued
ATTENTION You cannot save the error block information of a failed node if the
System HM is not available. &ASY directory must be available in the
System HM.
HM Text file The text file ERRBK.XX is used for saving the error block
information and resides in the NET>&ASY directory of HM. When a
node fails, the valid error blocks are added at the beginning of this
file. The text file can accommodate the error block information for a
maximum of 10 failed nodes.
NOTE: When retrieving error block information from multiple failed

nodes, the system HM retrieves only the first error block information
from the multiple failed nodes. However, all the valid error blocks are
retrieved from the latest failed node.
If the error block information cannot be retrieved or saved in a text

file, a System Error Journal (SEJ) is generated.
If the &ASY directory is not available, the error blocks of a failed

node are not retrieved and saved.
If the ERRBK.XX file is protected then a temporary file is not

created and a SEJ is generated. If the ERRBK.XX file is not
accessible and is not protected, the error block information is
retrieved and saved in a temporary file.
When a node failure occurs subsequently, the System HM performs

the following:
• Retrieves the error block information from the temporary file and
saves it to the ERRBK.XX file.
• Deletes the temporary file.
• Retrieves the error block information from the latest failed node
and updates the ERRBK.XX.

20.3.2 Save Error Blocks on Node Reload, Continued
Error block The system HM can retrieve and save up to a maximum of 32 valid
information error block information of a failed node in the HM text file. The text
file contains the information displayed in SMCC /MAINTENANCE
> MODULE ERROR > DETAILED MODULE ERRORS.
The detailed error block contains Error Entity Type, Error Severity,
Error Desc Size, Error Desc Type, Occurrence Time, Task name,
Program Counter1, Program Counter2, Program Counter3, Param1
and Param2.
For example:
Rec=1; Error Entity Type=$ILLOGICAL_CONDITION;
Error Desc Type=$Software_Error; Time=6/25/2007 11:41:39:8005
Task Name=UG$_RED; PC1=003D0D34; PC2=004059DA;
PC3=0040614A
Param1 INTEGERS Values=170,180; Param2 INTEGERS
Values=0,0
Register information The System HM retrieves the register information from a failed node
and saves them in the text file. The register information contains the
following details:
• Address registers: A0, A1, A2, A3, A4, A5, A6, and A7.
• Data registers: D0, D1, D2, D3, D4, D5, D6, and D7.
Format of register information:

D0=00000000;D1=00000007;D2=41A66032 D3=00000000
D4=00000000;D5=00000002;D6=00000001;D7=00000008
A0=800B99E0;A1=002DCBB5;A2=002DCB8F;A3=00507A00;
A4=800B9AF2;A5=800B9A14;A6=000B8C82;A7=800B99C6
Node attributes The System HM retrieves the node attributes from a failed node and
saves them in a text file.
The following node attributes are saved in the text file:
Node number,version, node type, personality type, and processor
type.
Format of node attribute:

Failed Node=1
Version=68.10; Type=US; Personality=usonp;
Processor=G$K2LCN_with_8MW

Section 21 – Checkpointing
21.0 Overview
Description This section defines checkpointing. It describes how you configure

your system for checkpointing for HGs, NIMs, AMs, and CGs.
It also explains how automatic checkpointing functions, and what

happens if an error occurs.

What is checkpointing? Checkpointing is the storing of the process database from a module
or gateway in files, from which the data can be reloaded into the
module or gateway, should it be necessary to restart it. Where a
gateway serves process devices, such as the boxes on a Data
Hiway, or PMs or LMs on a Universal Control Network, their
process data can be included in the checkpoint files, and reloaded.
The term "checkpoint" arises from the notion that a "snapshot" of
the data is acquired at some point in time—a "checkpoint."
Zip Disk Zip Disk
LCN
HM
Module
UXS US
LCN
NIM HG
50891
Initiating a checkpoint Through the module or gateway status displays, you can enable
automatic checkpoints—the collection of checkpoint data every
four hours, and you can demand a checkpoint at any time.
Good checkpointing To protect their data in case of a failure, you can configure your
practices system to automatically request checkpointing. This procedure
stores checkpoint data to the hard disk on an HM.
Always make it a practice to periodically perform a demand

checkpoint of all critical nodes. Save these checkpoints to
removable media. In the unlikely event of a hard disk failure, you
will have checkpoint data from which you can recover your data.

21.1 How to Configure for Checkpointing
Preparation For demand checkpointing to removable media, no configuration is

necessary other than to use the Utilities' Create Volume command to
initialize the disks that will receive the checkpoints.
We recommend each removable medium (volume) used to receive

checkpoints be initialized with at least 240 files.
When you save a checkpoint on a removable medium, if they don't

already exist, appropriate checkpoint directories are created on the
medium. These directories are listed on Table 2-1 in this manual.
WARNING WARNING—If you reconfigure checkpoint volumes on an HM that

is on-line, you will have to copy all of the data on that HM to
removable media or another HM. You must copy all of the data on
the HM because it must be initialized, which erases the content of
the HM.
The HM must then be reloaded with the new volume configuration

and the data that was copied from it.
How many checkpoint Configure a checkpoint volume on an HM for each node that is to
volumes are needed? have automatic checkpointing (you can use more than one HM for
checkpointing).
This is accomplished in the Volume Configuration portion of

Network Configuration, on form SW88-517, which represents the
Physical Node for Checkpoint Configuration Display.
References Refer to Network Form Instructions for instructions for filling in

form SW88-517.
See Network Data Entry for instructions covering the installation of

the new NCF and restarting the HM with the new volumes.
Also refer to Engineer’s Reference Manual—this manual.

21.1 How to Configure for Checkpointing, Continued
Creating checkpoint Appropriate checkpoint directories in checkpoint volumes on HMs

directories are created during system startup Task 18, as each node is started up
for the first time. At that time, the appropriate Honeywell-provided
null-checkpoint medium is used as the data source for load
operation.
Added LCN nodes If you add a node to the LCN that needs checkpoints, unless you
intend to use only removable media for the checkpoints (this means
no automatic checkpointing), you must reconfigure HM volumes to
add a checkpoint volume for the new node (see the Warning above).
If you add units to an AM or a CG, if the HM checkpoint volume for

the node affected is large enough (see Engineer’s Reference
Manual—this manual), you need only to add a checkpoint directory
for the unit and copy the master checkpoint file into that directory.
See Application Module Implementation Guidelines for the

procedure to add a checkpoint directory.

21.2 Checkpoint Functions
Introduction Checkpoints can be called on demand or automatically, as requested

by the user. These operations will be covered in the sections which
follow.
CAUTION .
First, some precautions
• Do not try to concurrently load both HGs in an HG pair, nor
both NIMs in a NIM pair—because one of the gateways may
fail. Complete loading of one of the gateways as the primary,
then the other can be loaded as the secondary.
• When you do a demand checkpoint to a removable medium, use
just-initialized disks only. If, for some reason, a demand
checkpoint to a removable medium is not completed and that
medium contained an older checkpoint, some of the checkpoint
data will be new and some may be old. This results in useless
data.
• Use demand checkpoints as backups for HM checkpoint data,
rather than copies of HM checkpoint data. If more than one
disk is needed, the data for one unit may be split between disks,
and such data can't be reloaded.
21.2.1 Demanding, Enabling, and Disabling Checkpoints
Requesting a demand The node status displays for AMs and CGs, and the process-network
checkpoint (UCN and Data Hiway) status displays have a SAVE DATA target
(pick). The SAVE DATA target can be used to request a demand
checkpoint at any time. When the SAVE DATA target is used,
prompters request that the medium specifies where the checkpoint is
to be stored. NET specifies the checkpoint is to go to the HM that
has the checkpoint volume for the physical node. $Fn specifies a
removable media drive. If more than one disk is needed to complete
the checkpoint, prompters ask you to mount a new medium.

21.2.1 Demanding, Enabling, and Disabling Checkpoints,
Continued
Auto save When you select the AUTO SAVE target, ENABLE and DISABLE targets
appear, and just above them, this line appears:
Current State: Enable (Disable)
Select the target for the other state, and the current state changes. In the enable
state, automatic checkpointing for the node is enabled and occurs as described
in the Automatic Checkpointing section which follows. The disable state
prevents automatic checkpointing for this node. These states have no effect on
demand checkpointing, and demand checkpointing has no enable or disable
states.
We recommend that you disable automatic checkpointing for a node and do not
request a demand checkpoint when you are using the DEB to load entities in the
node.
Because AMs can have hot, warm, and cold restarts, the time of the last AM
checkpoint (automatic or demand) is shown on the Node Status display for each
AM. Users can consider this time in deciding which type of restart to use.
Refer to Application Module Control Functions for definitions of hot, warm,
and cold restarts.
Refer to Hiway Gateway Implementation Guidelines for additional information

on the HG database and HG checkpointing.
.
CAUTION When you do a demand checkpoint to removable media, use just-initialized
disks only. If, for some reason, a demand checkpoint to a removable medium is
not completed and that medium contained an older checkpoint, some of the
checkpoint data will be new and some may be old. This results in useless data.
Use demand checkpoints as backups for HM checkpoint data, rather than copies
of HM checkpoint data. If more than one disk is needed, the data for one unit
may be split between disks, and such data can't be reloaded.

21.2.2 Automatic Checkpointing
Description Each HM, with checkpoint volumes, independently cycles through

its list of physical nodes to checkpoint. If automatic checkpointing
is enabled (Auto Save status on the node status display is
Enable), a checkpoint from each logical node in the physical node
is requested. This applies to HGs, NIMs, AMs, and CGs.
Each physical AM and CG has as many logical nodes as it has units.

Each NIM and HG has only one logical node.
Checkpoint cycle time The standard automatic checkpoint-cycle time is 4 hours. This
means that every 4 hours, each logical node is asked for its
checkpoint data. If the checkpointing for all logical nodes is
complete within 4 hours, the next cycle begins at the start of the next
4-hour cycle. If it is not complete when the time arrives for the next
cycle, the next cycle begins as soon as the previous cycle is
complete.
The cycle starting times are (in 24-hour format)

• 00:30 am 12:30 pm
• 04:30 am 16:30 pm
• 08:30 am 20:30 pm
Checkpoint time-out If a requested checkpoint for a logical node is not complete within
60 minutes, a time-out message is printed on the Real-Time Journal
(see 21.3 in this manual) and the cycle continues as described above.
If a node fails while being checkpointed, a failure message is printed
in the Real-Time Journal and the cycle continues as described
above.
If a primary HM fails during a checkpoint cycle, its secondary HM

doesn't continue with the cycle, but restarts checkpoint cycles at the
next cycle start time.

21.2.2 Automatic Checkpointing, Continued
Automatic checkpoints Each History Module with checkpoint volumes contains five
at intervals other than Processor Status Data Point (PSDP) parameters that allow you to
4 hours
monitor automatic-checkpointing functions and to change from the
standard automatic-checkpoint interval and offset.
The first four of these parameters represents time in hours, minutes,

and seconds. The fifth parameter is an integer. You can view these
parameters in the TLK1 displays. See 10.4 in this manual for TLK1
clock displays.
CAUTION .
If you set up an HM for frequent checkpointing, be careful not to
create any system performance problems. Frequent checkpointing
increases both the HM and network workloads. Even though a 10
second delay is set up between units being checkpointed, do not
configure the same HM for both frequent checkpointing and
continuous history.
CAUTION .
If the default automatic checkpoint period is modified, the allowable
range for the period is 00:01 hours to 12:59 hours. Do not use
00:00 hours to force continuous checkpointing. History access will
become blocked if automatic checkpointing is disabled on any node
being checkpointed by that HM.

Automatic checkpoint Here is a list of the five PSPD automatic-checkpoint parameters:

parameters
• TIMEBASE(1)—This HM’s automatic-checkpoint interval. The
default value of this parameter is 4 hours. You can view and
change this parameter. Seconds may be displayed; however, if
they are entered, they are arbitrarily set to zero. The new Period
must be greater than or equal to the Offset, the parameter in
TIMEBASE(2). The new Period, converted to minutes, must be
an exact divisor of 1440, the number of minutes in a day (24
hours/day times 60 minutes/hour).
• TIMEBASE(2)—This HM’s automatic-checkpoint offset value.
The default value of this parameter is 30 minutes. You can view
and change this parameter. Seconds may be displayed; however, if
they are entered, they are arbitrarily set to zero. The new Offset
must be less than the Period, the parameter in TIMEBASE(1).
• TIMEBASE(3)—The time it took to complete the last automatic-
checkpointing cycle. This is a view-only parameter.
• TIMEBASE(4)—Start time of the current or last automatic
checkpoint. This is a view-only parameter. A nonzero value for
seconds may be displayed since the internal dynamics of the HM
can keep the automatic checkpoint from starting exactly on the
minute (seconds = 00). The starting time is updated whenever a
new Period or Offset is entered. If a new Period or Offset is
entered during a checkpoint’s duty cycle, the current starting time
is overwritten by the new starting time.
• NODENUM—The number of the node currently being processed.
If no automatic checkpointing is in progress, this parameter
contains a value of zero.
To change parameters These PSDP parameters can be changed by using the PERFMENU
display CHKPTIME as shown in the following figure. Also, any of
these parameters can be included in a custom display by referencing
the PSDP for the node and the desired parameter. For example, to
display the time it took to complete the last checkpoint for HM 16,
reference $PRSTS16.TIMEBASE (3).

CHKPTIME
Display
10248
If you change period Because automatic checkpointing is initiated “on the minute,” a new
or offset Period or Offset is not be recognized until the next “on the minute.”
If both the Period and Offset are to be changed, complete both
changes before the next “on the minute.”

How an auto An auto checkpoint file is set up in the local volume of each HM
checkpoint file is configured for automatic checkpointing, when automatic
constructed
checkpointing starts up for the first time. The file is given a network
unique name by using its HM pair number. The initial auto
checkpoint file is named Cxx_CPNT.MM, where xx is the HM pair
number 1 - 20. It is built as a protected file.
What happens if auto If the file gets corrupted, it is renamed CP_RNzzz.MM, where zzz is
checkpoint file is an integer between 0 and 30, and a new Cxx_CPNT.MM file is
corrupted
created.
If the corrupted file was detected while the intervals or offsets were
being changed, the new file contains the new values.
If the corrupted file was discovered during an HM startup, the new

file contains the default values.
Detecting automatic If the auto checkpoint file is corrupted, an error message appears in
checkpoint errors the real-time journal, that warns that the file was corrupted and that
a renamed file has been set up.
If a requested checkpoint for a logical node is not completed within

60 minutes, a time-out message appears in the real-time journal (see
21.3) and the cycle continues. If a node fails while being
checkpointed, a failure message is printed in the real-time journal
and the cycle continues.
If a primary node fails during its checkpoint cycle, its designated

secondary, if it has one, doesn’t continue with the cycle but restarts
checkpointing at the next cycle time.

21.2.3 Levels of Automatic Checkpointing
Summary of states The three levels of automatic checkpointing, the status displays to
use for viewing and modification, and checkpoint state descriptions
are summarized in the following table:
Table 21-1 Autocheckpoint States

Level Status Display State Description
NIM Gateway Status ENABLE Checkpoint Control will attempt to checkpoint the NIM,
display and then proceed to attempt checkpointing of devices
on the UCN based on
• UCN checkpoint state, and
• individual device checkpoint states.
DISABLE Checkpoint Control will not attempt to checkpoint the
NIM or any devices on the UCN.
UCN UCN Status display ENABLE Checkpoint Control will attempt to checkpoint any
devices on the UCN with checkpoint state of ENABLE.
INHIBIT Checkpoint Control will not attempt to checkpoint any
devices on the UCN.
Device UCN Status display ENABLE Checkpoint Control will attempt to checkpoint this
or device.
Device Status INHIBIT Checkpoint Control will not attempt to checkpoint this
display device.
(PM,APM,LM)

21.2.3 Levels of Automatic Checkpointing, Continued
Default on a node load The default automatic checkpointing states on a node load (of a
node with no active primary) for the different levels are shown in
the following table:
Table 21-2 Default Autocheckpoint States on Node Load

Type of Checkpoint Auto Checkpoint Default State
Node Load Level
Primary NIM Defaults to checkpoint state in the checkpoint
NIM file used to load.
UCN INHIBIT
Device Each device’s checkpoint state will default to
the state as it was saved in the checkpoint file
used to load.
Primary NIM Unaffected by device load.
Device
UCN Unaffected by device load.
Device INHIBIT

21.2.3 Levels of Automatic Checkpointing;, Continued
Review of If you are relying on autocheckpointing to provide current checkpoint

autocheckpoint files for your UCN, keep in mind the three levels that must be
disable levels
enabled for a UCN node to be checkpointed.
For example, suppose it became necessary for you to reload the NIM.
As listed in the above table, Default Autocheckpoint States on Node
Load, the autocheckpoint state for the UCN defaults to INHIBIT on a
NIM load. If you forget to change the checkpoint state back to
ENABLE, the next time autocheckpointing is initiated for the UCN,
checkpointing will be performed for the NIM (if NIM state is
ENABLE) but not for any other nodes on the UCN. If database
changes are then made and the NIM is checkpointed, the NIM
checkpoint file will contain the new information but the process box
checkpoint file will not be updated.
The following table shows the results of the different combinations of

autocheckpoint states for the different levels of autocheckpointing:
Table 21-3 Autocheckpoint State Combinations

NIM UCN Process Nodes that will be
boxes(all) checkpointed
ENABLE ENABLE ENABLE NIM
Process boxes
ENABLE ENABLE INHIBIT NIM only
ENABLE INHIBIT ENABLE NIM only
ENABLE INHIBIT INHIBIT NIM only
DISABLE ENABLE ENABLE None
DISABLE ENABLE INHIBIT None
DISABLE INHIBIT ENABLE None
DISABLE ENABLE INHIBIT None
DISABLE INHIBIT INHIBIT None
Understanding how these levels affect the checkpoint files created

during an automatic checkpoint will help you avoid creating
inconsistent checkpoint files that may cause point fragments if used to
load a node.

21.2.4 Checkpoint File Organization
Introduction You can use the Utilities' List File Attributes command (LS or CAT)
to list the files in your checkpoint directories (see Table 2-1 for the
directory names). The lists include the date and time of each
checkpoint. Old checkpoint data is retained while new data is being
stored, so while the data is being stored there are two copies of each
file.
Filename symbols The symbols used in filenames in the following tables have these
definitions:
bb = Box number
hh = Hiway number (1 through 20)
mm = UCN Node number (1 through 32)
r = Revision level of this file (r = 1 or 2)
r = 1 the first time the file is saved,
r = 2 the second time,
then it alternates each time the file is saved.
uu = UCN number (1 through 20)
uuu = Unit number (1 through 100)
HG Checkpoint Files Checkpoint files are grouped in the HG as shown below.
Table 21-4 HG Checkpoint Files

HG Checkpoint Files Description
HG0hhAXr.CP AUX data (R520 and newer)
HG0hhbbL.CP MC Logic Block data
HG0hhbbr.CP Box-resident data
HG0hhEXr.CP ASSOCDSP data (R520 and newer)
HG0hhHGr.CP HG-resident data
HG0hhMAS.CP Master-revision file
HG0hhOPr.CP Output alarm data (R520 and
newer)

21.2.4 Checkpoint File Organization, Continued
NIM Checkpoint Files Checkpoint files are grouped in the NIM as shown below.
Table 21-5 NIM Checkpoint Files

NIM Checkpoint Files Description
NM0mmNMr.CP NIM-resident data file
NM0mmMAS.CP NIM master file
LM0mmuur.CP LM-resident data file
LM0mmuuM.CP LM master file
PM0mmuur.CP PM-resident data file
PM0mmuuM.CP PM-master file
APMmmuur.CP APM-resident data file
APMmmuuM.CP APM-master file
HPMmmuur.CP HPM-resident data file
HPMmmuuM.CP HPM-master file
SM0mmuur.CP SM-resident data file
SM0mmuuM.CP SM-master file
AM Checkpoint Files Checkpoint files are grouped in the AM as shown below.
Table 21-6 AM Checkpoint Files

AM Checkpoint Files Description
AMuuuMAS.CP Master checkpoint file
AMuuuPDr.CP Point data
AMuuuNTr.CP Point names
AMuuuLAr.CP CL
AMuuuCDr.CP Custom DSDs
With an automatic checkpoint, only the data that changes will be

checkpointed. This causes some files to be version one and some files
to be version two. With a manual checkpoint, all data is saved and all
files will have the same version.

21.2.4 Checkpoint File Organization, Continued
CG Checkpoint Files Checkpoint files are grouped in the CG as shown below.
Table 21-7 CG Checkpoint Files

CG Checkpoint File Group Description
CIuuuMAS.CP Master checkpoint file
CIuuuPDr.CP Point data
CIuuuNTr.CP Point names
CIuuuCDr.CP Custom DSDs

21.3 Checkpoint Error Messages
Introduction Error messages are printed in the real-time journal, if the journal is
active on a US with the Operator Personality, and:
• if a node processing a checkpoint request fails or,
• if a requested checkpoint is not complete within 60 minutes
(timed out).
Error message form The messages are in this form:

Checkpoint of UNI uu in XX nd to HM nd Failed; Code nn
Checkpoint of UNI uu in XX nd to HM nd Timed Out
Checkpoint of HWY hh in HG nd to HM nd Failed; Code nn
Checkpoint of HWY hh in HG nd to HM nd Timed Out
Checkpoint of HWY hh in NM nd to HM nd Failed; Code nn
Checkpoint of HWY hh in NM nd to HM nd Timed Out
Where:
• uu = unit number
• XX = AM or CG
• nd = node number
• hh = hiway number
• nn = error code number
Error code meaning The meaning of the error codes are:
Table 21-8 Error Code Meaning

Code Checkpoint Error
05 A File Manager error against the HM, possibly a bad drive, bad
sector, or bad data on the drive.
06 File access error, such as trying to access a protected file. The
AM Processor Status Point parameter CPFMERR* contains a
code that further defines the type of error:
Code CPFMERR Error
03 Physical error
20 Device not found
26 Insufficient storage space
28 Exceeded maximum number of files per volume
* See 22.1 for information on accessing CPFMERR.
07 Auxiliary file access error.

14 Target node failed.
15 Target node had an unexpected state change, such as being
reset during the checkpoint operation.
36 Duplicate directory error.

21.3.1 System Error Messages—Hiway Checkpoint
Introduction Checkpoint errors may cause messages to be printed in the Real-

time Journal and in the System Error Journal.
Message form The messages are in the form:

D$ CP CHKPNT AA BB CC DD
where:
AA = Indicates the internal HG module name:
14 = lost process event
15 = lost hiway event
16 = lost peripheral event
178 = file manager error
181 = HG database errors
182 = checkpoint task – report Box DB errors
BB = Provides a cause-of-error indication:
nn = number of node that lost event
190 = Error against HM (bad drive, sector, or data)
194 = File Manager error.
195 = Checkpoint volume full or not enough room to
do checkpoint.
199 = Checkpointing inhibited
. 205 = Box in TEST control state; must be FULL or
BASIC.
216 = Gateway cannot communicate with Process
Network.
220 = Hiway Error
221 = Data Inconsistency (checkpoint file may be
protected or corrupted)
CC = 5001 through 5063 (the last two digits are the box
number)
60nn (nn is the HG file number)
0 (the system crashed)
DD = Event serial number

21.3.2 System Error Messages—UCN Auto Checkpoint
Introduction If an automatic checkpoint operation is not completely successful, a

software error message will be reported to the System Error Journal
and the Real Time Journal. The software task that reports these
errors is (the slow command handler), the NIM processing task
responsible for checkpoint and restore operations:
UG$_CH_SLOW 28, 94, nn, xx
where:
nn = node’s UCN node number, 1 through 64
xx = type of error as listed in Table 4
xx Value Meaning
05 Checkpoint volume too small to create the checkpoint file.
07 &Inn checkpoint volume not found on an HM.
41 UCN communication problem—NIM cannot send checkpoint

request to UCN node.
55 UCN node is in IDLE state and cannot be checkpointed.

Database may not be valid.
65 I/O link resource error. Not enough resources on I/O link to

checkpoint IOM.
66 UCN node is in softfail state, so cannot respond to checkpoint

request.
68 Checkpoint file on HM is wrong version or wrong revision.

Proper upgrade of checkpoint files is needed.
69 Checkpoint request rejected by the UCN node. Contact

Honeywell TAC.
73 Communication problem on the I/O link.

Section 22 – Processor Status Data Point
22.0 Overview
Introduction This section defines processor-status data points (PSDPs), discusses

their use, and lists each PSDP parameter with its definition.
RULA PSDP The Universal Station may have additional PSDP parameters related
parameters to the optional software module RULA (Remote User LCN Access).
The RULA User Manual shipped with the software (MP-RLSW01)
describes these RULA PSDP parameters.

22.1 Purpose of Processor Status Data Points
Description Every node on the LCN has a Processor Status Data Point (PSDP)
that contains several parameters common to all LCN nodes. These
parameters reflect important status and memory-use values.
Additionally, there are node specific (e.g., AM, US) parameters for
the PSDP that reflect performance and configuration.
How to see PSDP You can see many of the PSDP parameters in the TLK1 display set
parameters and their and you can change the values of certain parameters. PSDP
values
parameters can also be used in custom schematics built by the user.
Refer to section 10 in this manual for use of the TLK1 display set
and using the DATACHNG display. This is the generic Parameter
Access and Value Change display.
How to read a PSDP The PSDP's name is $PRSTSnn, where nn is the LCN node number.
parameter using
DATACHNG
To read the value of PSDP parameter DVCSTATE in node 38, on
the DATACHNG display, enter
$PRSTS38.DVCSTATE
in the VARIABLE ID port and press [ENTER].
When PSDP The values of PSDP parameters that are updated periodically are not
parameters are valid meaningful until the end of the first sample period following node
startup or an LCN time change.
No error indication is provided if you access such values before they

are valid.

22.2 PSDP Parameters in All Nodes
ATTENTION .
These PSDP Parameters can be found in all nodes
$COMSTAT Remote Node visibility. Indicates the visibility status of the remote node with
(R681) respect to the selected node.
Source – System
TYPE – Array [ 1..96] of Enum of $COMVIS
Value Range – OK
a:mrg
b:mrg
ab:mrg
Default Value – OK
Access Lock – View Only
$CBLMTP Cable marginal threshold limit. A value > 0 activates the marginal state
(R681) functionality for the cable. If the number of errors on the cable is greater than
the threshold limit, the cable auxiliary status is indicated as MRGNAL.
Source – User
TYPE – Integer
Value Range – 0-2
Default Value – 0
Access Lock – ENG
$NDM1TP Node marginal threshold limit for 1 minute. A value > 0 activates the marginal
(R681) state functionality for the node. If the number of errors (for 1 minute) on the
node is greater than the threshold limit, the node auxiliary status is indicated as
MRGNAL.
Source – USER
TYPE – Integer
Value Range – 0-3
Default Value – 0
Access Lock – ENG
$NDM15TP Node marginal threshold limit for 15 minutes. A value > 0 activates the
(R681) marginal state functionality for the node. If the number of errors (for 15
minute) on the node is greater than the threshold limit, the node auxiliary
status is indicated as MRGNAL.
Source – USER
TYPE – Integer
Value Range – 0-10
Default Value – 0
Access Lock – ENG

22.2.1 PSDP Parameters in All Nodes, Continued
ACTION An integer that indicates what action should be taken as a result of a change to
the NCF. 0 = no action, 1 = restart, 2 = HM initialization.
TYPE—Integer
ACTIVCBL RNOS—Identifies currently active LCN cable. 0 = cable A, 1 = cable B.

TYPE—Integer
AUXQUAL APPLICATION—Auxiliary device status qualifier to indicate annunciation

requirements on console.
PURPOSE—Indicates device specific status annunciation policy for the status
display.
TYPE—Enumeration of $AUXQUAL. This parameter can have one of these
values: NORMAL, INDICATE, ANNUNC, JOURNAL.
AUXSTAT APPLICATION—Auxiliary device status to be displayed by MMI in certain

node types (for example, the HM disk redundancy status or the CG link status).
PURPOSE—Indicates device specific status information on the node status
display.
TYPE—String Array
CABLESTS An integer that indicates the status of the LCN cables.

0 = No State
1 = No Cable Suspect
2 = Cable A Suspect (Cable B OK)
3 = Cable B Suspect (Cable A OK)
4 = Both Cables Suspect
5 = Cable A Marginal (Cable B OK)
6 = Cable B Marginal (Cable A OK)
7 = Cable A Suspect & Cable B Marginal
8 = Cable B Suspect & Cable A Marginal
9 = Both Cables Marginal
TYPE—Integer
CBREV(i) An array (1..32) of the currently loaded Custom Systems Overlays (a.k.a. sets)
loaded in the node. These 24 character strings list the overlay name, revision,
and memory load address. This allows DATACHNG or any schematic to list
the Load Modules.
PURPOSE—Provides a check on custom software packages.
TYPE—String Array

22.2 PSDP Parameters in All Nodes, Continued
CLKRESET RNOS—Allows a forced resynch of hardware clock after a problem has

occurred. STORE ONLY PARAMETER!
PURPOSE—Provides a clock synch command.
TYPE—Boolean
Storing either TRUE or FALSE to this parameter causes a reevaluation of the
hardware clock. This is useful after a faulty clock board has been replaced, to
force a reevaluation of the clock hardware immediately instead of waiting for
the periodic reevaluation.
CLK_CBL Indicates the clock cable select status. A value of NOUPDATE means neither
cable is receiving clock updates; CBLA means that the node is receiving clock
updates on cable A only; CBLB means that the node is receiving clock updates
on cable B only; ALTCBLA means that the node is alternately receiving clock
updates on both cables and the last update was received on cable A, and
ALTCBLB means the node in receiving clock updates on both cables and the
last update was received on cable B.
TYPE—Enumeration of $CLK_CBL. The states are: NOUPDATE / CBLA /
CBLB /ALTCBLA / ALTCBLB.
CLK_MOD Indicates the clock mode. A value of MASTER means this node is the LCN
clock master. SLAVE means that the node is the clock slave. LISTENER
means the node has listen-only selected, and LOCAL means the node is in local
mode.
TYPE—Enumeration of $CLK_MOD. The states are: MASTER / SLAVE /
LISTENER / LOCAL.
CLK_SYN Indicates the source that is currently being used to synchronize the clock. A
value of NOTSYN means the clock is not synchronized to either the clock
hardware interrupt or the line power frequency. PRECREF means that the
clock is using the precision reference or the line power frequency. DIGSYNCH
means the clock is using the digital received time frame. SUBSYNCH means
the clock is using the subchannel received time frame.
TYPE—Enumeration of $SYN_SRC. The states are: NOTSYN / PRECREF /
DIGSYNCH / SUBSYNCH.

CLK_TRN Indicates the clock translator status of the node. A value of TRNSLTR means
that this node is the translator of clock signals from the old hardware clock
format to the new (K2LCN) clock format. A value of NONTRNS means the
node is not the translator node.
TYPE—Enumeration of $TRAN_MD. States are: TRNSLTR/NONTRNS.
CLK_WRD Contains an integer representation of the clock system hardware status word.
COMM(i) RNOS—Provides cable statistics on each node on LCN including the

communications and driver level.
PURPOSE— Provides LCN communication and cable reliability data.
TYPE—Array of Integers (Large and complex structure, array of 1200)
Refer to Appendix C in LCN Guidelines - Implementation, Troubleshooting,
and Service.
CMNT_TIME(i) This array lists the time stamps on the operator comments associated with
Status Accountant objects listed in this node’s status detail. This array is
indexed by object number.
TYPE—Array of Time
CPUFREE
RNOS—Percent of free processor (CPU) time over previous 15 seconds.
Purpose— Indicates the CPU load versus capacity.
TYPE—Real
CPUMAX
RNOS—Maximum percent CPU free time (maximum CPUFREE value) over
15-second sample period during current hour.
PURPOSE—Indicates the CPU loading range.
TYPE—Real
CPUMIN
RNOS—Minimum percent CPU free time over 15-second sample period during
current hour.
PURPOSE—Indicates the CPU loading range.
TYPE—Real

CUR_NCF
Indicates the revision level of the currently loaded NCF. Can be used with
parameter IMPACT to determine the impact of an NCF change.
TYPE—Time
DVCERCNT(i)
The error count of a particular “device” attached to this node. This array is
indexed by device number (1..129).
TYPE—Integer
DVCLDID
Indicates the logical device identifier.
TYPE—String
DVCSTATE(i)
The state of a particular “device” attached to this node. This array is indexed
by device number (1..129).
TYPE—Enumeration of DVCSTATE
DVCSUBST(i)
The substate of a particular “device” attached to this node. This array is
indexed by device number (1..129).
TYPE—Enumeration of DVCSUBST
DVCTRCNT(i)
The transaction count for a particular “device” attached to this node. This
array is indexed by device number (1..129).
TYPE—Integer
DVCVVID
Indicates the device virtual volume identifier.
TYPE—String
HEAPBCN2
Current number of blocks of free pool 2 heap memory.
TYPE—Real

HEAPBCNT
RNOS—Current number of free Pool 1 heap blocks.
TYPE—Real
HEAPFRA2
RNOS—Percent of Pool 2 heap fragmentation (0=no fragmentation,
100=totally fragmented). A value above 2 or so indicates problems in heap.
TYPE—Integer
HEAPFRAG
RNOS—Percent of Pool 1 heap fragmentation (0=no fragmentation,
100=totally fragmented). A value above 2 or so indicates problems in heap.
TYPE—Integer
HEAPFRE2
RNOS—Current amount of free heap (words, one word = 16 bits) memory in
node. Pool 2 only.
TYPE—Real
HEAPFREE RNOS—Current amount of free heap (words, one word = 16 bits) memory in
node. Pool 1 only.
TYPE—Real
HEAPMIN RNOS—Minimum number of words of heap ever reached since node started.
Pool 1 only.
TYPE—Real
HEAPMIN2 RNOS—Minimum number of words of heap ever reached since node stated.
Pool 2 only.
TYPE—Real
HEAPTOT2 RNOS—Heap Pool 2 total amount of heap memory (words, one word = 16
bits).
TYPE—Real

HEAPTOTL RNOS—SYSGENed total amount of heap memory (words) plus section 12

returned memory. Pool 1 only.
Refer to Application Module Implementation Guidelines for a definition of
heap memory.
TYPE—Real
IMPACT Indicates the impact if this node is not reloaded with the latest available
NCF.
TYPE—Integer
0 – Severe
1 – High
2 – Moderate
3 – Insynch if the values of the parameters NEW_NCF and CUR_NCF are
equal.
3 – No impact if the values of the parameters NEW_NCF and CUR_NCF are
not equal.
INS_UNIT Indicates the installation unit. An installation unit is a section of the NCF.
Changes to certain installation units affect certain LCN node types and not
others. This is used to determine which nodes need to be reloaded after an
NCF change.
TYPE—String

MCREV(i) DATA ACCESS—Identifies the time stamp of custom name files in use on
the LCN. Indexes give:
1 ENM_SETS.SE
2 PAR_LIST.SE Time stamp of custom name files in current
3 PARAMETR.SP use on the LCN.
4 SEGMENTS.SP
5 ENM_SETS.SE
6 PAR_LIST.SE Time stamp of custom name files in use at
7 PARAMETR.SP node load time.
8 SEGMENTS.SP
A revision of zero or 1/1/79 indicates a normal empty file, a revision past the
year 2015 indicates a revision mismatch was detected during the load (node
is shown as CNAMEREV or WARNING). Other revision dates are real
revisions and should match closely with the corresponding “last modified”
date of the disk copy of these files on the &ASY volume.
PURPOSE— Identifies the US, AM, and CG custom name files time stamp
in use and when the node was loaded.
TYPE—Date Array
NCF_SYNC Indicates if the NCF has changed.

TYPE—Boolean
NETVERS Indicates the version of the local LCN.

TYPE—Integer
NEW_NCF Indicates the revision of the latest available NCF. Can be used with
parameter IMPACT to determine the impact of an NCF change.
TYPE—Time
NODESTAT(i) RNOS—Provides node’s view of other LCN node states on the LCN. This
array is indexed by LCN physical node number. Possible values are:
NOT_CONF, OFF_NET, PN_ALIVE, LOCAL_BT, NETWK_BT,
UND_TEST, QUALIFID, LOADED, RUNNING, TERMNATE, and
FAILED. Array (1-96)
PURPOSE—Provides LCN consistency check for node isolation and LCN
reconnect functionality.
TYPE—Enumeration array of $PNSTATE.

NODE_NO DATA ACCESS—Gives the integer node number for node.

PURPOSE—Provides integer node number for reference.
TYPE—Integer
NOTE_TIM(i) Indicates the time stamp associated with the last state change of a status
message shown on the Status Detail display. This time array is indexed by
message number.
TYPE—Time
OB_BUILT The total integer number of status messages currently defined in this node.
TYPE—Integer
OB_CMNT(i) Indicates the operator comment associated with a status message shown on
the Status Detail display. This string array is indexed by message number.
TYPE—String
OB_ENTTY(i) Indicates the entity associated with a status message shown on the Status
Detail display. This array is indexed by message number.
TYPE—Entity
OB_NAME(i) Indicates the name of a status message object shown on the Status Detail
display left side. This string array is indexed by message number.
TYPE—String array 0 to 1000.
OB_NOTE(i) Indicates the explanation string associated with the latest state change of a
status message shown on the status detail display right side. This string
array is indexed by message number.
TYPE—String
OB_SCHEM(i) Indicates the name of the schematic that is associated with a status message
shown on the Status Detail display. This string array is indexed by message
number.
TYPE—String

OB_STATE(i) Indicates the latest state of a status message shown on the Status Detail
display. This array (0 to 1000) is indexed by message number. OB_STATE
(0) = NODE STATE.
TYPE—Enumeration of $SASTATE. Values are OK, WARNING,
SEVERE, FAIL.
OSTRANOD(i) RNOS—Indicates if an LCN node is “ISOLATED” or not as viewed by this

node. This BOOLEAN array is indexed by LCN physical node number.
PURPOSE—Provides LCN consistency check for node isolation and LCN
reconnect functionality.
TYPE—Boolean array
PARSEC DATA ACCESS—Parameters/sec rate based on IDB service from any

function set in the physical node during the previous 15 seconds. Indicates
the number of parameters requested from this node to support nodes on
LCN. This parameter has a different meaning in Network Gateways (see
22.7). Actually PARSEC counts how many parameters are flowing through
the LCN Data Access Servers on this node. This is a count from all data
owners in this node (PSDP, UNITOPS, node specific data owner, and so
on.).
RPARSEC and SPARSEC are a count of how many parameters are flowing
through this node’s LCN Data Access Requestor tasks.
So, typically PARSEC counts how many parameters are being served to the
other nodes on the network. RPARSEC and SPARSEC count how many
parameters this node is requesting of other nodes (and of itself).
In the case of the “X-nodes” (AxM, UsX, APP, IN, EST, ESVT, ACE-T).,
requests from the TPN Server go through the DA requestor tasks and affect
the RPARSEC and SPARSEC parameters. If the target data owner is local
to the node, these parameters also affect PARSEC. If the target data owner
is not local, PARSEC is not affected.
PURPOSE—Indicates the load on this node from the system.
TYPE—Real

PFPSHLDB DATA ACCESS—The “hold breath” count since reload or reset based on
the Data Access timeout. A similar name is used in the AM.
PURPOSE—Indicates the difficulty in accessing data in another node due to
the other node’s loading.
TYPE—Real
PTSESTBL DATA ACCESS—Number of process points currently established (loaded)

in the node.
PURPOSE—Indicates the point capacity currently used.
TYPE—Integer
REQUESTS DATA ACCESS—Indicates the number of Data Access parameter requests

(LCN messages) that this node received per second during the previous 15
second period. The units of this parameter are LCN messages per second.
TYPE—Real
RNUMREAD Indicates the number of Data Access parameter requests (LCN messages)
that this node made, per second, that occurred in the previous 15 second
period that contained any reads. The units of this parameter are LCN
messages per second.
TYPE—Real
Indicates the number of Data Access parameter requests (LCN messages)

RNUMSTOR that this node made, per second, that occurred in the previous 15 second
period that contained any stores. The units of this parameter are LCN
messages per second.
TYPE—Real
DATA ACCESS—Read parameters/sec rate based on IDB requests to any

RPARSEC LCN node during previous 15 seconds. Indicates the number of parameters
this node is requesting from other nodes on LCN.
PURPOSE—Indicates the system request load from this node.
TYPE—Real

RREQUEST DATA ACCESS—Indicates the number of Data Access parameter requests

(LCN messages) that this node made, per second, that occurred in the
previous 15 second period. The units of this parameter are LCN messages
per second.
PURPOSE—Indicates the data owner load from this node.
TYPE—Real
SERVTIME DATA ACCESS—Indicates the average time that a Data Access request
(LCN message) took to complete during the previous 15 second period. The
units of this parameter are in milliseconds.
PURPOSE—Indicates the data access processing efficiency.
TYPE—Real, milliseconds
SPARSEC DATA ACCESS—Store parameters/sec rate based on IDB requests to any

LCN function during the previous 15 seconds. Indicates the number of
parameters this node is writing to other nodes on LCN.
PURPOSE—Indicates the system response load from this node.
TYPE—Real

22.3 Application Module PSDP Parameters
Introduction The following PSDP parameters are only in AMs. Refer to the
Application Module Parameter Reference Dictionary for more detailed
information about each parameter including value ranges and value
types.
NOTE: For PSDP parameters for the Application ModuleX (AXM),

see the Application ModuleX User Guide.
Reference Refer to Application Module Implementation Guidelines for further

discussion of the AM PSDP memory-allocation parameters.
$AUTOSAV (R620) CONTROL KERNEL- The auto checkpointing enable/disable status of

this node on the LCN.
PURPOSE- Allows you to read the current status (ENABLE or
DISABLE) of auto checkpointing, and allows you to enable or disable
auto checkpointing.
TYPE- ATTRIB
$CLDAVGC (R650)
CONTROL KERNEL— Average number of AM/CL Process Change
events per second serviced in the current hour.
$CLDAVGP (R650)
events per second serviced in the previous hour.
$CLDAVGS (R650)
events serviced in the last snapshot period (nominally 15 seconds).
$CLDBACT (R650)
CONTROL KERNEL— Activate or inactivate the AM/CL Process
Changes function. Inactivating the AM/CL debugger frees up the
memory.
$CLDBAPT[1..5]
(R650)
CONTROL KERNEL— AM/CL point name filter for AM/CL Process
Changes.

22.3 Application Module PSDP Parameters, Continued
$CLDBBLK[1..5]
(R650)
CONTROL KERNEL— AM/CL block name filter for AM/CL Process
Changes.
$CLDBDPT[1..5]
(R650)
CONTROL KERNEL— Point name portion of the destination point
name/unit name filter pair for AM/CL Process Changes.
$CLDBEHR (R650)
CONTROL KERNEL— Determines if the AM/CL Process Change
events are sent to the HM.
$CLDBEXP[1..5]
(R650)
CONTROL KERNEL— Used to suppress the matching of AM/CL
Process Change parameter ($CLDBPAR).
$CLDBFIL (R650)
CONTROL KERNEL— Indicates if the AM/CL Process Change event
strings are sent to a file.
$CLDBFNM (R650)
CONTROL KERNEL— Pathname to the file that is used for writing
the AM/CL Process Changes when the file output option (parameter
$CLDBFIL) is enabled.
$CLDBFST (R650)
CONTROL KERNEL— Status return code for the File Manager when
the AM encounters an error while it writes the AM/CL Process Changes
output to a file.
$CLDBMEM (R650)
CONTROL KERNEL— Indicates if the AM/CL Process Change
events are sent to the local memory table or not.
$CLDBMTB[1..100]
(R650)
CONTROL KERNEL— Memory table of AM/CL Process Changes
output.
$CLDBOND (R650)
CONTROL KERNEL— Indicates whether or not on-node AM/CL
Process Change events are collected in history.
$CLDBPAR[1..5]
(R650)
CONTROL KERNEL— Destination parameter name filter for AM/CL
Process Changes.

$CLDBPRT (R650)
CONTROL KERNEL— Determines if the AM/CL Process Change
events are sent to the Event Manager (RTJ) for printing or not.
$CLDBSTS (R650)
CONTROL KERNEL— Runtime status for AM/CL Process Change
events.
$CLDBUNT[1..5]
(R650)
CONTROL KERNEL— Unit name portion of the destination point
name/unit name filter pair for AM/CL Process Changes.
$CLDMAXC (R650)
CONTROL KERNEL— Maximum number of AM/CL Process Change
events per cycle serviced in the current hour.
$CLDMAXP (R650)
CONTROL KERNEL— Maximum number of AM/CL Process Change
events per cycle serviced in the previous hour.
$CLDMINC (R650)
CONTROL KERNEL— Minimum number of AM/CL Process Change
events per cycle serviced in the current hour.
$CLDMINP (R650)
CONTROL KERNEL— Minimum number of AM/CL Process Change
events per cycle serviced in the previous hour.
$ROLLATP (R640)
CONTROL KERNEL—Rolling Average Alarm Trip Point
$ROLLPRA (R640)
CONTROL KERNEL—Rolling Average Process Accumulation
ADAVGC
CONTROL KERNEL—Alarms per second in current hour.
ADAVGP
CONTROL KERNEL—Alarms per second in previous hour.
ADAVGS
CONTROL KERNEL—Alarms per second in snapshot period.
ADMAXC
CONTROL KERNEL—Maximum alarms per cycle in current hour.
ADMAXP
CONTROL KERNEL—Maximum alarms per cycle in previous hour.
ADMINC
CONTROL KERNEL—Minimum alarms per cycle in current hour.
ADMINP
CONTROL KERNEL—Minimum alarms per cycle in previous hour.

ALBURST
CONTROL KERNEL—Maximum number of process alarms in any one
second since load or value reset.
PURPOSE—Indicates the peak alarm load from the AM.
TYPE—Integer
AMDATA(i)
CONTROL KERNEL—Internal AM data use only.
AMDATA (54) = 0 for primary AM, = 1 for secondary AM.
AMDATA (48) = an integer that represents the amount of additional
redundancy buffer in use. See AM Implementation Guidelines – Section
8.3.
AMMEMADJ
CONTROL KERNEL—Total user memory heap used from current AM
load configuration.
PURPOSE—Indicates memory usage in the AM.
TYPE—Real
AMMEMAOP
CONTROL KERNEL—Total user memory minus software options
(such as CBREV table size).
PURPOSE—Indicates memory usage in the AM.
TYPE—Real
AMMEMTOT
CONTROL KERNEL—Total AM memory used for point data, CLs,
CDSs, buffers for checkpoint and off-node I/O.
AMOVRABT
CONTROL KERNEL—AM abort trip point for Fast Processor (number
of cycles behind/before node crash). If set to -1, AM will never crash.
AMOVRTHR
CONTROL KERNEL—Alarm trip-point count for Fast Processor
(number of cycles).
AMSCHDMP(i)
CONTROL KERNEL—Dump schedule for unit i.

BKGCLBC
CONTROL KERNEL—Number of background CL blocks unable to be
queued/second in current hour.
PURPOSE—Indicates AM loading.
TYPE—Real
BKGCLBP
queued per second in previous hour.
TYPE—Real
BKGCLBS
queued per second in snapshot period.
TYPE—Real
BKGCLC
CONTROL KERNEL—Number of background CL block run per
second in current hour.
TYPE—Real
BKGCLNR(i)
CONTROL KERNEL—Name of background CL block running as
background task (i).
TYPE—Real
BKGCLP
second in previous hour.
TYPE—Real
BKGCLS
second in snapshot period.
TYPE—Real

BKGDANC CONTROL KERNEL—Number of background CL off node Data

Access requests/sec in current hour.
TYPE—Real
BKGDANP
CONTROL KERNEL—Number of background CL off node Data
Access requests/sec in previous hour.
TYPE—Real
BKGDANS
CONTROL KERNEL—Number of background CL off node Data
Access requests/sec in snapshot period.
TYPE—Real
BKGDAREQ
CONTROL KERNEL—Number of background CL data access
requestors.
TYPE—Real
BKGELTIM(i)
CONTROL KERNEL—Elapsed time (sec) background CL task (i) has
been in the run state.
TYPE—Real
BKGFMC
CONTROL KERNEL—Number of background file manager requests in
the current hour.
TYPE—Real
BKGFMP
the previous hour.
TYPE—Real

BKGFMS
the snapshot period.
PURPOSE—Indicates AM loading
TYPE—Real
BKGPNTRN(i)
CONTROL KERNEL—Point name associated with the CL running as
background task (i).
TYPE—String
BKGQFUL
CONTROL KERNEL—Background queue-full status.
TYPE—Boolean
BKGQTIME
CONTROL KERNEL—Time the last background CL block was in the
queue.
TYPE—Real
BKGQUEUE
CONTROL KERNEL—Number of background CL blocks queued.
TYPE—Real
BKGRUN
CONTROL KERNEL—Number of background tasks active.
TYPE—Real
BKGSTACK
CONTROL KERNEL—Background task stack size assuming
background CL option is used. This is set in the NCF.
BKGTASKS
CONTROL KERNEL—Number of background CL tasks, assuming
background CL option is used.

CDSAVGC
CONTROL KERNEL—CDS parameter accesses per second in current
hour.
CDSAVGP
CONTROL KERNEL—CDS parameter accesses per second in previous
hour.
CDSAVGS
CONTROL KERNEL—CDS parameter accesses per second in snapshot
period.
CLAVGC
CONTROL KERNEL—Average CLs per second in current hour.
CLAVGP
CONTROL KERNEL—Average CLs per second in previous hour.
CLAVGS
CONTROL KERNEL—Average CLs per second in snapshot period.
CLBACKF
CONTROL KERNEL—CL backward-branch limit for fast processor.
CLBACKIP
CONTROL KERNEL—Number of back branches allowed on a CL
block linked to an IPP point.
TYPE—Integer
CLBACKS
CONTROL KERNEL—CL backward-branch limit for slow processor.
CLMAXC
CONTROL KERNEL—Maximum CLs per second in current hour.
CLMAXP
CONTROL KERNEL—Maximum CLs per second in previous hour.
CLMINC
CONTROL KERNEL—Minimum CLs per second in current hour.
CLMINP
CONTROL KERNEL—Minimum CLs per second in previous hour.
CLPZAVGC(i)
CONTROL KERNEL—Average size of clean point in current hour for
each possible clean point in words; secondary only.
CLPZAVGP(i)
CONTROL KERNEL—Average size of clean point in previous hour for
each possible clean point in words; secondary only.
CLPZMX(i)
CONTROL KERNEL—Maximum size of a clean point in words for
each possible clean point since the last startup or resynch of AM;
secondary only.
CLPZMXC(i)
CONTROL KERNEL—Maximum size of a clean point in current hour
for each possible clean point; secondary only.
CLPZMXP(i)
CONTROL KERNEL—Maximum size of a clean point in previous hour
for each possible clean point; secondary only.

CLPZS(i) CONTROL KERNEL—Size of most recent clean point in words for

each possible clean point; secondary only.
CLPZSP(i) CONTROL KERNEL—Size of previous (second most recent) clean

point in words for each possible clean point; secondary only.
CPFMERR CONTROL KERNEL—Last checkpoint file manager error. The value

51 means no error.
CPTIMEC(i) CONTROL KERNEL—Time to checkpoint unit (i).
CPTIMEFL CONTROL KERNEL—Time (minute) to checkpoint all AM units to

disk.
CPTIMEHM CONTROL KERNEL—Time (minute) to checkpoint all AM units to the

HM.
CSCODE CONTROL KERNEL—Total code size of custom packages loaded.
CSHEAPC CONTROL KERNEL—Current Pool 1 heap used by loaded custom

packages.
TYPE—Real
CSHEAPMX CONTROL KERNEL—Maximum Pool 1 heap used by custom

packages since node loaded.
CSHEAPT CONTROL KERNEL—Total Pool 1 heap limit for custom packages

loaded.
CVBAVGS CONTROL KERNEL—Average current value buffer memory used per

cycle during snapshot period.
DIAGSTAT AM ANALYSIS—For R510. A Boolean that indicates the diagnostic

collection status of the following parameters: MAXFPTNM,
MAXSPTNM, MAXCLNM. TRUE means collection is enabled.
FALSE (default) means collection is disabled. NOTE: This is a high
cost activity; enable collection for short study periods only. See other
AM ANALYSIS parameters in this section.

CONTROL KERNEL—Average point process specials (PPS) per cycle in

EIPAVGC
current hour. Note: If you observe a negative number, then the AM/CLM is
averaging more than nine PPSs per second and exceeded the maximum
integer value of 32,767 (9*60*60=32,400 per hour).
CONTROL KERNEL—Average point process specials (PPS) per cycle in

EIPAVGP
previous hour. Note: If you observe a negative number, then the AM/CLM is
CONTROL KERNEL—Average point process specials (PPS) per cycle in a

EIPAVGS
snapshot period. Note: If you observe a negative number, then the AM/CLM
is averaging more than nine PPSs per second and exceeded the maximum
EIPMAXC CONTROL KERNEL—Maximum point process specials (PPS) per cycle in

EIPMAXP CONTROL KERNEL—Maximum point process specials (PPS) per cycle in

EIPMINC CONTROL KERNEL—Minimum point process specials (PPS) per cycle in

EIPMINP CONTROL KERNEL—Minimum point process specials (PPS) per cycle in

FPTMAVGC CONTROL KERNEL—Average duration (milliseconds) of processing for

Fast Point Processor in the current hour; secondary only.

CONTROL KERNEL—Average duration (milliseconds) of processing for

FPTMAVGP
Fast Point Processor in the previous hour; secondary only.
FPTMS CONTROL KERNEL—Duration (milliseconds) of processing for Fast Point

Processor for the most recently completed FPP cycle; secondary only.
FPTMSP CONTROL KERNEL—Duration (milliseconds) of processing for Fast Point

Processor for the previous (second most recently completed) FPP cycle;
secondary only.
GETAVGC CONTROL KERNEL—Average non-CDS parameter fetches per second in

current hour (from this AM). Note: These are internal requests from this AM
to itself that do not go through data access; however, it also includes fast
CDS accesses if AMCL04 is loaded. By contrast, PARSEC counts
parameters that go through data access.
GETAVGP CONTROL KERNEL—Average non-CDS parameter fetches per second in

previous hour (from this AM). Note: These are internal requests from this
AM to itself that do not go through data access; however, it also includes fast
GETAVGS CONTROL KERNEL—Average non-CDS parameter fetches per second in

snapshot period (from this AM). Note: These are internal requests from this
AM to itself that do not go through data access; however, it also includes fast
HEAPMAXP CONTROL KERNEL—Maximum heap for permanent memory data.

IDLAVGC CONTROL KERNEL—Average idle time (%) in current hour.
IDLAVGP CONTROL KERNEL—Average idle time (%) in previous hour.
IDLAVGS CONTROL KERNEL—Average idle time (%) in snapshot period.
IDLAVGSP CONTROL KERNEL—Average idle time (%) in previous snapshot period.
TYPE—Real
CONTROL KERNEL—CVB overflow count for current hour.

IPCVBOVC
PURPOSE—Indicates capacity being pushed near limit.
TYPE—Integer

IPCVBOVP CONTROL KERNEL—CVB overflow count for previous hour.

TYPE—Integer
CONTROL KERNEL—Prefetch/poststore overruns, dynamic.

IPDAOVER
TYPE—Integer
IPDAOVRC CONTROL KERNEL—Prefetch/poststore overruns, dynamic,

increment/decrement for current hour.
TYPE—Integer
IPDAOVRP CONTROL KERNEL—Prefetch/poststore overruns, dynamic,

increment/decrement for previous hour.
TYPE—Integer
IPOVRRNC CONTROL KERNEL—IPP overruns in current hour.

TYPE—Integer
IPOVRRNP CONTROL KERNEL—IPP overruns in previous hour.

TYPE—Integer
IPOVRRUN CONTROL KERNEL—IPP overrun count expressed as a difference

between system cycles and IPP processing cycles.
TYPE—Integer
IPOVRTHR CONTROL KERNEL—IPP overrun alarm threshold. -1 = stop.

PURPOSE—Allows setting a different alarming limit.
TYPE—Integer
IPPFAVGC CONTROL KERNEL—Average number of prefetches per second from

IPP in this hour.
PURPOSE—Indicates IPP load in node.
TYPE—Real

IPPFAVGP CONTROL KERNEL—Average number of prefetches per second from

IPP in previous hour.
TYPE—Real
IPPFAVGS CONTROL KERNEL—Average snapshot period IPP prefetchs per

second.
TYPE—Real
IPPFMAXC CONTROL KERNEL—Maximum number of IPP prefetches per cycle in

current hour.
TYPE—Integer
IPPFMAXP CONTROL KERNEL—Maximum number of IPP prefetches per cycle in

previous hour.
TYPE—Integer
IPPRAVGP CONTROL KERNEL—Average number of IPP points per second in

previous hour.
TYPE—Real
IPPRAVGS CONTROL KERNEL—Average snapshot IPP points per second.

TYPE—Real
IPPRCYCC CONTROL KERNEL—Number of IPP processing cycles lost in this hour.

TYPE—Integer
IPPRCYCP CONTROL KERNEL—Number of IPP processing cycles lost in last hour.

TYPE—Integer
IPPRMAXC CONTROL KERNEL—Maximum number of IPP points per cycle this

hour.
TYPE—Integer

IPPRMAXP CONTROL KERNEL—Maximum number of IPP points per cycle last

hour.
TYPE—Integer
IPPSAVGC CONTROL KERNEL—Average number of IPP stores per second this

hour.
TYPE—Real
IPPSAVGP CONTROL KERNEL—Average number of IPP stores per second last

hour.
TYPE—Real
IPPSAVGS CONTROL KERNEL—Average number of IPP snapshot stores per

second.
TYPE—Real
IPPSMAXC CONTROL KERNEL—Maximum number of IPP stores per cycle this

hour.
TYPE—Integer
IPPSMAXP CONTROL KERNEL—Maximum number of IPP stores per-cycle last

hour.
TYPE—Integer
LAST_CLB AM ANALYSIS—For R510. The name of the CL block last executed in

the foreground. A string of 8 characters. Default value is blanks. NOTE:
Array of string parameters can be read from foreground CL programs (not
background). This is existing functionality. See other AM ANALYSIS
parameters in this section.
LAST_ENT AM ANALYSIS—For R510. The name of the entity last processed by the
fast or slow point processors. A string length of 16 characters. Default
value is blanks. See other AM ANALYSIS parameters in this section.

MAXCLNM AM ANALYSIS—For R510. The names of the last two slowest CL block
names. A string length of 55 characters. Default value is blanks. See other
AM ANALYSIS parameters in this section.
MAXFPTNM AM ANALYSIS—For R510. The names of the last two slowest entities
detected on the fast point processor. A string length of 33 characters.
Default value is blanks. See other AM ANALYSIS parameters in this
section.
MAXSPTNM AM ANALYSIS—For R510. The names of the last two slowest entities
detected on the slow point processor. A string length of 33 characters.
Default value is blanks. See other AM ANALYSIS parameters in this
section.
MCVBAVGC CONTROL KERNEL—Average current value buffer memory used per
cycle during current hour.
MCVBAVGP CONTROL KERNEL—Average current value buffer memory used per
cycle during previous hour.
MCVBMAXC CONTROL KERNEL—Maximum current value buffer memory used per
MCVBMAXP CONTROL KERNEL—Maximum current value buffer memory used per
MCVBMINC CONTROL KERNEL—Minimum current value buffer memory used per
MCVBMINP CONTROL KERNEL—Minimum current value buffer memory used per
MCVBMNCC CONTROL KERNEL—Cycle for minimum current value buffer memory
used during current hour.
MCVBMNCP CONTROL KERNEL—Cycle for minimum current value buffer memory
used during previous hour.
MCVBMXCC CONTROL KERNEL—Cycle for maximum current value buffer memory
used during current hour.
MCVBMXCP CONTROL KERNEL—Cycle for maximum current value buffer memory
used during previous hour.
MEMADJNX CONTROL KERNEL—Change (delta) in AM user memory heap for next
AM load based on NCF configuration.
TYPE—Real

MEMCDPN(i) CONTROL KERNEL—Memory required for unit (i) CDS and point name
storage.
MEMCKPT CONTROL KERNEL—Memory used for checkpoint.
MEMCL(i) CONTROL KERNEL—Memory required for unit(i) CL blocks.
MEMCS(i) CONTROL KERNEL—User memory usage by all custom packages on a
per unit basis.
MEMCVBLM CONTROL KERNEL—Size of CVBs at last AM start.
MEMCVBMX CONTROL KERNEL—Largest amount of memory used by a CVB since
the AM was last started.
MEMCVBNX CONTROL KERNEL—Sets size of CVBs on startup.
MEMCVBTH CONTROL KERNEL—CVB alarm threshold.
MEMFREE CONTROL KERNEL—Free memory for point data, CLs, CDSs,
checkpoint, and off node buffers.
MEMIOLM CONTROL KERNEL—Memory reserved for prefetch, poststore buffers.
MEMPTS(i) CONTROL KERNEL—Memory required for unit (i) point storage.
MIPCVBLM CONTROL KERNEL—IPP memory reserved the CVB.
TYPE—Integer
MIPCVBMX CONTROL KERNEL—Maximum CVB memory used by IPP since load.
TYPE—Integer
MIPIOTOT CONTROL KERNEL—IPP fetch/store memory reserved.
TYPE—Real
MSAVGC CONTROL KERNEL—CL messages per second serviced in current hour.
MSAVGP CONTROL KERNEL—CL messages per second serviced in previous
hour.
MSAVGS CONTROL KERNEL—CL messages per second serviced in snapshot
period.

MSMAXC CONTROL KERNEL—Maximum CL messages per cycle serviced in

current hour.
MSMAXP CONTROL KERNEL—Maximum CL messages per cycle serviced in
previous hour.
MSMINC CONTROL KERNEL—Minimum CL messages per cycle serviced in
current hour.
MSMINP CONTROL KERNEL—Minimum CL messages per cycle serviced in
previous hour.
NUMPTS(i) CONTROL KERNEL—Number of unit (i) points.
OVERRUNS CONTROL KERNEL—Number of fast processor cycle overruns currently
behind. A small negative number (-1 or -2) is sometimes seen in this value.
This value may be interpreted to mean zero overruns.
OVRFASTC CONTROL KERNEL—Number of fast processor cycle overruns in current
hour.
OVRFASTP CONTROL KERNEL—Number of fast processor cycle overruns in
previous hour.
OVRSLOWC CONTROL KERNEL—Number of slow processor cycle overruns in
current hour.
OVRSLOWP CONTROL KERNEL—Number of slow processor cycle overruns in
previous hour.
PFAVGC CONTROL KERNEL—Average number of prefetches per second in
current hour.
PFAVGP CONTROL KERNEL—Average number of prefetches per second in
previous hour.
PFAVGS CONTROL KERNEL—Average number of prefetches per second in
snapshot period.
PFMAXC CONTROL KERNEL—Maximum number of prefetches per cycle in
current hour.
PFMAXP CONTROL KERNEL—Maximum number of prefetches per cycle in
previous hour.
PFMINC CONTROL KERNEL—Minimum number of prefetches per cycle in
current hour.
PFMINP CONTROL KERNEL—Minimum number of prefetches per cycle in
previous hour.

PFMNCYCC CONTROL KERNEL—Cycle in current hour when prefetches minimum.

PFMNCYCP CONTROL KERNEL—Cycle in previous hour when prefetches minimum.
PFMXCYCC CONTROL KERNEL—Cycle in current hour when prefetches maximum.
PFMXCYCP CONTROL KERNEL—Cycle in previous hour when prefetches
maximum.
PFPSHLDC CONTROL KERNEL—Number of times control processing “held its
breath” for 5 second during current hour.
PFPSHLDP CONTROL KERNEL—Number of times control processing “held its
breath” for 5 second during previous hour. See also PFPSHLDB in section
22.2.
PFPSHLDT CONTROL KERNEL—“Hold Breath” alarm limit. The initial value is 5. If
the value is above 5 in an hour, there is a warning.
PFPSOVER CONTROL KERNEL—Current prefetch/poststore overrun count. It adds
one to its count for each time a Prefetch/poststore is not completed within
½ second. It decements one for each time a prefetch/poststore is
completed.within ½ second (with lower bound of 0).
PFPSOVRC CONTROL KERNEL—Total prefetch/poststore overrun count in current
hour. It adds one to its count for each time a Prefetch/poststore is not
completed within ½ second. It decements one for each time a
prefetch/poststore is completed within ½ second (with lower bound of 0).
PFPSOVRP CONTROL KERNEL—Total prefetch/poststore overrun count in previous
hour. It adds one to its count for each time a Prefetch/poststore is not
completed within ½ second. It decements one for each time a
prefetch/poststore is completed within ½ second (with lower bound of 0).
PRAVGC CONTROL KERNEL—Average points per second in current hour.
PRAVGP CONTROL KERNEL—Average points per second in previous hour.
PRAVGS CONTROL KERNEL—Average points per second in snapshot period.
PRCSTATE CONTROL KERNEL—Processor state.
PRMAXC CONTROL KERNEL—Maximum points per cycle in current hour.
PRMAXP CONTROL KERNEL—Maximum points per cycle in previous hour.
PRMINC CONTROL KERNEL—Minimum points per cycle in current hour.
PRMINP CONTROL KERNEL—Minimum points per cycle in previous hour.
PRMNCYCC CONTROL KERNEL—Cycle in current hour when the minimum number
of points per second was processed.

PRMNCYCP CONTROL KERNEL—Cycle in previous hour when the minimum

number of points per second was processed.
PRMXCYCC CONTROL KERNEL—Cycle in current hour when the maximum number
of points was processed.
PRMXCYCP CONTROL KERNEL—Cycle in previous hour when the maximum
number of points was processed.
PROCTYPE CONTROL KERNEL—Type of CPU in AM (1=68040, 2=68020).
PROUNT(i) CONTROL KERNEL—Process unit (i) exists flag.
PSAVGC CONTROL KERNEL—Average number of poststores per second in
current hour.
PSAVGP CONTROL KERNEL—Average number of poststores per second in
previous hour.
PSAVGS CONTROL KERNEL—Average number of poststores per second in
snapshot period.
PSMAXC CONTROL KERNEL—Maximum number of poststores per cycle in
current hour.
PSMAXP CONTROL KERNEL—Maximum number of poststores per cycle in
previous hour.
PSMINC CONTROL KERNEL—Minimum number of poststores per cycle in
current hour.
PSMINP CONTROL KERNEL—Minimum number of poststores per cycle in
previous hour.
PSMNCYCC CONTROL KERNEL—Cycle in current hour when the minimum number
of poststores occurred.
PSMNCYCP CONTROL KERNEL—Cycle in previous hour when the minimum number
PSMXCYCC CONTROL KERNEL—Cycle in current hour when the maximum number
PSMXCYCP CONTROL KERNEL—Cycle in previous hour when the maximum
number of poststores occurred.
REDBFMIN CONTROL KERNEL—Minimum redundancy buffer space available in
words since the last startup or resynchronization; Secondary AM only.
REDBFZ CONTROL KERNEL—Redundancy buffer size in words; Secondary AM
only. The base value is 122,880.

REDCONFG CONTROL KERNEL—Indicates, when true, that this AM is configured for

redundancy.
REDINOP CONTROL KERNEL—Indicates, when true, that this AM is operating in

redundant mode.
REDTRAP CONTROL KERNAL—Hex address, as a string, for a bad instruction trap

to be used if trigger code has been set to REDTRIP: Secondary AM only.
REDTRIP CONTROL KERNEL—Special test function. Used to initiate special trap

function and test functionality; Secondary AM only.
RESRVMEM Reserved memory. Memory reserved for future options. For information,
refer to 7.2 in AM Implementation Guidelines.
RESYNCS(N) CONTROL KERNEL—Indicates the number of resynchronizations since

start up for each possible cause of resynch. Reasons (n=):
1. Total number of resynchronizations

2. Redundant bus parity
3. Insufficient room
4. Clean point too large
5. Transient backdoor failure
6. Transient LCN failure
Note : This is an array of 10 elements, but only the first 6 are used.
SFWRERR CONTROL KERNEL—Last detected software error code.
SNAPTIME CONTROL KERNEL—Period (sec) for snapshot averages.

STACKADD CONTROL KERNEL—Maximum additional stack size of all custom
packages loaded. This amount is added to FPP and SPP runtime stack sizes.
STRAVGC CONTROL KERNEL—Average stores per second in current hour.
STRAVGP CONTROL KERNEL—Average stores per second in previous hour.
STRAVGS CONTROL KERNEL—Average stores per second in snapshot period.
TIMEDOWN(I) CONTROL KERNEL—Seconds unit (i) was down before last startup.

TMEMCDPN CONTROL KERNEL—Total memory used for CDS descriptors and point
names.
TMEMCL CONTROL KERNEL—Total memory used for CL.
TMECS CONTROL KERNEL—Total user memory used by all custom packages

loaded.
TMEMPTS CONTROL KERNEL—Total memory used for point data.
UNMEMTOT(I) CONTROL KERNEL—Total memory for unit (i) point data, CL, and CDS.

22.4 Computer Gateway PSDP Parameters
$AUTOSAV (R620) CG FUNCTIONS- The auto checkpointing enable/disable status of

this node on the LCN.
DISABLE) of auto checkpointing, and allows you to enable or
disable auto checkpointing.
TYPE- ATTRIB
$CGINGR (n)
CG FUNCTIONS—General configuration and data holding parameter
for debug. Indexed where:
• n = 1 for number of seconds between time synch messages.
• n = 2 for maximum seconds for host to confirm message.
• n = 3 controls form of floating point conversion.
• n = 4 selects baud rate for link.
• n = 5 selects bisynch or HDLC_LAPB protocol.
• n = 6 for number of links.
• n = 7 selects primary/secondary mode of operation.
• n = 8 for number of times ENQ sent before link failed.
• n = 9 for number of times NAK sent before link failed.
• n = 10 for selection of station ID.
• n = 11 for time delay between messages.
• n = 12 to set number of HDLC retrys.
PURPOSE—Supplies configuration, load, and debug data.
TYPE—Integer array
$CGSTRNG (n)
CG FUNCTIONS—General configuration descriptions. Index of 1
supplies 40 character configuration title.
PURPOSE—Supplies configuration and debug descriptions.
TYPE—String array

22.4 Computer Gateway PSDP Parameters, Continued
ACPRATE CG FUNCTIONS—Number of ACP turn-on messages/minute during the

last 1 minute sample period.
PURPOSE—Indicates the parameter store load from this node.
TYPE—Real
DDTGRAT(i) CG Functions—Data Definition Tables parameters/sec “get” rate based
on number of DDT get requests from the ULP. Index 1 is for rate during
the last full 1 minute sample period. Index 2 is for the rate over the
previous 1 minute sample period.
Purpose—Indicates the CM-60/50 load on the LCN.
Type—Real
DDTSRAT(i) CG FUNCTIONS—Data Definition Tables parameters per minute “store”
rate based on number of DDT store requests to the ULP. Index 1 is for
rate during the last full 1 minute sample period. Index 2 is for the rate
over the previous 1 minute sample period.
PURPOSE—Indicates the CM-60/50 load on the LCN.
TYPE—Real
DL1_STS CG Functions—Current status of data link #1.
DL2_STS CG Functions—Current status of data link #2.
GHISTRT(i) CG Functions—Get History Rate—GETHIS parameters/sec rate based on
number of GETHIS value requests from the ULP with outage, time
change, and start of definition records in count. Index 1 is for rate during
the last full 1 minute sample period. Index 2 is for the rate over the
previous 1 minute sample period.
Purpose—Indicates HM history access load by the CM-60/50.
Type—Real

GPARGRT(i) CG FUNCTIONS—Single point parameters per minute “get” rate based on

number of single point parameter get requests from the ULP. Index 1 is for
the parameter rate during the last full 1-minute sample period. Index 2 is
for the rate over the previous 1-minute sample period. Index 3 is for the
element rate during the last full 1-minute sample period. Index 4 is for the
rate over the previous 1-minute sample period.
PURPOSE—Indicates the CM-60/50 load on the LCN.
TYPE—Real
GPARSRT(n) CG FUNCTIONS—Single point parameters/sec “store” rate based on
number of single point parameter store requests from the ULP. Index 1 is
for the parameter rate during the last full 1-minute sample period. Index 2
is for the rate over the previous 1-minute sample period. Index 3 is for the
element rate during the last full 1-minute sample period. Index 4 is for the
rate over the previous 1-minute sample period.
PURPOSE—Indicates the CM-60/50 load on a node or nodes.
TYPE—Real
NMACIDP CG FUNCTIONS—Number of ACIDP points currently built.
PURPOSE—Indicates the capacity used of the 250 possible.
TYPE—Integer
NMCRDP CG Functions—Number of CRDP points currently built.
Purpose—Indicates the capacity used of the 250 possible.
TYPE—Integer

RECVRAT (n) CG FUNCTIONS—Rate per minute of data transfers from ULP to CG.
Indexed where:
• n = 1 for number of words.
• n = 2 for number of blocks.
• n = 3 for number of messages.
Rate per second is calculated over a 1-minute sample period.
PURPOSE—Indicates the link utilization or load.
TYPE—Real
UDSIPRAT(n) CG FUNCTIONS—Rate per minute of data transfers to CG from US for
user displays. Indexed where:
• n = 1 for number of words per second.
• n = 2 for number of blocks per second.
• n = 3 for number of messages per second.
PURPOSE—Indicates the operator display load.
TYPE—Real
UDSOPRAT(n) CG FUNCTIONS—Rate per minute of output data transfers to US from
CG for user displays. Indexed where:
• n = 1 for number of words per second.
• n = 2 for number of blocks per second.
• n = 3 for number of messages per second.
PURPOSE—Indicates the operator display load.
TYPE—Real

ULT_STS CG FUNCTIONS—Current status of ULP processor

XMITRAT(n) CG FUNCTIONS—Rate per minute of data transfers from CG to ULP.
Indexed where:
• n = 1 for number of words.
• n = 2 for number of blocks.
• n = 3 for number of messages.
PURPOSE—Indicates the link utilization or load.
TYPE—Real

22.5 History Module PSDP Parameters
$HISTCOL (R620) HM FUNCTIONS – Allows you to read the current status

(enable/disable) of history collection for this HM node on the LCN,
and also allows you to enable or disable history collection for the
HM node.
TYPE - ATTRIB
CHCYCAV(i) HM FUNCTIONS—Average continuous history collection cycle

time (seconds) per type of history for the last hour. This is the time
for all nodes with type to respond to the history request.
1 60 second average collection time.
PURPOSE—Indicates the response time for gathering history.
TYPE—Real array
CHCYCMN(i) HM FUNCTIONS—Minimum continuous history collection cycle

1 60 second minimum collection time.
TYPE—Real array

22.5 History Module PSDP Parameters, Continued
CHCYCMX(i) HM FUNCTIONS—Maximum continuous history collection cycle

1 60 second maximum collection time.
TYPE—Real array
CHWATAV(i)
HM FUNCTIONS—Average continuous history wait time (waiting
for the minute synch) for each type collection cycle for the last hour.
1 60 second average wait time.
PURPOSE—This value indicates the amount of free time the
continuous history function has each minute. This is the total time
spent collecting and processing the last history type data.
TYPE—Real array
CHWATMN(i) HM FUNCTIONS—Minimum continuous history wait (free) time

for history type during the last hour.
1 60 second minimum wait time.
continuous history function has each minute. This value may be
negative and is indicative of the total time spent collecting and
processing the last minute’s history type data.
TYPE—Real array

CHWATMX(i) HM FUNCTIONS—Maximum continuous history wait (free) time

for history type during the last hour.
1 60 second maximum wait time.
continuous history function has each minute. This value may be
negative and is indicative of the total time spent collecting and
processing the last history type data.
TYPE—Real array
HMVOLNAM(i) HM FUNCTIONS—Array of configured volume names and virtual

device names (such as WR01, WR12).
1 to 15 fifteen virtual volume names drive 0 or 5.
16 to 30 fifteen virtual volume names drive 1 or 4.
31 to 45 fifteen virtual volume names drive 3.
46 to 60 fifteen virtual volume names drive 2.
61 to 75 fifteen virtual device names drive 0 or 5.
76 to 90 fifteen virtual device names drive 1 or 4.
91 to 105 fifteen virtual device names drive 3.
106 to 120 fifteen virtual device names drive 2.
PURPOSE—Provides name list for HM disk configuration.
TYPE—Array of string
NMCHPTS(i) HM FUNCTIONS—Number of history points currently loaded in

continuous history groups indicated:
1. 60 second point count.
5. Total count of all history groups loaded.
PURPOSE—Indicates the history capacity used.
TYPE—Integer array

NODENUM HM FUNCTIONS—Identifies the node currently being

checkpointed.
PURPOSE—Allows monitoring of checkpoint operation.
TYPE—Integer
TIMEBASE (n) HM FUNCTIONS—Provides data on checkpoint operation. For n=:

6. checkpoint period.
7. checkpoint offset.
8. last checkpoint elapsed time.
9. next checkpoint start time.
PURPOSE—Allows monitoring the HM checkpoint operation.
TYPE—Array of date/time
Note: Date/time data type is not directly useable in schematics.
CHKPTIME display has special handling for proper display and
operation.

22.6 Hiway Gateway PSDP Parameters
Only used for HGs

The following PSDP parameters are only in HGs.
Reference
See Hiway Gateway Parameter Reference Dictionary that
provides more detailed information about each parameter
including value ranges and value types.
$AUTOSAV (R620) HG FUNCTIONS- The auto checkpointing enable/disable status

of this node on the LCN.
TYPE - ATTRIB
$BXRSTRP (R680) HG FUNCTIONS – ENABLE/INHIBIT the system alarm.
PURPOSE – Allows you to select between the two options,
ENABLE/INHIBIT. The ENABLE option annunciates the system
alarm, when the Hiway box state changes are caused by the point
load or change of address related parameters of DHP or PIU. The
INHIBIT option, suppresses the system alarm, when the Hiway
box state changes are caused by the point load or change of
address related parameters of DHP or PIU. This value is read
from the SYSTEM ALARM ON DHP/PIU POINT LOAD option
of NCF when HG is rebooted. The user can redefine the value.
TYPE – Enumeration
DEFAULT – ENABLE
$EIPMAXC (R660) HG FUNCTIONS –The maximum number of EIP events in any

one second in the current hour.
PURPOSE - Indicates the loading on HG with respect to Event
Initiated Processing.
TYPE – Integer
$EIPMAXP (R660) HG FUNCTIONS –The maximum number of EIP events in any

one second in the previous hour.
TYPE – Integer

22.6 Hiway Gateway PSDP Parameters, Continued
$EIPTOTC (R660) HG FUNCTIONS –The total number of EIP events sent to the
LCN in the current hour.
TYPE – Real
$EIPTOTP (R660) HG FUNCTIONS –The total number of EIP events sent to the
LCN in the previous hour.
TYPE – Real
$EIPTOTS (R660) HG FUNCTIONS –The total number of EIP events sent to the
LCN in the previous 15 seconds.
TYPE – Real
$EVTMAXC (R660) HG FUNCTIONS –The maximum number of events in any one

second during the current hour.
PURPOSE - Indicates the loading on HG with respect to the
processing of all events and alarms.
TYPE – Integer
$EVTMAXP (R660) HG FUNCTIONS –The maximum number of events in any one

second during the previous hour.
TYPE – Integer
$EVTTOTC (R660) HG FUNCTIONS –The total number of events sent to the LCN in
the current hour.
TYPE – Real

$EVTTOTP (R660) HG FUNCTIONS –The total number of events sent to the LCN in
the previous hour.
TYPE – Real
$NODMAXC (R660) DATA ACCESS - Maximum number of node data access in any
one second in the current hour.
PURPOSE - Indicates the loading on HG due to the processing of
data access requests that has resulted in a Hiway read or store.
TYPE – Integer
$NODMAXP (R660) DATA ACCESS - Maximum number of node data accesses in the
current hour.
PURPOSE - Indicates the loading on HG because of the
processing of data access requests that have resulted in Hiway
reads or stores.
TYPE – Integer
$NODTOTC (R660) DATA ACCESS - Maximum number of node data accesses in the
current hour.
reads or stores.
TYPE – Real
$NODTOTP (R660) DATA ACCESS - Total number of node data accesses in the
previous hour.
reads or stores.
TYPE - Real
$NODTOTS (R660) DATA ACCESS - Total number of node data accesses in the last
15 seconds.
reads or stores.
TYPE – Real

$OPOVRC (R640) HG FUNCTIONS –The number of overruns in the current hour.

PURPOSE - Indicates that the OP alarm scanning task did not
complete a cycle within the OP alarm scan period specified by
$OPSNPRD (use $HIWAYxx.$OPSNPRD). It's also available
through the HG Node Status display at the bottom: HWY ALM
ENB/DIS.
TYPE—Real
NOTE: The OP alarm scanning task will not stop the current cycle
even if it overruns until it completes the cycle. The value in
$OPOVRC can be reset by disabling the OP alarm function.
$OPOVRP (R640) HG FUNCTIONS – The number of overruns in the previous hour.

PURPOSE – Indicates that the OP alarm scanning task did not
$OPSNPRD.
TYPE—Real
$OPOVRP can be reset by disabling the OP alarm function.
$OPOVRUN (R640) HG FUNCTIONS – The cumulative total of OP overruns detected

during the OP alarm-scanning task.
PURPOSE – Indicates that the OP alarm scanning task did not
$OPSNPRD.
TYPE – REAL
$OPOVRUN can be reset by disabling the OP alarm function.
$PARMAXC (R660) DATA ACCESS – The maximum parameter access rate in any
one- second in the current hour.
PURPOSE – Indicates the loading on HG because of the
reads or stores.
TYPE – Integer

$PARMAXP (R660) DATA ACCESS – The maximum parameter access rate in any
one-second during the previous hour.
reads or stores.
TYPE – Integer
$PARSECC (R660) DATA ACCESS – The parameter access rate (running average per
second) in the current hour.
reads or stores.
TYPE – Real
$PARSECP (R660) DATA ACCESS – The parameter access rate (overall average per
second) in the previous hour.
reads or stores.
TYPE – Real
$PRCMAXC (R660) HG FUNCTIONS –The maximum number of process alarms in

any one second in the current hour.
PURPOSE – Indicates the loading on HG with respect to the
processing of process alarms and sequence of events.
TYPE – Integer
$PRCMAXP (R660) HG FUNCTIONS –The maximum number of process alarms in

any one second in the previous hour.
PURPOSE – Indicates the loading on HG with respect to the
TYPE – Integer
$PRCTOTC (R660) HG FUNCTIONS –The total number of process alarms sent to the
TYPE – Real

$PRCTOTP (R660) HG FUNCTIONS –The total number of process alarms sent to

the LCN in the previous hour.
TYPE – Real
$PRCTOTS (R660) HG FUNCTIONS –The total number of process alarms sent to

the LCN in the previous 15 seconds.
TYPE – Real
$RDAVGC (R660) DATA ACCESS – The parameter read rate (running average per
second) in the current hour.
processing of data-access read requests.
TYPE – Real
$RDAVGP (R660) DATA ACCESS – The parameter read rate (overall average per
second) in the previous hour.
TYPE – Real
$RDAVGS (R660) DATA ACCESS – The parameter read rate (per second) in the
last 15 seconds.
TYPE – Real
$RDMAXC (R660) DATA ACCESS – The maximum number of parameters that

have been read in any one second in the current hour.
TYPE – Real
$RDMAXP (R660) DATA ACCESS – The maximum number of parameters that

have been read in any one second in the previous hour.
TYPE – Integer

$SEQMAXC (R660) HG FUNCTIONS –The maximum number of sequence

events/messages in any one second in the current hour.
processing of sequence events and CL messages.
TYPE – Integer
$SEQMAXP (R660) HG FUNCTIONS –The maximum number of sequence

events/messages in any one second in the previous hour.
TYPE – Integer
$SEQTOTC (R660) HG FUNCTIONS –The maximum number of sequence

events/messages sent to the LCN in the current hour.
TYPE – Real
$SEQTOTP (R660) HG FUNCTIONS –The maximum number of sequence

events/messages sent to the LCN in the previous hour.
TYPE – Real
$SEQTOTS (R660) HG FUNCTIONS –The maximum number of sequence

events/messages sent to the LCN in the previous 15 seconds.
TYPE – Real
$STRMAXC (R660) DATA ACCESS –The maximum number of parameters stored in

any one second in the current hour.
processing of requests for data-access stores.
TYPE – Integer

$STRMAXP (R660) DATA ACCESS –The maximum number of parameters stored in

any one second in the previous hour.
TYPE – Integer
ALBURST The maximum number of events that has occurred in any one
second since the HG was loaded or the parameter was reset by the
operator. Event types included in this count are the same as for
EVTRATE.
TYPE – Integer
BOXBUFFS(i) HG FUNCTIONS—The number of change and alarm buffers for

box (i).
PURPOSE—Indicates the HG/Hiway load due to AM/US actions.
TYPE—Real
BXACCESS(i) HG FUNCTIONS—The number of accesses per second to Hiway

address (i) based on the 15 second sample rate of DHI board data.
PURPOSE—Indicates the load level on the Hiway.
TYPE—Real
CPTIMEFL (R660) The time required to checkpoint to a drive.

PURPOSE - The parameter indicates the time taken for the last
checkpoint, initiated either through System Status Display or by
auto-checkpointing.
TYPE – Real

CPTIMEHM The time required to checkpoint to an HM.

(R660) PURPOSE - Indicates the loading on HG with respect to checkpointing.
The parameter indicates the time taken for the last checkpoint, initiated
either through System Status Display or by auto-checkpointing.
TYPE – Real
DHMSGSEC(i) DATA ACCESS—The number of messages per second sent to 1 of 5 data
handler streams. Message requests entering HGs are split into 5 parallel
queues of differing priority, depending on the requesting function. The
queue with index 1 is the highest priority queue and queue 5 is the lowest
priority queue. This parameter represents the average number of messages
per second flowing through a particular queue during the last 15 second
period.
Queue 1—HG internal operations and operator changes.
Queue 2—CG and AM control actions.
Queue 3—history gathering and display call ups, including demand updates
after a change from a display.
Queue 4—trends, normal display updates, and tools and friendly display
queries.
Queue 5—point build, slow updates, SMCC access, and organizational
summaries.
These are displayed in the PERFMENU schematic HGDETAIL (R660).
PURPOSE—Indicates internal load on DA queues and handlers.
TYPE—Real
DHPARSEC(i) DATA ACCESS—Parameter requests entering HGs are split into 5 parallel
queues of differing priority depending on the requesting function. The
queue with index 1 is the highest priority queue and queue number 5 is the
lowest priority queue. This parameter represents the average number of
parameters per second flowing through a particular queue during the last 15
second period.
Queue 1—HG internal operations and operator changes.
Queue 3—history gathering and display call ups, including demand updates
after a change from a display.
Queue 4—trends, normal display updates, and tools and friendly display
queries.
Queue 5—point build, slow updates, SMCC access, and organizational
summaries.
These are displayed in the PERFMENU schematic HGDETAIL (R660).
PURPOSE—Indicates internal load on DA queues and handlers.
TYPE—Real

EVTRATE HG FUNCTIONS—Pure 15 second count (not a rate) of events and

alarms.
PURPOSE—Indicates the event load from the Hiway.
TYPE—Real
HWYERR(i) HG FUNCTIONS—The number of errors per minute for address (i)

based on a 1 hour sample rate of data to be kept by driver on each
Hiway box address.
PURPOSE—Indicates the error rate on Hiway communications.
TYPE—Real
HYSTARTS HG FUNCTIONS—The number of IOCB (I/O control block) chain

starts on the Hiway.
PURPOSE—Indicates the Hiway load due to AM/US actions.
TYPE—Real
IOCBS HIWAY DRIVER—Number of IOCBs (I/O control blocks) based

on a 15 second sample rate.
TYPE—Real
POLLRES HG FUNCTIONS—Number of Hiway poll responses per second

based on a 15 second sample rate of DHI board data (corresponds to
Hiway address 65 in board data).
TYPE—Real
POLLS HG Functions—Number of hiway polls per second based on a 15

second sample rate of DHI board data (corresponds to Hiway
address 64 in board data).
Purpose—Indicates the load level on the Hiway.
Type—Real
STRAVGC (R660) The parameter store rate (running average per second) in the current
hour.
TYPE – Real

STRAVGP (R660) The parameter store rate (overall average per second) in the
previous hour.
TYPE – Real
STRAVGS (R660) The parameter store rate (per second) in the last 15 seconds.
TYPE – Real

22.7 Network Gateway PSDP Parameters
ATTENTION
One of three values can be returned for Network Gateway PSDP
parameters:
• Average values and the array values (indexes shown in Table 22-1)
are based on one minute sample periods.
• Four parameters (NGPAGSDE(i), NGPAREAD(i), NGPAREQS,
NGPASTOR(i)) are based on the data access 15 sec sample period.
• Counts where the totals are since a node reload.
AALONEIN NG FUNCTIONS—Cable A alone-in-ring.

PURPOSE—Cable status on the PIN.
TYPE—Boolean
ABADADDR NG FUNCTIONS—Cable A bad address passed.

TYPE—Boolean
ACBLSTAT(i) NG FUNCTIONS—Cable A detail operational data. See Table 22-1

for index descriptions.
TYPE—Array of integer

22.7 Network Gateway PSDP Parameters, Continued
Table 22-1 Network Gateway Index Values

Index Description Index Description
1 TOKENS PASSED 25 REMOD THRESHOLD XCEDED
2 TOKENS HEARD 26 FRAGMENT THRSHLD XCEDED
3 NO SUCCESSOR 27 NO DRIVER Rx BUFFER
4 WHO FOLLOWS 28 Rx FROM INACTIVE NODE
5 TOKEN PASS FAILED 29 Rx FROM INACTIVE SAP
6 NOISE BURST 30 LCC SPARE 3
7 CHECKSUM ERROR 31 LCC SPARE 2
8 E BIT ERROR 32 LCC SPARE 1
9 FRAME FRAGMENT 33 Tx 0 PACKET
10 Rx FRAME TOO LONG 34 Tx 1 PACKET
11 NO Rx RESOURCES 35 Tx 2 PACKET
12 Rx OVERRUN 36 Tx 3 PACKET
13 DUPLICATE RWR 37 Tx NO BUFFER
14 NULL RWR 38 Tx SPARE 2
15 NO RESPONSE RWR 39 Tx SPARE 1
16 UNEXPECTED RESPONSE RWR 40 Rx 0 PACKET
17 ERROR IN RESPONSE RWR 41 Rx 1 PACKET
18 Tx UNDERRUN 42 Rx 2 PACKET
19 TBC SPARE 1 43 Rx 3 PACKET
20 TOKEN ROTATION TIME 44 Rx BAD MESSAGE
21 TOKEN ROTATION THRSHOLD XCEDED 45 Rx SPARE 2
22 TOKEN PASS FAIL THRSHOLD XCEDED 46 Rx SPARE 1
23 NOISE THRESHOLD EXCEEDED 47 COM SPARE 2
24 FCS THRESHOLD EXCEEDED 48 COM SPARE 1

ADUPADDR NG FUNCTIONS—Cable A duplicate address detected.

TYPE—Boolean
AINRINGR NG FUNCTIONS—Cable A in-ring-requested.

TYPE—Boolean
ANONGIBD NG FUNCTIONS—Cable A sees no NGI board.

TYPE—Boolean
AONLINEE NG FUNCTIONS—Cable A property on-line.

TYPE—Boolean
ASILENTT NG FUNCTIONS—Cable A silent – no activity.

TYPE—Boolean
ASUCCCHG NG FUNCTIONS—Cable A successor node change.

TYPE—Boolean
ASUSPECT NG FUNCTIONS—Cable A quality is suspect.

TYPE—Boolean
AXMTHANG NG FUNCTIONS—Cable A transmit hang detected.

TYPE—Boolean
BALONEIN NG FUNCTIONS—Cable B alone-in-ring.

TYPE—Boolean

BBADADDR NG FUNCTIONS—Cable B bad address passed.

TYPE—Boolean
BCBLSTAT(i) NG FUNCTIONS—Cable B detail operational data. See Table 22-1,

earlier in this subsection, for index descriptions.
TYPE—Array of integer
BDUPADDR NG FUNCTIONS—Cable B duplicate address detected.

TYPE—Boolean
BINRINGR NG FUNCTIONS—Cable B in-ring-requested.

TYPE—Boolean
BNONGIBD NG FUNCTIONS—Cable B sees no NGI board.

TYPE—Boolean
BONLINEE NG FUNCTIONS—Cable B property on-line.

TYPE—Boolean
BSILENTT NG FUNCTIONS—Cable B silent – no activity.

TYPE—Boolean
BSUCCCHG NG FUNCTIONS—Cable B successor node change.

TYPE—Boolean
BSUSPECT NG FUNCTIONS—Cable B quality is suspect.

TYPE—Boolean

BXMTHANG NG FUNCTIONS—Cable B transmit hang detected.

TYPE—Boolean
LOCTITLE The 2-character name of the local LCN. TYPE—String

LOC_DESC The 20-character description of the local LCN. Type—String
LOC_NUMB The number associated with the local LCN. TYPE—Real
NGPAGSDE(i) DATA ACCESS—Total number of get self-defining enum requests
from network. An array of 256 (indexed 0-255) values indexed by
network number. NGPAGSDE(0) is the total of NGPAGSDE(1..255).
NOTE: This parameter’s values are kept by data access and exist in all
nodes, but only if the node is an NG is the value valid.
PURPOSE—Provides loading i.nformation on NG.
TYPE—Real
NGPAREAD(i) DATA ACCESS—Total number of parameter reads from a particular

network. An array of 256 (indexed 0-255) values indexed by network
number. NGPASTOR(0) is the total of NGPASTOR(1..255).
NGPAREAD(0) is the total of NGPAREAD(1..255).
NOTE: This parameter’s values are kept by data access and exist in all
nodes, but only if the node is an NG is the value valid.
PURPOSE—Provides loading information on NG.
TYPE—Real

NGPAREQS DATA ACCESS—Total count of parameter access requests since last

reset to 0. Storing any value to this parameter resets NGPAREQS,
NGPAREAD(i), NGPASTOR(i), and NGPAGSDE(i) to zero.
NOTE: This parameter’s values are kept by data access and exist in
all nodes, but only if the node is an NG is the value valid.
TYPE—Real
NGPASTOR(i) DATA ACCESS—Total number of parameter stores from a particular

network. An array of 256 (indexed 0-255) values indexed by network
number. NGPASTOR(0) is the total of NGPASTOR(1..255).
NOTE: This parameter’s values are kept by data access and exist in
all nodes, but only if the node is an NG is the value valid.
TYPE—Real
PARSEC Because the NG has no points (except the PSDP), this parameter
would be fairly useless for performance measurement purposes.
Therefore, in the NG only, this parameter represents the number of
parameters per second being read or stored from and to this LCN by
all other LCNs, summed with the PARSEC for this NG's PSDP. In
other words, PARSEC in the NG is a measure of the number of
parameters per second that are “flowing through” the NG. Also see
PARSEC in subsection 22.2.
RECVAVGM NG FUNCTIONS—Average receive message size in bytes.

PURPOSE—NG performance and loading data.
TYPE—Real
RECVERRS NG FUNCTIONS—Number of PIN errors reported.

TYPE—Real

RECVFLMG NG FUNCTIONS—Number of receive file messages.

TYPE—Real
RECVFLWD NG FUNCTIONS—Word count for receive messages.

TYPE—Real
RECVMSGS NG FUNCTIONS—Total number of receive messages.

TYPE—Real
RECVPKTS NG FUNCTIONS—Number of receive 512 word packets.

TYPE—Real
RECVTMOT NG FUNCTIONS—Time out for receive messages.

TYPE—Real
RECVWORD NG FUNCTIONS—Total number of receive words.

TYPE—Real
REMTITLE(i) The 2 character name of the remote LCN whose number is i.

TYPE—String
REM_DESC(i) The 20 character description of the remote LCN whose number is i.

TYPE—String
XMITAVGM NG FUNCTIONS—Average transmit message size in bytes.

TYPE—Real

XMITERRS NG FUNCTIONS—Number of PIN errors reported.

TYPE—Real
XMITFLMG NG FUNCTIONS—Number of transmit file messages.

TYPE—Real
XMITFLWD NG FUNCTIONS—Word count for transmit messages.

TYPE—Real
XMITMSGS NG FUNCTIONS—Total number of transmit messages.

TYPE—Real
XMITPKTS NG FUNCTIONS—Number of transmit 512 word packets.

TYPE—Real
XMITTMOT NG FUNCTIONS—TIME OUT FOR TRANSMIT MESSAGES.

PURPOSE—NG PERFORMANCE AND LOADING DATA.
TYPE—REAL
XMITWORD NG Functions—Total number of transmit words.

TYPE—Real

22.8 Universal Station PSDP Parameters
$ANPPROP (R670) This parameter propagates the annunciation policy of the

node/network/IOP to all the stations in a console. Only an ON value can
be stored to this parameter. If you attempt to store an OFF value, an
error is reported. When the propagation is complete, the boolean flag is
reset to OFF.
Source: User
Value Type: Boolean
Access Lock: Engineer
Residency: US
Value Range: ON
OFF (default)
$CALCPRD (R680) This parameter enables the load calculation task and controls the
periodicity of load calculations. A value of 0 indicates that the task is
stopped. A value > 3 indicates the periodicity (in seconds) at which the
load calculations are performed.
Source: User
Value Type: Integer
Residency: US
Value Range: 0, 4 – 600 seconds
0 seconds (default)
$CALSTAT (R680) This parameter indicates the status of LCN load calculation tool running
on the US node. The following values indicate the status of the tool:
OFF – The US task is stopped.
ON – The US task is running fine.
ERROR – An error has occurred during startup or execution of the load
calculation task.
Source: System
Value Type: Enumeration
Access Lock: View-only
Residency: US
Value Range: ON, OFF, ERROR
OFF (default)
$CBLACCL This R510 parameter returns the ordinal value of the access level
required to use the LCN Cable Swapping function. This value is
configured in the NCF.

22.8 Universal Station PSDP Parameters, Continued
$CBLINHT This R510 parameter returns the time remaining, in minutes, until LCN
Cable Swapping will resume.
$CBLNCFT This R510 parameter returns the time value, configured in the NCF, for
LCN Cable Swapping. When the value is zero, LCN cable swapping is
disabled.
$CLSNODE (nn) This parameter indicates the segment number to which the node belongs
(R680) to, if TPN Bridge is present.
Source: User
Value Type: Integer Array (1…96)
Residency: US
Value Range: 0 - 7
0 (default)
$IOPADD (R670) This parameter disables the system alarm annunciation for an IOP.
Setting this flag to ON transfers the addresses from the IOP TO
DISABLE row to the first available empty row in the $IOPANP
schematic. When the addresses are transferred, the Boolean flag is reset
to OFF.
Source: User
Value Type: Boolean
Residency: US
Value Range: ON
OFF (default)

$IOPBXAD This parameter specifies the UCN node number of the IOP to be
(R670) disabled in the $IOPANP schematic.
Source: System
Value Type: Integer
Residency: US
Value Range: 1 - 64
0 (default)
$IOPBXAP(bb) This parameter specifies the UCN node number of the disabled IOPs.
(R670) Source: System
Access Lock: Read only
Residency: US
Value Range: 1 - 64
0 (default)
$IOPDEL(dd) This parameter enables the disabled IOP in the $IOPANP schematic.
(R670) When this parameter is set to ON, the value for $IOPNWAP(dd),
$IOPBXAP(dd) and $IOPMDAP(dd) are set to zero. The value OFF for
$IOPDEL(dd) parameter indicates that the corresponding row has been
used for disabling an IOP. The user can only store an ON value to this
parameter, otherwise an error is reported. Disabling the IOP is the only
mechanism by which the value of this parameter can be changed to OFF.
Source: User
Value Type: Boolean Array (1…16)
Residency: US
Value Range: OFF
ON (default)
$IOPMDAD This parameter specifies the module number of the IOP to be disabled in
(R670) the $IOPANP schematic.
Source: User
Value Type: Integer
Residency: US
Value Range: 1 - 40
0 (default)

$IOPMDAP(mm) This parameter specifies the module number of the disabled IOPs.
Residency: US
Value Range: 1 - 40
0 (default)
$IOPNWAD This parameter specifies the Network number of the IOP to be disabled
R670) in the $IOPANP schematic.
Source: User
Value Type: Integer
Residency: US
Value Range: 1 - 20
0 (default)
$IOPNWAP(nn) This parameter reads the Network number of the disabled IOPs.
Value Type: Integer Array (1...16)
Residency: US
Value Range: 1 - 20
0 (default)
$LDALDB (R680) This parameter allows the user to set the deadband for the system alarms
that are generated when the total LCN load or total Parameters per
Message crosses the specified trip limits. A value between 0 and 99 is to
be specified to generate the system alarms. If this parameter value=100,
the system alarms are not generated even if the total LCN load or total
Parameters per Message crosses the specified trip limits. The unit of
deadband for total LCN load isthin % and the unit of deadband for total
Parameters per Message is 100 of $PPMLOTP.
Source: User
Value Type: Integer
Residency: US
Value Range: 0 – 99, 100
100 (default)

$LDALFL (ss) This parameter indicates the status of the system alarm, when the total
(R680) LCN load on the network and the total Parameters per Message crosses
the trip limits.
Source: System
Value Type: Boolean
Residency: US
Value Range: TRUE, FALSE
FALSE (default)
$LDHHTP (ss) This parameter shall have the high high trip point for the parameter
(R680) ESTIMATED % of LCN LOAD.
Source: User
Value Type: Real Array (0…7)
Residency: US
Value Range: $LDHITP (ss) - 100
65 (default)
$LDHITP (ss) (R680) This parameter indicates the high trip point for the parameter total
ESTIMATED % of LCN LOAD.
Source: User
Residency: US
Value Range: 35 - $LDHHTP (ss)
55 (default)
$LMSGSEC (ss) This parameter indicates the total MESSAGES PER SECOND on the
(R680) network.
Source: System
Residency: US
Lower Limit: 0
0 (default)

$LPARMSG (ss) This parameter indicates the total PARAMETERS PER MESSAGE on
(R680) the network.
Source: System
Residency: US
Lower Limit: 0
0 (default)
$LPARSEC (ss) This parameter indicates the total PARAMETERS PER SECOND on the
(R680) network.
Source: System
Residency: US
Lower Limit: 0
0 (default)
$NODEANP(nn) This parameter reads/writes to the local annunciation policy of any

(R670) US/GUS on an LCN.
Source: User
Value Type: Boolean Array (1...96)
Residency: US
Value Range: ON (ENABLE), OFF (DISABLE)

$NWANPnn(bb) This parameter reads and writes from/to the local annunciation policy
(R670) of any US/GUS on an LCN. The value of this parameter represents the
system alarm annunciation policy for a particular box/module on
hiway/UCN.
Source: User
Value Type: Boolean Array (1...64)
Residency: US
Value Range: ON (ENABLE), OFF (DISABLE)
$PARLIMC (ss) This parameter allows some fine-tuning (bias factor) to be performed
(R680) on the LCN load calculation.
Source: User
Value Type: Real
Residency: US
Value Range: (-10) – (+10)
0 (default)
$PARLIMX (ss) This parameter allows some fine-tuning to be performed on the LCN
(R680) load calculation. The user can specify a value for PARLIMX other than
4500. This value is based on the number of parameters per second that
equate to 100% loading of the system configuration.
Source: User
Value Type: Integer
Residency: US
Value Range: 0 – 5000
4500 (default)

$PICCAN (R660) This R660 parameter cancels the AM/HG/UCN point-interconnection-

search that is in progress. If the $PICCAN value is set to ON (Cancel
target), the Point Interconnection query is cancelled and the request is
set to OFF. See section 37 for information on finding point
interconnections.
Source: User
Value Type: Boolean
Access Lock: Operator
Residency: US
Value Range: OFF (default)
ON
$PICDEF (R660) This R660 parameter defines whether the $INTRCON display uses the
default value for the Point-Interconnection-search query request
parameter.
If the $PICDEF value is set to ON (default), the Point Interconnection
function uses the entity type of the requested point as the search query
request parameter. You can also select $PICQRYA (for AM),
$PICQRYH (for HG), or $PICQRYU (for UCN) or any other Point-
Interconnection -search request parameters.
If the $PICDEF value is set to OFF, the point interconnection display
uses the value in $PICQRY as the Point-Interconnection -search query
request parameter.
See section 37 for information on finding point interconnections.
Source: User
Value Type: Boolean
Residency: US
ON

$PICENT (R660) This R660 parameter identifies the current entity (Entity target) that is
used in the Point-Interconnection-search. The values are meaningful
only during the execution of the Point-Interconnection-search. See
section 37 for information on finding point interconnections.
Source: User
Value Type: String of 19 characters
Access Lock: Read Only
Residency: US
Value Range: " " (Null) (default)
1 to 19 characters that represent the TPN point name used in the search.
$PICFILE (R660) This R660 parameter defines whether the Point Interconnection search
results are sent to the file specified in the operator find names Fnm
query.
If the $PICFILE value (file target) is set to ON, the Point
Interconnection results are sent to the file specified in the operator find
names Fnm query. If the $PICFILE value is set to OFF, the data is not
sent to the file. The file status can be seen in the $PICFST file status
parameter. See section 37 for information on finding point
interconnections.
Source: User
Value Type: Boolean
Residency: US
ON

$PICFST (R660) This R660 parameter stores the Point Interconnection status of the file
output. See section 37 for information on finding point
interconnections.
Source: System
Value Type: Integer
Residency: US
Value Range: 0 (default) through 32767
NOTE: 51 is the status OK value, refer to CL/AM Reference Manual

for the File Manager Status Return Values List.
$PICPRNT (R660) This R660 parameter defines whether the Point-Interconnection-search

results are sent to the printer specified in the Fnm query.
If the $PICPRNT value (Print) is set to ON, the Point-Interconnection

results are sent to the printer specified in the Fnm query file used in the
search. If the $PICPRNT value is set to OFF, the data is not sent to the
printer.

Source: User
Value Type: Boolean
Residency: US
ON

$PICQRY (R660) This R660 parameter is the descriptor (string name) of an Fnm query.
The operator enters this descriptor into the $INTRCON display to see
the results of the appropriate Point-Interconnection-search query.
$PICDEF overrides the $PICQRY option if the operator selects the
default as $PICDEF.
After the operator enters the descriptor in the Fnm Query port, the value
is retained until the operator enters a new descriptor value or the US is
restarted. If the query is not defined, then all the AM/HG/UCN nodes
on the LCN are searched on the NET and the printing and file output
options are disabled.
NOTE: The descriptor name should not be ''--" or a "NULL" string.

These strings can be interpreted by the $INTRCON schematic as a
signal to clear the name.

Source: User
Residency: US
Value Range: "" (Null) (default)
A 1 to 64-character string that specifies the query used for the point-
interconnection-search.

$PICQRYA (R660) This R660 parameter is the default Fnm query to be used by the Point-
Interconnection-search for AM points.
$PICQRYA is a string name of a Documentation Tool query saved in the
sysqry.dc file with the descriptor entry. This entry describes the default
search parameters when the requested point type belongs to the AM.
A request error results when the operator sets the default $PICDEF
parameter to ON and $PICQRYA contains a NULL value.
After the engineer enters the $PICQRYA value in the Fnm Query port,
the value is retained until the engineer enters a new value, or the US is
restarted.
NOTE: The descriptor name should not be ''--" or a "NULL" string. These
strings can be interpreted by $INTRCON schematic as an empty string
and the parameter value will be reset.
The value for $PICQRYA is entered through a schematic display such as

DATCHNG display.

Source: User
Residency: US
A 1 to 64 character string that is the name of the point-interconnection-
search query.

$PICQRYH (R660) This R660 parameter holds the default Fnm query to be used by the point
interconnection display for an HG point. $PICQRYH is a string name of a
Documentation Tool query that has been saved in the sysqry.dc file with
the descriptor entry. This entry describes the default search parameters
when the requested point type belongs to the HG.
A request error is initiated if the operator sets the default $PICDEF
parameter to ON and $PICQRYH contains a null value.
When the engineer enters a value for the $PICQRYH parameter, the value
is retained until the engineer enters a new value or the US is restarted.
NOTE: The descriptor name should not be ''--" or a "NULL" string. These
strings can be interpreted by the $INTRCON schematic as an empty
string and the parameter value will be reset.
The value for $PICQRYH can be entered through the DATCHNG

display.

Source: User
Residency: US
search query.

$PICQRYU (R660) This R660 parameter holds the default Fnm query to be used by the
point interconnection display for a UCN point. $PICQRYU is a string
name of a Documentation Tool query that has been saved in the
sysqry.dc file with the descriptor entry. This entry describes the default
search parameters when the requested point type belongs to the UCN.
A request error is initiated if the operator sets the default $PICDEF

parameter to ON and $PICQRYU contains a NULL value.
When the engineer enters a value for the $PICQRYU parameter, the
value is retained until the engineer enters a new value or the US is
restarted.
NOTE: The descriptor name should not be ''--" or a "NULL" string.

These strings can be interpreted by the $INTRCON schematic as an
empty string and the parameter value will be reset.
The value for $PICQRYU can be entered through the DATCHNG

display.

Source: User
Residency: US
search query.

$PICREQ (R660) This R660 parameter activates the point interconnection display.
If $PICREQ is set to ON, the point interconnection display is activated.

When the request is processed, $PICREQ is set to the OFF state.
Setting the value to OFF has no effect.

Source: User
Value Type: Boolean
Residency: US
ON
$PICRSLT[1..36] This R660 parameter is a memory table that contains the Point-
(R660) Interconnection-search results. Up to 36 string values can be used to
represent the outputs seen on the $INTRCON schematic.
NOTE: $PICRSLT should contain a valid subscript (1..36) to read the

value. The 36 string values represent a maximum of 72
interconnections. If the number of interconnections exceeds 72, the
display results stop after first 72 values. The print and file
interconnection outputs continue until the interconnection search is
finished.

Source: System
Value Type: Array 1..36 of string 76 characters
Residency: US
76 characters that represent an output from point-
interconnection-search.

$PICSTAT (R660) This R660 parameter returns the current interconnection search status.
The values displayed are,
INACTIVE – request is currently off

BUSY – search is in progress
UNAVAILABLE – interconnection search cannot be executed
ERROR <cccc...> – type of error encountered
where <cccc…> indicates:
PRT – Printer error
FILE – File error
MED – Pathname media error
CONV– Conversion error
INT – Internal error

Source: System
Residency: US
Value Range: UNAVAILABLE (default)
1 to 28 characters that represent the status of the point-interconnection-
search.
$PICTMST (R660) This R660 parameter contains the start time of the current Point
Interconnection search.

Source: System
Value Type: Time
Residency: US
Value Range: 00:00:00 (default)
Represents the start time of the Point-Interconnection-search. Example:
12:01:59.

$PICTMEN (R660) This R660 parameter contains the end time of the current Point
Interconnections search. See section 37 for information on finding
point interconnections.
Source: System
Value Type: Time
Residency: US
Value Range: 00:00:00 (default)
Represents the end time of the Point-Interconnection-search.
Example: 12:01:59.
$PPMALFL (ss) (R680) This parameter indicates the status of system alarm, when the total
Parameters per Message on the network has crossed the trip limits.
Source: System
Value Type: Boolean
Residency: US
Value Range: TRUE, FALSE
FALSE (default)
$PPMLLTP (ss) (R680) This parameter indicates the low low trip point for the parameter
PARAMETERS PER MESSAGE.
Source: User
Residency: US
Value Range: 0 - $PPMLOTP (ss)
20 (default)

$PPMLOTP (ss) (R680) This parameter indicates the low trip point for the parameter
PARAMETERS PER MESSAGE.
Source: User
Residency: US
Lower Limit: $PPMLLTP (ss)
100 (default)
$TOTLOAD (ss) (R680) This parameter represents the total ESTIMATED % OF LCN
LOAD of the network.
Source: System
Residency: US
Value Range: 0 – 100
0 (default)
ACKEM(n) This R500 integer parameter returns the number (0-600) of

acknowledged emergency alarms for each priority in the specified
unit.
If the Unit is not configured, the counters are zero.
TYPE—Integer
n = Area relative unit number (1-36). This number corresponds to
that seen on the Console Status Display > Unit Assignment
Display.
ACKHI(n) This R500 integer parameter returns the number (0-600) of

acknowledged high alarms in the specified unit.
TYPE—Integer
Display.

ACKLO(n) This R500 integer parameter returns the number (0-600) of

acknowledged low alarms in the specified unit.
TYPE—Integer
Display.
AREAALM MMI FUNCTIONS—Total number of events processed by this

US or UXS in the previous 15 second period. All events are
counted, including process alarms, state changes, etc. This
parameter measures event throughput.
PURPOSE—Indicates the event load on the TPN and US.
TYPE—Real

CURRDSP PURPOSE—Find the name of the schematic currently on display.

(R600) Track which displays are most used.
Determine which displays are no longer used.
Determine the sequence of displays invoked.
Put the schematic source filename on each schematic.
TYPE— String
NMSCHPR MMI FUNCTIONS—Number of parameters requested on the last

schematic display callup.
PURPOSE—Indicates the display load on the LCN.
TYPE—Real
QSTS(1) This R510 array type parameter returns the name of the last
requested query of a prebuilt Documentation Tool query for a
custom schematic. Read Only. See section 36 for information on
executing pre-defined Doc Tool queries.
Reference: Documentation Tool manual, and section 19 of the
Actors Manual.
QSTS(2) This R510 array type parameter returns the status of the last
requested query of a prebuilt Documentation Tool query for a
custom schematic. Read Only. See section 36 for information on
executing pre-defined Doc Tool queries.
QSTS(3) This R510 array type parameter returns the invocation date/time of
the last requested query of a prebuilt Documentation Tool query
for a custom schematic. Read Only. See section 36 for
information on executing pre-defined Doc Tool queries.

QRYSORT This R610 functionality is extended to support schematics, thus

(R610) allowing schematics that used the “query actors” to make use of
the sort capabilities.
The QRYSORT value is from 0 to 6, as described in the

Predefined Queries section of the Engineer Reference Manual.
The QRYSORT parameter is initialized to 0 at node startup.
Note: The PSDP parameters can be accessed and/or changed by

the following means: DATACHNG Schematic, CL, or Customer
Schematic.
See the following table for query sort values.
TYPE QRYSORT Definition

Value
Temporary 0 “No Sort.” The Sort Directive in the CL/CP (Command Processor) query
will override this option.
1 “Sort by Entity Name.” Automatically reset to ‘No Sort’ at completion of

Query. The Sort Directive in the CL/CP will override this option.
2 “Sort by user specified first field.” Automatically reset to ‘No Sort’ at

completion of Query. The Sort Directive in the CL/CP will override this
option.
Node 3 “No Sort.” This option overrides the CL/CP Sort Directive. This value is
Global not automatically reset. Once set, this option can only be changed to
another Node Global type or Reset.
4 “Sort by Entity Name.” This option overrides the CL/CP Sort Directive.
This value is not automatically reset. Once set, this option can only be
changed to another Node Global type or Reset.
5 “Sort by first user specified field.” This option overrides the CL/CP Sort
Directive. This value is not automatically reset. Once set, this option can
only be changed to another Node Global type or Reset.
Reset 6 Used to Reset the Node Global options. Once a Node Global option is
set, it can be changed to a temporary type only by setting this option.
Setting this option, resets the PSDP value to 0.

UBOOL(1..100) This R610 parameter provides an array of 100 Boolean values.
Data Type: Boolean

Residency: US
Value Range: On/Off
UENT(1..100) This R610 parameter provides an array of 100 Entity values.
Data Type: Entity

Residency: US
Value Range: Entity
UINTEGER(1..100) This R610 parameter provides an array of 100 Integer values.
Data Type: Integer

Residency: US
Value Range: Integer
UNACKEM(n) This R500 integer parameter returns the number (0-600) of

unacknowledged emergency alarms for each priority in the
specified unit.
TYPE—Integer
Display.

UNACKHI(n) This R500 integer parameter returns the number (0-600) of

unacknowledged high alarms in the specified unit.
TYPE—Integer
Display.
UNACKLO(n) This R500 integer parameter returns the number (0-600) of

unacknowledged low alarms in the specified unit.
TYPE—Integer
Display.
UNIT_ID(n) This R500 parameter returns a two-character string that is the

user-configured Unit ID, as defined in the NCF Unit Names.
If the Unit is not configured, “garbage” is returned. This will be
fixed in a maintenance release.
TYPE—2 character string
Display.
UNITASSG(n) This R500 parameter returns one of the following enumerated

values, indicating if the unit is under the control of any station
loaded with the local Area database.
NO (deassigned)
YES (assigned)
If the Unit is not configured, the status is NO.
TYPE—ENUM: UNITASGN
Display.

UNITCONS(n) This R500 parameter returns one of the following enumerated

values, indicating if the process alarms for the unit will be
annunciated on the stations in the local console (Console Alarm
Status):
ENABLE (alarms are annunciated)
DISABLE (alarms are not annunciated)
If the Unit is not configured, the status is DISABLE.
TYPE—ENUM: ALENBST
Display.
UNITRECV(n) This R500 parameter returns one of the following enumerated

values, indicating the current unit alarm recovery state:
NOLOST (no lost events)
RECVREQD (recovery has been requested)
LOSTEVNT (lost events exist, but no recovery has been
requested)
RECINPRG (recovery is in progress)
If the Unit is not configured, the status is NOLOST.
TYPE—ENUM: UNITREC
Display.

UNITSTAT(n) This R500 parameter returns an enumerated value indicating the

current composite alarm status of the specified unit. The values
are listed below in order of precedence:
UNACKEM
UNACKHI
UNACKLO
ACKEM
ACKHI
ACKLO
If all the counters are zero, the status is NOALARM.

If the Unit is not configured, the status is NOTCONFG
TYPE—ENUM:$ALRMSTS
Display.
UNITSYS(n) This R500 parameter returns one of the following enumerated

values, indicating if the process alarms for the unit will be
annunciated on any stations system-wide (System Alarm Status):
ENABLE (alarms are annunciated, historized, and journalized.)
DISABLE (alarms are not annunciated. The process alarm event
history collection and RTJ are not affected.)
INHIBIT (alarms are not annunciated, and the process alarm event
history collection and RTJ are stopped.)
If the Unit is not configured, the status is DISABLE.
TYPE—ENUM: ALENBST
Display.

UREAL(1..100) This R610 parameter provides an array of 100 Real values.
Data Type: Real

Residency: US
Value Range: Real
USKEYACC This R610 parameter provides the ability to read and write to the
keylevel access parameter of any GUS (or US) on a TPN. This
parameter is available to all GUSs, USs, and AMs connected to
the same TPN, independent of the console. The change will be
journalized to both the HM and to the RTJ. The following are
possible key values:
ENGR (changes key access of the station to Engineer)
SUP (changes key access of the station to Supervisor)
OPR (changes key access of the station to Operator)
RESET (resets the value of the parameter to reflect the actual
hardware key switch)
VIEW or OPR is displayed when the hardware key switch is in the
Operator position, depending on the current default set by the
ACCESS CHG target on the Console Status display. Storing the
value “VIEW” for the USKEYACC parameter is blocked.

NOTE: The USKEYACC parameter can be changed only when

the access level is Engineer. Consider the following scenario.
Initially the station Keylock is in ENGINEER. You will be able to
change the local Keylock level to either SUPERVISOR or
OPERATOR using the PSDP parameter USKEYACC. Now the
access level is no longer ENGINEER, so you will not be able to
change the access level from the local station using the PSDP
parameter. The options now available to the user are to change the
Keylevel access from another station that has Engineer access or
to turn the local Keylock position to ENGINEER.
Data Type: $keyvalu

Residency: US
Value Range: VIEW (View)
OPR (Operator)
SUP (Supervisor)
ENGR (Engineer)
RESET (Reset)
USTRING(1..50) This R610 parameter provides an array of 50 String values, each
40 characters long.
Data Type: Entity

Residency: US
Value Range: Up to 40 characters

22.9 HM60 PSDP Parameters
STATE See the RULA User’s Manual for information about PSDP
parameters.
STATE1 See the RULA User’s Manual for information about PSDP
parameters.
LNCONECT(i) ARCHIVER—An array indexed by node number that contains

the local history connection status of every node on the
network as known to this archiver node.
PURPOSE—Indicates current history status.
LHBRSTTM COLLECTOR—The time at which the largest burst of

exception reports occurred.
PURPOSE—Indicates time of heaviest load.
TYPE—Time/date
LHCOSTOT COLLECTOR—Total number of exception reports for

historized parameters received during the last period by local
history on this data owner.
1 Last minute
2 Last hour maximum
3 Last hour minimum
4 Last hour average
5 Max since load
PURPOSE—Indicates historizing rate on network by this
node.
TYPE—Array of real

22.9 HM60 PSDP Parameters, Continued
LHMEMUSE COLLECTOR—The memory usage by local history functions

in this data owner.
1 Allocated
2 Available
3 Parameters loaded
4 Parameter rate
PURPOSE—Indicates memory usage in node.
LHOVERNS(i) COLLECTOR—An array indexed by scan class specifying the

number of overruns that have occurred on this data owner in
the last period.
1 Last minute
2 Last hour maximum
3 Last hour minimum
4 Last hour average
PURPOSE—Indicates excessive history or system loading.

22.10 Remote User Link Adapter (RULA) PSDP Parameters
Reference
For a list of PSDP parameters for Remote User LCN Access (RULA),
see the RULA User’s Manual.

22.11 Network Interface Module PSDP Parameters
$AUTOSAV (R620) The auto checkpointing enable/disable status of this node on the
LCN.
TYPE - ATTRIB
$EIPMAXC (R660) The maximum number of EIP events in any one second in the
current hour.
PURPOSE - Indicates the loading on NIM with respect to Event
TYPE – Integer
$EIPMAXP (R660) The maximum number of EIP events in any one second in the
previous hour.
TYPE – Integer
$EIPTOTC (R660) The total number of EIP events sent to the LCN in the current hour.
TYPE – Real
$EIPTOTP (R660) The total number of EIP events sent to the LCN in the previous
hour.
Initiated Processing. The EIP events for this parameter include the
process-special EIP events and CL message EIP events.
TYPE – Real
$EIPTOTS (R660) The total number of EIP events sent to the LCN in the previous 15
seconds.
Initiated Processing. The EIP events for this parameter include the
process-special EIP events and CL message EIP events.
TYPE – Real

22.11 Network Interface Module PSDP Parameters,
Continued
$EVTMAXC (R660) The maximum number of events in any one second during the
current hour.
PURPOSE - Indicates the loading on NIM with respect to the
NOTE: EIP EVENTS ARE NOT INCLUDED.
TYPE – Integer
$EVTMAXP (R660) The maximum number of events in any one second during the
previous hour.
TYPE – Integer
$EVTTOTC (R660) The total number of events sent to the LCN in the current hour.
TYPE – Real
$EVTTOTP (R660) The total number of events sent to the LCN in the previous hour.
TYPE – Real
$MUALMNM(xx) (R680) The number of MUs consumed by the configured Alarmable

Numeric point type.
PURPOSE – Indicates the number of MUs consumed by the
configured Alarmable Numeric point type of the selected node in
HPM.
NOTE: (xx) indicates the HPM node number.
TYPE – Integer
$MUARRAY(xx) (R680) The number of MUs consumed by the configured Array point type.
configured Array point type of the selected APM/HPM node.
NOTE: (xx) indicates the APM/HPM node number.
TYPE – Integer

Continued
$MUDEVCT(xx) (R680) The number of MUs consumed by the configured Device Control
point type.
configured Device Control point type of the selected APM/HPM
node.
TYPE – Integer
$MUDIGCP(xx) (R680) The number of MUs consumed by the configured Digital Composite
point type.
configured Digital Composite point type of the selected
PM/APM/HPM node.
NOTE: (xx) indicates the PM/APM/HPM node number.
TYPE – Integer
$MUFREE(xx) (R680) The number of available MUs in the selected node.

PURPOSE – Indicates the available number of MUs of the selected
node in PM/APM/HPM.
TYPE – Integer
$MULOGIC(xx) (R680) The number of MUs consumed by the configured Logic point type.
configured Logic point type of the selected PM/APM/HPM node.
TYPE – Integer
$MUNUM(xx) (R680) The number of MUs consumed by the configured Numeric point
type.
PURPOSE – Indicates the number MUs consumed by the
configured non-Alarmable Numeric point type of the selected node
in PM/APM/HPM.
TYPE – Integer

Continued
$MUPRMOD(xx) (R680) The number of MUs consumed by the configured Process Module
point type.
configured Process Module point type of the selected node in
PM/APM/HPM.
TYPE – Integer
$MURGCTL(xx) (R680) The number of MUs consumed by the configured Regulatory

Control point type.
configured Regulatory Control point type of the selected node in
PM/APM/HPM.
TYPE – Integer
$MURGPV(xx) (R680) The number of MUs consumed by the configured Regulatory PV

point type.
configured Regulatory PV point type of the selected node in
PM/APM/HPM.
TYPE – Integer
$MUSTRNG(xx) (R680) The number of MUs consumed by the configured String point type.
configured String point type of the selected node in APM/HPM.
TYPE – Integer
$MUTIME(xx) (R680) The number of MUs consumed by the configured Timer point type.
configured Times point type of the selected node in APM/HPM.
TYPE – Integer
$NODMAXC (R660) Maximum number of node data accesses in any one second in the
current hour.
PURPOSE - Indicates the loading on NIM because of the processing
of data-access requests that resulted in UCN reads or stores.
TYPE – Integer

Continued
$NODMAXP (R660) Maximum number of node data accesses in any one second in the
previous hour.
TYPE – Integer
$NODTOTC (R660) Total number of node data accesses in the current hour.
TYPE – Real
$NODTOTP (R660) Total number of node data accesses in the previous hour.
PURPOSE – Indicates the loading on NIM because of the
processing of data-access requests that resulted in UCN reads or
stores.
TYPE – Real
$NODTOTS (R660) Total number of node data accesses in the last 15 seconds.
stores.
TYPE – Real
$PAISLOT(xx) (R680) The number of Analog Input points configured on the node.
PURPOSE – Indicates the number Analog Input points configured
on the selected LM/SM node.
NOTE: (xx) indicates the LM/SM node number.
TYPE – Integer
$PAOSLOT(xx) (R680) The number of Analog Output points configured on the node.
PURPOSE – Indicates the number Analog Output points configured
TYPE – Integer
$PARMAXC (R660) The maximum parameter access rate in any one-second in the
current hour.
stores.
TYPE – Integer

Continued
$PARMAXP (R660) The maximum parameter access rate in any one-second during the
previous hour.
processing of data access requests that resulted in UCN reads or
stores.
TYPE – Integer
$PARSECC (R660) The parameter access rate (running average per second) in the
current hour.
stores.
TYPE – Real
$PARSECP (R660) The parameter access rate (overall average per second) in the
previous hour.
stores.
TYPE – Real
$PARSLOT(xx) (R680) The number of Array points configured on the node.

PURPOSE – Indicates the total number of Array points configured
on the selected APM/HPM node.
TYPE – Integer
$PCTLSLT(xx) (R680) The number of Regulatory Control points configured on the node.
PURPOSE – Indicates the number of Regulatory Control points
configured on the selected PM/APM/HPM node.
TYPE – Integer
$PDCSLOT(xx) (R680) The number of Digital Composite points configured on the node.
PURPOSE – Indicates the number of Digital Composite points
configured on the selected PM/APM/HPM/LM/SM node.
NOTE: (xx) indicates the PM/APM/HPM/LM/SM node number.
TYPE – Integer

Continued
$PDEVSLT(xx) (R680) The number of Device Control points configured on the node.
PURPOSE – Indicates the number of Device Control points
configured on the selected APM/HPM node.
TYPE – Integer
$PDISLOT(xx) (R680) The number of Digital Input points configured on the node.
PURPOSE – Indicates the number of Digital Input points configured
TYPE – Integer
$PDOSLOT(xx) (R680) The number of Digital Output points configured on the node.
PURPOSE – Indicates the number of Digital Output points
configured on the selected LM/SM node.
TYPE – Integer
$PFLAG(xx) (R680) The number of Flag points configured on the node.

PURPOSE – Indicates the number of Flag points configured on the
selected APM/HPM node.
TYPE – Integer
$PLOGSLT(xx) (R680) The number of Logic points configured on the node.
PURPOSE – Indicates the number of Logic points configured on the
selected PM/APM/HPM/LM/SM node.
TYPE – Integer
$PNUMRIC(xx) (R680) The number of Numeric points configured on the node.

PURPOSE – Indicates the number of Numeric points configured on
the selected APM/HPM node.
TYPE – Integer

Continued
$PPMSLOT(xx) (R680) The number of Process Module points configured on the node.
PURPOSE – Indicates the number of Process Module points
TYPE – Integer
$PPVSLOT(xx) (R680) The number of Regulatory PV points configured on the node.

PURPOSE – Indicates the number of Regulatory PV points
TYPE – Integer
$PRCMAXC (R660) The maximum number of process alarms in any one second in the
current hour.
PURPOSE – Indicates the loading on NIM with respect to the
TYPE – Integer
$PRCMAXP (R660) The maximum number of process alarms in any one second in the
previous hour.
TYPE – Integer
$PRCTOTC (R660) The total number of process alarms sent to the LCN in the current
hour.
TYPE – Real
$PRCTOTP (R660) The total number of process alarms sent to the LCN in the previous
hour.
TYPE – Real

Continued
$PRCTOTS (R660) The total number of process alarms sent to the LCN in the previous
15 seconds.
TYPE – Real
$PTIME(xx) (R680) The number of Timer points configured on the node.

PURPOSE – Indicates the number of Timer points configured on the
selected PM/APM/HPM/LM/SM node.
TYPE – Integer
$PUALMNM(xx) (R680) The number of PUs consumed by the configured Alarmable

Numeric point type.
PURPOSE – Indicates the number of PUs consumed by the
configured Alarmable Numeric point type of the selected HPM
node.
NOTE: (xx) indicates the HPM node number.
TYPE – Real
$PUANLIN(xx) (R680) The number of PUs consumed by the configured Analog Input point
type.
configured Analog Input point type of the selected node in LM/SM.
TYPE – Real
$PUANLOP(xx) (R680) The number of PUs consumed by the configured Analog Output
point type.
configured Analog Output point type of the selected node in
LM/SM.
TYPE – Real

Continued
$PUDEVCT(xx) (R680) The number of PUs consumed by the configured Device Control
point type.
configured Device Control point type of the selected node in
APM/HPM.
TYPE – Integer
$PUDIGCP(xx) (R680) The number of PUs consumed by the configured Digital Composite
point type.
configured Digital Composite point type of the selected node in
PM/APM/HPM/LM/SM.
TYPE – Real
$PUDIGIN(xx) (R680) The number of PUs consumed by the configured Digital Input point
type.
configured Digital Input point type of the selected node in LM/SM.
TYPE – Real
$PUDIGOP(xx) (R680) The number of PUs consumed by the configured Digital Output
point type.
configured Digital Output point type of the selected node in
LM/SM.
TYPE – Real
$PUFREE(xx) (R680) The number of available PUs in the node.

PURPOSE – Indicates the number of PUs available in the selected
PM/APM/HPM/LM/SM node.
TYPE – Real

Continued
$PULOGIC(xx) (R680) The number of PUs consumed by the configured Logic point type.
configured Logic point type of the selected PM/APM/HPM/LM/SM
node.
TYPE – Integer
$PUPRMOD(xx) (R680) The number of PUs consumed by the configured Process Module
point type.
configured Process Module point type of the selected node in
PM/APM/
TYPE – Integer
$PURGCTL(xx) (R680) The number of PUs consumed by the configured Regulatory Control
point type.
configured Regulatory Control point type of the selected node in
PM/APM/HPM.
TYPE – Integer
$PURGPV(xx) (R680) The number of PUs consumed by the configured Regulatory PV

point type.
configured Regulatory PV point type of the selected node in
PM/APM/HPM.
TYPE – Integer
$PUTIME(xx) (R680) The number of PUs consumed by the configured Timer point type.
configured Timer point type of the selected node in LM/SM node.
TYPE – Real

Continued
$RDAVGC (R660) The parameter read rate (running average per second) in the current
hour.
TYPE – Real
$RDAVGP (R660) The parameter read rate (overall average per second) in the previous
hour.
TYPE – Real
$RDAVGS (R660) The parameter read rate (per second) in the last 15 seconds.
of data-access read requests.
TYPE – Real
$RDMAXC (R660) The maximum number of parameters that have been read in any one
second in the current hour.
TYPE—Integer
$RDMAXP (R660) The maximum number of parameters that have been read in any one
second in the previous hour.
TYPE—Integer
$SEQMAXC (R660) The maximum number of sequence events/messages in any one

second in the current hour.
processing of sequence events and messages.
TYPE – Integer

Continued
$SEQMAXP (R660) The maximum number of sequence events/messages in any one

second in the previous hour.
TYPE – Integer
$SEQMEM(xx) (R680) The sum of sequence slot size of all the Process Module points.
PURPOSE - Indicates the sum of sequence slot size of all the
Process Module points in the selected PM/APM/HPM node.
TYPE – Integer
$SEQTOTC (R660) The maximum number of sequence events/messages sent to the

TYPE – Real

Continued
$SEQTOTP (R660) The maximum number of sequence events/messages sent to the

LCN in the previous hour.
TYPE – Real
The maximum number of sequence events/messages sent to the

$SEQTOTS (R660) LCN in the previous 15 seconds.
TYPE – Real
$STRMAXC (R660) The maximum number of parameters stored in any one second in the
current hour.
TYPE – Integer
$STRMAXP (R660) The maximum number of parameters stored in any one second in the
previous hour.
PURPOSE - Indicates the loading on NIM with respect to
TYPE – Integer
ALBURST The maximum number of events in any one second that has occurred
since the NIM was loaded or the parameter was reset by the
operator. Event types included in this count are the same as for
EVTRATE.
TYPE— Integer
CPTIMEFL (R660) The time required to checkpoint to a drive.

PURPOSE - Indicates the loading on NIM with respect to check-
pointing. The parameter also indicates the time taken for the last
checkpoint, initiated either through the System Status Display or by
auto-checkpointing.
TYPE – Real

Continued
CPTIMEHM (R660) The time required to checkpoint to an HM.

PURPOSE - Indicates the loading on NIM with respect to check-
pointing. The parameter also indicates the time taken for the last
checkpoint, initiated either through the System Status Display or
by autocheck pointing.
TYPE – Real
DHMSGSEC(i) Parameter requests entering NIMs are split into 5 parallel queues of
differing priority, depending on the requesting function. The queue
with index 1 is the highest priority queue and queue number 5 is
the lowest priority queue. This parameter represents the average
number of messages per second flowing through a particular queue
during the last 15 second period. These values can be seen in the
PERFMENU schematic NIMDETAIL (R660).
Queue 1—NIM internal operations and operator changes.

Queue 3—history gathering and display call ups, including demand
updates after a change from a display.
Queue 4—trends, normal display updates, and tools and friendly
display queries.
Queue 5—point build, slow updates, SMCC access, and
organizational summaries.
DHPARSEC(i) Parameter requests entering NIMs are split into 5 parallel queues of
differing priority depending on the requesting function. The queue
with index 1 is the highest priority queue and queue number 5 is
the lowest priority queue. This parameter represents the average
number of parameters per second flowing through a particular
queue during the last 15 second period. These values can be seen in
the PERFMENU schematic NIMDETAIL (R660).
Queue 1—NIM internal operations and operator changes.

Queue 3—history gathering and display call ups, including demand
updates after a change from a display.
Queue 4—trends, normal display updates, and tools and friendly
display queries.
Queue 5—point build, slow updates, SMCC access, and
organizational summaries.

Continued
STRAVGC (R660) The parameter store rate (running average per second) in the
current hour.
TYPE – Real
STRAVGP (R660) The parameter store rate (overall average per second) in the
previous hour.
TYPE – Real
STRAVGS (R660) The parameter store rate (per second) in the last 15 seconds.
TYPE – Real

22.12 Application Processing Platform PSDP Parameters
$CHANNME (R651) Channel Utilization – Contains the application name associated with
each channel.
TYPE: 12 character string array (0-31). Not all applications have a
name.
$CHNHIGH (R651) Channel Utilization – Contains the number of reserved high priority
data access channels.
TYPE: Integer
$CHNDASR (R651) Channel Utilization – Contains the number of high priority data access
servers.
TYPE: Integer
$CHNRESR (R651) Channel Utilization –Specifies whether the channels are reserved for
high priority data access.
TYPE: Boolean array (0-31). If any element is true, then the
CHANINFO display shows YES (reserved) for that channel.
$CHNCONF (R651) Channel Utilization – Specifies whether each of the channels is
configured.
CHANINFO display shows YES or NO for that channel. If not
configured, CHANINFO will show blank.
$CHNACTI (R651) Channel Utilization – Specifies whether each of the channels is an
active data access channel.
$XACCESS Initial Security Setting – This PSDP can be in one of the following
states:
• READ ONLY – The Windows 2000-side can read but cannot write
TPS Network data.
• READ WRITE ONLY FOR CL INITIATED – The Windows 2000-

side can read TPS Network data, but can only write TPS Network
data from applications that are initiated by CL on the TPS Network-
side.
• READ WRITE – The Windows 2000-side can read and write TPS
Network data from CL-initiated and non-CL initiated applications
(this state cannot be set by any means unless the XACCESS external
load module is loaded.

22.12 Application Processing Platform PSDP
Parameters, Continued
ATTENTION .
For nodes that run CL server and TPN Server, the initial security
setting ($XACCESS) must be set to READ-WRITE. Currently
$XACCESS security is limited when Windows 2000 appplications use
the TPN Server to access TPN data.
The TPN Server supports only read-only access and read-write access.
When read-write only for CL Initiated Applications is selected, the
TPN Server will default to read-only access.

22.13 Global User Station PSDP Parameters
$CHANNME (R651) Channel Utilization – Contains the application name associated with
each channel.
TYPE: 12 character string array (0-31). Not all applications have a
name.
$CHNHIGH (R651) Channel Utilization – Contains the number of reserved high priority
data access channels.
TYPE: Integer
$CHNDASR (R651) Channel Utilization – Contains the number of high priority data access
servers.
TYPE: Integer
$CHNRESR (R651) Channel Utilization –Specifies whether the channels are reserved for
high priority data access.
CHANINFO display shows YES (reserved) for that channel.
$CHNCONF (R651) Channel Utilization – Specifies whether each of the channels is

configured.
CHANINFO display shows YES or NO for that channel. If not
configured, CHANINFO will show blank.
$CHNACTI (R651) Channel Utilization – Specifies whether each of the channels is an

active data access channel.

22.14 Reserved
This section number has been reserved to maintain the existing section
numbering.

22.15 Parameters On Every Point in the System
Introduction
Some parameters are on every point in the system, including reserved
points such as the processor status data points (PSDPs). These
parameters are known as the “generic” and “internal” parameters. The
“internal” parameters reveal individual fields of the internal form of
the point id. The “generics,” as the name implies, contain information
of a general nature that applies to all points. Internal and generic
parameters are “read only”.
Entity forms
A TotalPlant Solution (TPS) system entity (tagname) has an external
(alpha string) form (for example, 'A100') and an internal (numeric)
form. The external form uses regular uppercase ASCII characters and
can be 19 bytes long (16 for the entity name, 2 for the network name,
and one delimiter character '\'). The internal form is stored and passed
around the LCN as a 16-character string (regardless of the long tag
option setting). Checkpoint files and memory lists of entities always
have 16 bytes of storage for the strings associated with each entity. If
the name is shorter, it is blank-filled to the right. The internal number
is not kept with the entity name, but is stored in the system and
associated with the name when needed. One or two character LCN
names are permitted.
External form
parameters
Some parameters associated with the external form of the entity are:
NAME
LOCTITLE
LOC_DESC
LOC_NUMB
Examples:
A100.NAME = 'A100' or FE\A100.NAME = 'FE\A100
$PRSTSxx.LOCTITLE = 'FE'
$PRSTSxx..LOC_DESC = 'Fuels East'
$PRSTSxx..LOC_NUMB = 5
Also, associated with the NG PSDP are REMTITLE[1..64],

REM_DESC[1..64], and REM_NUMB[1..64] for the same
information about remote LCNs.
If A100 is on network FE, then A100 will compare with FE\A100 if
the context you're in uses the Data Access routine written for
comparing entities.

22.15 Parameters On Every Point in the System, Continued
Date and Time Parameters
$ADATE2 The ASCII date in the form DD/MM/YY where DD is the day (01-31),
MM is the month (01-12), and YY is the year (00-99), maximum of 8
characters and no spaces. Also see $ADATE.
$ADATE The ASCII date in the form MM/DD/YY where MM is the month (01-
12), DD is day (01-31), and YY is the year (00-99).
Maximum of 8 characters and no spaces. Also see $ADATE2.
$ADATIM2 The ASCII date and time in the form DD/MM/YY hh:mm:ss:msms
where
DD is the day (01-31), MM is the month (01-12), YY is the year (00-
99), hh is the hour (00-23), mm is the minute (00-59), ss is seconds (00-
59), and msms is the tenths of milliseconds (0-9999).
Maximum of 22 characters and no spaces. Also see $ADATIME.
$ADATIME The ASCII date and time in the form MM/DD/YY hh:mm:ss:msms
where MM is the month (01-12), DD is the day (01-31), YY is the year
(00-99), hh is the hour (00-23), mm is the minute (00-59), ss is seconds
(00-59), and msms is the tenths of milliseconds (0-9999).
Maximum of 22 characters and no spaces. Also see $ADATIM2.
$ATIME The ASCII time in the form hh:mm:ss where hh is the hour (00-23),
mm is the minute (00-59), and ss is seconds (00-59).
Maximum of 8 characters and no spaces.
$IDAY The integer value of the day of the month (01-31), of up to two digits.
$IHOUR The integer value of the current hour (00-23), of up to two digits.
$IMIN The integer value of the current minute (00-59), of up to two digits.
$IMONTH The integer value of the current month (01-12), of up to two digits.
$IMSEC The integer value of the current tenth of milliseconds (0000-9999), of
up to four digits.
$ISEC The integer value of the current second (00-59), of up to two digits.
$IYEAR The integer value of the current year (0000-2047) of up to four digits.

$MONTH The enumerated value of the current month (JANUARY-

DECEMBER), maximum of 8 characters and no spaces (SEPTEMBR
is shortened).
TYPE: $MONTH
$TIMODAY The current LCN time in internal LCN time format. A 48-bit counter
of the number of tenths of milliseconds since base time (Monday
January 1, 1979 00:00:00:0000).
$WEEKDAY The enumerated value of the current day of the week (SUNDAY-
SATURDAY), maximum of 8 characters and no spaces (WEDNESDY
is shortened).
TYPE: $WEEKDAY
$YNCTIME Indicates whether or not time is currently synchronized.
Internal Entity Parameters

CRB The number of the LCN to which the node containing this point is
connected. A value of zero indicates the point is on the local LCN. If
CRB is requested for a local LCN point using the full notation (for
example, FE\A100) then the actual number of the local LCN will be
returned instead of zero. Points on remote LCNs never return the local
value of zero.
DATA_RLM The data realm of this point. The data realm is used internally, in part,
to route messages to the proper LCN node. Its value varies depending
on point type and the point’s data owner. For example: DATA_RLM
for AM points is equal to the unit number plus one; it's the hiway
number plus one for HG points, and the physical node number plus one
for the PSDPs, etc.
ENT_TYPE This point’s entity type ENT_TYPE is returned as an enumeration
value of the entity type enumeration set.
TYPE—Enumeration of ENTYTYPE
FUNC_SET This point’s function set. The function set is used internally, in part, to
route messages to the proper LCN node. Its value varies depending on
the point type and the “data owner” of the point.

LRC This point’s local routing code. The LRC is used as an index into a
logical node's entity database. A logical node contains all the points
with the same function set and data realm (see FUNC_SET and
DATA_RLM). Note: In the AM, each unit is a logical node. There
will be holes left in the index from deleting points. The system will fill
in the holes as you add new points. Use the Documentation Tool to
see the LRC codes for a node, unit, etc.
Internal Entity Fields
The internal form of the entity uses 8 bytes of storage to describe an

entity with a unique number. The fields of the internal entity are:
Internal Entity Field Parameter

entity type ENT_TYPE
unit UNIT or UNITNAME
LCN CRB (0 = local LCN)
function set FUNC_SET
data realm DATA_RLM
revision SERIAL
local routing code (2 bytes) LRC
Note that the LCN-function set-data portion of the entity ID is used as

a communication address to route Data Access requests around the
LCN. Once the request is in the right node, the local routing code
directs it to the right entity.
Whenever an entity is deleted, the storage location that it occupied in

the database is cleared out by placing blanks in the name and zeros in
every field of the internal ID except the revision. The revision field is
incremented by one so that the next entity that occupies that storage
location will not get the same internal entity ID even if it uses the
same entity type and unit, etc.

NAME The name of this point. For example, A100.NAME would return the
string: A100. If the CRB field of the internal entity id used in the
request is set to zero (local LCN), the value of NAME returns the
local notation (for example, “A100”). If the CRB field is set to a
nonzero value, the value of NAME returns the remote notation (for
example, FE\A100). This is useful for determining if an internal
entity id in your database is still valid. For example, the US uses this
parameter to detect that a point in a compiled group has changed so
that it can display MISMATCH in that slot. Performance tip: it is
faster to get the name of a point using the NAME parameter than it is
to do the opposite, that is, get the internal entity id by converting the
entity name.
TYPE—String
NODE_NO The physical node number of the node where this point resides.
Variable results can be returned for the $UNITOPS point (see
subsection 22.12).
NODETYPE The node type of the node where this point resides. The value of
NODETYPE is an integer that can be converted to a node type using
the following list:
0 = CG, CM60, CM60N, CM60S, etc.
1 = HG
2 = HM
3 = AM, APP, ESVT
4 = US, EP, UNP, UWS, UXS, GUS, ES-T
5 = reserved
6 = reserved
7 = reserved
8 = NIM
9 = NG
SERIAL This point’s revision level. This number is incremented each time a
position in the logical node entity database has an entity deleted. Its
value ranges from 0 to 255. When a point is rebuilt, all other fields
of the internal entity id can remain the same except this field.
Therefore, it can indicate a “rebuild count” of an entity.

SUBSCRPT This point’s subscript. Most points are not subscripted and return an
error if this parameter is requested. An example of a point type that is
subscripted is the GROUP point type. The subscript of a GROUP point
is related to the GROUP point's group number. No process point types
are subscripted.
UNIT This point’s unit number. UNIT is the index into the unit assignment
table for the unit associated with this point. Also see UNITNAME. For
example, if a point is in unit AA and AA is the first unit in the unit
table, UNIT returns a value of 1. The PSDPs are in the SY (system)
unit and return 101 as the value of UNIT.
UNITNAME This point’s unit name. UNITNAME is returned as an enumeration
value of the unit enumeration set. Also see UNIT.

Section 23 – Configuring for Performance
23.0 Overview
Introduction
This section defines two items that are the basis for system
performance measurements and system integrity. These items are
• The Performance Cluster concept, and
• The Honeywell Control Unit (HCU)
Other
performance
described
Guidelines for configuring LCN-based equipment for predictable
performance and for estimating AM performance are also provided.
Finally, this section includes History Module performance hints.

23.1 The Performance Cluster Concept
Introduction
The LCN is a complex network of different types of nodes, and to
facilitate network configuration and understanding the effect of that
configuration on system performance and integrity, the performance-
cluster concept was developed. We recommend it as an aid in
configuring the system hardware.
The Performance
Cluster
An operator in a plant is usually responsible for a specific process. That
process employs a set of equipment used to produce a product. The
performance-cluster concept aligns the LCN-based TotalPlant Solution
(TPS) System equipment needed to support such an operator. An
example of a cluster is shown below.
Figure 23-1 The Performance Cluster
CM
US 1 US 2 US 3 US 4 AM HM
CG
NIM or
NIM
HGor HG
UCN or Data Hiway
NIM or HG Primary
and Secondary
Process-Connected
Devices
1246
Each performance cluster includes one physical Universal Control

Network (UCN) or one physical Data Hiway. The process is connected
to the process-connected devices on the UCN or hiway and they are
carried through to the LCN by a NIM pair (UCN) or by an HG pair
(hiway). Advanced control is organized into units and is processed in an
AM. Process history is collected by an HM.
The performance of the cluster is adequate to handle the process and to

provide maximum responsiveness to the operator.
While it is possible to configure the equipment in combinations other
than that of the cluster, the performance values given here apply to
only the cluster with the mix of equipment described here.

23.1 The Performance Cluster Concept, Continued
Notice
This section provides performance data for performance clusters that
include either an HG and a Data Hiway or a NIM and a Universal
Control Network (UCN). This data is valid for UCNs with Process
Managers, only. At the time this publication is printed, performance
data for clusters that include a UCN with one or more Logic Managers
(LMs) is not available. This section will be revised when performance
data for clusters with LMs is available.
The statements about performance of the performance cluster assume

that one NIM pair and associated Universal Control Network are
included in the cluster, or that one HG pair and associated Data Hiway
are included in the cluster, but not both. In this section, "NIM/HG"
refers to either a NIM or an HG, but not both.
The Console, Area,

and Units of the
cluster
A console that consists of one to four Universal Stations is provided in
the cluster for the operator's use in monitoring and controlling his or
her area in the process. That area consists of one or more physical
process units, which are sets of process inputs and outputs on a piece
of plant equipment. The figure below illustrates this concept.
Figure 23-2 Console, Area, and Units
Console for One Operator
One Area
Unit 1 Unit 2 Unit 2 . . . Uni

1247

23.1.1 Performance Cluster Capacity
Introduction
Here, we list the capacities expected from the nodes in a cluster using
68020 and 68040-based processors.
Application
Module
The AM serves the area with up to 220 valves under advanced control
at a rate of up to 90 control points per second for 68020 AMs. This is
increased to 290 valves and 120 control points/sec for 68040 AMs.
History Module
The HM serves the area, collecting up to 2400 history points on a 68020
HM, and can provide storage for other cluster- and area-related data
(refer to 7.2 and see Table 7-9). We recommend a separate HM be used
to store "convenience-" and system-related data (refer to 7.2 and see
Table 7-9). For a 68040 based HM this can be increased to 3000 points.
Console
The console serves the area and one operator.
It has from one to four USs and we recommend a minimum of three.
In large systems, a separate engineer's console with one US, a disk
drive, and a printer is useful.
Process
connections to the
area
One NIM pair or one HG pair serves the area. Each 68020 NIM pair
handles up to 8000 data points. Each HG pair handles up to 3000 data
points. The parameter access per second limits are as follows.
No AM Control AM Control at AM Limit

HG 68020 1200 630
HG 68040 1800 960
NIM 68020 1200 750
NIM 68040 2000 1400

23.1.2 Cluster Performance (68020-Based Processors)
Introduction
To state the performance of a cluster, it is necessary to define the
operating conditions at the time the performance is measured. The
following values are for a 1-second measurement period.
Universal Station
No. 1
Has a Group Display that is updated every 4 seconds. This display
shows 5 NIM/HG points (total of 100 parameters), 3 AM points (total
of 60 parameters), and 4 trend-pen points (2 NIM/HG points, 2 AM
points) updated every 4 seconds.
Universal Station
No. 2
A Group Display is called up. This display is updated every 4
seconds. It shows 8 NIM/HG points (total of 240 parameters), and 4
trend-pen points (total of 4 parameters) updated every 4 seconds.
Universal Station
No. 3
Has a Schematic Display that is updated every 4 seconds. This display
shows 150 update areas (total of 150 parameters), and 4 trend-pen
points (2 NIM/HG points and 2 AM points) updated every 4 seconds.
Universal Station
No. 4
A Schematic Display is called up. This display is updated every 4
seconds. It shows 150 update areas with 100 NIM/HG-point
parameters and 50 AM parameters, and 4 trend-pen points (2 NIM/HG
points and 2 AM points) updated every 4 seconds.
Application
Module
The 68020 AM has a 90 control points per second processing capacity
with 100 parameters input from NIM/HG points and 50 output
parameters to the NIM/HG (150 "off-node" parameters). This is with
automatic checkpointing in progress. 68040 increased to 120
PTS/Sec.

23.1.2 Cluster Performance (68020-Based Processors),
Continued
NIM or HG
The NIM/HG is handling 1 alarm per second with a burst of 30 alarms
per second, once per minute.
History Module
The 68020 HM is collecting history for 2400 points per minute (1600
NIM/HG points and 800 AM points) for three history groups (60
points) per second. Automatic checkpointing is in progress for the
NIM/HG, AM, and this cluster's event journal is on this HM. The
68040 increased to 3000 PTS/Sec.
Computer
Gateway
Every 5 seconds, the CG inputs 100 parameters; 60 of these are from
the NIM/HG and 40 are from the AM. The CG outputs to the AM
every 1 minute, which is an insignificant load on the AM.
Overhead
In a multiple cluster system, about 10% of additional data-transfer
overhead occurs because of cross-cluster transactions.

23.1.3 LCNEs in Performance Clusters
Introduction
LCN Extenders (LCNE and XLCNE2) can be used to connect two
clusters. What follows are some important guidelines for positioning
LCNEs and XLCNE2s in a network.
References
Service.
Guidelines
The following is a summary of those guidelines:
• Both NIM/HGs in a NIM/HG pair should be on the same coaxial-
cable LCN segment. They should not be separated by an LCNE or
XLCNE2 and a fiber-optic LCN segment.
• All USs in a console should be on the same coaxial-cable segment.
NIM/HGs that often communicate with a given US should be on the
same coaxial-cable segment as that US.
• If the Clock Source Repeater is not used, the two clock-source
nodes must be on the same coaxial-cable segment.
• Each LCNE or XLCNE2 can be housed in the chassis for one of
these node types: NIM/HG, AM, HM, CG, or US. Because the
NIM/HG is the least likely of these node types to have its power
turned off, it should be considered as the first choice.

23.2 The Honeywell Control Unit
Description
The HCU is the second concept that performance measurements are
based on. The HCU represents a 10-valve control unit. The cluster
can be expected to handle from 10 to 20 HCUs, depending on the mix
of point-processing rates and the memory used by the points in the
AM. Table 23-1 defines the mix of points in the HCU
Notes about the

sample Honeywell
Control Unit
The total number of NIM/HG points is 89 maximum
The total number of AM points is 65
The total number of data points in the HCU is 154
Percentage of AM fetches and stores for CDS parameters 30%

Percentage of AM fetches and stores on the same point 30%
Percentage of all fetches and stores to other units 5%
For every 4 HCUs, a CG adds about 4 points to initiate ACPs, but the
data references are out of the points listed on Table 23-1. The load on
the AM is about 440 fetches and 40 stores per second (120 per second
for the cluster).
Average AM
Pt/Sec. rate for
one HCU
68020 HPHCCU = 5.1 points per second
68040 HCU+ = 8.45 points per second

23.2 The Honeywell Control Unit, Continued
Table 23-1 Sample Honeywell Control Unit (HCU) Point Mix

(68020-Based AM)
Node Point Type Number Processing Period in Comments
Seconds
NIM Regulatory 10 These are the 10 valves. One of

them (10%) uses DDC control from
the AM (AM output goes to the
valve through the OP parameter of
a PMAO point).
Nonregulatory
Analog Input 55
Analog Output 1 No history
Digital Input 15 No history
Digital Output 3 No history
Digital Composite 2 No history
HG Regulatory 1 These are the 10 valves. One of

4 them (10%) uses DDC control from
5 the AM.
1 Cascade to a PID in the box

2 Data Acquisition, only.
Nonregulatory
RV (CB) 10
PIU Analog Input 45
PIU Analog Output 1 No history
PIU Digital Input 15 No history
PIU Digital Output 3 No history
PIU Digital 2 No history
Composite
AM Regulatory
DDC 1 1
Basic Primary 1 2
Highest Primary 3 10, 15, 60
Ratio 3 2, 5, 15
Simple Calculation 19 2 at 5, 1 at 10, 8 at 15, 7 Various algorithms and four different
at 30, 1 at 60 CL blocks.
CL + PID 5 15
CL + CL 5 10, 2 at 15, 1 at 30,

1 at 60
Other 3 5, 10, 15
Nonregulatory 18 (Not scheduled)

2 (Not scheduled) No history
3 10 No history
2 300 No history
HM History Groups 8 History for 126 points

Note: Effective AM HCU load = 5.1 Points per Second per HCU

23.2 The Honeywell Control Unit, Continued
Table 23-2 Sample Honeywell Control Unit (HCU) Point Mix

(68040-Based AM) continued
Node Point Type Number Processing Period in Comments
Seconds
NIM Regulatory 10 These are the 10 valves. One of

them (10%) uses DDC control from
the AM (AM output goes to the
valve through the OP parameter of
a PMAO point).
Nonregulatory
Analog Input 55
Analog Output 1 No history
Digital Input 15 No history
Digital Output 3 No history
Digital Composite 2 No history
HG Regulatory 1 These are the 10 valves. One of

4 them (10%) uses DDC control from
5 the AM.
1 Cascade to a PID in the box
2 Data Acquisition, only.
Nonregulatory
RV (CB) 10
PIU Analog Input 45
PIU Analog Output 1 No history
PIU Digital Input 15 No history
PIU Digital Output 3 No history
PIU Digital Composite 2 No history
AM Regulatory
DDC 1 1
Basic Primary 1 1
Highest Primary 3 10, 15, 30
Ratio 3 1, 2 10
Simple Calculation 19 3 at 5, 11 at 10, 3 at Various algorithms and four different
15, 2 at 30 CL blocks.
CL + PID 5 2 at 5, 3 at 10
CL + CL 5 5,3 at 10,15
Other 3 2, 5, 10
Nonregulatory
18 (Not scheduled)
2 (Not scheduled) No history
3 5 No history
2 120 No history
HM History Groups 8 History for 126 points

Note: Effective AM HCU load = 8.45 Points per Second per HCU

23.3 Focused Load Concept
Data owner nodes

In relation to the performance load cluster, you must also consider the
effect of a focused load on a node. Data is “owned” by such nodes as
the HG, NIM, AM, and CG. When a data owner is accessed by other
nodes to obtain data for such things as history and displays, a load is
imposed on the data owning node. A focused load occurs when a
number of nodes request data simultaneously from a data owner and
the amount of data requested is great.
A focused load can also occur on a UCN node (PM, APM, etc.) when
other nodes simultaneously request large amounts of data.
Performance
problems
A focused load can cause performance problems. Increasing the
number of USs in a console, or temporarily increasing the number of
USs using a display that accesses one or two data owners, during a
plant upset, for example, can aggravate performance problems. In the
structure of the LCN, the typical hierarchy of access can cause a load
to be focused on one data owning node, as the following figure shows,
and can lead to performance problems on that node.
Concept figure
Figure 23-3 Focused Load on Data Owner
US
US AM
US HM
US CG
Focused load
HG/ reduces data owner's
NIM performance.
15046

23.4 Factors that Affect System Performance
Introduction
Here we discuss configuration or operational factors that you can use
to improve system performance.
Don’t configure
boxes that do not
exist
Data Hiway performance is enhanced if you don’t configure process-
connected boxes that do not exist. Failed boxes should be repaired
and placed back in service as soon as practical, because failed boxes
that are not restarted impair hiway performance.
Give priority to
preferred access
devices
Configure preferred access devices on Data Hiways (HGs, Operator
Stations, and computers) with the highest priorities (lowest hiway
addresses) to provide quick access for these devices. If you have
hiway-grant errors for such devices, consider rearranging the
addresses for the more critical devices (for more information, refer to
Hiway Gateway Implementation Guidelines).
Do not exceed a
Data Hiway’s rated
load
The content of Data Hiways should be carefully organized so that the
total load on any HG pair does not exceed the rated load of the HG
(refer to Hiway Gateway Implementation Guidelines).
Use the cluster

concept
Follow the cluster concept as closely as practical. A cluster should
handle control for only one area.

23.4 Factors that Affect System Performance;, Continued
Minimize cross-
cluster activity
Take care that cross-cluster activity caused by access from other
consoles doesn't become a normal operating condition. This increases
the load on the AM and the NIM/HG pair.
Organize the
pathname catalog
Organize the pathname catalog in the area database so that the most-
often-used schematics are listed first. This reduces the search time to
access HM resident displays. The US “remembers” the last three
custom schematics accessed from the HM to further improve
performance.
Complex
schematics take
longer
Complex schematics (those with many subpictures, complex solids,
and such) are less efficient to display and take longer to call up to the
screen.

23.5 Estimating LCN Load on Your System
An experience-
based estimator
The estimator chart provided below was derived through actual
operating experience. Most of the data that contributed to the chart
was obtained from Honeywell’s Large System Test Facility in
Phoenix.
You can use this estimator to obtain an estimate of the load on your
LCN at the time you take the required data.
Remember, this
yields only an
estimate
We believe this estimate is conservative, but any decisions or changes
you make as a result of using this estimator are your responsibility.
What we learned
by developing this
estimator
Sustained overloading of an LCN is rare. The average load on most
LCNs rarely exceeds 30%. If you have symptoms of overloading such
a slow access times or overrun error messages, the problem is more
likely caused by loading of individual nodes, rather than exceeding the
LCN capacity.
How to make an
estimate
Perform the following steps:
Table 23-2 Estimating LCN Load on Your System

Step Action Result
1 On the PERFMENU display The PARCHKR display appears
(see Section 10), select showing the PARSEC value for
PARCHKR. each node on the LCN.
2 Add all of the PARSEC The total parameters per second
values. value for the LCN.
3 Use the total parameters per This is the estimated LCN load at
second value to find the % the time you read the PARSEC
value. values. If yours is a small system
with little history collection, 4-
hour checkpointing, and a low
event load , the load will be about
10% less than the chart
indicates.

23.5 Estimating LCN Load; on Your System,; Continued
The LCN load

estimator chart
Use this chart to estimate your LCN load. For smaller LCN systems
(30 nodes or less), reduce the estimate from the chart by 10 percent.
This chart was set up for a large, busy system.
Figure 23-4 LCN Load Estimator Chart and explanatory notes
Explanatory notes for Figure 23-4:

A Estimated base load for 64 running but non-operating nodes.
B Estimated heavy alarm load in 64-node LCN (12/sec. + 180
burst/min.).
C Estimated checkpoint load with 7 Hiways/UCNs, 7 AMs, 2 CGs,
10 minute checkpoint interval; checkpoints taking about 5 minutes.
D Estimated history load with 15,000 history pts, 1 min. rate, 7 HMs.
E Practical limit (65-70%) for a constant LCN load.

23.5 Estimating LCN Load; on Your System, Continued
NOTE
A characteristic of highly loaded LCN operation is a swing of 15-20%
around the average LCN load. Based on tests with the Large System
Test Facility, the average load on any operational LCN system should
not exceed 60-65%. Exceeding this load may cause the loss of
redundancy (one of a pair of nodes will crash). The busiest customer
systems in the field today have an LCN load in the 30% range.
Operating with
more than 85%
LCN load
Extended operation with an LCN load that exceeds about 85% can
cause any of the following:
• One of the nodes in a redundant-node pair fails (crashes).
• Long display call-up and update times.
• AM overruns, “hold-breath” messages, and prefetch or prestore
problems.
• HM history overruns and history loss.
• Loss of synchronization in digital clocks (LCN segments with only
K2LCN processor boards).
• Inability to ride-through LCN cable failures.

23.6 System load calculation tool
Introduction
With R680, the LCN load can be monitored using the System Load
Calculation Tool. The LCN Load is calculated based on a formula and
the calculated value is displayed in the LCNPERF schematic. The
display can be accessed through the LCNPERF target in PERFMENU.
For more information about viewing the load details through

LCNPERF display, refer Section 18.19 of the Process Operations
Manual.
Purpose
The load calculation tool provides an online mechanism to calculate
the total load on LCN and other LCN load related parameters. The
LCNPERF schematic displays the following:
• A tabular view of the selected load parameters for individual LCN

nodes
• Estimated percentage of LCN load
• The selected LCN load parameters
The parameters displayed in the LCNPERF schematic can be used for

the following purposes:
• Monitoring the LCN load

• Changing the Trip limits
• Enabling / Disabling load calculation task

23.6 System load calculation tool, Continued
Load Calculation
Formula
The LCN load calculation tool runs on the US node. The PSDP
parameter $CALCPRD enables the load calculation task and controls
the periodicity of load calculations.
ATTENTION
ATTENTION –Honeywell recommends enabling the load calculation
task only on one or two nodes per segment, as it accesses more than
200 parameters.
When the load calculation task is enabled on any US/GUS node, the
CPUFREE of that node reduces by 10%-13% initially and will have an
offset of 4%-5% after the initialization. This does not have any
significant effect on the performance of the node.
The following formula is used for calculating the total estimated

percentage of load on LCN:
Formula 1: For calculating the total Estimated % of Load on LCN
Percentage load on LCN =( (total_par_sec + 1500 + (msg_per_sec * 7))/ 8800) *

100 * ($PARLIMX (0)/4500) + $PARLIMC (0).
where,
total_par_sec is the total number of parameters (on AM, NIM, HG, CG and NG
nodes) per second.
msg_per_sec is the number of messages (on AM, NIM, HG, CG and NG nodes)
per second.
Note: The Base load is calculated as follows:

(1500/8800)*100 = 17.05 %
The base load is 17.05% for a typical traffic on LCN for non-data
access. When multiple segments are configured on a network, the base
load of 17.05 will be distributed amongst the segments. This
distribution helps to avoid the base load being reckoned repeatedly.

Trip limits
The trip limits are used for diagnosing the LCN load parameter values.
If the load values cross the trip limits, the load values are indicated in
different colors and a system alarm is raised.
The following are the configurable PSDP parameters for the trip
limits:
• $PPMLOTP (0) (Low trip limit for parameters per message)

• $PPMLLTP (0) (Low low trip limit for parameters per message)
• $LDHITP (0) ( High trip limit for estimated percentage of LCN
load)
• $LDHHTP (0) ( High high trip limit for estimated percentage of
LCN load)
Node specific load

details
The schematic displays the node specific details for the following node
type groupings:
• AM/APP/ESVT, NIM, HG, CG and NG nodes

• US/GUS/ES-T, HM nodes
• All Nodes
The following load related parameters are displayed in the schematic

for each node that is configured and running on the LCN:
• PARSEC - Parameters per second

• MSGSEC - Messages per second
• PARMSG - Parameters per message (Calculated as
PARSEC/MSGSEC)
• CPUFREE
• Node status

Node specific load

details, Continued
The parameter values are displayed in different colors based on the
load. The following table lists the limits and the applicable color
indication for the node specific parameters:
Parameter Limit Color Node Status
MESSAGES PER SECOND <=35 CYAN NA

(REQUESTS)
>= 35 AND <=40 YELLOW HI MSG RATE
> 40 RED HH MSG RATE
PARAMETERS PER >=50 CYAN NA

MESSAGE (PARSEC /
REQUESTS) >= 20 AND < 50 YELLOW LW MSG EFF
< 20 RED LW MSG EFF
CPUFREE (CPUFREE) >40 CYAN NA
>20 AND <= 40 YELLOW HEAVY LOAD
<= 20 RED OVER LOAD
LCN load details

The schematic displays the following LCN load details:
• TOTAL LCN PARSEC – Total parameters per second

• TOTAL LCN MSG/SEC – Total messages per second
• AVERAGE LCN PAR/MSG – Average LCN parameters per
message
• ESTIMATED % LCN LOAD
• LCN LOAD Status (LOW, MODERATE, HEAVY, EXTREMELY
HEAVY)
• Trip limits for parameters $LPARMSG (AVG PARAMETERS
PER MESSAGE) and $TOTLOAD (ESTIMATED % LCN LOAD)

LCN load details,

Continued
The following table lists the limits, color indication and the applicable
PSDP parameters for the LCN load parameters:
Load Parameter Limit Color PSDP

parameters
AVG PARAMETERS >= $PPMLOTP(0) GREEN $PARMSG(ss)

PER MESSAGE
>= PPMLLTP (0) AND YELLOW
<= $PPMLOTP (0)
< $PPMLLTP (0) OR If RED

$PPMALFL (0) set to TRUE.
ESTIMATED % LCN < $LDHITP (0) GREEN $TOTLOAD(ss)

LOAD
>= $LDHITP (0) AND YELLOW
<= $LDHHTP (0)
> $LDHHTP (0) OR If RED

$LDALFL (0) is set to TRUE.
LCN LOAD STATUS < 35 – LCN LOAD IS LOW GREEN N/A
>= 35 AND < $LDHITP(0) –

LCN LOAD IS MODERATE
>= $LDHITP (0) AND YELLOW

<= $LDHHTP(0) – LCN
LOAD IS HEAVY
> $LDHHTP (0) – LCN RED

LOAD IS EXTREMELY
HEAVY or If $LDALFL(0) is
set to TRUE.

System alarms
The system alarms (of event type 49) are generated when the
parameter $LPARMSG or $TOTLOAD crosses the configured limit.
The PSDP parameter $LDALDB allows you to set the deadband for
the system alarms. The generated alarm indicates the parameter that
triggered the alarm. The system alarms are generated only for the LCN
level load details and not for the node level load details. When the
system alarm is raised, the US node on which the tool runs is switched
to MAINT state.
Note: When the deadband value is set to 100, the system alarms are
not raised even if the parameter $LPARMSG or $TOTLOAD crosses
the configured limit.
A tip: Load
analysis
The LCN load specific parameters and the node specific parameters
can be historized and used for analyzing the load on LCN. The PSDP
parameters used for representing the LCN load cannot be historized.
However, these load specific PSDP parameter values can be stored in
the custom parameters of an AM custom point. Alternately PSDP
parameters can be historized directly in PHD. The customized
parameters can be historized and used for generating Trend reports.

TPN bridge
support
If a TPN bridge exists in the network, the LCN load parameters are
calculated and displayed for each individual segment.
If the LCN nodes are grouped into various segments, (similar to the
actual TPN-Bridge cluster membership), the schematic displays the
following details:
• The load parameter of nodes that belong to a specific segment.
• The LCN load parameters of a specific segment.
LCN node –
segment
relationship
The LCN nodes are grouped into segments, to monitor the segment-
wise load on the LCN. If a TPN bridge exists in the network, the
physically connected LCN nodes of the TPN bridge network are
grouped into segments. If there is no TPN bridge in the network, the
nodes can be grouped into segments based on the criteria such as type,
controlling specific process units and so on. The CLSNODE.DS can
be compiled and used for defining the node membership on these
network segments.
CLSNODE.DS file
For load calculations, the CLSNODE display is used for assigning
segment numbers to the LCN nodes. Before invoking the CLSNODE
display, the INITIALIZE CLSNODE target in the CLSNODE.DS
file is to be modified using the Picture Editor. All the nodes in the
network is to be assigned with a segment number. By default, 0 is
assigned as segment number for all the nodes. The segment number is
to be assigned to the LCN nodes as shown in the following example:
SS_INT(ENT20.$CLSNODE(94),5);
Where,
94 – denotes the LCN Node number
5 – denotes the segment number

CLSNODE.DS file,
Continued
The CLSNODE.DS file is compiled and is used later for initializing

the node-segment relationship.
When a US node is rebooted and/or a node is moved to a different

segment, the default value 0 is assigned to the segment number of all
the nodes. The segment numbers are re-assigned using the
CLSNODE.DS file.
The CLSNODE.DS file can be edited and the node-segment

relationship can be saved permanently using the picture editor. The
segment numbers can be dynamically assigned to the nodes by directly
accessing the CLSNODE.DS file.
Reference
For more information about CLSNODE display, refer Section 18.19 of
the Process Operations Manual.

CLSNODE display
The $CLSNODE(nn) (where nn is the node number ranging from 1
through 96) parameter array for an US node appears in the CLSNODE
display. The parameter value indicates the segment number assigned
to the nodes. These segment numbers are displayed in individual
boxes for each node in the CLSNODE display. The segment numbers
corresponding to the node numbers can be edited in the individual
boxes.
When the node-segment is defined, use the INITIALIZE CLSNODE

target to write the segment number to the PSDP parameters.
The node-segment relationship must be defined using the CLSNODE

display for every node on which the load calculation tool is running.
References
With TPS 340, LCNLOAD_G400.PCT is provided as an RAC display
utility. This display is used for viewing/analyzing the total load on the
LCN and on the AM/NIM/HG/CG/NG nodes.
See Section 8 of the TPS System and Process Operations Guide for
further information on LCNLOAD_G400.PCT.
For information about PSDP parameters, refer Section 23.5.

23.7 HM Performance Hints and Rules of Thumb
Introduction
The following section gives you hints and rules of thumb for
improving the performance of your History Module (HM) in the
following areas:
• HM utilization
• Continuous history
• Directory Searches
• Event Journal
CAUTION .
These hints and rules of thumb are generally true. Like all general
principles, however, there are exceptions to the rules, so the rules
should be applied thoughtfully. HM system performance, in particular,
is highly dependent on system configuration and system load because
each user’s environment and system configuration has unique
characteristics. Response time and load percentages should be used
only as guidelines.

23.7.1 HM Utilization
HM utilization
Use the following hints and rules of thumb to determine if your HM is
over utilized or under utilized:
1) If the HM's average CPUFREE is below 40%, the HM is fully
loaded; you should not add any additional burden to it. Keep the
rest of the CPU free in the event of process upset, which cause
heavy burst loads.
2) A corollary to rule 1: If your HM's average CPUFREE is already
below 35%, seriously consider reducing the load on your HM,
because it may not be able to handle heavy burst loads. This is
especially true if this HM's performance already is slow.
3) If the average number of disk transfers exceeds 800-900 transfers
per minute, the HM is fully loaded; you should not add any
additional burden to it.
4) A corollary to rule 3: If your HM's average disk usage exceeds
1000 transfers per minute, seriously consider reducing the load on
your HM, because it may not be able to handle heavy burst loads.
This is especially true if this HM's performance already is slow.
5) To track the load on your HM, historize its CPUFREE and disk
transfers per minute using regulatory AM points.

23.7.2 Continuous History Hints and Rules of Thumb
Rules of thumb
1) Use this guideline to decide if you can put more load on your HM: a
full 40 PPS load of continuous history of any single collection rate
will add approximately 11% CPU load (for a 68020 processor) and
3.5 disk transfers per second. Equivalent loads are: 2400 60-second
points, 800 20-sec points, 400 10-sec points and 200 5-sec points.
2) Use this guideline to decide if you can put more load on your HM: a
full 40 PPS load of continuous history of mixed collection rates will
add approximately 17% CPU load (for a 68020 processor) and 5
disk transfers per second.
3) Schedule background functions (logs, history retrieval, journal
retrieval, checkpoints, prints to virtual printers) so that the HM is
not overloaded with requests all at once and, especially, not during
its (continuous history) marshalling and average calculation cycles.
Try to stagger the background requests before and after these
cycles.
4) Ask for more history (both event and continuous history) less often,
rather than less history more often. For continuous history, a good
approach is to ask for 1 hour's worth of snapshots every 60 minutes
(but schedule it 3-8 minutes after the top of the hour).
5) Request backward retrievals for recent continuous history data.
Request forward retrievals for older history data. If the rules are
observed, the difference in load on the HM for these retrievals can
be as high as 10:1 (as described in the following scenario):
For 999 hours of 1-minute continuous history snapshots, you want
to retrieve the last 5 hours of 1-minute snapshot data. A forward
search loads the HM because the search occurs from the beginning
of the file (59700 samples) before the requested data is located. A
backward search does not load the HM because the last point
collected is the first sample accessed; therefore, no search is
required. Not all functions can do backward retrieval.
6) Know and apply the rules for programming effective continuous
history retrievals (See Section 7 of this manual). Inefficient retrieval
of continuous history snapshot data often imposes extremely
burdensome (and unnecessary) loads on an HM and is the major
cause of HM performance degradation.
7) Configure only as much continuous history snapshot data as you
will need. Configuring many hours of snapshot data creates large
files and impacts performance. This effect is multiplied for fast
history. For example, 8 hours of 5 second data takes twelve times as
much disk space as 8 hours of 60 second data.

23.7.3 Fast Search User Volume
Improve system
performance
In R500, an HM fast search user volume is available to provide you
with directory searches 20 times faster than the standard linear
volume/directory search method by using an AVL (binary search) tree
algorithm. This means quicker access to schematics and other files in
the user volume. Also, the fast search volume usually improves
performance of all system functions that rely heavily on directory
searches, including copy files, delete file, create file, copy file, read
file, and schematic access. This value of this function becomes even
more significant as you move to larger History Modules, which will
have more files to search.
Binary search vs.

linear search
Files not on a fast search user volume are located using a linear
volume/directory search. This is very time consuming for user
volumes configured for many files because all configured volume
directory entries are searched to the requested file, even if these entries
are empty. This is often a significant factor in slow schematic call
ups. Honeywell’s AVL (binary search) tree algorithm maintains a
single fast search user volume with directories of frequently used files
and does a binary search of the sorted files in that volume,
significantly speeding the search process.
Configuration
By setting up a fast search directory in the fast search volume the HM
can locate files very quickly. The fast search volume is always the
first user volume defined in the user volume configuration page in the
HM.
Implementation
For maximum performance, Honeywell recommends the following:
1) Specify fast search directories first in the search path sequence.
2) Configure the fast search volume with as much space as possible.
3) Configure the fast search volume for the maximum number of files
(9995).
4) Place performance-critical schematics, pictures, CL's and other
critical files in the fast search volume.
NOTE: The fast search volume is limited to 63 directories and 9995
files. File descriptors are not available with the fast access option.

23.7.4 Directory Searches Hints and Rules of Thumb
Increase speed of
directory searches
Hints and rules of thumb that increase efficiency and speed of linear
directory searches:
1) Avoid using file descriptors. Configuration of file descriptors on a
volume will degrade the directory search performance of that
volume by between 35 and 100%, depending on HM configuration
and system load. Especially avoid file descriptors on the system
(&0np) and area (&3np) volumes.
2) Create volumes with fewer files. All file entries configured in a
volume are compared on a directory search. Therefore, the smaller
the number of files configured in the volume the faster the search
(shown below). Create one or more fast search user volumes by
configuring 500 or fewer files.
Requirement: Search for a schematic in 10 paths, where the
schematic is found in the last path searched. All 10 searches in
volumes configured for the same number of files. Note these search
times are approximations and will vary dependent on HM load and
configuration.
Number of files configured in Search time (seconds)
User Volume for 68020 processor
9995 18 sec.
1000 3.8 sec.
500 3.0 sec.
Number of files configured in Search time (seconds)

Area Volume (&3np) for 68020 processor
5000 3.8 sec.
1000 2.0 sec.
500 1.8 sec.

23.7.4 Directory Searches Hints and Rules of Thumb,
Continued
Increase speed of
directory
searches,
continued
3) The Area Database volume (&3np) has a memory resident directory
and offers fast directory searches. Under light HM load, a directory
search in the area volume is from 2 to 3 times faster (using a 68020
processor) than a user volume configured for the same number of
files. Access to the area volume is also more consistent. This speed
difference is even greater under plant upset/trip and heavy HM
loads.
4) Place schematics and logs in fast search volumes.
5) Configure search paths with performance in mind.
6) The WDA 445 and 512 drives are faster than WREN (I)(II)(III) and
WDA 210 drives because of a read cache on the drive controller.
Faster seek and read times also marginally increase performance.

23.7.5 Event Journal Hints and Rules of Thumb
Event Journal
rules of thumb
Event Journal hints and rules of thumb include:
1) The “burst buffer" is not a buffer at all. It is the file on the HM:
NET>!2np>BB000000.CM (where np is the HM node pair
number). This file is used as temporary storage for events before
they are passed on to the journal event sorting and distribution
functions. HM memory usage is not affected by the size of the burst
buffer.
2) It is a good idea to configure the burst buffer for 3 times the
maximum event burst that you expect. This sizing is very important
because if the burst buffer overflows events are permanently lost
and cannot be recovered.
ATTENTION .
Note that the burst buffer is sized to hold process alarms and will only
hold about one third as many operator messages (the largest event).
Event Journal
rules of thumb,
continued
3) The HM will time sort events when the events are received in the
HM sorting task within 10 seconds of the time the event occurred.
Events that are received in the HM sorting task outside of this 10
second window are written directly out to disk without being time
sorted.
4) SOE (Sequence of Events) events are post-sorted on retrieval
(Release 410 and after) and are always displayed in the proper time
order.

Section 24 – NCF and LCN Status Displays
24.0 Reserved
In earlier versions of this manual, this section contained information about NCF and LCN
Status Displays. Refer to LCN Guidelines - Implementation, Troubleshooting, and Service for
this information. This section has been retained to direct users familiar with an earlier version
of this manual to the new location of the information and to preserve the validity of references
to other sections of this manual.

Section 25 – LCN Reconnection
25.0 Reserved
In earlier versions of this manual, this section contained LCN Reconnection information.
Refer to LCN Guidelines - Implementation, Troubleshooting, and Service for this information.
This section has been retained to direct users familiar with an earlier version of this manual to
the new location of the information and to preserve the validity of references to other sections
of this manual.

Section 26 – LCN/Data Hiway Hardware Compatibility
26.0 Reserved
In earlier versions of this manual, this section contained LCN/Data Hiway Hardware
Compatibility information. Refer to Hiway Gateway Implementation Guidelines for this
information. This section has been retained to direct users familiar with an earlier version of
this manual to the new location of the information and to preserve the validity of references to
other sections of this manual.

Section 27 – How to Move to a New TPS Release
27.0 Overview
Introduction
This section defines a “release,” provides general advice about
upgrading your system software.
27.1 What is a Release?
Introduction
From time to time, Honeywell releases a new version of the LCN-
based TotalPlant Solution (TPS) system, usually with a designator
such as, "Release 500" or “R500”
What a “Release”
contains
These releases provide or offer new hardware or software products or
upgrades to existing products.
Usually, each major release is accompanied by a Customer Release

Guide that defines the changes provided or offered in the release and
provides instructions for implementation of that release.

27.2 Upgrading Software
New software
Most, if not all, releases are accompanied by new software. New
software for a system that is on-line and involved in process control
can usually be loaded into its node without breaking any “path to a
valve,” by using the Software Upgrade process.
System data
translation
In many releases, it is necessary to translate some of the system data,
such as the data in checkpoint files, to make it compatible with a new
software release.
Translators are provided for this purpose, usually in the Engineering
functions, and instructions for them are provided in the Customer
Release Guide that accompanies the release.

27.2.1 The Software Upgrade Process
Description
The upgrade sequence is designed to ensure an uninterrupted "path to
the valve" and continuing operator visibility of the process, with a
minimum of disruption and unnecessary alarming. It is based on a
characteristic of TPS that allows nodes running on differing releases
of software to coexist on the same LCN even though they are unable
to exchange data.
Is the upgrade
process required?
When new-release software is compatible with the previous release,
the Software Upgrade process is not used.
Instead, you load the new software images on the HM and, when
convenient, reload and restart each individual node.
The Customer Release Guide, or in some cases a release letter,
specifies whether this procedure is appropriate.
What is required?
The Software Upgrade process is to be used when a software release
includes changes that make new software for one or more nodes
incompatible with the previous version. You must choose between:
• Taking the whole system down for reloading, or
• Following the upgrade scenario
If you follow the upgrade scenario, you can do a node-by-node
changeover while continuing to view and control the process.

27.2.2 Preparation for a Software Upgrade
Plan ahead
Before starting, plan ahead. Know and record the sequence you will
follow and know what recovery steps are appropriate at each stage in
the event of problems.
Keep control
system in steady
state
HG and NIM redundancy are lost and functionality is reduced during
portions of this process. The control system should be in a steady
state and no unrelated Engineering functions should be attempted
during the upgrade.
Limit control
commands
Control commands should be limited to changes of OP, SP, and Mode.
It is best to start out with all nodes up and running their normal
personality software to make sure that they have compatible
configuration files.
Save to removable
media
A useful preliminary step is saving to disks the following:
• Directory &ASY
• Checkpoints for all nodes
• Area Database.
Save these removable media in a secure place for use if you need to
restart a node with old-release software before the upgrade process is
complete.
Do one cluster at a
time
If your system consists of two or more Performance Clusters (see
Section 23 in this manual), we recommend that you complete the
update of one cluster before starting the next.
Reference
Refer to the Customer Release Guide that accompanies the new
release for Software Upgrade instructions.

Section 28 – Purchased Options
28.0 Overview
Key File Options

Several software options are enabled through a Key File volume or
directory (&KFO) that is generated by Honeywell for each LCN. For
a new system, the Key File Options purchased for that system are
installed during the initial system start up (for more information, refer
to the System Startup Guide).
Subsection 28.1 provides the following information for each Key File
Option:
• The function of each key file option.
• How to install the option on an already operating system.
• How to remove the option, if that is possible.

Other software
Several application software options are available from Honeywell.
Many of these are installed through the Custom Software Backplane
(for more information, see Section 31 in this manual). Instructions for
the installation and use of each of these applications is included in the
application package.
For information about currently available application software, contact

your Honeywell account representative or site support specialist.
Hardware options
In earlier versions of the Engineer’s Reference Manual, subsection
28.2 provided specific information about kits available to add
hardware options to TotalPlant Solution (TPS) systems. Because the
hardware options offered by Honeywell have expanded significantly,
it is no longer practical to provide information about specific kits in
this section. Instead, subsection 28.1 now contains general
information about the types of kits available with guidelines for
system configuration changes you may need to make to accommodate
newly installed hardware options.
Most hardware options are either built into the TPS systems before
they are shipped, or are delivered as kits for installation in the field.
The built-in options are supported by the Site Planning, Installation,
and Service publications in this bookset. Each hardware option kit
includes a copy of its installation instructions.
For information about currently available hardware options, contact

your Honeywell account representative or site support specialist.
Hardware to
support Key File
Option
The following HM Disk Redundancy Key File Option requires a
History Module with dual disk drives.
Software key-files
If purchased, the software options described here are enabled by keys
built into the &KFO volume or directory by Honeywell. The &KFO
volume or directory is provided for each Local Control Network.

28.1 Key File Options
Introduction
In this section, each Key File Option is described, including the
documents that contain further information on that key file, along with
a brief installation procedure.
If the option can be removed after installation, that removal procedure

is mentioned.
Installation of the
key-files
The installation of the keys is accomplished in
• NETWORK CONFIGURATION, under SYSTEM WIDE
VALUES.
For a first time startup, these options are enabled by installing the key-
file options during initial Network Configuration. Refer to the System
Startup Guide. The instructions for installing the key files for a first-
time startup are in the “Configure System Wide Values” task.
Enabling these options in nodes that are already running, requires a

change to SYSTEM WIDE VALUES through on-line reconfiguration,
and requires that the affected nodes be shut down and reloaded with
files and data including the modified Network Configuration File
(NCF). Instructions for doing this for each option are provided in the
remainder of this section.

28.1.1 AM Redundancy
Description
A secondary Application Module backs up the operation of the
primary AM. All of the application data in the primary AM is
transferred to the secondary AM, where an exact copy of the data is
maintained to be used if the primary AM should become inoperative.
This option can be installed only in enhanced AMs with the 68020
microprocessor.
References
Refer to the Application Module Implementation Guidelines binder to
review guidelines for the implementation of Application Modules,
including guidelines for the AM Redundancy option.
Refer to Application Module Implementation Guidelines of this

manual for a list of the processor status data point (PSDP) parameters
related to AM Redundancy and definition the meaning of the values
they contain.
Refer to the LCN Guidelines - Implementation, Troubleshooting to

review instructions for adding a new node to an operating system.
Refer to the LCN System Installation manual for installation

instructions for the AM Redundancy hardware.
Refer to the Five/Ten-Slot Module Service for service instructions

including board locations and spare parts information.
Refer to the Network Data Entry for instructions for on-line

reconfiguration. This manual is used to install the new configuration
on the network.

28.1.1 AM Redundancy, Continued
How to install the

enhancement
Follow the kit instructions packed with the hardware options kit. A
backup AM can be added to an existing AM by adding a new AM to
the LCN and installing and interconnecting each AM. Power must be
turned off in each AM if any modifications are made to it.
Changes must be made in each of the following Engineering Main

Menu activities:
• LCN NODES—Add the backup node and add the new node’s
number as the redundant node.
• VOLUME CONFIGURATION—The AM checkpoint volume size
must be recalculated and reconfigured.
For more information, refer to the Application Module Implementation
Guidelines. Also see Tables 7-1 and 7-7 in Engineer’s Reference
Manual - this manual.
To startup, apply power to the AMs and see the Application Module
Implementation Guidelines.
How to take out

the enhancement
Shut down the backup AM. If LCN NODES reconfiguration was
completed, the backup nodes' status on the Node Status Display will
then be OFF. If Volume Configuration was completed, and if you
need to, you can reconfigure to go back to the original AM checkpoint
volume size.

28.1.2 HG Point Display Ranges
Description
Adds HG data point parameters that specify a scale that is different
than the full sensor range, for the PV and SP bars on the point's Group
and Detail displays.
For example, if the sensor has a range of 0°C to 100°C, values can be
entered in the display range parameters to make 0% on the bar
represent 50°C, and to make 100% on the bar represent 75°C.
Hardware required
None.
References
Refer to the Process Operations Manual. It provides instructions for
changing the display range and for use of the Group and Detail
displays.
Refer to Network Data Entry. It provides instructions for on-line

reconfiguration that is needed to install the option in the Universal
Stations.
How to install the

option
In SYSTEM WIDE VALUES, reconfigure SOFTWARE OPTIONS,
using the &KFO volume provided by Honeywell to enable this option.
After installing the new Keyfile option, shutdown and reload all
Stations (US/UxS/GUS/EST), one at a time. After reloading all
Stations, shutdown and reload all HGs.
Note: Shutdown the backup HG and reload it. Then shutdown the
primary HG (the backup HG is activated) and reload it.
To startup, follow the reconfiguration instructions on the Network

Configuration displays and refer to Network Data Entry.

28.1.2 HG Point Display Ranges, Continued
How to take out

the option
To take out this option, you must obtain a new key option file from the
Honeywell software distribution center, modify the NCF (System
Wide Values/Software Options/Load New Keyfile). After installing
the new Keyfile option, shutdown and reload all Stations
(US/UxS/GUS/EST), one at a time. After reloading all Stations,
shutdown and reload all HGs.
Note: Shutdown the backup HG and reload it. Then shutdown the
primary HG (the backup HG is activated) and reload it.
Instead of taking out this option, you can eliminate its effect for any
HG point by placing “--------” (NaN) in the display range parameters,
PVDSPHI, PVDSPLO, SPDSPHI, and SPDSPLO.

28.1.3 Enhanced Trend Pens
Description
Provides a Pen Assignment display that operators use to assign point
parameters to trend pens (without this option, pen assignments are
made through the Group display). A zigzag in a trend pattern
indicates that a pen has had a parameter reassigned to it. This option
also adds a trend-pen calibration function.
Hardware required
None.
References
Refer to the Process Operations Manual. It provides a description of,
and instructions for, the Pen Assignment display.
How to install the

option
In SYSTEM WIDE VALUES, reconfigure SOFTWARE OPTIONS,
using the &KFO volume provided by Honeywell to enable this option.

How to take out

the option
To take out this option, you must get a new key option file from the
Wide Values/Software Options/Load New Keyfile), then reload all US
nodes.

28.1.4 HM Disk Redundancy
Description
HMs with Wren III disk drives and HMs with WDAs (Winchester
Disk Assemblies) can be configured with redundant disk drives, if the
HM Disk Redundancy Software Option is purchased. When so
configured, a failure or other interruption of the operation of one of the
disk drives is reported but does not cause the HM to fail. The HM
continues to operate because the same data has been stored in both
drives, and read/writes continue on the “good” drive.
References
Refer to 7.5 of this manual for information about the operation of
redundant disk drives, configuring redundant HM disk drives, and
synchronizing the drives.
See Command Processor Operation. It provides instructions for using

commands related to HM disk redundancy: SYN, STA, and OFF.
Refer to the Network Data Entry for instructions for on-line re-
configuration needed to install the new configuration on the network.
For service information, see History Module Service. It also includes

the setting for the SCSI bus address on each drive to establish
redundant-drive partners.
How to install the

enhancement
Changes must be made in the following Engineering Main Menu
activities. On-line reconfiguration can be used to install the new
configuration on the network.
• SYSTEM WIDE VALUES—Reconfigure SOFTWARE OPTIONS,

using the &KFO volume provided by Honeywell to enable this
option.
• VOLUME CONFIGURATION—If there are two drives and they
are redundant partners, configure the Number of Disks as 1. If
there are four drives that are to serve as dual, redundant partners,
configure the Number of Disks as 2. If the disk drives are changing
to Wren IIIs, change the Type of Winchester Disks to 3.
After installing redundant drives, you must restore the primary drive
as explained above. Then, use the SYN command to copy all of the
data from the initial drive to its redundant partner. When the partner
drives contain the same data, they are said to be synchronized.

28.1.4 HM Disk Redundancy, Continued
How to take out

the enhancement
When the HM is started up with either the &HMO (on process) or
&HMI (initialization) images, if one of the partner drives (or drive
pairs) does not have power applied, the system won't recognize
redundant drives and will assume that the HM is to operate without
disk redundancy.
To take out this option, you must get a new key option file from the
Wide Values/Software Options/Load New Keyfile), then reload all US
nodes.

28.2 Hardware Options
Introduction
In some cases, new hardware that can be added to existing TPS
systems is provided as whole modules and devices. For other
hardware options and upgrades, kits are provided that contain the parts
necessary to add the hardware and instructions for the installation of
that hardware.
CAUTION .
In any case, new hardware should be installed only by people who

have been trained to understand the impact of the new equipment and
its installation on system operation and performance.
The hardware kits and instructions available from Honeywell are only
for people with such training and experience.
High-performance
processors
Many hardware upgrades involve replacing the standard processor
with the high-performance processor. When first used in releases
R210 and 210M1, the HMPU processor/memory board (with 2 Mw of
memory and a math coprocessor) was the high-performance design
used. Later high-performance designs now include the HPK2-2 and
HPK2-3 (with 2 Mw and 3 Mw of memory on-board), and the K2LCN
series of processor/memory boards with from 2 Mw to 6 Mw of on-
board memory. The HMPU is still required in redundant AMs
because it is the only board with a math coprocessor on board.
Both the HMPU and HPK2 series of boards can work in conjunction
with separate EMEM external memory boards to increase a module’s
total memory. The K2LCN series of boards cannot interface with
external memory in this way. Some application software packages
require the use of an HMPU board. This requirement is identified in
the documentation provided with each such package. Some standard
software options, such a the Math Library for AMs, require an HMPU
board. This requirement is identified with systems with such options
are configured.
All of the above boards are still valid high-performance boards,

provided the memory requirements of the software release are
applicable.
You should inform your hardware maintenance staff about the high-
performance processor requirements defined here, so that they will not
replace a required board with an improper one.

28.2 Hardware Options, Continued
High-performance
processors,
continued
You should inform your hardware maintenance staff about the high-
performance processor requirements defined here, so that they will not
replace a required board with an improper one.
Additional
configuration
changes
Network Configuration (NCF) changes are required by many kits.
They can be made through on-line reconfiguration, which usually
requires a shut down and reloading of the affected nodes. See the
Network Data Entry, for on-line NCF reconfiguration instructions.
General
installation
references
New hardware not provided with kit instructions can be installed by
referring to the appropriate publications in the system bookset,
especially the following publications:
• See LCN Guidelines - Implementation, Troubleshooting, and
Service
• See LCN System Installation
• See LCN System Checkout
• See Process Manager Implementation Guidelines
• See Smartline Transmitter Integration Manual
• See Process Manager/Advanced Process Manager Installation
• See Process Manager/Advanced Process Manager Checkout
• See Process Manager/Advanced Process Manager Service
• See Logic Manager Implementation Guidelines
• See Logic Manager Installation
• See Logic Manager Service
• See Advanced Process Manager Implementation Guidelines
• See Universal Control Network Guidelines
• See Universal Control Network Installation

28.2.1 Application Module Hardware Upgrades
Description
The Application Module can be upgraded from a standard (68020-
based) microprocessor to an enhanced (68040-based) microprocessor
to increase the speed and performance of the module.
Newer software releases may also require additional memory as well

as the enhanced processor. Larger memories accommodate more user
information, such as more:
• Data Points
• CL Programs or
• Custom Data Segments
With R500, AMs can use memory from 3.0 Mw to 16.0 Mw (Mw =
megawords). The minimum AM memory requirement for various
software releases are:
• R200 requires a minimum of 1.5 Mw
• R300 requires a minimum of 2 Mw
• R400 or later requires a minimum of 2 Mw
• R500 or later requires a minimum of 3 Mw
Upgrade kits offer more memory, enhanced processing, or both.
References
See Application Module Implementation Guidelines to check
guidelines for AM configuration, including information about the
effect of the AM memory size on user memory and checkpoint volume
size. Also, see Section 7 in this manual for aid in configuring volume
sizes.
The AM checkpoint volume size is not affected by installing an
enhanced processor, but if an LCN has both an enhanced and a
standard (68020) AM, the Personality Image volume must be made
larger, because two versions of the AM image will be present.
See Five/Ten-Slot Module Service for service instructions including

board locations and spare parts information. Refer to the Network
Data Entry. It provides instructions for on-line reconfiguration that
are needed to install the new configuration on the network.

28.2.1 Application Module Hardware Upgrades, Continued
How to install
additional memory
The AM checkpoint volume size must be recalculated and
reconfigured in VOLUME CONFIGURATION.
For more information see Application Module Implementation

Guidelines and Engineer’s Reference Manual - this manual. You can
use on-line reconfiguration to install the new configuration on the
network.
To startup, apply power and use the AM Status display to reload and
restart the AM.
How to take out

additional memory
Remove power from the AM and remove the new memory board(s).
If Volume Configuration was completed, and if you need to, you can
reconfigure to go back to the original AM checkpoint volume size.
How to install the

enhanced
processor
In VOLUME CONFIGURATION, under PROGRAM IMAGE for this AM,
select AM IV {AM IV indicates an enhanced (68040) AM and AM II
indicates a standard 68020 AM}.

How to take out

the enhanced
processor
Reinstall the original boards. If Volume Configuration has been
changed, reconfigure under PROGRAM IMAGE to change from AM
IV back to AM II.

28.2.2 Enhanced (68040) Computer Gateway
Description
The enhanced CG uses the higher-performance Motorola 68040
microprocessor to add speed and performance to older TPS systems.
In addition, these boards contain the added memory required by newer
software releases:
• CGs using releases up to and including R310 require 1 Mw of
memory.
• CGs using releases from R400 require 2 Mw of memory.
References
See Section 7 of this manual for instructions for configuring volume
sizes. The HM-checkpoint volume size is not affected the 68020
option, but if an LCN has both an enhanced and a standard (68020)
CG, the Personality Image volume must be made larger, because two
versions of the CG image will be present (see Table 7-9).
Refer to the Five/Ten-Slot Module Service for service instructions,

including board placement and parts information.
How to install the

microprocessor
enhancement
In VOLUME CONFIGURATION, under PROGRAM IMAGE for this
CG, select CM IV (CM IV indicates an enhanced (68040) CG and CM
II indicates a standard 68020 CG).

Configuration displays and refer to Network Data Entry, binder
TPS 3030-1.
How to take out

the enhancement
changed, reconfigure under PROGRAM IMAGE to change from CM IV
back to CM II.

28.2.3 Computer Gateway to Plant Network Module
Upgrade
Description
There are two upgrade options that will convert a standard Computer
Gateway to a Plant Network Module and one upgrade option that will
upgrade a Computer Gateway to a Computer Gateway with a high-
performance microprocessor.
References
sizes.

How to install the

microprocessor
enhancement
CG, select CM IV(CM IV indicates an enhanced (68040) CG and CM
II indicates a standard 68020 CG).
To startup follow the reconfiguration instructions on the Network

How to take out

the enhancement
changed, reconfigure under PROGRAM IMAGE to change from CM IV
back to CM II.

28.2.4 Programmable Logic Controller Gateway Upgrades
Description
There are several upgrade options for the Programmable Logic
Controller Gateway. Some add redundant partner PLCGs, some
enhanced performance, and some do both.
References
See Section 7 of this manual for instructions if it is necessary to
configure volume sizes.

How to install the

enhancement
Follow the installation instructions contained in the kit. No
reconfiguration is required when installing a relay-panel upgrade.

How to take out

the enhancement
changed, reconfigure under PROGRAM IMAGE.

28.2.5 Enhanced (68040) Hiway Gateways
Description
The enhanced HGs use the higher-performance Motorola 68040
microprocessor. The enhanced HG can handle significantly higher
parameter-access loads than the standard (68020) HG.
Kits are available to enhance capability and increase memory.
References
sizes. The HM checkpoint volume size is not affected by this option,
but if an LCN has both an enhanced (68040) and a standard (68020)
HG, the Personality Image volume must be made larger, because two
versions of the HG image will be present.
See the Five/Ten-Slot Module Service for service instructions,

How to install the

microprocessor
enhancement
HG, select HG IV [HG IV indicates an enhanced (68040) HG and HG
II indicates a standard 68020 HG].

Configuration displays and refer to the Network Data Entry.
How to take out

the enhancement
Reinstall the original boards. If VOLUME CONFIGURATION has
been changed, reconfigure under PROGRAM IMAGE to change from
HG IV back to HG II.

28.2.6 Universal Station and Workstation Upgrades
Description
There are several upgrades that can be added to the Universal Station
and Universal Workstation. We have broken these upgrades into
categories:
Table 28-3 Upgrade Categories to the Universal Station or

Workstation
Category Action Subsection
Disk Drive Replaces Floppy Disk Drives and 28.2.6.1
Cartridge Disk Drives with drives.
Kits are available for both the Universal 2.6, 2.7
Station and the Universal Workstation.
Improved Improves display monitor quality. 28.2.6.2
Display Screen
Kits are available for both Universal
Station and Universal Workstation.
Enhanced Upgrades from standard-performance 28.2.6.3
Processor or processor to high-performance processor
Memory or adds extra memory.
Addition
Kits are available for both the Universal
Station and the Universal Workstation.
Printer Replaces printer with higher-speed 28.2.6.4
Enhancement printer.
Applicable to both the Universal Station
and the Universal Workstation.
Touch Screen Kit adds an Upper-Tier touch screen to a 28.2.6.5
Universal Station.
Not usable on the Universal Workstation.
Keylock Switch Improves the security of the Keylock 28.2.6.6
Replacement Switch.
Not usable on the Universal Workstation.
Keyboard Adds keyboards to the workstation. 28.2.6.7
Additions
Not usable on the Universal Station.
Go to the subsection describing the category of interest.

28.2.6.1 Disk Drive Upgrades
Description
Drives use disks. Disk drives replace the floppy and cartridge drives
previously supplied with the Universal Stations.
References
Refer to the Process Operations Manual. It describes drive operation.
Refer to the Universal Station Service for disk service instructions

including troubleshooting, assembly, disassembly, and replacement
parts.
Refer to the Universal Work Station Installation, Operation, and

Service for drive service instructions including troubleshooting,
assembly, disassembly, and replacement parts.
Refer to the Network Data Entry. It provides on-line reconfiguration

instructions.
Refer to LCN System Installation. It describes the emplacement of

cabling of the drive(s).
Refer to LCN System Checkout. It describes equipment checkout,

application of power, and validation of the drive(s).
How to install the

enhancement
Follow the instructions that come with the kit(s).
Under LCN NODES, select this US and enter the number(s) for the
disk drive(s). If this US had floppy drives, delete those numbers.
To perform startup, follow the instructions on the on-line
reconfiguration displays and refer to Network Data Entry.
How to take out the

enhancement(s)
Reverse the kit instructions to remove the drives and, if you wish, re-
install the cartridge or floppy drives. If you reinstalled floppy drives,
you must reconfigure for this US under LCN Nodes to delete the drive
number(s) and reenter the floppy drive number(s). If you do not go
back to floppies and leave a drive number configured, that drive will
appear to be out of service.

28.2.6.2 Improved Display Screen Upgrades
Description
Improved display resolution and improved cursor performance can be
attained by upgrading a Universal Station or a Universal Workstation
with a non-interlaced-scanning display monitor and the EPDG and
EPDG-I/O boards.
References
While installing a US kit, check the installation instructions packed
with the kit. Also refer to Universal Station Service.
While installing a UWS kit, check the installation instructions packed

with the kit. Also refer to Universal Work Station Installation,
Operation, and Service.
These publications provide service instructions, including board

placement and parts information.
How to install the

enhancement
Follow the kit instructions that are packed with the kit.
No software changes or configuration changes are required.
Use another US (or UWS) to restart (reload) this US, or if another US

is not available, reload (bootload) this US by itself. See the
Operator's Digest (the pocket guide) for these procedures.
How to take out

the enhancement
Reverse the kit instructions and use another US or UWS to restart
(reload) this US, or if another US is not available, reload (bootload)
this US by itself.

28.2.6.3 Enhanced Processor or Memory Upgrades
Description
Enhanced Universal Stations and Universal Workstations contain the
Motorola 68040-based microprocessor that adds speed and
performance to older TPS systems. In addition, these boards contain
the added memory required by newer software releases:
• USs and UWSs using releases up to and including R230 require 2
Mw of memory.
• USs and UWSs using releases from R300 to R410 require 3 Mw of
memory.
• The Universal Personality through the R400 series requires the
larger 4 Mw of memory.
• The Operator Personality for R500 requires 4 Mw of memory.
• The Universal Personality for R500 requires 6 Mw of memory.
There are also some kits which add only memory to earlier versions of
the standard (68020) Universal Stations and Workstations.
References
sizes.
If an LCN has both an enhanced (68040) and a standard (68020) US,

the Personality Image volume must be made larger, because two
versions of the US image will be present (see Table 7-9).
Refer to the Universal Station Service for service instructions,

How to install the

microprocessor
enhancement
US, select US IV [US IV indicates an enhanced (68040) US and US
II indicates a standard 68020 US].

How to take out

the enhancement
changed, reconfigure under PROGRAM IMAGE to change from US IV
back to US II.

28.2.6.4 Printer Enhancement Upgrades
Description
The ASPI 46 Printer is a 400 cps (characters per second) high-speed
replacement for the standard 150 cps matrix printer (ASPI 32 or ASPI
41). It plugs into the same connector as the standard printer and
requires no software changes.
Hardware required
ASPI 46 Printer. No kit is required.
References
Refer to the Process Operations Manual. It describes printer
operation, ribbon replacement, and paper replacement.
Refer to the Universal Station Service for printer service instructions
parts.
instructions, should they be needed (see “Network Configuration,”
below).
Refer to LCN System Installation. It describes the emplacement,
cabling, and application of power to the printer.
Refer to LCN System Checkout. It describes equipment checkout,
application of power, and validation of the ASPI 46 printer.
How to install the

enhancement
Connect the printer to the printer port on a Universal Station or
Workstation (refer to Appendix A in LCN System Installation).
• If there was no printer on this US, under LCN NODES, select this
US and enter the printer number.
• If Network Configuration was not changed, start up by just applying
power to the printer (refer to the Process Operations Manual for
operating instructions).
• If Network Configuration was changed, see Network Data Entry
for instructions about on-line reconfiguration displays.
How to take out

the enhancement
Remove the ASPI 46 printer, and if you wish, replace it with the old
printer. If Network Configuration was changed, and is not changed
back, a missing printer will appear to be out of service. Use on-line
reconfiguration to change the printer number back to blank.

28.2.6.5 Touch Screen Upgrade
Description
A touchscreen can be installed in a US in the upper tier of a console.
This touchscreen is the improved “smart frame” type.
References
Refer to the Process Operations Manual. It describes touchscreen
operation.
Refer to the Universal Station Service for touchscreen service

instructions including troubleshooting, assembly, disassembly, and
replacement parts.

instructions.
How to install the

enhancement
If this US had no touchscreen, under LCN NODES, select this US and
select YES under TOUCH SCREEN.
If Network Configuration was changed, startup following the

instructions on the on-line reconfiguration displays and refer to
Network Data Entry.
Otherwise, apply power and startup the US through the Console Status
display at another US.
How to take out

the enhancement
Reverse the kit instructions to remove the touch screen. If Network
Configuration was changed, reconfigure to select NO under TOUCH
SCREEN.

28.2.6.6 Keylock Switch Replacement Upgrade
Description
An older keylock switch can be replaced with a more secure keylock.
References
Refer to the Universal Station Service for service instructions
parts.
How to install the

enhancement
Follow the kit instructions.
No configuration changes are required.
How to take out

the enhancement
No scheme to take out the enhancement is offered.

28.2.6.7 Keyboard Addition Upgrades
Description
The R300 (and later) software release supports use of the Universal
Personality, which allows both the Supervisor’s Keyboard and the
Engineer’s Keyboard to be used at the same time. These kits provide
for either the Engineer’s or Supervisor’s keyboard to be added to a
Universal Workstation
They can be installed only on the Universal Workstation.
References
Refer to the Process Operations Manual. It describes proper
operation.
Refer to the Universal Work Station Installation, Operation, and

Service for service instructions including troubleshooting, assembly,
disassembly, and replacement parts.
How to install the

upgrade
Follow the instructions that come with the kit.
Restart the node using the Process Operations Manual, if necessary.
How to take out

the enhancement
Reverse the kit instructions to return to a single keyboard.

28.2.7 HM Upgrades
Description
History Modules that are to run on Release 210 and later releases,
including R300 and R400, must either have EMPU and EMEM
boards, or they must have an HMPU, HPK2 or K2LCN
microprocessor board.
The enhanced HMs use one of the higher-performance HMPU, HPK2,

or K2LCN microprocessor boards. Each of these boards uses the
68020 microprocessor. The 68020-based microprocessor improves the
processing rate of the HM.
HMs with Wren III disk drives and HMs with WDAs can be
configured with redundant disk drives, if the HM Disk Redundancy
Software Option is purchased.
The minimum HM memory and Winchester drive requirements for

various software releases are:
• R210 requires a minimum of 1.5 Mw. Wren I, II, or III can be used.
• R230 requires a minimum of 1.5 Mw. Use any Wren drive or
WDA.
• R300 requires a minimum of 2 Mw. Use Wren II or III or WDA.
• R400 requires a minimum of 2 Mw. Wren III or WDA can be used.
• R500 requires a minimum of 3 Mw. Wren III or WDA can be used.
References
Refer to this manual for information about the operation of redundant
disk drives, configuring redundant HM disk drives, and synchronizing
the drives. For information about the HM Redundancy Key File
Option, refer to this manual.
See Command Processor Operation. It provides instructions for using

commands related to HM disk redundancy: SYN, STA, and OFF.
Refer to the Network Data Entry. It provides instructions for on-line
reconfiguration that are needed to install the new configuration on the
network.
For service information, see History Module Service. It also includes

the setting for the SCSI bus address on each drive that establishes
redundant-drive partners.

28.2.7 HM Upgrades, Continued
Startup
considerations
If any type of Wren drive is being converted to one or more Wren III
or WDA drives, it may be necessary to transfer the content of the HM
to the new drives. Before installing the hardware kit, use the Utilities
BACKUP command to store the HM content (less continuous history
and journals) on removable media (disks). After the modified HM is
started with the on-process personality, use the RESTORE command
to return the data to the primary drive.
The HM has to be shut down to install an upgrade kit, so after the
drive(s) is added, apply power to the node and drive(s). Use the Node
Status display to startup the initial drive.

28.2.8 Time-Sync Upgrades for Network Interface Module
Description
Network Interface Modules (NIMs) can be upgraded to add Time-
Sync capability.
References
Refer to the Universal Control Network Guidelines.

operation.
How to install the

upgrade
Follow the instructions that come with the kit. Restart the node using
the Process Operations Manual, if necessary.

28.2.9 Precision Clock Sources
Description
A precision clock source is added to the LCN when more accurate
time keeping is required than may be available with the standard
power-line-frequency clock source.
This option is used where there is inadequate accuracy in the

frequency of the ac power source.
References
The Installation Instructions that are included in the hardware kits.
Service for additional clock source information.
How to install the

enhancement
Follow the instructions provided. To startup, reapply power and
startup the clock-source node using the appropriate Node Status
display.
How to take out

the enhancement
Reverse the kit instructions and reload and restart the clock-source
node using the appropriate Node Status display.

28.2.10 Process Manager to Advanced Process Manager
Upgrades
Description
Kits are available to upgrade a Process Manager to an Advanced
Process Manager.
References
Refer to Process Manager/Advanced Process Manager Service.
Refer to Process Manager/Advanced Process Manager Checkout.

operation.
How to install the

upgrade
The Process Manager you are upgrading must be at software release
R300 or later.
Follow the installation instructions packed with the kit.
How to take out

the enhancement
Reverse the kit instructions.

28.2.11 LCN Extender
Description
The LCN Extender (LCNE or XLCNE2) is a hardware module that is
installed in selected nodes to allow two nodes to be separated by a
fiber optic LCN. Coaxial cable LCNs can be up to 300 meters in
length and fiber-optic LCN segments can be up to 8000 meters in
length.
References
Service. It defines where the LCN Extenders (LCNEs or XLCNE2s)
are installed and how the fiber-optic cables are connected.
How to install the

enhancement
Service for installation information.
After installing the LCNE or XLCNE2 boards in the appropriate

nodes, reapply power and use the appropriate Node Status Display to
reload and restart each node.
How to take out

the enhancement
Remove the LCNE and XLCNE2 boards from the nodes, reconnect (if
that is possible) and properly terminate the coaxial cables using the
appropriate Node Status Display to reload and restart each node.

28.2.12 Micro TDC 3000 Upgrades
Introduction
The Micro TDC 3000 system is available in two sizes:
• The original six-node version, and
• The current-production eight-node version.
Six-node Micro
TDC 3000
The six-node Micro TDC 3000 system is delivered in two
configurations:
• Version A, consisting of two electronics towers, each capable of
holding three LCN nodes. There is a single power supply in each
tower. A single 14” CRT monitor is supplied along with four
nodes:
– Universal Station
– Application Module
– Network Interface Module
– History Module
• Version B, which includes the same towers, components and nodes
of Version A, plus an additional 14” CRT monitor and Universal
Station node.
Optional nodes may be added to either version to include a total
maximum of six nodes per Micro TDC 3000.
Eight-node Micro
TDC 3000
The eight-node Micro TDC 3000 system is also delivered in two
configurations:
• Version A, consisting of two electronics towers, each capable of
holding four LCN nodes. There is a single power supply in each
tower. A single 20” CRT monitor is supplied along with four LCN
nodes:
– Universal Station
– Application Module
– Network Interface Module
– History Module

28.2.12 Micro TDC 3000 Upgrades, Continued
Eight-node Micro
TDC 3000,
continued
• Version B, which includes the same towers, components and nodes
of Version A, plus an additional 20” CRT monitor and Universal
Station node.
Optional nodes may be added to either version to include a total
maximum of eight nodes per Micro TDC 3000.
Description
Upgrade kits are available for either the six-node or eight-node types.
The kits allow you to change from Version A to Version B, add a
keyboard, and achieve full TPS system status by placing each node on
its own power supply.
LCN restrictions
removed
Micro TDC 3000 units that have been upgraded to full TPS system
status need not be restricted to the six or eight node maximum
systems.
References
Refer to Micro TDC 3000 User’s Manual for installation and service
information. Also refer to Multinode Module Service for specific
service information on the special 10-slot module used in the Micro
TDC system.
How to install the

enhancement
Follow the kit instructions.
If configuration changes are required, refer to Network Data Entry for

on-line reconfiguration instructions.
How to take out

the enhancement
No scheme to take out the enhancement is offered.

Section 29 – LCN Cable Diagnosis
29.0 Reserved
In earlier versions of this manual, this section contained information about LCN Cable
Diagnosis. Refer to LCN Guidelines - Implementation, Troubleshooting, and Service for that
information. This section has been retained to direct users familiar with an earlier version of
this manual to the new location of the information and to preserve the validity of references to
other sections of this manual.

Section 30 – Event-Initiated Reports—Implementation and
Use
30.0 Overview
Introduction
This section describes the implementation and use of event-initiated
printed reports.
Description An Event-Initiated Report is a AM US

printed report that is initiated or CG Message Report
by a message from a user-

LCN
written program to one or
NIM
more Universal Stations. or HG Message
Event
It is the user-written program
that detects the event that
initiates printing of the report.
3698
Event-Initiated Reports can also be directed to files on a History

Module or removable media. For more information, see Report to
Output File section of this manual.
How is the report

initiated?
One way that a program could be notified of an event is through the
event-initiated processing (EIP) function that is available through the
EIP-related parameters in most HG points and in NIM digital points
(see System Control Functions).

30.1 Implementation of Event-Initiated Reports
Introduction
Any user-written program can send a message that initiates an Event-
Initiated Report, including:
• Advanced Control Programs (ACPs) in upper-level processors
connected to a CG
• CL programs in AMs
• Sequence programs in APMs, PMs and MCs
Classes of reports
There are two classes of Event-Initiated Reports:
• Area Reports from logs, reports, journals, and trends configured in
the Area Database
• Event History Reports
Message sending
capabilities
Characteristics of message-sending capabilities of AMs, APMs, CGs,
and PMs/MCs that you should consider as you implement event-
initiated reports are found later in this section. Other important
information can be found in the following publications.
References
For more detailed information:
• See the Control Language/Multifunction Controller Reference
Manual
• See the Control Language/Application Module Reference Manual
• See the Control Language/Process Manager Reference Manual
• See the Control Language/Advanced Process Manager Reference
Manual
• See the Computer Gateway User Manual

30.1.1 Message-Source Considerations
Introduction
The following is a summary of the characteristics of message-sending
capabilities of AMs, APMs, CGs, and PMs/MCs that you should
consider as you implement event-initiated reports.
Messages from AMs

The messages from AMs consist of up to 16 individual message items
of various types. Maximum string length is 64 characters.
Messages from APMs

There is no maximum message item length from APMs, but the total
string length is limited to 60 characters if the destination is a CRT or
71 characters if the destination is the LOG.
Messages from CGs

The messages from CGs originate in the upper-level processor as
complete strings of up to 120 characters.
Messages from
PMs, MCs
The messages from PMs and MCs consist of up to seven individual
message items of various types. Message items are limited to eight
characters or less. For example, “Error has occurred”.
This means that not all of the event-initiated message options can be
used in one message, but you can use the “=” and “,” separators to
reduce the number of items (see the Operation of Event-Initiated
Reports section that follows).
In addition, PMs and MCs cannot handle variable time arguments.

They must use the $RMINS or $RSECS options to specify time for
event-history retrievals.
Use of separators
with message items
In the following message descriptions, spaces are shown as separators
between options and option components. “=” and “,” can also be used
as separators. For messages from PMs and MCs, this is important
because of the seven message item limit. For example, $AREA 05
(two message items) could be written $AREA=05 (one message item),
and ALM UNT A1 A2 A3 (five message items) could be written
ALM,UNT A1,A2,A3 (two message items).

30.1.2 Area Reports
Introduction
Any log, report, journal, and trend configured in the Area Database
can be initiated by an Area Report.
Reference
See Area Form Instructions.
Area Report
message form
Initiate the report by sending a message in this form:
“$OUT_RPT <rprtname> $AREA an $CONS cn $CONF parname (ix)”
Where <rprtname> is a name found in the left-most field of the

Report/Log/Trend/Journal menu that is called up through the
System Menu.
The other fields are optional and can be in any order. The meaning of
these fields is as described below.
$AREA an and
$CONS cn
The unit that contains a data point sending the message determines
which US receives the CL message. For each combination of an area
that contains the unit and a console, the system tries to print the
specified report. The $AREA an and $CONS cn options provide a way
to eliminate multiple attempts to print the report.
In other words, if two stations in a console have different areas, with

each area containing the designated unit, then the area report will print
twice. This also holds true if virtual printers are used. If three areas in
a console have the same unit, the area report will print three times.
Table 30-1 $AREA and $CONS Information

IF… THEN the unit…
$AREA an is used Selects the area numbered “an.” This is useful if the
unit where the message originates is assigned to more
than one area.
$CONS cn is used Selects the console numbered “cn.” This is useful if
the area is assigned to more than one console.
If the unit is not assigned to the specified area or the area is not on the
specified console, no report is printed.

30.1.2 Area Reports, Continued
$CONF parname (ix)

Specifies confirmation of completion of the printing of this report by
storing a real number of 1.0 or 2.0 in parameter parname(ix).
The parname field contains the name of a parameter (usually a CDS
parameter in the point to which this CL block is attached) and (ix)
contains an optional index to an array-value in this parameter. This
field can be used by the user-written program to determine when
printing of the report is finished. The user-written program is
expected to place 0.0 in the named parameter before the message is
sent and then to check for a nonzero number placed there by the
Report Manager when printing is finished.
1.0 means "successful completion." 2.0 means "unsuccessful

completion," because the printer could not print or could not complete
printing of the report.
Sending an area-
report from a CL
program
To send an area-report message from a CL program (CL/AM, CL/PM,
or CL/MC) use a statement like this:
SEND: “$OUT_RPT FFL1 <options, if any>“
Note the use of quotation marks around the message.
Sending an area-
report from a user
program
To send an area-report message from a user program in a computer or
computing module connected to a CG, use the computer's or
computing module's Send Message function.
These functions are described in the indicated paragraphs in the
following publications:
• See the Processor Gateway User Manual
• See the CM50S User Manual
In R210, it was necessary to have the Real-Time Journal enabled to
print these reports. This is no longer necessary.

30.1.2 Area Reports, Continued
Why specify an
area and console
number?
If your message does not specify an area and a console number, the
system tries to print the report at an appropriate US. An appropriate
US is any US that has the point's unit sending the message assigned to
its area database. If that US does not have the report in its area
database, it issues a “report not found” message.
You can avoid this by specifying the area and the console.
The following is an example of a CL block with a SEND message that

specifies an area and console number:
SEND: “$OUT_RPT FFL941 $AREA 01 $CONS 06 $CONF STATUS(1)”
This prints Free Format Log FFL941 in Area 01 at console 06. It prints
on the printer specified for FFL941 under the System Menu.

30.1.3 Event History Reports
Introduction
Any of the reports available through the Event History Retrieval
display (called up through the System Menu) can be initiated by an
Event History Report.
Event History
Report form
Initiate the report by sending a message in this form:
“$OUT_EHR rpt item <date & time> <options, if any>“
The parameter rpt is the type of report.
The item parameter defines the items to be included in the report and
item qualifiers.
rpt is defined as follows:
ALM = process alarms, item must be UNT, MOD, or PNT.
MSG = operator messages, item must be UNT, MOD, or PNT.
CHG = process changes, item must be UNT, MOD, or PNT.
SOE = sequence of events, item must be UNT.
STS = system status, item must be HBX, HWY, ABX, NOD, or ALL.
MNT = system maintenance, item must be HBX, HWY, ABX, NOD, or ALL.
ERR = system errors, item must be HBX, HWY, ABX, NOD, NOD, or ALL.
ENGR = engineer changes, item must be NOD or ALL.
The remaining parameters of the report are listed and defined below.
The “item”
parameter
The item parameter defines the items to be included in the report and
item qualifiers, as follows:
Table 30-2 The Item Parameter
Parameter Definition
UNT uu uu Defines the units whose data is to be included in the report, and uu is the unit ID.
There can be up to eight uu unit IDs. The unit IDs have to be assigned to the Area
Data Base.
PNT ptname Defines the points to be included in the report and ptname is a point name. There
can be up to eight point names.
MOD modname Defines the process modules to be included in the report. Modname is a process-
module point name. There can be up to 8 modname process-module point names.
HBX hn bn bn Defines the process network, and boxes on that network, whose data is to be
included in the report. hn is the process network (hiway or UCN) number (1 through
20), and bn is the number of a box on that network. There can be up to eight bn box
numbers.
HWY hn Defines the process network whose data is to be included in the report, and hn is the
process network (hiway or UCN) number (1 through 20).
ABX Specifies that data for all boxes on all process networks be included in the report.
NOD nn nn Defines the nodes whose data is to be included in the report, and nn is a node
number. There can be up to eight nn node numbers.
ALL Specifies that all data of the type indicated by rpt is to be included in the report.

30.1.3 Event History Reports, Continued
The <date & time>

parameter
The <date & time> parameter defines the time interval whose data
is included in the report. Use one of these methods to define the time
interval:
Table 30-3 Date and Time Parameter
Parameter Definition
$ATIME Beg_time Defines the absolute values of the start date and time, and then the stop date
End_time and time.
Specify these as a dd MMM yy hh:mm:ss character string, or as a Time
variable in seconds, where MMM is JAN, FEB, and so on.
$RMINS ttttt Defines the time in minutes before the time this message is sent that is the
start of the report's interval.
The time this message is sent is the end of the report's time interval.
ttttt designates minutes and must be an integer. This integer defines how far
back in history the report should cover. For example, if you use $RMINS
1440, the report includes the last 1440 minutes (24 hours) of history reports
The report’s end time is the time the report was requested. The report’s start
and stop times are established at the time the CL SEND: statement is
executed.
$RSECS ttttt Defines the time in seconds before the time this message is sent that is the
start of the report's interval.
The time this message is sent is the end of the report's time interval.
ttttt designates seconds and must be an integer. This integer defines how far
back in history the report should cover. For example, if you use $SECS 3600,
the report includes the last 3600 seconds (1 hour) of history. The report’s end
time is the time the report was requested. The report’s start and stop times
are established at the time the CL SEND: statement is executed.
$IMINS date_time Defines the report interval time as a start time and date, followed by an
ttttt interval time in minutes.
Specify date_time as a dd mmm yy hh:mm:ss character string.
ttttt is a value (string, real, or integer) of up to five digits, in a range from 0 to
32767 minutes (32767 minutes = 546.12 hours); or it can be a time value of
up to 24 hours (an hh:mm:ss character string or an LCN time type).
$ISECS date_time Defines the report interval time as a start time and date, followed by an
ttttt interval time in seconds.
Specify date_time as a dd mmm yy hr:mm:ss character string, or as a TIME
variable.
Here, ttttt is a value (string, real, or integer) of up to five digits, in a range
from 0 to 32767 seconds (32767 seconds = 546.12 minutes = 9.1 hours); or
it can be a time value of up to 24 hours (an hh:mm:ss character string or an
LCN time type).

The <options, if
any> parameter
This entry represents the options
• $AREA an
• $CONS cn
• $CONF parname (ix)
which were defined for Area Reports, the section above. In addition,
the option $PTR pn may be entered, where pn is the number of the
printer on the console where the report is to be printed.
Sending an Event
History Report
from a CL
program
The following is the general form of a CL statement that sends an

event-history report (64 characters max.):
SEND: "$OUT_EHR rpt item <date & time> <options, if any>"

Sending an Event
History Report
from a CL
program, continued
Following is an example of an AM/CL block that sends out an alarm

report on PM point TIC21841 to printer 1:
BLOCK REPORT(POINT REPORT; AT GENERAL)

SEND: "$OUT_EHR ALM PNT TIC21841 $ATIME $PTR 1"
Following is an example of an AM/CL block that prints process

alarms for the 1st 18 minutes of the hour starting at 9:00 a.m., Sept.
16, 1993:
PACKAGE
CUSTOM
PARAMETER STATUS: NUMBER ARRAY(1..5)
END CUSTOM
BLOCK REPORT (POINT REPORT; AT BACKGRND)

SET STATUS(1) = 0.0
SEND: “$OUT_EHR ALM UNT 01 $IMINS 16 SEP 93 09:00:00 18 $CONS
1 $PTR 1”
END REPORT
END PACKAGE
Following is an example where the CL block prints process alarms for

70 minutes in the past hour relative to now (present time).
PACKAGE
CUSTOM
PARAMETER STATUS: NUMBER ARRAY(1..5)
END CUSTOM
BLOCK REPORT (POINT REPORT; AT BACKGRND)

SET STATUS(1) = 0.0
SEND: “$OUT_EHR ALM UNT 01 $RMINS 70 $CONS 1 $PTR 1”
END REPORT
END PACKAGE

Sending an Event
History Report
from a user
program
To send an area-report message from a user program in a computer or
computing module connected to a CG, use the computer's or
computing module's Send Message function.
These functions are described in the following publications:

• CM50S User Manual
• Processor Gateway User Manual
• CG User Manual

30.2 Operation of Event-Initiated Reports
Introduction
Because Event-Initiated Reports are initiated by user-written
programs, the tasks of operators at a console are unaffected by this
function, except that the printers must be kept supplied with paper and
ribbons, and must be on-line, ready to print the reports.
Operator
interaction
It is possible to prepare a user-written program that initiates such a
report after interaction with an operator and, in such a case, a local
operating procedure would likely be developed.
R210 stipulation
In R210, it was necessary to enable the Real-Time Journal for Event-
Initiated Reports to function. This is no longer necessary.
Message
constraints
In addition to causing the specified report or log to be printed, the
messages described here are distributed as normal CL messages.
These messages may be subjected to the following constraints:
• Message displays and the Real-Time Journal may truncate the ends
of these messages because of message-width limitations.
• Time variables are displayed and printed only with the time
component. The date is not included.

30.2.1 Error Handling
Introduction
Error handling varies according to how far the message progressed
toward the actual printing of the report or log, as defined for the
following cases.
Report
successfully
delivered
If the specified report is successfully delivered to a printer, the
confirmation parameter value (if one is specified) changes to 1 (refer
to the $CONF parname(ix) parameter in the Area Reports section).
CL SEND
statement errors
Any errors that occur as a CL SEND statement is executed are
described in the Real Time Journal and in Operator Messages in the
Event History Menu, which you will find under the System Menu.
Printer fails
If the printer fails, the confirmation parameter value (if one is
specified) changes to 2 (refer to 30.1.1, the $CONF parname(ix)
parameter).
Message errors
If a receiving area or console cannot interpret the arguments of a
report request, a “synthetic” CL message is built as an error message.
These messages report errors such as argument-syntax errors and
report names not found in the Area Database.
No error reported
In some cases, a US cannot detect that an Event-Initiated Report has
been sent to it, so no error can be reported. These cases include the
following:
• Misspelled $OUT_RPT or $OUT_EHR character strings.
• The unit to which the message-originating point belongs is not
assigned to the specified area.
• The specified area is not assigned to the specified console.
• The specified printer number is not that of a printer on the specified
console.

Section 31 – Custom Software Backplane and Generic
Overlays
31.0 Overview
Introduction
The Custom Software Backplane is a provision that allows the
addition of optional, standard, and custom software modules to a node
without modifying the node’s original personality software.
Such software modules are loaded and linked to personality software.

This is somewhat analogous to plugging a circuit board into a
hardware backplane where it is able to access functions provided by
the backplane.
Benefits
A significant benefit of this software is that it allows a new function to
be added to an LCN node after it is installed and operational. Other
benefits include:
• Installation of functions independent of standard software release
schedules.
• Extra software logic does not encumber a node if it is not needed.
• Memory savings because this approach produces a software module
typically smaller than personality software.

31.1 Custom Software Installation
Introduction
When a optional, standard, or custom software module is to be
included in a system, the documentation that comes with that module
provides detailed information about how the module is incorporated
into the system. This is necessary because the module may be created
long after the main system is installed and standard LCN or UCN
documentation cannot anticipate what the new functionality might be.
If custom software is being added to the AM, because of CL extension

and memory management considerations, directory NET>&CLX must
be accessed as well. See the Application Module Implementation
Guidelines for further information on adding custom software to the
AM.
The remaining instructions in this section will assist you in installing

optional, standard, or custom software modules in nodes other than the
AM.
Installation steps
The following is a brief summary of the typical installation steps. If
there are conflicts between these steps and the specific instructions
supplied with your custom software, follow the specific instructions.
Table 31-1 Installation Steps

Step Action
1 Have the software modules available on removable media (disks).
2 Using the Create Directory (CD) command, create the NET>&CUS

directory on your HM if one does not already exist. Refer to
Command Processor Operation.
3 Copy the software module files (with .LO file extensions) from your
distribution media to the NET>&CUS directory.
4 Configure the node that the custom software will be used on.
Declare module names, specify additional memory if required, and
keep external directives set to the NO default.
5 Check and install the new NCF.
6 Shut down and reload the node just configured, using the new
NCF.
Additional information about phases of a custom software installation

is contained in the sections to follow.

31.1.1 The NET>&CUS Directory
Allocating space for

the NET>&CUS
directory
All custom software modules will be transferred from distribution
media to the NET>&CUS directory on the History Module. If this
directory does not exist, you must allocate space for it on the HM.
Estimating space
for the &CUS
directory
You must estimate the space needed for the &CUS directory.
Use the Utilities List File attributes command (see Command

Processor Operation) to list the software module files (.LO files) on
the Honeywell-provided distribution media. From the list, determine
the total number of sectors used by all files with a .LO extension. Use
this formula to determine the total space needed:
[464 + (# of sectors used by .LO files)] / 4 = Total in KB
The result is the minimum space in kilobytes required to store your

custom software in the NET>&CUS directory on the History Module.

31.1.2 Using the LCN Node Configuration Menu
Introduction
Space for custom software is allocated by selecting parameters on
Page 2 of the LCN Node Configuration Menu. This section explains
it.
Finding the LCN

Node
Configuration
Menu
From the Engineering Main Menu, select LCN NODES to reach page
1 of the Node Configuration display. Then use the keys labeled [PAGE
FWD] or [PAGE BACK], as necessary, to find the desired node.
If you are adding a node not yet known to the NCF, you can enter the
appropriate data on any page of the Node Configuration display.
Once the desired node is found, select MODIFY NODE to get to Page
2. An example of the page is shown below:
Figure 31-1 LCN Node Configuration Menu
DD MM YY 11:55:56 1
COMPUTING MODULE NODE PAGE 2 OF 2 MOD AM 40
NODE 40
ENTER EXTERNAL LOAD MODULE NAMES & ASSOCIATED PERSONALITY-TYPES:

NAME - - - PERS. NAME - - - PERS. NAME - - - PERS. NAME - - - PERS.
HISARC CIO
CGBASE CIO
CIO
ADDITIONAL MODULE MEMORY (WORDS)
TOTAL (MODULES PLUS ADDITIONAL 135168

MEMORY?
MAX. EXTERNAL MODULE MEMORY (WORDS)
FURTHER EXTERNAL DIRECTIVES? YES NO
F1=CHECK F3=SET OFFLINE F5=ABORT F7=NEXT ITEM F9=PACK NCF

F2=INSTALL F4=PRINT
50896
In the sections that follow, each selection on this page is described.

31.1.2 Using the LCN Node Configuration Menu, Continued
Specifying custom
software to be
installed
Key in the names of the custom software modules to be added. You
must also key in the personality name for each module if the default
has not been specified.
If a module name is entered for a module that depends on another
module, the second module will also appear in the menu boxes.
ADDITIONAL
MODULE MEMORY
selection
This field entry lets you reserve more memory words than are required
for the module code. This feature is rarely used because most programs
dynamically allocate memory space from the system heap memory.
Unless your custom module documentation states otherwise, leave this

value set to zero.
Calculating total
memory
After you have keyed in all the names of all the modules, press [ENTER]
and the configurator calculates the amount of memory required.
At this time, the configurator checks for modules that depend on
modules you have named and adds them to the list.
The configurator then actually reads the header of each custom module
file and sums the total memory required.
MAXIMUM
EXTERNAL MODULE
MEMORY selection
Enter in the MAXIMUM EXTERNAL MODULE MEMORY field the
actual amount of memory you want allocated. In most cases, this will
be the same as the total size estimated above.
If you anticipate an increase in the size of a custom module (such as,

while doing software development), you can increase this number.
You must enter a value in this field for the software to load properly.
FURTHER EXTERNAL
DIRECTIVES selection
Unless your custom module documentation states otherwise, always
leave this selection at NO .

31.2 Generic Overlays
Introduction
Overlays provide a capability for table-driven generation of pictures
and CL sequences based on equipment lists and a generic source. This
function enhances the system’s effectiveness and friendliness for batch
applications, and provides a useful tool for any application. Generic
Overlays can be used only by the Engineer’s personality and the
Universal personality in the Universal Station.
Although similar to them, they function a little differently from the

custom software modules. Generic overlays are very simple to add to
the system.
Differences
The following table illustrates the differences between custom
software files and generic overlay files:
Table 31-2 Custom Software versus Generic Overlay Differences

Function Custom Software Generic Overlay
Directory NET>&CUS NET>&OVG
File Extension .LO .OV
Actually, generic overlay files may be loaded from any directory

declared in the modify path menu. However, we strongly recommend
you use the NET>&OVG directory path.
Incorporating and
invoking a new
generic overlay
Simply follow these steps to incorporate a new generic overlay:
Table 31-3 Procedure to Incorporate a New Generic Overlay

Step Action
1 Copy the files with .OV extensions from the distribution media to
the NET>&OVG directory (recommended).
2 Select SUPPORT UTILITIES from the Engineering Main Menu,
then select MODIFY VOLUME PATHS to check that the path to the
.OV files is set correctly. Correct the path if necessary.
3 Now select COMMAND PROCESSOR from the Engineering Main
Menu and invoke the overlay by simply typing its name. No node
configuration or other setup is required.

Section 32 – Report to Output File
32.0 Overview
Description
The Report to Output File feature provides a means of saving reports
and journals electronically. They are:
• Saved on either the History Module or on removable media, and
• Displayed or printed as requested from schematics or the Command
Processor display.
How is it done?
The feature is implemented by using a virtual printer. The system
“thinks” it is writing to a printer, but the output is diverted to a file in a
volume on electronic storage media.
How the data is routed to various output files is established by the user
with a virtual printer configuration file. In this file, the user not only
establishes the filenames and paths, but also indicates how errors are
handled.
Exceptions
The Report to Output function does not apply to
• Printed Trends or
• Real-Time Journals.

32.1 Virtual Printer Assignments
What “assigning”
a virtual printer
means
Unlike physical printers, virtual printers are actually files on a history
module or a removable medium. They are not physically connected to
a console or to a Universal Station. Assignment of a virtual printer is
just a way of representing the US on which a virtual printer’s status
and errors are reported (annunciated).
Typically, each US in a console operates the same Area database, so

status and errors for any virtual printer are reported on only one US. If
more than one Area database is used in the console, status and errors
for a virtual printer are reported on the appropriate US on each Area
database. This is illustrated in the examples below.
Virtual Printer
assignment
Physical printers are assigned on a system using numbers from 1 to 10.
Virtual printers are numbered in the range from 11 to 30. Universal
Stations on a console have numbers from 1 to 10.
In a console with a one area, the lowest numbered US (not a node

number) on a console, the system assigns virtual printer (VP) number
11. The next higher numbered US is assigned 12, then assignment
continues until all 20 virtual printers have been assigned.
NOTE: Only stations with operator personalities or universal

personalities are assigned virtual printers.

32.1 Virtual Printer Assignments, Continued
One-area example
Perhaps an example will better illustrate the printer assignments.
In our example, let’s say three stations within a console are using
either Operator Personality or Universal Personality. The node
numbers assigned to those Universal Stations are 34, 35, and 36, but
their station numbers are 1, 5, and 7—not necessarily in the same
order. Table 32-1 shows the node numbers and their corresponding
station numbers.
Notice all 20 virtual printer numbers are assigned in sequence from the
lowest station number to highest station number, regardless of each
US’s node number or the node number’s order.
Also note all stations may not necessarily be assigned the same
number of virtual printers. In the example, station number 7 has only 6
virtual printers assigned.
Table 32-1 Virtual Printer Assignment One Area Example
US Station
Virtual Printer Number Assignments
Node Number
Number
36 1 11 14 17 20 23 26 29
34 5 12 15 18 21 24 27 30
35 7 13 16 19 22 25 28
Two-area example
In a console with four USs,
• two USs are loaded with Area 1, and
• two USs are loaded with Area 2.
Table 32-2 shows the virtual printer assignments.
Table 32-2 Virtual Printer Assignment Two Area Example
Station Console Virtual Printer Assignments
Number (two different areas in the console)
1 (Area 1) 11 13 15 17 19 21 23 25 27 29
2 (Area 1) 12 14 16 18 20 22 24 26 28 30
3 (Area 2) 11 13 15 17 19 21 23 25 27 29
4 (Area 2) 12 14 16 18 20 22 24 26 28 30
Status changes and errors for Area 1 reports output to virtual printer
12 are reported (annunciated) on station 2.
Status changes and errors for Area 2 reports output to virtual printer
12 are reported (annunciated) on station 4.

32.2 Setting Up a Configuration File
Introduction
You must build a configuration file to define virtual printers. The
Command Processor editor (ED) is used to build the configuration file.
Naming the
configuration file
Only one configuration file per console is allowed and the file must be
named:
VPCONFnn.XX
Where:
• nn is the two digit console number from 01 to 10.
• The file extension must be XX.
• The file must be saved in the &ASY directory.
Activating the
virtual printers
After the file is established and its contents are specified, you must
reload all the console’s Universal Stations running operator or
universal personality for the virtual printers to become effective.
Contents of a
configuration file
The contents of the configuration file are records defining the VP
(virtual printer) number and its options. A report is usually written to
a VP that has been set up just for it.
Constructing the
configuration file
Build each configuration record in the configuration file as follows:
VP: PATH>FILENAME.XT FO FO ERROR
The parameters in each record are explained below.
VP
The virtual printer number from 11 through 30.

32.2 Setting Up a Configuration File, Continued
PATH
If you are sending your data to the HM, use the path
NET>VDIR
If data is being sent to removable media, use the path
$Fn>VDIR
Note, however, that any volume or directory designation beginning
with a “!” or “&” are disallowed.
FILENAME.XT
FILENAME can be up to eight valid alphanumeric or wildcard
characters. The suffix (.XT) must begin with X, Y, or Z and be in
either upper or lower case. It can be followed by any valid
alphanumeric or wildcard character.
• WILDCARD—Each wildcard character is specified by entering a
question mark (?). If one or more wildcard characters are entered,
each question mark is replaced by a random numeric digit (0–9).
• VOLUME—The volume (see “PATH,” above) must exist at the
time a filename is created by your configuration file. A missing
volume is considered an error.
• REPORT CREATION—Only a single virtual printer report is
placed in a file that has been named with wildcard characters. If the
file was named without wildcard characters, a new report is
appended to the reports currently in the file.
• FINDING FILES—If your filename contains wildcard characters,
you cannot readily determine what filenames the system assigned.
Determine system-assigned names by listing your filenames after
the file(s) has been used.
ERROR
This field specifies how errors are to be handled:
• If SYS is specified, the system handles errors as long as it can.
• If USER is specified, and if failover was unsuccessful or was not
specified, an information screen is presented to the user so recovery
options can be specified.
• If the field is left blank, the system defaults to the USER option.
See “Error Handling” in this section to review the error handling

process.

32.2 Setting Up a Configuration File, Continued
FO
Each FO is a FailOver two-digit number.
This specifies the virtual printer number(s) that is used if this virtual
printer number cannot be used.
• Any number of FOs, up to the maximum chain of 19, can be
assigned. The VP cannot specify itself as a failover printer.
• Any real printer, numbered from 1 to 10, cannot be specified.
• Failover does not migrate from one failover chain to another. That
is, if all the VPs specified in the failover chain of a certain printer
fail, there is no attempt to follow any of those VPs’ failover chains.
• On systems at R410 and later, failover occurs for demanded reports
and reports and logs initiated by CL programs, but it does not occur
for reports requested through the Organizational Summary displays.
32.3 Sending Reports to a Virtual Printer File
Sending a report
Send reports to a virtual printer in exactly the same way as you would
to a physical printer. Just change the printer number you normally
request, to the virtual printer number.
Specifying printer
numbers
Printer numbers are specified as follows:
• On the Report/Log/Trend/Journal Menu, Event History Menu, and
PV Retrieval Menu. For more information refer to the Process
Operations Manual.
• When reports, trends, logs, and journals are defined in Area
database configuration. For more information, refer to Area Form
Instructions.

32.4 Using File Descriptors to Identify Virtual Printer
Files
Introduction
File descriptors can be very helpful in identifying individual virtual
printer files. You list these files using a Command Processor LS
command with the File Descriptor option:
LS Net>VDIR>FILE.* -FD
When a report is stored in a virtual printer file, the system enters the
following in its file descriptor:
|1 - 8|10-17|19 - 26|
| DATE|TIME |RPT NAME|
CL programs, including CL programs that send Event Initiated
Reports, can enter a string of up-to-36 characters in the file descriptor
by using the SEND command’s $DESC option (for more information
about Event Initiated Reports see Section 30 of this manual).
Entering 36-
character
descriptor in a CD
parameter
In this example, the custom data parameter DESCSTR, is given the
string content “I’M A 36-CHARACTER DESCRIPTOR STRING.”
CUSTOM
PARAMETER DESCSTR: STRING
VALUE = "I’M A 36-CHARACTER DESCRIPTOR STRING"
END CUSTOM
Writing a file
descriptor string
Then, when this CL program executes, the report SYSTATUS is
written and the parameter DESCSTR is placed in the file descriptor.
BLOCK ROF (POINT ROFPOINT; AT GENERAL)
SEND: "$OUT_RPT SYSTATUS $DESC DESCSTR"
END ROF
A file descriptor with program written string has this form:

|1 - 8|10-17|19 - 26|28 - 64|
| DATE|TIME |RPT NAME|I’M A 36-CHARACTER DESCRIPTOR STRING|
Demand-Initiated
file descriptors
For Demand-Initiated reports, the date, time, and report name are
written in automatically. You cannot enter a file descriptor string into
these reports.

32.5 Displaying and Printing Reports
Introduction
You may use either schematics or the Command Processor to display
and print reports stored in virtual printer files.
Using schematics
There are two Picture Editor actors that can be placed in a schematic.
They follow the existing rules of Picture Editor format:
DSP_FILE (PATH>FILENAME)
PRT_FILE (PATH>FILENAME)
The actors R_STR and R_INT can be used with both of the above as
shown in these examples:
DSP_FILE(R_STR(1,10,21,’ENTER PATH AND
FILENAME’,TRUE,0))
PRT_FILE(R_STR(1,10,21,’ENTER PATH AND
FILENAME’,TRUE,0),
R_INT(1,12,2,’ENTER PRINTER NUMBER’,TRUE,0))
You must know the name and path of the report.
Reference
Refer to the Picture Editor Reference Manual and check the following
information:
R_INT Read Integer Data F.4.7
R_STR Read String Data F.4.13
Screen regions F.1.7
Parameter explanation F.6.1
Using the
Command
Processor
Because many of the report filenames may be generated by the system,
you will probably use the LS command with the -FD option to
determine which reports you want displayed.
The LS command produces a list of the file descriptors in each file.
Based on the descriptor contents, you can choose which files you want
displayed and printed.
After you have determined the files you want, use the regular PRINT
(P or PR) command to print your report.

32.6 Status and Error Messages
Introduction
This subsection describes the status messages and error messages that
are generated by virtual printer operations, and their causes. Universal
Station status changes associated with the messages are also described.
For information about how the system and operators handle virtual
printer errors, see 32.7.
Two classes of
messages
Virtual printer operations generate these two classes of messages:
• Messages that report status changes and errors related to reports
directed to a virtual printer. These messages include the phrase
“REPORT_MEDIA.”
• Messages that report status changes and errors related to the system
interpreting (parsing) a virtual printer configuration file. These
messages include the phrase “VP CONFIG.”
How to see the

messages
Virtual printer messages are available on the Status Detail display for
the US to which the virtual printer is assigned. They are also available
on the Status Notification display. The Status Detail display has only
the most recent messages, while you can see all of the messages on
Status Notification display.
Use the Console Status display to call up the Status Detail display.
For detailed instructions, see Section 14 of the Process Operations
Manual.
The Status Notification display is accessed through the Event History

Retrieval display. For detailed instruction see Section 10 of the
Process Operations Manual.

32.6 Status and Error Messages, Continued
US status
changes
The system generates two messages that are not considered as error
messages and do not change the status of the assigned US. These VP
CONFIG messages are:
NO ERRORS FOUND IN CONFIGURATION FILE
NO CONFIGURATION FILE FOUND
All other messages are error messages, and all of these change the US
status.
• REPORT MEDIA messages change the US status to SEVERE.
• VP CONFIG messages change the US status to WARNING.
When a VP CONFIG message is generated, the Status Detail display

message says:
SYNTAX ERRORS IN FILE, STATUS NOTIFICATION LOG HAS DETAILS.
When this message appears, call up the Status Notification display to

see the error message(s).
REPORT MEDIA
error messages
These messages are generated when a report cannot be delivered to a
virtual printer. The messages explain why the operation could not be
completed. For example, the following is a portion of an actual
message:
OK—> SEVERE VP# $F3 VP13 SPECIFIED VOLUME IS NOT ON THE
MEDIA
In this case the report was directed to drive $F3, volume VP13, virtual
printer 13, but the name of the volume on the disk mounted in drive
$F3 was JOHN. Because the specified volume was not found, the
system could not determine if VP13 was in that volume or not, so it
did not report a virtual printer number (the field after “VP#” is blank).

32.6 Status and Error Messages, Continued
VP CONFIG error
messages
Table 32-3 lists phrases in virtual printer configuration file error
messages and the probable causes of those messages. These messages
also refer to the virtual printer number or if that cannot be determined,
the line number of the virtual printer record in the configuration file.
Table 32-3 VP CONFIG Error Messages
Error message Phrase Probable Causes
While processing VP # • Colon missing after a VP number in a
configuration file record
• Virtual printer number not in the range from 11
to 30
• An non-numeral used in virtual printer number
While processing Comment delimiter missing ({ or }) or an extra
comment removal opening or closing delimiter
While processing path • No space between “:” and the beginning of the
name configuration record path name
• Invalid pathname syntax
• Invalid device ($Fn or NET)
• File name extension (suffix) that doesn’t begin
with X, Y, or Z
While processing fail • Virtual printer number not in the range from 11
over table to 30
• Circular reference in a fail over table (virtual
printer references itself)
While processing— • Incorrect configuration file name
unable to open file • An attempt to place a configuration file in a
volume or directory other than &ASY
While processing—bad • An I/O error encountered while trying to read a
read operation file
While processing bad • An FO field referenced a virtual printer not

failover entry configured
• Duplicate virtual printer numbers in a failover
table
While processing media Error field in a configuration record contains
full keyword something other than SYS or USER.
While processing An unexpected character follows SYS or USER
unexpected data in a configuration record
While processing This type of error should not occur. If it does,
unknown area contact TAC or the equivalent service in your
region.

32.7 Error Handling
Introduction
You may choose (see 32.3) one of two methods of error handling:
• SYStem or
• USER.
This section describes how the system handles errors when each of
these methods have been specified.
SYStem error
handling
If SYStem error handling has been specified, the system checks to see
if the error is caused by lack of space in a file or directory. If true, the
system invokes the sequences in the order shown in Table 32-4.
If the error is not caused by lack of file or directory space, a failover
attempt is tried immediately (Table 32-5, Stage 2).
Table 32-4 SYStem Error Handling Process

IF…
Stage THEN …
1 • There is not The system tries to make room by deleting

enough file an unprotected file in the directory.
space An attempt is made to dispatch the report. If
or successful the error process is halted.
• No more entries If unsuccessful, another unprotected file is
can be handled deleted and the attempt is retried.
by the directory.
After all unprotected files are deleted, the
process continues…
2 • There is still not A FailOver swap is attempted. That is…

enough space.
If the user has specified one or more
FailOver virtual printers, the system chooses
each failover virtual printer in turn in an
attempt to dispatch the report.
After all virtual printers in that Failover
sequence are tried unsuccessfully, the error
process continues.
3 • The previous The system puts the US in the SEVERE

attempts fail. state.
Result: The operator must direct error
handling through the USER error sequence
(see "Answering a USER error" in 32.7)

32.7 Error Handling, Continued
USER error handling

USER error handling invokes the following sequences.
Table 32-5 USER Error Handling Process

IF…
Stage THEN …
1 • An error A FailOver swap is attempted. That is…
occurs. If the user has specified one or more FailOver
virtual printers, the system chooses each
failover virtual printer in turn in an attempt to
dispatch the report.
After all virtual printers in that Failover
sequence are tried unsuccessfully, the error
process continues…
2 • The previous The system puts the US in the SEVERE state
attempts fail.
Result: The operator must direct error handling
through the USER error sequence (see
"Answering a USER error" in 32.7)
Answering a
USER error
Regardless of the error handling specified, you must manually resolve
a SEVERE status problem with the following procedure.
Table 32-6 SEVERE Status Handling Procedure

Step Action
1 Use the [CONS STATS] key to…
call up the CONSOLE STATUS AND ASSIGNMENT display.
2 Select STATUS DETAIL which calls the STATUS DETAIL display.
3 Select the virtual printer status line that shows the transition to the
SEVERE state.
4 Select VIEW OBJECT DETAIL
The MEDIA ERROR CORRECTIONS OPTIONS display appears.

5 Select one of these options to resolve the problem:
• RETRY (After you have fixed the problem)
• RETRY with a different Virtual Printer
• ABORT

32.7 Error Handling, Continued
Changing the US
from SEVERE or
WARNING state
back to OK
To do so, you must shut down and reload the US.
We recommend that on the Status Detail display, you enter a comment

for the status line (object) that notes that the error that caused the
change of state has been resolved. You should also inform others who
may be concerned that the error has been resolved. Instructions for
entering and viewing comments are in the Process Operations
Manual.

32.8 Purging and Protecting Virtual Printer Files
Why should virtual

printer files be
purged or
protected?
Virtual Printer files that are no longer used should be purged from the
system. If the system runs out of space, automatic error handling
procedures may purge files that you don’t want destroyed.
For these reasons, you should do your own “housekeeping” by

protecting the files you don’t want destroyed and purging the files you
don’t need.
Purging virtual
printer files
You must use the Command Processor to manually delete the report
files.
Since many of the filenames may have been generated by the system,
use the LS command, then choose the files you either want to delete or
save.
You can save files for future use by copying them to external media.
Protecting virtual
printer files
You can avoid destroying files that you still need on the system by
protecting them.
To protect files, refer to 5.24 in Command Processor Operation,

binder TPS 3030-1.

Section 33 – Keyboard Button LED Assignment and Control
33.0 Overview
Introduction
This section describes the implementation and use of CL messages to
assign primmod values to buttons and control the LEDs on the
buttons.
Description This section describes Trigger

primmod assignments on
specified LED buttons
associated with any of the AM US
Message
40 configurable LED or CG
buttons to be dynamically
changed for the local LCN
Universal Station.
NIM
or HG Message
References to LEDs are
specific to the red and
yellow lights visible on
each of the LED buttons
on the US keyboard. Each
16392
LED can be set to one of
three possible states: ON,
OFF, or BLINK.
How is the CL
message
initiated?
One way a program could be notified to send a CL message which
controls the buttons is—
A schematic in a US sends a trigger value to the point containing
the CL program which has a message to send.

33.1 Implementation
Introduction
Any user-written program can send a message that controls the
buttons, including:
• Advanced Control Programs (ACPs) in upper-level processors
connected to a CG
• CL programs in AMs
• Sequence programs in APMs, PMs, and MCs
Types of
messages
There are two types of these CL messages:
• Button PRIMMOD Assignment
• Button LED Control
Message sending
capabilities
Characteristics of message-sending capabilities of AMs, APMs, CGs,
and PMs/MCs that you should consider as you implement these
messages are found later in this section. Other important information
can be found in the following publications.
References
For more detailed information:
• See the Control Language/Multifunction Controller Reference
Manual
• See the Control Language/Application Module Reference Manual
• See the Control Language/Process Manager Reference Manual
• See the Control Language/Advanced Process Manager Reference
Manual
• See the Button Configuration Data Entry
• See the Button Configuration Form Instructions

33.1.1 Message-Source Considerations
Introduction
Here a summary of the characteristics of message-sending capabilities
of AMs, APMs, CGs, and PMs/MCs that you should consider.
Messages from
AMs
The messages from AMs consist of up to 16 individual message items
of various types. Maximum string length is 64 characters.
Messages from
APMs
There is no maximum message item length from APMs, but the total
string length is limited to 60 characters, if the destination is a CRT, or
71 characters if the destination is the Real Time Journal.
Messages from
CGs
The messages from CGs originate in the upper-level processor as
complete strings of up to 120 characters.
Messages from
PMs, MCs
The messages from PMs and MCs consist of up to seven individual
message items of various types. Message items are limited to eight
characters or less. For example, “Error has occurred.”
This means that not all of the message options can be used in one
message, but you can use the “=” and “,” separators to reduce the
number of items.
Use of separators
with message
items
In the following message descriptions, spaces are shown as separators
between options and option components. “=” and “,” can also be used
as separators. For messages from PMs and MCs, this is important
because of the seven message item limit.
For example, $AREA 05 (two message items) could be written
$AREA=05 (one message item), and ALM UNT A1 A2 A3 (five
message items) could be written ALM,UNT A1,A2,A3 (two message
items).

33.1.2 Button PRIMMOD Assignment
Overview
With R520, Button Primmod Assignment permits US LED Buttons to
be dynamically assigned to different primmod values by using a
schematic utilizing an actor or by using a CL message. The types of
CL messages which can be used include AM, MC, and
PM/APM/HPM.
CL SEND
statement
A predefined form of the SEND statement (see example below) allows
you to assign a primmod or clear a previous assignment on a specified
LED button. The message is distributed to all US nodes whose area
databases contain the unit of the point to which the CL belongs. The
CL message can be further filtered by console and/or area databases.
The primmod is stored to lamp specific data with the LED buttons and
will occur even if the lamp specific data was previously assigned with
a unit id, an annunciator group, or no value. (For detailed information
on the actors that can assign and read primmod names associated with
the configurable buttons, see the Actors Manual)
Example of CL SEND
Statement to assign
Primmod
The following predefined form of the SEND statement will be
recognized to allow you to assign a Primmod value to the lamp-
specific data associated with a specific configurable LED button:
SEND:$BTN_PRM<button><Primmod>$AREA=aa$CONS=bb $CLEAR
$BYPASS
Where:
$BTN_PRM is a keyword that must be specified;
<button> symbolic button name that is a string of 1..8 characters;
<Primmod> Primmod name that is a string of 1..16 characters
(except for PM & MC);

33.1.2 Button PRIMMOD Assignment, Continued
Example of CL SEND
Statement to assign
Primmod , continued
$AREA is an option that allows you to specify a particular area;
aa must be specified with the $AREA option and is a valid area
number from 1..10;
$CONS is an option that allows you to specify a particular console;
bb must be specified with the $CONS option and is a valid area
number from 1..10
$CLEAR is an option that allows you to clear the lamp-specific data
assignment;
$BYPASS is an option that allows you to specify that the SEND
message will go to only the HM and not to the Operator Message
Summary or the RTJ.
Note: The button assignment will still occur as usual.
Node Startup/Area
Change
During node startup and area change, the US will create “default”
symbolic names of “AN_CNFxx,” where xx represents a 1- or 2-digit
configurable LED button number from 7 to 46. Any of the “default”
symbolic names that are overwritten during node startup or area
change by the Button Name File will not be recognized as valid
symbolic names.
Button Name File

The text editor is used to create the Button Name File. A symbolic
name can be defined for the 40 configurable LED buttons in the file
consisting of the maximum file size of 1000 lines, allowing adequate
room for user comments. These symbolic names are used in the CL
messages and actors to identify the destination button. (For detailed
information on the Button Name File, see Button Configuration Data
Entry and Button Configuration Form Instructions.)
Actor
GET PRIMMOD
This actor allows the user to retrieve a primmod value assigned to the
lamp-specific data of a configurable LED button. This actor can be
used in a target action within a custom schematic, or a button action
assigned to a configurable button, and will retrieve a primmod only on
the local US (see Actors Manual).

33.1.3 Button LED Control
Overview
Button LED Control permits US Button LED states to be dynamically
changed via an AM, MC, or a PM type CL Send statement.
CL SEND
statement
The primary intent of the SEND statement function is to allow user-
written applications to alter the red and yellow LEDs on the
configurable LED buttons. These LEDs are set ON, OFF, or BLINK
using a single SEND statement. This occurs even if the lamp specific
data was previously assigned with a unit id, an annunciator group, or
primmod name.
CL SEND example
Following is an example of a CL SEND statement that allows a
custom user application to alter the behavior of the red and/or yellow
LEDs on the configurable buttons.
SEND:”$BTN_LED<button>RED=<state>YEL=<state>$AREA=aa$CONS
=bb$BYPASS”
Where:
$BTN_LED is the first keyword that must always be specified;
<button> symbolic button name, which is a string of 1..8 characters
that must always be specified as the second field in the string;
RED is a keyword that must be specified to alter the red LED;
YEL is a keyword that must be specified to alter the yellow LED;
<state> must be specified when the RED or YEL keyword is used
(ON, OFF, or BLI);
$AREA is an option that allows you to specify a particular area;
aa must be specified with the $AREA option and is a valid area
number from 1..10;
$CONS is an option that allows you to specify a particular console;
bb must be specified with the $CONS option and is a valid console
number from 1..10;
$BYPASS is an option that allows you to specify that the SEND
message will go to only the HM and not to the Operator Message
Summary or the RTJ.
Note: Normal SEND statement syntax and variable rules apply.
SEND: “$BTN_LED AN_CNF22 RED=OFF YEL=BLI $BYPASS”

33.1.3 Button LED Control, Continued
Area Database
Change
Performing an area change will cause the Button Configuration file
and its associated Button Name file to be read in for the specified area.
The Button LEDs status will be reset to reflect the status specified in
the Button Configuration file. The Button Name file is an optional way
to rename the configurable buttons. See the Button Configuration Data
Entry Manual – Section 7 for information on building this file.
Once a Button Name File has been successfully read, any user-defined
symbolic names specified in the Button Name File will overwrite the
corresponding “default” button names. The defined symbolic button
names will be recognized as valid names only upon completion of
node startup or an area change. The “default” symbolic names
overwritten during node startup or area change will be no longer be
recognized as valid symbolic names.
RED/YEL
keywords
This function allows the user to alter both the red and yellow LEDs,
but if only the red LED is specified in the SEND statement, only the
red LED behavior is altered; likewise for the yellow LED. In addition
to the symbolic button name, the user must specify at least one of the
LED keywords in the SEND statement.
BYPASS Option
This option provides a way to specify that a SEND message should
NOT go to, or bypass, the Message Summary and the RTJ printer.

33.1.4 Error Handling
Introduction
This section describes error handling for Button Primmod Assignment:
and Button LED Control.
Button Name File

When a Button Name File is not found upon completion of startup or
area change, no Status Accountant object and message is generated.
When it is successfully found, a message is generated and displayed
on the Status Detail display.
In addition to the existing two object messages, any of four messages
may appear on the Status Detail Display for a US after node startup or
area change. If an attempt is made to edit the button file, while at the
same time performing an area change, a message is generated (“Error
occurred attempting to read button name file”).
CL SEND
statement
message
If the SEND message references an invalid symbolic button name (one
that is not a default name or one previously defined) or an invalid
primmod name, this could result in not receiving alarm notifications.
Any of four messages associated with invalid SEND messages may
appear as SEND objects on the Status Detail Display for a US after
node startup or area change.
Actors
When a target or button with a series of actors begin executing,
continued execution depends upon the successful execution of the
previous actor. Therefore, error handling associated with the new
actors will be based upon whether or not continued actor execution
should occur.
CAUTION .
An Area Change will update the configurable LED buttons to reflect

their preconfigured lamp specific data assignment. However, it is not
recommended that you execute SEND messages at the exact same
time as initiating an Area Change request because there is no way to
ensure whether the SEND messages are processed before or after the
Area Change. Not following this recommendation may result in the
configurable LED buttons reflecting a state that is not expected.

Section 34 – LCN Node Version Revision Logging
34.0 LVRLOG Overview
Introduction
The LCN Node Version/Revision Logging function is a software
application package which operates on Universal Stations of the
Honeywell TPS system. This function is a TPS “backplane” extension
of the Universal Station Operator personality and Universal
personality. This function is packaged as an External Load Module.
Description
The LCN Node Version/Revision Logging function is a display
initiated version/revision report generator.
With R670, you can initiate the LVRLOG application in GUS or

LCN-connected ES-C nodes. For details, refer to the TPS System
Operations Guide, TP07W.

34.1 LVRLOG General Functionality
Report generation
With the LCN Node Version/Revision Logging function, the operator
can request (from a single provided Universal Station display) the
generation of a report which details the following:
• each node on the LCN (also each card in the node)
• each Data Hiway connected to the LCN (also each Box on the
DataHiway)
• each UCN connected to the LCN (also each Module on the UCN
and each card in the Module)
The information in the report includes the version and revision for the
hardware, firmware, and software currently being used on the system.
This report includes information down to the card level. The limiting
factor is the electronic accessibility of information from particular
electronic modules (not all modules can be accessed for
version/revision information). The report contains node, module, and
card type and number information.
For the LCN nodes, the report includes the version and revision of the
personality software currently loaded in the node. For the LCN nodes,
the report also includes the name, the version, the revision and the
memory location of each External Load Module loaded in the node.
ATTENTION .
Throughout this LCN Node Version/Revision Logging function section

the term “Universal Station” is used to denote the station on which the
user communicates with the Honeywell TPS system. Actually, you can
use a Universal Station, a Universal StationX, a Universal Work Station or
a Global User Station (through the Native Window) to communicate with
the Honeywell TPS system.
User interface
A single custom display (LVRLOG) is used by the operator to—
• enter “user entered” 8 character “site” identifier.
• enter “user entered” 8 character “LCN ID.”
• initiate the generation of the report.
• view the generated report via a “display window” that can be paged.
• enter LCN console printer number.
• initiate printing of the generated report on the LCN console printer.
• cancel printing of the generated report.

34.1 LVRLOG General Functionality, Continued
Report format
The generated report is in the form of two text files which reside in the
History Module. The first file is generated for display and printing by
the LCN system. The second file is generated specifically for import
into Microsoft Excel. To facilitate the import of the report into
Microsoft Excel, the fields in this file’s records are separated by
commas. The records in both of the text files are a maximum of 132
characters in length. Both generated report files contain embedded
field heading information as appropriate to identify the data.
Example
0 07/10/96 15:30:54
1 SITEID LCNID PNN NODET NODEN BOARDT SLOTN HWV HWR FWV FWR FWT SWV SWR SWNAME SWLOC
2 IAC_UHF Test_Sys 01 HG 06 K2LCN-2MW 01 00 M 00 B 01 50 30 HGO
2 IAC_UHF Test_Sys 01 HG 06 K2LCN-LCN 01 02 A 00 A 01 50 30 HGO
2 IAC_UHF Test_Sys 01 HG 06 HWY 02 00 K 00 L 01 50 30 HGO
2 IAC_UHF Test_Sys 02 NIM 09 HPK2-3MW 01 04 K 00 B 01 50 13 NMO
2 IAC_UHF Test_Sys 02 NIM 09 LCNI 02 00 F 00 C 01 50 13 NMO
2 IAC_UHF Test_Sys 02 NIM 09 EPNI 05 02 H 00 B 01 50 13 NMO
2 IAC_UHF Test_Sys US 26 K4LCN_8MW 01 05 A 00 A 01 50 49 UP
2 IAC_UHF Test_Sys US 26 K4LCN_LCN 01 03 A 00 A 01 50 49 UP
2 IAC_UHF Test_Sys US 26 EPDG/SCSI 05 02 H 01 H 01 50 49 UP
2 IAC_UHF Test_Sys US 26 LOADMOD 50 01 UPLVR 00C0E11A
2 IAC_UHF Test_Sys US 26 LOADMOD 50 09 UPBASE 00C1C61C
2 IAC_UHF Test_Sys HMON 50 K2LCN-8MW 01 04 J 00 B 01 50 33 HMO
2 IAC_UHF Test_Sys HMON 50 K2LCN-LCN 01 02 A 00 A 01 50 33 HMO
2 IAC_UHF Test_Sys HMON 50 SPC 02 01 F 00 G 01 50 33 HMO
3 SITEID LCNID HWY BOXT BOXN CARDT CARDN BOXSIZE

4 IAC_UHF Test_Sys 01 HG 02

4 IAC_UHF Test_Sys 01 HLPIU 05 ANALOGIN 01 REGULAR
4 IAC_UHF Test_Sys 01 HLPIU 05 ANALOGOT 03 REGULAR
4 IAC_UHF Test_Sys 01 HLPIU 05 DIGIN 04 REGULAR
4 IAC_UHF Test_Sys 01 HLPIU 05 DIGOUT 05 REGULAR
4 IAC_UHF Test_Sys 01 HLPIU 05 NONE 09 REGULAR
5 SITEID LCNID UCN NODET NODEN CARDT MODN FILEN CARDN FILEP HWR FWR SWV SWR SWNAME REDUNCY
6 IAC_UHF Test_Sys 02 NIM 01 MODEM 27
6 IAC_UHF Test_Sys 02 NIM 01 PROTOCOL 00 01
6 IAC_UHF Test_Sys 02 NIM 01 UCNLLN 3B 01
6 IAC_UHF Test_Sys 02 NIM 01 DRIVER 3B 01
6 IAC_UHF Test_Sys 02 NIM 01 TBC 00
6 IAC_UHF Test_Sys 02 APM 13 APMMMOD 01 01 FILE_1 2A REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCOM 01 02 FILE_1 24 42 42 04 APMCOM REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCOMD 01 02 FILE_1 22 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMIOL 01 03 FILE_1 13 41 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCTL 01 04 FILE_1 26 43 42 01 APMCTL REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCTLD 01 04 FILE_1 00 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMTBC 08
6 IAC_UHF Test_Sys 02 APM 13 HLAI 01 a 01 06 24 3.3
6 IAC_UHF Test_Sys 02 APM 13 AO 06 a 01 11 02 3.4
6 IAC_UHF Test_Sys 02 APM 13 DI 07 a 01 12 01 3.3
6 IAC_UHF Test_Sys 02 APM 13 NONE 08 a 01 13
6 IAC_UHF Test_Sys 02 APM 13 PI 09 a 01 14 20 3.3
7 REPORT COMPLETE

Key value definitions

The first character of each file record is a “key” to the contents of the
record. The definition of the key values is as follows:
0 = Heading and Error records
1 = LCN node, card description (and load module description)
header record
2 = LCN node, card description (and load module description)
record
3 = Data Hiway box, card description header record
4 = Data Hiway box, card description record
5 = UCN node, card description header record
6 = UCN node, card description record
7 = Completion record
The key value can be used to identify the record types, when the file is
imported into Microsoft Excel.
Meanings of header
record field descriptors
The meanings of the header record field descriptors are as follows:
Table 34-1 LCN Node, Board Description Header Record
Field Descriptor Field Descriptor Meaning
SITEID Site ID, 8 character user entered
LCNID LCN ID, 8 character user entered
PNN Process Network Number (LCN node associated DH
or UCN Number)
NODET LCN Node Type
NODEN LCN Node Number
BOARDT Node Board Type (or LOADMOD if Load Module)
SLOTN Node Slot Number
HWV Hardware Version
HWR Hardware Revision
FWV Firmware Version
FWR Firmware Revision
FWT Firmware Type
SWV Software Version
SWR Software Revision
SWNAME Personality or Load Module name
SWLOC Location of Load Module

Meanings of header
record field
descriptors,
continued
Table 34-2 Data Hiway Box, Card Description Header Record
HWY Data Hiway Number
BOXT Box Type
BOXN Box Number
CARDT Card Type
CARDN Card Number
BOXSIZE Box Size
Table 34-3 UCN Node, Card Description Header Record

UCN Universal Control Network Number
NODET UCN Node Type
NODEN UCN Node Number
CARDT Card Type
MODN Module Number
FILEN File Number
CARDN Card Number
FILEP File Position
HWR Hardware Revision
FWR Firmware Revision
SWV Software Version
SWR Software Revision
SWNAME Software Name
REDUNCY Redundancy

Node (Boxes)
reported
Information on the following specific LCN Nodes, Data Hiway Boxes,
and UCN Nodes is provided in the report generated by the LCN Node
Version/Revision Logging function. Not all modules can be accessed
for version/revision information. In the case of the Data Hiway,
revision/version information is not available at the box or card level.
Table 34-4 LCN Nodes Reported

LCN Node Report Full LCN Node Name
Descriptor
US Universal Station (also Universal Work Station)
UXS Universal StationX

AM Application Module
AXM Application ModuleX

HM History Module
NG Network Gateway
CG Computer Gateway
HG Hiway Gateway
NIM Network Interface Module
CLM Control Link Module (for CLM R500 and later).
(Before CLM R500, any AM which is configured as a
CLM is reported as an AM.)
AMX AMX (for AMX R500 and later). (Before AMX R500,
any NIM which is configured as an AMX is reported
as a NIM.)
GUS Global User Station (available with LCN R510)
ATTENTION .
Any PLCG (Programmable Logic Controller Gateway) or EPLCG

(Enhanced Programmable Logic Controller Gateway) is reported as a
HG.

Node (Boxes)
reported,
continued
Table 34-5 Data Hiway Boxes Reported
Data Hiway Box Full Data Hiway Box Name
Report Descriptor
CB Basic Controller
AU Analog Unit
HLPIU High Level Process Interface Unit
LEPIU Low Energy Process Interface Unit
LLPIU Low Level Process Interface Unit
CBRCD Basic Controller Reserve Controller Director
EC Extended Controller
ECRCD Extended Controller Reserve Controller Director
MC Multifunction Controller
MCRCD Multifunction Controller Reserve Controller Director
DHP Data Hiway Port / TPCD 620 Hiway Interface Module
OPSTA Operator Station, Basic or Enhanced
H4500 Honeywell 4500 Computer
HG Hiway Gateway
GPCI General Purpose Computer Interface
Table 34-6 UCN Nodes Reported

UCN Node Full UCN Node Name
Report Descriptor
PM Process Manager
APM Advanced Process Manager
HPM High-Performance Process Manager
LM Logic Manager
SM Safety Manager (Triconex TRICON System)
(available with LCN R500)
SM Safety Manager (Honeywell FSC System) (available
with LCN R510)

34.2 LVRLOG Requirements
Hardware
requirements
The LCN Node Version/Revision Logging function requires (or can
optionally utilize) the following TPS system hardware:
• Universal Station (optional, at least one (1) Universal Station,

Universal StationX, Universal Work Station, or Global User Station
is required)
• Universal StationX (optional)
• Universal Work Station (optional)
• Global User Station (optional) (Global User Station available after
R510)
• Matrix Printer (Console Printer) (optional)
• Signum 2043 Printer (optional)
• History Module
When used with a Global User Station, the LCN Node

Version/Revision Logging function will operate only in the “native
window.”
The LCN Node Version/Revision Logging function requires dedicated

memory in each Universal Station, Universal StationX, Universal
Work Station or Global User Station on which it is to be used.
Memory
requirements
The LCN Node Version/Revision Logging function must have
sufficient memory dedicated to the use of the function. The following
personalities require the indicated amount of dedicated memory:
Operator Personality - 61K bytes (approximately)

Universal Personality - 61K bytes (approximately)
Software
requirements
The LCN Node Version/Revision Logging function requires a
Universal Station loaded with an Operator or Universal personality of
LCN Release 432, LCN Release 510, or LCN Release 520. The
function software must be configured and loaded into each US from
which the report generation function is to be initiated.

34.2 LVRLOG Requirements, Continued
Software
requirements,
continued
The function utilizes the following Honeywell Developer’s Display
Data Base (DDB) indices in the definition of Custom Global Display
Data Base variables: (2830 through 2834 inclusive — are assigned for
use by Phoenix Custom Systems Developers).
ATTENTION .
Indices used to define Custom Global Display Data Base variables

have been dedicated (see Actors Manual, SW09-55) as follows:
Table 34-7 Dedicated Custom Global DDB Indices

From - To Dedicated for Use by
100 — 1999 Yamatake Honeywell Developers
2000 — 3999 Honeywell Phoenix Custom Systems Developers
4000 — 5999 Honeywell Canada Developers
6000 — 7999 Honeywell PACE Developers
8000 — 9999 Honeywell Fort Washington Developers
10000 — 11999 Honeywell Icotron Developers
12000 — 13999 Honeywell / third party projects and joint ventures
14000 — 15999 Honeywell Toolkits Developers
WARNING
Caution should be taken in the use of the LCN Node Version/Revision
Logging function that would conflict with the use of Custom Global
Display Data Base variables defined using indices dedicated for other
uses.

34.3 LVRLOG Installation Requirements
Distributed files
The LCN Node Version/Revision Logging function software is
composed of several files which must be loaded on the target system.
The distributed disk contains the following load files necessary for
installation.
Two load object (.LO) files are provided—one load object (.LO) file
for each personality, Operator and Universal. These files can be found
on the provided LCN Software removable media (disk &Z1) under the
&CUS directory.
Load Object File Disk &Z1

OPLVR.LO LCN Node Version/Revision Logging function
software for Operator Personality.
UPLVR.LO LCN Node Version/Revision Logging function
software for Universal Personality.
One schematic file (.DO) is provided. This file is located on the

provided removable media (disk &Z1) under the TLK1 directory.
Schematic File Disk &Z1

LVRLOG.DO Display used to initiate action of the LCN Node
Version/Revision Logging function for R432 and
R5xx systems.

34.3 LVRLOG Installation Requirements, Continued
Finding directory
for storage of
displays
In the Operator or Universal Personality, find a directory that can be
used for the storage of displays as follows:
Table 34-8 Find a Directory

Step Action Result
1 Press the SYST MENU key. SYSTEM MENU appears.
2 Touch or TAB and SELECT the ORGANIZATIONAL
ORGANIZATIONAL SUMMARY SUMMARY MENU appears.
MENU target.
3 Touch or TAB and SELECT the At the bottom of the screen, a
SCHEMATIC TITLES target. DISPLAY target appears.
4 Touch or TAB and SELECT the The TITLE SUMMARY -
DISPLAY target. SCHEMATIC appears.
5 Choose one of the PATHNAMES
FOR SCHEMATIC SEARCH that
starts with “NET.” The pathname
should have the general form
“NET>xxxx>”.
The name of the directory is in the field represented as “xxxx” (to be

used in steps later in this section). Choose the directory that is used to
store the “Toolkit” displays.

34.4 LVRLOG Initial (First Time) Installation
Initial installation
The information in this section is for the initial installation. Refer to
the Upgrade Installation section if the software is already installed.
History Module
directories
Using the Command Processor function of the Engineering (LCN
R4XX systems only) or Universal Personality, determine if the
directory &CUS exists in the System History Module.
LSV NET
(list volumes on the network)
If the directory (&CUS) does not exist, use the Create Directory
command to create a directory under a volume on the History Module.
CD NET>vol> &CUS
(vol is an existing volume on the History Module)
Copying Load
Files to the HM
Mount the disk containing the LCN Node Version/Revision Logging
software in a removable media drive. Using the Command Processor
function of the Engineering (LCN R4XX systems only) or Universal
Personality, execute the following command to copy the LCN Node
Version/Revision Logging software package files to the History
Module.
CP $Fx>&CUS>OPLVR.LO NET>&CUS>= -D
CP $Fx>&CUS>UPLVR.LO NET>&CUS>= -D
(where x = the removable media drive number)

schematic in a removable media drive. Using the Command Processor
Module.
CP $Fx>TLK1>LVRLOG.DO NET>xxxx>= -D
(where xxxx = the previously chosen display object
storage directory)

34.4 LVRLOG Initial (First Time) Installation, Continued
Universal Station
configuration
Table 34-9 Universal Station Configuration
Step Action
1 From the Modify Volume Paths display in the Engineering (LCN
R4XX systems only) or Universal Personality, set the NCF Backup
Path to a removable media pathname.
$Fx>&ASY>
where x = drive number
Insert a backup &ASY disk in the removable media drive.

2 From the Main Menu of an Engineering (LCN R4XX systems only)
or Universal Personality, touch or TAB and SELECT the LCN
NODES target.
3 A display will appear with a target for each node possible on the
LCN. Verify that the Configurator is in the ON-LINE mode in the
upper right corner of the display.
Select the target for the node number of the Universal Station that is
to be configured. The PAGE FWD key may be required to display
the target for the desired US number.
4 A display will appear which allows the configuration of the selected
US. If this US has not already been configured onto the network, do
so at this time.
5 Touch or TAB and SELECT the MODIFY NODE target.
6 The next display that appears (page 2) will allow you to configure
the software on the selected US.
This display contains 24 entry ports to enter Module Names, and 24

entry ports to enter Personality Types for external load modules.
NOTE:
It is important that you do not use the ENTER key until instructed.
Use the TAB keys to move from port to port, or if you have a
touchscreen, use that feature.

Universal Station
configuration,
continued
Table 34-9 Universal Station Configuration, continued
Step Action
7 If the US being configured is used as both Operator and Universal
personalities, key in the module names and personality types for
both personalities.
If the US being configured is always in the Operator personality, key

in the name and personality type for the Operator personality. In
this case, the Universal personality module does not have to be
configured.
If the US being configured is always in the Universal personality,

key in the name and personality type for the Universal personality.
In this case, the Operator personality module does not have to be
configured.
Module Type Personality

OPLVR OPR Operator
UPLVR UP Universal
8 Key in the required Module Names (in the entry ports for the
External Load Module Name) and required Personality Types (in the
entry ports for the Associated Personality Type), but—
do not press the ENTER key.
Touch or TAB and SELECT the NO target for the USE DEFAULT
PERSONALITY TYPE? question.
9 Press the <ENTER> key.
10 The LCN Configurator will determine the total size of the Software
defined for each personality configured. The LCN Configurator will
then return the size for each personality configured along side the
line “TOTAL (MODULES PLUS ADDITIONAL MEMORY).”
Round each of these numbers up to the next 1 K.

Add 2 K to the rounded numbers.
Key the totals into the associated boxes along side the line
“MAXIMUM EXTERNAL MODULE MEMORY (WORDS).”
This extra memory will allow for possible future maintenance or

upgrade releases to be loaded without requiring an NCF change.
12 Press the CTL and one key together:
(i.e., F1, to check the new NCF)
Press the CTL and two keys together:
(i.e., F2, to install the new NCF)

Universal Station
configuration,
continued
Table 34-9 Universal Station Configuration, continued

Step Action
14 Return to the Engineering (LCN R4XX systems only) or Universal
Personality Main Menu display. A message will appear at the
bottom of the display indicating the successful completion of the
NCF installation.
The Universal Station is now ready to be loaded with the addition of

the LCN Node Version/Revision Logging software.
15 Proceed with the loading of the US using the normal US load
procedure:
1. Shut down and reload the US.
2. Check if the new function is available for use:
Use the [CONS STATS] key to call up the CONSOLE STATUS

display. Select STATUS DETAIL which calls up the
STATUS DETAIL display.
3. After allowing time to load (several minutes, more on large

systems),
if the function is NOT available, the status will read:
Cust.Loader (OK --> Warning) (Description of
problem...)
NOTE:
Usually this error indicates that the configured software requires that
more memory be configured in the NCF. Follow Steps 1-15 to
correct the problem.
16 The entire above procedure (Universal Station Configuration) must
be repeated for each Universal Station on which the LCN Node
Version/Revision Logging function is to operate.

34.5 LVRLOG Upgrade Installation
Description
The information in this section is for installing an upgrade of the
software. Refer to the “Initial Installation” section if the software is
being installed for the first time.
Copying the Load
Files to the HM
software in a removable media drive. Using the Command Processor
Module.
CP $Fx>&CUS>OPLVR.LO NET>&CUS>= -D
CP $Fx>&CUS>UPLVR.LO NET>&CUS>= -D

schematic in a removable media drive. Using the Command Processor
Module.
CP $Fx>TLK1>LVRLOG.DO NET>xxxx>= -D
(where xxxx = the previously chosen display object storage
directory chosen during initial installation)

34.5 LVRLOG Upgrade Installation, Continued
Loading the node
Table 34-10 Loading the Node
Step Action
1 1. Shut down and reload the node.
2. Check if the new function is available for use:
Use the [CONS STATS] key to call up the CONSOLE STATUS
display. Select STATUS DETAIL which calls up the
STATUS DETAIL display.
3. After allowing time to load (several minutes more on large
systems), if the function is NOT available, the status will read:
Cust.Loader (OK --> Warning) (Description of
problem...)
NOTE: Usually this error indicates that the upgraded software
requires that more memory be configured in the NCF. Follow Steps
1-15 in “Universal Station Configuration” section to correct the
problem.
2 Step 1 above must be repeated for each Universal Station on which
the LCN Node Version/Revision Logging function is to operate.

34.6 Operating the LCN Node Version/Revision Logging
Function (LVRLOG)
Call Up LCN Node

Version/Revision
Logging Display
Use the LCN NODE VERSION/REVISION LOGGING display to
communicate with the LCN Node Version/Revision Logging function.
Table 34-11 Call Up LCN Node Version/Revision Logging Display

Step Action
1 Press the operator keyboard SCHEM key.
A prompt of “ENTER SCHEMATIC NAME” will appear in the upper

left corner of the screen and an associated port will open.
2 Key in LVRLOG.
The LCN NODE VERSION/REVISION LOGGING display (Figure

34-1) will appear on the screen.
Figure 34-1 LCN Node Version/Revision Logging Display
16424

Function (LVRLOG), Continued
Enter Site ID
The Site ID that appears in the generated report can be entered or
modified.
Table 34-12 Open Site ID Data Entry Port

Step Action
1 Touch or TAB and SELECT the ENTER SITE ID target.
The target will change color (from cyan to green) and a data entry
port will open to the right of the target.
2 Enter a 1 - 8 character alphanumeric Site ID.
Figure 34-2 LCN Node Version/Revision Logging Display (with

“Enter Site ID” data entry port)
16425

Enter Site ID,

continued
The data entry port will close, the target will change color (from green
to cyan) and the Site ID that was entered will now appear within the
border of the target.
Figure 34-3 LCN Node Version/Revision Logging Display (with Site

ID)
16426

Enter LCN ID
The LCN ID that will appear in the generated report can be entered or
modified.
Table 34-13 Open LCN ID Data Entry Port

Step Action
1 Touch or TAB and SELECT the ENTER LCN ID target.
2 Enter a 1 - 8 character alphanumeric LCN ID.
Press the <ENTER> key.

“Enter LCN ID” data entry port)
16427

Enter LCN ID,

continued
to cyan) and the LCN ID that was entered will now appear within the
border of the target.

LCN ID)
16428

Export file format

option
You may choose to have the export file generated with heading
information or without heading information. The use of the export
file without heading information may ease the job of importing the
file into some applications.
If you choose to have the export file generated without heading

information, you must select the “Exclude headings from export file”
target. If you choose to have the export file generated with heading
information, you must deselect the “Exclude headings from export
file” target.
Target is in Selected state if… Target is in the Deselected state

if…
the target is colored green (and is the target is colored cyan (and is half
full intensity). intensity).
When you touch TAB and The Target will …

SELECT…
the cyan colored “Exclude headings change color from cyan to green
from export file” target, (thus selecting the target).
the green colored “Exclude change color from green to cyan
headings from export file” target, (thus deselecting the target).
The state (selected or deselected) that the “Exclude headings from

export file” target is in when the report generation is initiated,
determines the format of the generated export file.
See the section of this document entitled “Export File (LVRLOG.RE)”

for a description of the export file.
Touch or TAB and SELECT (as required to select or deselect) the

“Exclude headings from export file” target (see Figure 34-5).

Select report
Node/Box subset
The three node/box subset targets (the “LCN nodes” target, the “DH
boxes” target and the “UCN nodes” target in Figure 34-5) allow you to
choose the system nodes and boxes for the generated report.
Node/Box is Selected if... Node/Box is Deselected if...

the subset target is colored green the subset target is colored cyan
(and is full intensity). (and is half intensity).
When you touch TAB and The Target will …

SELECT…
one of the cyan colored node/box change color from cyan to green
subset targets, (thus selecting the target).
one of the green colored node/box change color from green to cyan
subset targets, (thus deselecting the target).
At least one of the three node/box subset targets will remain in the
selected state at all times. The display will reject an attempt to set all
three node/box subset targets to the deselected state.
the last node/box subset target in the The display will not deselect the
selected state, node/box subset target; instead,
the display will generate an
audible error tone and display the
message “ERROR” in the upper
left corner of the display.
If... Then...
the “LCN nodes” target is in the the generated report will contain all
selected state when the report of the LCN nodes information.
generation is started,
the “DH boxes” target is in the the generated report will contain all
selected state when the report of the Data Hiway boxes
generation is started, information.
the “UCN nodes” target is in the the generated report will contain all
selected state when the report of the UCN nodes information.
generation is started,

Select report
Node/Box subset,
continued
Touch or TAB and SELECT (as required to select or deselect) the
three node/box subset targets (the “LCN nodes” target, the “DH
boxes” target and the “UCN nodes” target).
Initiate Report
Generation
Before initiating the report generation, verify that all LCN nodes, DH
boxes, and UCN nodes that you want information on (included in the
generated report), are in as “normal” an operating state as possible.
Examples are:
If... They...
the LCN nodes are in the OFF, will not be included in the generated
FAIL, PWR_ON, or ISOLATED report.
states,
the DH boxes are in the HWY ERR will not be included in the generated
state, report.
the UCN nodes are in the OFFNET will not be included in the generated
state, report.
The above examples do not cover all cases in which the node or box
will not be included in the generated report.
Touch or TAB and SELECT the INITIATE REPORT GENERATION

target in the LCN Node Version/Revision Logging Display
(see Figure 34-5).

Initiate report
generation,
continued
All targets (except the PERFMENU DISPLAY target) will disappear
from the display. The report generation status of “Report Generation
Requested” will appear approximately in the center of the display.
The message “Nodes/Boxes Processed 0” will appear three lines
under the report generation status.

Report Generation Status)
16429

Initiate report
generation,
continued
In a few seconds, the report generation status will change to “Report
Generation In Progress.” The number field in the message
“Nodes/Boxes Processed 0” will begin to be updated with a running
total of the LCN nodes, Data Hiway boxes, and Universal Control
Network nodes processed in the generation of the report.

Report Generation In Progress)
16431

Initiate report
generation,
continued
In a few minutes (more in the case of a large system), the targets will
reappear on the display. In the INITIATE REPORT GENERATION
target, the report generation status will be displayed. If the report was
generated, the report generation status will be “Report Generation
Complete.” If the report was not generated, the report generation
status will be “Report Generation Failure.” Touch or TAB and
SELECT the INITIATE REPORT DISPLAY target (see Figure 34-8)
to display the generated report.
Report Generation Complete or Failure)
16431
After a report has been generated (the appearance the report

generation status of “Report Generation Complete appears in the
INITIATE REPORT GENERATION target), the message “Export
File Pathname: NET>&CUS>LVRLOG.RE” appears on the display
beneath the three node/box subset targets. This informs you of the
pathname of the export file, so that you can copy the file for export to
another application on another system.

Initiate report
generation,
continued
The Export File Pathname is always the same pathname (and cannot
be changed). The Export File Pathname is displayed for convenience.
After the report has been generated (and the report generation status of
“Report Generation Complete” is indicated in the INITIATE REPORT
GENERATION target), touch or TAB and SELECT the INITIATE
REPORT DISPLAY target (see Figure 34-8) to display the report.
The LCN Node Version/Revision Logging display disappears from the
Universal Station screen and is replaced by a display which shows the
leftmost 80 characters of the first twenty-two records of the generated
report (see Figure 34-9 below).
Action Result
Press the PAGE FWD key. Review the next twenty-two records of the
generated report.
Touch or TAB and Review the rightmost eighty (80) characters

SELECT the ROLL RIGHT for each group of twenty-two records of the
target. generated report (see Figure 34-10).
Figure 34-9 Generated Report - Leftmost 80 Characters
16432

Initiate Report
Display,
continued
Action Result
Touch or TAB and SELECT Return to the leftmost eighty (80) characters
the ROLL LEFT target. of each group of twenty-two records of the
generated report (see Figure 34-9).
Press the PAGE BACK key. Reviews a previously viewed group of
twenty-two records of the generated report.
By pressing the PAGE it is possible to page back (up to a maximum
BACK key, of) four groups of twenty-two records of the
generated report.
Press the PRIOR DISP key to return to the first group of twenty-two
two times records of the generated report,
Figure 34-10 Generated Report - Rightmost 80 Characters
16433

Initiate Report
Display,
continued
To correlate displayed report information that exists on a single report
line but cannot entirely be viewed without using the ROLL RIGHT
target and ROLL LEFT target:
Action Result
Touch or TAB and SELECT the The background of the selected line
desired line of the displayed report. of the displayed report will change
color from black to blue.
Touching or TABbing and the background of the selected line
SELECTing the ROLL LEFT target will remain blue as the left and right
and ROLL RIGHT target, sides of the displayed report lines
are reviewed.

Enter Printer
Number
The printer number of the printer on which the generated report is to
be printed can be entered or modified by:
Step Action
1 Touch or TAB and SELECT the ENTER PRINTER number target.
2 Enter a 1 or 2 digit Printer Number.
Figure 34-11 LCN Node Version/Revision Logging Display

(Printer Number data entry port)
16434

Enter Printer
Number,
continued
to cyan), and the printer number that was entered will now appear
within the border of the target.
Figure 34-12 LCN Node Version/Revision Logging Display (Printer
Number in the “Enter Printer Number” target)
16435
Initiate Report Printing

After the report has been generated (and the report generation status of
“Report Generation Complete” is indicated in the INITIATE REPORT
GENERATION target), touch or TAB and SELECT the INITIATE
REPORT PRINTING target to print the generated report
(see Figure 34-12 above).
If the printer number is set to the number of an existing functioning Printer,
the generated report will be printed. See the section entitled Display/Print
File (LVRLOG.RD) for an example of the printed report.

Cancel Printing
While the generated report is being printed, touch or TAB and

SELECT the CANCEL PRINTING target (see Figure 34-12). The
printer on which the generated report is being printed will stop
printing the generated report.
WARNING
The CANCEL PRINTING target will cancel any printing on the
printer, not just the printing of the generated report.

34.7 Files Generated by the LCN Node Version/Revision
Logging Function (LVRLOG)
Two report text

files
When you touch or TAB and SELECT the INITIATE REPORT
GENERATION target, the LCN Node Version/Revision Logging
function generates two text files. The first text file is for display and
printing. The second text file is for export to other applications.
Display/print file
(LVRLOG.RD)
LCN Node Version/Revision Logging function generates a text file
(LVRLOG.RD) for display and printing. This file is stored under the
pathname NET>&CUS>LVRLOG.RD. Each time a Report Generation
is requested, the existing LVRLOG.RD file (if existent) is deleted and
a new LVRLOG.RD file is created. The date and time in the first
record of the file is the date and time of the start of report generation.
LVRLOG.RD file
The three lines in bold print (and blank line following) are not a part
of the LVRLOG.RD file. They have been added to indicate the
character position and width of each field of each record.
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111
00000000011111111112222222222333333333344444444445555555555666666666677777777778888888888999999999900000000001111111111222222222
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678
0 08/17/96 10:08:19
2 IAC_UHF Test_Sys 01 HG 06 K2LCN-2MW 01 00 M 00 B 01 43 05 HGO
2 IAC_UHF Test_Sys 01 HG 06 K2LCN-LCN 01 02 A 00 A 01 43 05 HGO
2 IAC_UHF Test_Sys 01 HG 06 HWY 02 00 K 00 L 01 43 05 HGO
2 IAC_UHF Test_Sys 01 HG 06 LOADMOD 40 01 HGEMOD 0047D46E
2 IAC_UHF Test_Sys 02 NIM 09 HPK2-3MW 01 04 K 00 B 01 43 03 NMO
2 IAC_UHF Test_Sys 02 NIM 09 LCNI 02 00 F 00 C 01 43 03 NMO
2 IAC_UHF Test_Sys 02 NIM 09 EPNI 05 02 H 00 B 01 43 03 NMO
2 IAC_UHF Test_Sys AM 10 K2LCN-8MW 01 04 M 00 B 01 43 09 AMO
2 IAC_UHF Test_Sys AM 10 K2LCN-LCN 01 02 A 00 A 01 43 09 AMO
2 IAC_UHF Test_Sys AM 10 LOADMOD 42 01 FILE 00D8C500
2 IAC_UHF Test_Sys AM 10 LOADMOD 42 01 CONV 00D9A65C
2 IAC_UHF Test_Sys AM 10 LOADMOD 41 01 CVB 00DB9BBC
2 IAC_UHF Test_Sys AM 10 LOADMOD 40 01 AMPRNT 00DBCAFE
2 IAC_UHF Test_Sys AM 10 LOADMOD 40 01 TMCHG 00DC58A2
2 IAC_UHF Test_Sys AM 10 LOADMOD 40 00 SIM_10 00DC5CA4
2 IAC_UHF Test_Sys HMON 15 K2LCN-2MW 01 00 L 00 B 01 43 06 HMO
2 IAC_UHF Test_Sys HMON 16 K2LCN-2MW 01 00 M 00 B 01 43 03 HMO

Logging Function (LVRLOG), Continued
LVRLOG.RD file,
continued
2 IAC_UHF Test_Sys CG 20 HPK2-3MW 01 04 L 00 B 01 43 06 CIO
2 IAC_UHF Test_Sys CG 20 LCNI 02 00 H 00 C 01 43 06 CIO
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 06 UMIMOD 005A8F80
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 05 EMUMOD 005B1704
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 07 EIPMOD 005B8F0E
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 09 FMTMOD 005C2F44
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 05 PELMOD 005D8580
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 07 PERMOD 005EBD24
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 04 TDLMOD 005FF49A
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 06 EMMMOD 0060C330
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 03 WPBMOD 0063BC9C
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 05 EM2MOD 00643ED6
2 IAC_UHF Test_Sys CG 20 LOADMOD 40 05 GTMMOD 00673842
2 IAC_UHF Test_Sys US 25 HPK2-3MW 01 04 K 00 B 01 43 20 UP
2 IAC_UHF Test_Sys US 25 LCNI 02 00 J 00 D 01 43 20 UP
2 IAC_UHF Test_Sys US 25 FDC 03 00 J 00 J 01 43 20 UP
2 IAC_UHF Test_Sys US 25 QMEM4096 04 07 B 43 20 UP
2 IAC_UHF Test_Sys US 25 LOADMOD 43 05 UPBASE 00C6490C
2 IAC_UHF Test_Sys US 25 LOADMOD 40 02 UPCAL 00C68534
2 IAC_UHF Test_Sys US 25 LOADMOD 40 02 CRDRDR 00C6B936
2 IAC_UHF Test_Sys US 25 LOADMOD 40 01 UPKLCK 00C6CF38
2 IAC_UHF Test_Sys US 25 LOADMOD 43 01 UPLVR 00C6DB22
2 IAC_UHF Test_Sys UxS 27 K2LCN-8MW 01 04 J 00 B 01 43 48 UxS
2 IAC_UHF Test_Sys UxS 27 K2LCN-LCN 01 02 A 00 A 01 43 48 UxS
2 IAC_UHF Test_Sys UxS 27 WSI2 02 01 B 43 48 UxS
2 IAC_UHF Test_Sys UxS 27 TPDG/SCSI 05 03 R 01 F 01 43 48 UxS
2 IAC_UHF Test_Sys UxS 27 LOADMOD 43 05 UPBASE 00D473AA
2 IAC_UHF Test_Sys UxS 27 LOADMOD 43 05 CSCHEM 00D4AFD2
2 IAC_UHF Test_Sys UxS 27 LOADMOD 43 19 MSCHEM 00D4CDC2
2 IAC_UHF Test_Sys UxS 27 LOADMOD 43 05 UPXTST 00D5C08A
2 IAC_UHF Test_Sys UxS 27 LOADMOD 40 04 UPUPD 00D5DCB8
2 IAC_UHF Test_Sys UxS 27 LOADMOD 40 03 UPLRGC 00D5EC5A
2 IAC_UHF Test_Sys UxS 27 LOADMOD 40 07 UPXYPT 00D647A2
2 IAC_UHF Test_Sys UxS 27 LOADMOD 43 01 XPDFIL 00D716E4
2 IAC_UHF Test_Sys UxS 27 LOADMOD 40 02 UPCVRA 00D780AE
2 IAC_UHF Test_Sys US 29 K2LCN-8MW 01 04 M 00 B 01 43 20 UP
2 IAC_UHF Test_Sys US 29 K2LCN-LCN 01 02 A 00 A 01 43 20 UP
2 IAC_UHF Test_Sys US 29 EPDG/SCSI 03 02 J 01 K 01 43 20 UP
2 IAC_UHF Test_Sys US 29 LOADMOD 43 01 UPLVR 00D54F0C
2 IAC_UHF Test_Sys US 29 LOADMOD 43 05 UPBASE 00D6200E
2 IAC_UHF Test_Sys US 43 K2LCN-6MW 01 03 G 00 A 01 43 20 UP
2 IAC_UHF Test_Sys US 43 LOADMOD 43 05 UPBASE 00A4CA3C
2 IAC_UHF Test_Sys US 43 LOADMOD 40 07 UPXYPT 00A50664
2 IAC_UHF Test_Sys US 43 LOADMOD 40 01 UPKLCK 00A5D5A6
2 IAC_UHF Test_Sys US 43 LOADMOD 40 02 UPCVRA 00A5E190
2 IAC_UHF Test_Sys US 43 LOADMOD 43 00 UP_ATB 00A5FFB6
2 IAC_UHF Test_Sys US 43 LOADMOD 43 01 UPLVR 00A63F4E
2 IAC_UHF Test_Sys US 48 K2LCN-8MW 01 04 M 00 B 01 43 20 UP
2 IAC_UHF Test_Sys US 48 EPDG/SCSI 03 02 J 01 H 01 43 20 UP
2 IAC_UHF Test_Sys US 48 LOADMOD 43 05 UPBASE 00D4C26C
2 IAC_UHF Test_Sys US 48 LOADMOD 40 01 UPKLCK 00D4FE94
2 IAC_UHF Test_Sys US 48 LOADMOD 40 07 UPXYPT 00D50A7E
2 IAC_UHF Test_Sys US 48 LOADMOD 40 02 UPCVRA 00D5D9C0
2 IAC_UHF Test_Sys US 48 LOADMOD 43 01 UPLVR 00D5F7E6

4 IAC_UHF Test_Sys 01 HG 02

Example of
LVRLOG.RD file,
continued
4 IAC_UHF Test_Sys 01 HLPIU 05 ANALOGOT 03 REGULAR
4 IAC_UHF Test_Sys 01 HLPIU 05 DIGOUT 05 REGULAR

4 IAC_UHF Test_Sys 01 MC 10 ANALOGOT 01
4 IAC_UHF Test_Sys 01 MC 10 ANALOGOT 02
4 IAC_UHF Test_Sys 01 MC 10 DIGIN 03
4 IAC_UHF Test_Sys 01 MC 10 DIGOUT 05
4 IAC_UHF Test_Sys 01 MC 10 DIGOUT 06
4 IAC_UHF Test_Sys 01 MC 10 ANALOGIN 08
4 IAC_UHF Test_Sys 01 MC 10 FAIL 09
6 IAC_UHF Test_Sys 02 NIM 01 MODEM 27
6 IAC_UHF Test_Sys 02 NIM 01 PROTOCOL 00 01
6 IAC_UHF Test_Sys 02 NIM 01 UCNLLN 2A 00
6 IAC_UHF Test_Sys 02 NIM 01 DRIVER 2A 00
6 IAC_UHF Test_Sys 02 NIM 01 TBC 00
6 IAC_UHF Test_Sys 02 PM 09 PMMMOD 01 01 FILE_1 05 REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 PMMCOM 01 02 FILE_1 0B 31 42 03 PMMCOM REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 PMMCOMD 01 02 FILE_1 02 REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 PMMIOL 01 03 FILE_1 0C 32 REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 PMMCTL 01 04 FILE_1 0D 32 42 01 PMMCTL REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 PMMCTLD 01 04 FILE_1 02 REDUN_2F
6 IAC_UHF Test_Sys 02 PM 09 NONE 01 a 01 06
6 IAC_UHF Test_Sys 02 PM 09 HLAI 02 a 01 07 01 3.3
6 IAC_UHF Test_Sys 02 PM 09 HLAI 03 a 01 08 01 3.3
6 IAC_UHF Test_Sys 02 PM 09 DO 04 a 01 09 04 3.6
6 IAC_UHF Test_Sys 02 PM 09 NONE 05 a 01 10
6 IAC_UHF Test_Sys 02 PM 09 AO 06 a 01 11 25 3.9
6 IAC_UHF Test_Sys 02 PM 09 DI 07 a 01 12 23 3.3
6 IAC_UHF Test_Sys 02 PM 09 AO 08 a 01 13 02 3.4
6 IAC_UHF Test_Sys 02 APM 13 APMMMOD 01 01 FILE_1 2A REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCOM 01 02 FILE_1 24 42 42 04 APMCOM REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCOMD 01 02 FILE_1 22 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMIOL 01 03 FILE_1 13 41 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCTL 01 04 FILE_1 26 43 42 01 APMCTL REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMCTLD 01 04 FILE_1 00 REDUN_2F
6 IAC_UHF Test_Sys 02 APM 13 APMMTBC 08
6 IAC_UHF Test_Sys 02 APM 13 HLAI 01 a 01 06 24 3.3
6 IAC_UHF Test_Sys 02 APM 13 AO 06 a 01 11 02 3.4
6 IAC_UHF Test_Sys 02 APM 13 DI 07 a 01 12 01 3.3
6 IAC_UHF Test_Sys 02 APM 13 NONE 08 a 01 13
6 IAC_UHF Test_Sys 02 APM 13 PI 09 a 01 14 20 3.3
7 REPORT COMPLETE

Export file
(LVRLOG.RE)
The LCN Node Version/Revision Logging function generates a text
file (LVRLOG.RE) for export to other applications, such as Microsoft
Excel. This file is stored under the pathname
NET>&CUS>LVRLOG.RE. Each time a Report Generation is
requested, the existing LVRLOG.RE file (if existent) is deleted and a
new LVRLOG.RE file is created.
The date and time in the first record of the LVRLOG.RE file is the
date and time of the start of report generation.
LVRLOG.RE file with

target deselected
The example of the LVRLOG.RE file below was generated with the
“Exclude headings from export file” target deselected.
of the LVRLOG.RE file. They have been added to indicate the
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001111111111111111111111111111
0000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999990000000000111111111122222223
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234560
0,08/17/96,10:08:19, , , , , , , , , , , , , , , , , ,
1,SITEID ,LCNID ,PNN ,NODET ,NODEN ,BOARDT , , ,SLOTN , ,HWV ,HWR ,FWV ,FWR ,FWT ,SWV ,SWR ,SWNAME ,SWLOC ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,K2LCN-2MW, , ,01 , ,00 ,M ,00 ,B ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,HWY , , ,02 , ,00 ,K ,00 ,L ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,LOADMOD , , , , , , , , , ,40 ,01 ,HGEMOD ,0047D46E,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,HPK2-3MW , , ,01 , ,04 ,K ,00 ,B ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,LCNI , , ,02 , ,00 ,F ,00 ,C ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,EPNI , , ,05 , ,02 ,H ,00 ,B ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,K2LCN-8MW, , ,01 , ,04 ,M ,00 ,B ,01 ,43 ,09 ,AMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,09 ,AMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,42 ,01 ,FILE ,00D8C500,
2,IAC_UHF ,Test_Sys, ,HMON ,16 ,SPC , , ,02 , ,01 ,F ,00 ,G ,01 ,43 ,03 ,FILE ,00D8C500,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,42 ,01 ,CONV ,00D9A65C,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,41 ,01 ,CVB ,00DB9BBC,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,01 ,AMPRNT ,00DBCAFE,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,01 ,TMCHG ,00DC58A2,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,00 ,SIM_10 ,00DC5CA4,
2,IAC_UHF ,Test_Sys, ,HMON ,15 ,K2LCN-2MW, , ,01 , ,00 ,L ,00 ,B ,01 ,43 ,06 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,HMON ,15 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,06 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,HMON ,15 ,SPC , , ,02 , ,01 ,F ,00 ,G ,01 ,43 ,06 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,HMON ,16 ,K2LCN-2MW, , ,01 , ,00 ,M ,00 ,B ,01 ,43 ,03 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,HPK2-3MW , , ,01 , ,04 ,L ,00 ,B ,01 ,43 ,06 ,CIO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LCNI , , ,02 , ,00 ,H ,00 ,C ,01 ,43 ,06 ,CIO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,06 ,UMIMOD ,005A8F80,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,EMUMOD ,005B1704,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,07 ,EIPMOD ,005B8F0E,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,09 ,FMTMOD ,005C2F44,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,PELMOD ,005D8580,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,07 ,PERMOD ,005EBD24,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,04 ,TDLMOD ,005FF49A,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,06 ,EMMMOD ,0060C330,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,03 ,WPBMOD ,0063BC9C,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,EM2MOD ,00643ED6,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,GTMMOD ,00673842,
2,IAC_UHF ,Test_Sys, ,US ,25 ,HPK2-3MW , , ,01 , ,04 ,K ,00 ,B ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LCNI , , ,02 , ,00 ,J ,00 ,D ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,FDC , , ,03 , ,00 ,J ,00 ,J ,01 ,43 ,20 ,UP , ,

LVRLOG.RE file
generated with
target
deselected,
continued
2,IAC_UHF ,Test_Sys, ,US ,25 ,QMEM4096 , , ,04 , ,07 ,B , , , ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,EPDG/SCSI, , ,05 , ,02 ,H ,01 ,H ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00C6490C,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCAL ,00C68534,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,02 ,CRDRDR ,00C6B936,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00C6CF38,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00C6DB22,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,K2LCN-8MW, , ,01 , ,04 ,J ,00 ,B ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,WSI2 , , ,02 , ,01 ,B , , , ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,TPDG/SCSI, , ,05 , ,03 ,R ,01 ,F ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D473AA,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,CSCHEM ,00D4AFD2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,19 ,MSCHEM ,00D4CDC2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPXTST ,00D5C08A,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,04 ,UPUPD ,00D5DCB8,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,03 ,UPLRGC ,00D5EC5A,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00D647A2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,01 ,XPDFIL ,00D716E4,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00D780AE,
2,IAC_UHF ,Test_Sys, ,US ,29 ,K2LCN-8MW, , ,01 , ,04 ,M ,00 ,B ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,29 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,29 ,EPDG/SCSI, , ,03 , ,02 ,J ,01 ,K ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,29 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00D54F0C,
2,IAC_UHF ,Test_Sys, ,US ,29 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D6200E,
2,IAC_UHF ,Test_Sys, ,US ,43 ,K2LCN-6MW, , ,01 , ,03 ,G ,00 ,A ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00A4CA3C,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00A50664,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00A5D5A6,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00A5E190,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,00 ,UP_ATB ,00A5FFB6,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00A63F4E,
2,IAC_UHF ,Test_Sys, ,US ,48 ,EPDG/SCSI, , ,03 , ,02 ,J ,01 ,H ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D4C26C,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00D4FE94,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00D50A7E,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00D5D9C0,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00D5F7E6,
3,SITEID ,LCNID ,HWY ,BOXT ,BOXN ,CARDT , , ,CARDN , , , , , , , , , ,BOXSIZE ,
4,IAC_UHF ,Test_Sys,01 ,HG ,02 , , , , , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,ANALOGIN , , ,01 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,ANALOGOT , , ,03 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,DIGIN , , ,04 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,DIGOUT , , ,05 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,NONE , , ,09 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,ANALOGOT , , ,01 , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,DIGIN , , ,03 , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,DIGOUT , , ,05 , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,ANALOGIN , , ,08 , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,FAIL , , ,09 , , , , , , , , , , ,
5,SITEID ,LCNID ,UCN ,NODET ,NODEN ,CARDT ,MODN, FILEN ,CARDN ,FILEP , ,HWR , ,FWR , ,SWV ,SWR ,SWNAME ,REDUNCY ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,MODEM , , , , , ,27 , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,PROTOCOL , , , , , , , , , ,00 ,01 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,UCNLLN , , , , , , , , , ,2A ,00 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,DRIVER , , , , , , , , , ,2A ,00 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,TBC , , , , , ,00 , , , , , , , ,

LVRLOG.RE file
generated with
target
deselected,
continued
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMMOD , , 01 ,01 ,FILE_1 , ,05 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCOM , , 01 ,02 ,FILE_1 , ,0B , ,31 , ,42 ,03 ,PMMCOM ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCOMD , , 01 ,02 ,FILE_1 , ,02 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMIOL , , 01 ,03 ,FILE_1 , ,0C , ,32 , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCTL , , 01 ,04 ,FILE_1 , ,0D , ,32 , ,42 ,01 ,PMMCTL ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCTLD , , 01 ,04 ,FILE_1 , ,02 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,NONE ,01 a, 01 ,06 , , , , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,HLAI ,02 a, 01 ,07 , , ,01 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,DO ,04 a, 01 ,09 , , ,04 , ,3.6 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,AO ,06 a, 01 ,11 , , ,25 , ,3.9 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,DI ,07 a, 01 ,12 , , ,23 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMMOD , , 01 ,01 ,FILE_1 , ,2A , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCOM , , 01 ,02 ,FILE_1 , ,24 , ,42 , ,42 ,04 ,APMCOM ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCOMD , , 01 ,02 ,FILE_1 , ,22 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMIOL , , 01 ,03 ,FILE_1 , ,13 , ,41 , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCTL , , 01 ,04 ,FILE_1 , ,26 , ,43 , ,42 ,01 ,APMCTL ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCTLD , , 01 ,04 ,FILE_1 , ,00 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMTBC , , , , , ,08 , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,HLAI ,01 a, 01 ,06 , , ,24 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,AO ,06 a, 01 ,11 , , ,02 , ,3.4 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,DI ,07 a, 01 ,12 , , ,01 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,NONE ,08 a, 01 ,13 , , , , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,PI ,09 a, 01 ,14 , , ,20 , ,3.3 , , , , , ,
7,REPORT ,COMPLETE, , , , , , , , , , , , , , , , , ,

LVRLOG.RE file
generated with
target
selected, continued
The example of the LVRLOG.RE file below was generated with the
“Exclude headings from export file” target selected.
of the LVRLOG.RE file. They have been added to indicate the
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000111111111111111111111111111111
000000000111111111122222222223333333333444444444455555555556666666666777777777788888888889999999999000000000011111111112222222222
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,K2LCN-2MW, , ,01 , ,00 ,M ,00 ,B ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,HWY , , ,02 , ,00 ,K ,00 ,L ,01 ,43 ,05 ,HGO , ,
2,IAC_UHF ,Test_Sys,01 ,HG ,06 ,LOADMOD , , , , , , , , , ,40 ,01 ,HGEMOD ,0047D46E,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,HPK2-3MW , , ,01 , ,04 ,K ,00 ,B ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,LCNI , , ,02 , ,00 ,F ,00 ,C ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys,02 ,NIM ,09 ,EPNI , , ,05 , ,02 ,H ,00 ,B ,01 ,43 ,03 ,NMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,K2LCN-8MW, , ,01 , ,04 ,M ,00 ,B ,01 ,43 ,09 ,AMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,09 ,AMO , ,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,42 ,01 ,FILE ,00D8C500,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,42 ,01 ,CONV ,00D9A65C,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,41 ,01 ,CVB ,00DB9BBC,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,01 ,AMPRNT ,00DBCAFE,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,01 ,TMCHG ,00DC58A2,
2,IAC_UHF ,Test_Sys, ,AM ,10 ,LOADMOD , , , , , , , , , ,40 ,00 ,SIM_10 ,00DC5CA4,
2,IAC_UHF ,Test_Sys, ,HMON ,15 ,K2LCN-2MW, , ,01 , ,00 ,L ,00 ,B ,01 ,43 ,06 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,HMON ,16 ,K2LCN-2MW, , ,01 , ,00 ,M ,00 ,B ,01 ,43 ,03 ,HMO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,HPK2-3MW , , ,01 , ,04 ,L ,00 ,B ,01 ,43 ,06 ,CIO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LCNI , , ,02 , ,00 ,H ,00 ,C ,01 ,43 ,06 ,CIO , ,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,06 ,UMIMOD ,005A8F80,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,EMUMOD ,005B1704,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,07 ,EIPMOD ,005B8F0E,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,09 ,FMTMOD ,005C2F44,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,PELMOD ,005D8580,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,07 ,PERMOD ,005EBD24,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,04 ,TDLMOD ,005FF49A,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,06 ,EMMMOD ,0060C330,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,03 ,WPBMOD ,0063BC9C,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,EM2MOD ,00643ED6,
2,IAC_UHF ,Test_Sys, ,CG ,20 ,LOADMOD , , , , , , , , , ,40 ,05 ,GTMMOD ,00673842,
2,IAC_UHF ,Test_Sys, ,US ,25 ,HPK2-3MW , , ,01 , ,04 ,K ,00 ,B ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LCNI , , ,02 , ,00 ,J ,00 ,D ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,FDC , , ,03 , ,00 ,J ,00 ,J ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,QMEM4096 , , ,04 , ,07 ,B , , , ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00C6490C,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCAL ,00C68534,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,02 ,CRDRDR ,00C6B936,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00C6CF38,
2,IAC_UHF ,Test_Sys, ,US ,25 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00C6DB22,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,K2LCN-8MW, , ,01 , ,04 ,J ,00 ,B ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,K2LCN-LCN, , ,01 , ,02 ,A ,00 ,A ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,WSI2 , , ,02 , ,01 ,B , , , ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,TPDG/SCSI, , ,05 , ,03 ,R ,01 ,F ,01 ,43 ,48 ,UxS , ,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D473AA,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,CSCHEM ,00D4AFD2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,19 ,MSCHEM ,00D4CDC2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPXTST ,00D5C08A,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,04 ,UPUPD ,00D5DCB8,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,03 ,UPLRGC ,00D5EC5A,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00D647A2,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,43 ,01 ,XPDFIL ,00D716E4,
2,IAC_UHF ,Test_Sys, ,UxS ,27 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00D780AE,
2,IAC_UHF ,Test_Sys, ,US ,29 ,EPDG/SCSI, , ,03 , ,02 ,J ,01 ,K ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,29 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00D54F0C,
2,IAC_UHF ,Test_Sys, ,US ,29 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D6200E,
2,IAC_UHF ,Test_Sys, ,US ,43 ,K2LCN-6MW, , ,01 , ,03 ,G ,00 ,A ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00A4CA3C,

LVRLOG.RE file
generated with
target
selected,
continued
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00A50664,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00A5D5A6,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00A5E190,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,00 ,UP_ATB ,00A5FFB6,
2,IAC_UHF ,Test_Sys, ,US ,43 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00A63F4E,
2,IAC_UHF ,Test_Sys, ,US ,48 ,EPDG/SCSI, , ,03 , ,02 ,J ,01 ,H ,01 ,43 ,20 ,UP , ,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,43 ,05 ,UPBASE ,00D4C26C,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,01 ,UPKLCK ,00D4FE94,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,07 ,UPXYPT ,00D50A7E,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,40 ,02 ,UPCVRA ,00D5D9C0,
2,IAC_UHF ,Test_Sys, ,US ,48 ,LOADMOD , , , , , , , , , ,43 ,01 ,UPLVR ,00D5F7E6,
4,IAC_UHF ,Test_Sys,01 ,HG ,02 , , , , , , , , , , , , , , ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,ANALOGOT , , ,03 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,HLPIU ,05 ,DIGOUT , , ,05 , , , , , , , , , ,REGULAR ,
4,IAC_UHF ,Test_Sys,01 ,MC ,10 ,ANALOGIN , , ,08 , , , , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,MODEM , , , , , ,27 , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,PROTOCOL , , , , , , , , , ,00 ,01 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,UCNLLN , , , , , , , , , ,2A ,00 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,DRIVER , , , , , , , , , ,2A ,00 , , ,
6,IAC_UHF ,Test_Sys,02 ,NIM ,01 ,TBC , , , , , ,00 , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMMOD , , 01 ,01 ,FILE_1 , ,05 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCOM , , 01 ,02 ,FILE_1 , ,0B , ,31 , ,42 ,03 ,PMMCOM ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCOMD , , 01 ,02 ,FILE_1 , ,02 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMIOL , , 01 ,03 ,FILE_1 , ,0C , ,32 , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCTL , , 01 ,04 ,FILE_1 , ,0D , ,32 , ,42 ,01 ,PMMCTL ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,PMMCTLD , , 01 ,04 ,FILE_1 , ,02 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,DO ,04 a, 01 ,09 , , ,04 , ,3.6 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,PM ,09 ,DI ,07 a, 01 ,12 , , ,23 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMMOD , , 01 ,01 ,FILE_1 , ,2A , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCOM , , 01 ,02 ,FILE_1 , ,24 , ,42 , ,42 ,04 ,APMCOM ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCOMD , , 01 ,02 ,FILE_1 , ,22 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMIOL , , 01 ,03 ,FILE_1 , ,13 , ,41 , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCTL , , 01 ,04 ,FILE_1 , ,26 , ,43 , ,42 ,01 ,APMCTL ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMCTLD , , 01 ,04 ,FILE_1 , ,00 , , , , , , ,REDUN_2F,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,APMMTBC , , , , , ,08 , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,HLAI ,01 a, 01 ,06 , , ,24 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,AO ,06 a, 01 ,11 , , ,02 , ,3.4 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,DI ,07 a, 01 ,12 , , ,01 , ,3.3 , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,NONE ,08 a, 01 ,13 , , , , , , , , , , ,
6,IAC_UHF ,Test_Sys,02 ,APM ,13 ,PI ,09 a, 01 ,14 , , ,20 , ,3.3 , , , , , ,

34.8 LVRLOG Error Conditions
Non-recoverable
errors
If a non-recoverable error occurs during the generation of the report, a
failure status appears (in red) in the lower right corner of the LCN
NODE VERSION/REVISION LOGGING display, and the report
generation status is set to “Report Generation Failure.” The report
generation status is displayed in the INITIATE REPORT
GENERATION target.
Figure 34-13 LCN Node Version/Revision Logging Display (with a

failure status)
16436

34.8 LVRLOG Error Conditions, Continued
Non-recoverable
errors,
continued
The following non-recoverable errors are detected and displayed:
Failure Status Meaning

File Access Failure The LCN Node Version/Revision Logging function is
unable to complete file accesses calls to create the text
files (LVRLOG.RD and LVRLOG.RE), because of a non-
recoverable file creation error.
WARNING—Because the function generates only two files (LVRLOG.RD and

LVRLOG.RE), a File Access Failure will occur if:
an attempt is made to generate a report at one Universal Station while

displaying or printing a previously generated report at another Universal
Station.
File Access Error The LCN Node Version/Revision Logging function is

unable to complete file access calls to write a record to
one of the text files (LVRLOG.RD or LVRLOG.RE),
because of a non-recoverable write file record error.
File Access Error – The LCN Node Version/Revision Logging function is

FF unable to complete file access calls to write a free
format record to one of the text files (LVRLOG.RD or
LVRLOG.RE), because of a non-recoverable write file
record error.

34.8 LVRLOG Error Conditions, Continued
Recoverable
Errors
If you call up the LCN NODE VERSION/REVISION LOGGING
display at a Universal Station which has not been configured and
loaded with the LCN Node Version/Revision Logging software, the
display will appear as follows:
Table 34-14 LCN Node Version/Revision Logging Display
16437
The existing targets can be utilized to display, print, or cancel printing

of a previously generated report. However, if you wish to generate a
report, the LCN NODE VERSION/REVISION LOGGING display
must be called up on a Universal Station that has the LCN Node
Version/Revision Logging software configured and loaded.

34.9 Importing LVRLOG Report File into Spreadsheet
Converting LCN
Format File to PC
Format File
The text files (with pathnames of NET>&CUS>LVRLOG.RD and
NET>&CUS>LVRLOG.RE) generated by the LCN Node
Version/Revision Logging function are LCN format files. In order to
import these text files into personal computer applications (such as
Microsoft Excel), these LCN format files must first be converted to PC
text file format.
Several software tools with which the user can perform this required
conversion are available from Honeywell. Probably the simplest and
easiest to use transform mechanism is the “File Transfer for DOS”
package. With the “File Transfer for DOS” package the user can
convert an LCN format text file on a removable disk to a PC format
text file on a floppy disk.
Importing PC
Format File into
Microsoft Excel
The LVRLOG.RE file is formatted in such a way that it is easily
imported by Microsoft Excel (Rev. 5.0). After the LVRLOG.RE file
has been converted to PC text file format, with Microsoft Excel,
OPEN the converted LVRLOG.RE text file. Next, follow the
Microsoft Excel “Text Import Wizard” choosing the following
options:
File Type Delimited

Start Import at Row 1
File Origin Windows (ANSI)
Delimiters Comma
Text Qualifier None
Column Data Format Text for all Columns
After the data from the text file has been imported, adjust the “cell”
widths as required.
ATTENTION .
The converted LVRLOG.RE text file can also be imported by the

Microsoft Access relational database software (Rev. 2.0).

Section 35 – R530 Trend and Operating Display Functions
35.0 Overview
Description of
Configurable
Access Levels on
Parameters
The Configurable Access Level on Parameters R530 function
provides the ability to configure in the NCF, an access level needed to
make modifications to alarm limits, control limits, range limits, and
tuning parameters on the Point Detail Display.
Description of
One Key Call Up
of a Point Trend
The One Key Call Up of Point Trend R530 function expands the use
of the TREND key on the operator’s keyboard by invoking a trend of a
point’s parameters by using one keystroke. Pressing the TREND key
after selecting a point invokes a default trend display of a point’s SP,
PV, and OP. This function also provides the ability to replace the
default trend display with any custom schematic desired.
Description of
Save/Restore
Trend Data
An additional R530 function, Save/Restore Trend Data, provides a
method to save a specific set of trend settings from a custom schematic
trend and a method to read saved trend settings through two actors
TR_SAVE and TR_RSTR (see Actors Manual).
Description of
Detail Display
Navigation
The R530 Detail Display Navigation function provides the ability to
track the flow of point connections from display to display without
having to enter point names.
Description of
SP/OP Tolerance
Check
The R530 SP/OP Tolerance Check function is described as the
maximum delta value by which the setpoint or output of a process
point can be manually changed in either a plus or minus direction
without causing a violation warning.

35.1 Configurable Access Levels on Parameters
Introduction
The Configurable Access Level on Parameters R530 function provides
the ability to configure in the NCF, an access level needed to make
modifications to four different categories of parameters:
• Alarm Limits
• Control Limits
• Range Limits
• Tuning Parameters
Each of these four category of parameters can be configured to one of
four access levels: Operator, Supervisor, Engineer, or Defaulted.
Defaulted means to use the access level as described in the Parameter
Reference Dictionary “Access Lock” (see Engineer’s Reference
Manual (this manual) “Parameter Information,” and Network Form
Instructions for more information).
The function allows you to specify the access level needed to make
modifications to parameters in the Point Detail Display and from a
Custom Schematic.
Description
On R530 systems, the default value for each category is “DEFAULT.”
“DEFAULT” says that the parameter under each category has the
value specified in the Parameter Reference Dictionary. To use an
access level other than the default, the NCF System Wide Values,
Console Data, Page 5 must be modified. After making modifications,
install them and reload the US nodes indicated at install time.

35.1 Configurable Access Levels on Parameters, Continued
Parameter change
request
Parameter change requests are made from the Point Detail Display or a
Custom Schematic. Range Limits and Alarm Limits are located on the
FIRST PAGE of the Point Detail Display. The Control Limits and
Tuning Parameters are located on the CTL ALGO PAGE of the Point
Detail Display.
Access Level
Configurable
Options
In R530, the NCF provides, for each of the four categories, an option
of using either the access level as defined in the Parameter Reference
Dictionary “Access Lock” or an NCF-configured access level.
Access Level Meaning

ENGR Every parameter, that is not “Read Only” can be
modified only when the Key lock is ENGR.
SUPER Every parameter, that is not “Read Only” can be

modified only when the Key lock is either SUPER or
ENGR.
OPER Every parameter that is not “Read Only” can be

modified when the Key lock is OPER, SUPER, or
ENGR.
DEFAULT The key level necessary for modification is the access

level defined in the Parameter Reference Dictionary
“Access Lock.”
NOTE: If the Group/Detail Display has been configured to something

other than OPER, and “CONFIGURABLE ACCESS LEVEL ON
PARAMETERS” has also been configured, the more restrictive level
configured will be honored.

Parameter Access
Level Revision
Differences
R530 access level of parameter differences are listed below:
Prior to R530... R530 or later...

Access level for Alarm Limits, For each parameter fitting into the
Range Limits, and Tuning categories Alarm Limits, Control
Parameters CANNOT be Limits, Range Limits, and Tuning
configured. The access level is the Parameter, the NCF default value
level specified in the Parameter will be “DEFAULT.”
Reference Dictionary “Access Lock.”
Result: Nothing special is required if
the System Wide Values Console
Data Page Five has NOT been
modified.
There is an NCF option to control There are FOUR categories of
parameter access on the Detail and parameters that can be configured
Group Displays that can be to either DEFAULT, OPER, SUPER,
configured to OPER, SUPER, or or ENGR.
ENGR.
There is an NCF option to control
parameter access on the Detail and
Group Displays.
The Data Owner determines Parameters that fall into the four
whether a parameter can be categories will use the information
changed. from the NCF to determine if
changes to that parameter can be
made.

System Wide
Values, Console
Data
Modify parameter access levels in the NCF on the Console Data
screen. From the Engineering Main Menu shown below, select System
Wide Values and then Console Data.
Figure 35-1 System Wide Value, Console Data Selection
16628

Console Data
PAGE 5
The System Wide Values Console Data PAGE 5, shown below,
contains the new R530 Configurable Access Level on Parameters
function information. The Group/Detail Display information was
moved from Page 8 of the Console Data page because it has data
relating to this function. Page 4 of the Console Data page contains the
LCN Cable Swap Inhibit information moved from the previous Page 5
of the Console Data page to allow space for the new R530 access level
function.
Figure 35-2 System Wide Values, NCF Console Data PAGE 5 with
Configurable Access Level on Parameters Information
16625

Help Messages
A help message is added behind the “DEFAULT” target in the Configurable
Access Level on Parameters in the Console Data page that says:
SELECT DEFAULT FOR THE ACCESS LEVEL AS DEFINED

IN THE PARAMETER REFERENCE DICTIONARY
The message behind “OPER,” “SUPER,” and “ENGR” is the same

message that is behind similar targets that say:
SELECT THE LOWEST ACCESS LEVEL WHICH IS TO BE

NECESSARY TO ACTIVATE EACH OF THE INDICATED
OPERATIONS
References
Refer to the publications listed below for more information on R530
Configurable Access Levels on Parameters.
• System Control Functions

• Network Form Instructions
• Network Forms

35.2 One Key Call Up of Point Trend
TREND invocation
- Default trend
display
With the One Key Call Up of Point Trend R530 function, the default
trend display of a point can be invoked by executing the TREND key
from the operator’s keyboard when
• the point is in Detail display.
• the point is selected in a standard display (excluding the Group
display). See “standard display” definition below.
• the point name is entered into the point id prompt when neither of
the above applies.
The default trend display trends the parameters PV, SP, and OP of the
point specified when the TREND key is executed. This display can
also be invoked by selecting the TREND target (new in R530) from
the FIRST page menu of the Detail display. The PV, SP, and OP of
the point currently in Detail will be trended in the default trend
display.
NOTE: Execution of the TREND key or the TREND target is

interchangeable in the Detail display. (See Process Operations
Manual for more trend display information.)
Standard Display
The definition for standard display is any display (excluding custom
schematics) from which a point name can be selected, which includes:
• the Alarm Summary display
• the Organizational Summary displays
• the Slot Summary display
• the Trend Pen display
• the standard CHANGE ZONE subpicture (the point in the
change zone is considered “selected”
• the various pages of the Detail display
TREND invocation
- Custom
schematic display
Invocation of the custom schematic display is the same as the default
trend display, except that the default trend display will require to be
“replaced” with the custom schematic display desired.

35.2 One Key Call Up of Point Trend, Continued
“Replace” the
Default trend
display
To “replace” the default trend display, copy the custom schematic
object file to the &DSY directory with the name, $PT_CTRD.DO.
After copying the display, initiate an area change for the Universal
Station. The area change will load the appropriate display in the
&DSY directory into the Universal Station memory. After this
change, the custom schematic will now always appear when trend is
requested until another “replace” is initiated.
If the custom schematic display requires access to the point name from
which the TREND key was executed, the custom schematic display will
need to obtain the point name from the new global DDB, $TR_ENTY.
Collectors
Five new collectors have been added with the implementation of this
R530 “One Key Call up of Point Trend” function. See the Picture
Editor Reference Manual for more information on these collectors.
Missing Default
and Custom
display error
messages/Error
Handling
If the default ($PT_TRND) and/or custom ($PT_CTRD) display in the
&DSY directory is not found during an area change or node startup,
the US status will transition to a SEVERE state and messages will be
logged through the status detail.
NOTE: An area change can clean up the SEVERE state after restoring
either the schematic in &DSY or the $PT_TRND and $PT_CTRD.
Toolkit (TLK2)
The TLK2 directory contains the source file for the default trend
display. This source file can be customized using the Picture Editor to
“replace” the default trend display.
References
function “One Key Call Up of a Point Trend.”
• Operator’s Digest
• Picture Editor Reference Manual
• Process Operations Manual

35.3 Save/Restore Trend Data
Trend Setting
Elements Saved
The trend setting elements saved with the R530 “Save Trend Data”
function include
• the trend’s current Time Base
• the trend’s Y-Scale range
• up to four point ids (Point.Parameter)
• each point id’s associated trend display range
• each point id’s associated Data Source
• each Point Parameter’s trend trace color
Currently, trend settings that are not saved or displayed when using
the new TR_SAVE or TR_RSTR actors are the Scroll Counter and
aspects of Hair Line or Center Line trend graph mode. Those aspects
include the Center Line or the Hair Line Cursor and the ability to
move the Hair Line Cursor.
Save Trend Data

into Save/Restore
Trend
DataCustom
Schematics
To use the R530 “Save Trend Data” functionality, you are required to
incorporate the actors, TR_SAVE and TR_RSTR, into existing or new
schematics. Build two targets by using the Picture Editor and
configure the actors as the action to perform when the target is
selected. When the target associated with the save operation is
selected, the TR_SAVE actor will be initiated and the trend settings
for a specified trend graph will be stored into a specified .SS file on
the HM or removable media.
NOTE: Only one trend graph can be saved to one .SS file. To save
multiple graphs, multiple files must be used.
When the target associated with a restore operation is selected, the

TR_RSTR actor will be initiated and the saved trend settings from a
specified file will be incorporated into the specified trend graph.
The TR_SAVE or TR_RSTR actors treat the set of trend settings as a

single entity. This means that regardless of the trend functionality
incorporated into the current schematic, the actors will save or display
values for all trend settings identified above.

35.3 Save/Restore Trend Data, Continued
Save Trend Data

into ASCII files
In order to allow greater flexibility and accessibility to the new
functionality, the files containing the saved trend settings are ASCII
files and can be edited by using the Text Editor. The trend settings
contained in the file will be position-dependent and in ASCII format
(see SAMPLE below). This provides you with greater flexibility for
incorporating this functionality within existing schematics.
Figure 35-3 Saved Trend Data File
16683
The figure above identifies a SAMPLE Saved Trend Data File named
AMTRND1.SS. This file contains, in text format, all trend settings
saved for a trend graph. The file also contains information generated
by the “Save/Restore Trend Data” functionality, as well as optional
comments added into the file. The file contains three line types, a
trend graph settings line, trended parameter settings lines, and
comment lines. The trend graph settings and trended parameter
settings are delimited by the space character.

Save/RestoreTrend
Data into ASCII
files, continued
Each line in the Saved Trend Data File in Figure 36-1 is explained
below:
1, 2 The first two lines of data contain information related to a

trend graph (time base and high/low Y-scale displayed
range).
3,4,5,6 These lines contain information relative to a specific
trended parameter (the variable id, the high/low display
range, the data source and the trend graph’s trace color).
7, 8 These are comment lines signified by the “#” character.
Comment lines cannot be intermixed between trend
settings on the same line.
Any of the trend settings can be modified by replacing the current

setting with the desired setting. The desired setting must be valid and
reasonable. In addition, because the file is formatted, the replaced
setting must be placed in the correct position within the line.
NOTE: If an error occurs within the Saved Trend Data File, action
stops and does not continue to the following line.

Trend Graphs and

Trend Ids
On custom schematics, trend graph placement and the associated
Trend_Id numbers are completely user-specified. When a schematic is
created containing multiple trend graphs, each trend graph must be
given a specific Trend_Id number between 1 and 12. All trend actors
use the Trend_Ids to identify the target trend graph for its operation.
The two actors also use the Trend_Id to identify a specific trend graph.
Care should be observed when creating schematics with multiple trend
graphs such that, if needed, each trend graph’s Trend_Id can be
determined by the end user.
Different implementation methods using differing levels of trending

functionality can be used. Among them are
1. Create two targets, “SAVE” and “RESTORE,” to perform the tasks
of saving and restoring trend settings for all the trend graphs within
a new or existing custom schematic.
2. Create two sets of targets to perform the tasks of saving and
restoring trend settings for each trend graph within a new or
existing custom schematic. The actors can be implemented using
hard-coded parameter information allowing you to preset the
Trend_Id and target filename, thus requiring no additional
interaction during schematic execution.
3. Use the Define Initial and Define Final Picture Editor commands
(see Picture Editor). These commands allow you to define actions
that occur when a schematic is invoked or as it is being terminated.
You can create a custom schematic that automatically invokes the
TR_RSTR actor during schematic invocation. Additionally, you
can invoke the TR_SAVE actor when exiting a custom schematic
by using the Define Final Picture Editor command.
NOTE: Any of the implementation methods described above or any

combination of methods that satisfies your requirements can be used.
In all implementations, regardless of trend functionality existing on
the custom schematic, the set of trend settings saved or restored is the
same.

Error Handling
Errors messages can be generated from four basic sources: parameter
validation, file access, file content, and runtime execution.
1. Parameter validation error messages are generated if the actors

encounter a problem processing TREND_ID and PATHNAME
input parameters:
Error Message Meaning...
PARAMETER OUT OF RANGE Identifies an invalid number or a
number greater than the number of
trend graphs within the custom
schematic (<1 or >12).
INVALID DATA Displayed if the PATHNAME
parameter is invalid because of invalid
characters, invalid path structure, and
missing or wrong file extension.
2. File access error messages identify problems encountered when

the actors attempt to access the Saved Trend Setting file specified
by the PATHNAME. During a save operation, the TR_SAVE
actor is responsible for finding, creating (if necessary), and writing
the set of trend settings to the specified file. The possible error
messages that can be displayed during this operation are:
SAVE NOT DONE - BAD PATH The supplied path is invalid.
SAVE NOT DONE - CREATE BAD The creation of the specified file fails.
SAVE NOT DONE – WRITE FAIL When writing the data to the file fails.

Error Handling,
continued
3. During a display saved operation the TR_RSTR actor is

responsible for finding and reading the set of trend settings from a
specified file. Possible error messages during this operation are:
FILE DOES NOT EXIST The path/filename does not exist.
ERROR READING SAVED DATA Displayed if the file read operation
fails.
Because a Saved Trend Data file can be edited by using the Text
Editor, errors can result. If the data is incorrect information,
incorrect format, or invalid information, the following error may
occur:
BAD DATA FOUND IN FILE The file contains invalid or corrupted
trend settings.
References
function “Save/Restore Trend Data.”
• Actors Manual

35.4 Detail Display Navigation
Selected Point
Navigation
Invisible targets added behind the point id connections allow the
selection of the point id. When the point is selected, the selected point
is shown on the top line of the screen display. The TREND, GROUP,
ASSOC DISP, DETAIL, or CLEAR ENT (to deselect the selected
point) keys can now be depressed to acquire those displays.
Custom Data
Segments
The CUSTOM page has new target functionality behind the custom
data segment targets. When a Custom Data Segment is selected on a
CUSTOM PAGE of the detail display, a text input port opens up and
the selected CDS is displayed below the port as shown in the figure
below.
Figure 35-4 Connection Page in Detail Display with Connection
Point Selected
18 Apr 97 08:17:03 1
Selected CDS
16682
Another CDS can now be entered or one of the four keys mentioned above
can be pressed (the CLEAR ENT key will clear the text input port). If the
CDS is a point id, the appropriate schematic will be invoked.
References
Refer to the Process Operations Manual for more information on
R530 function “Detail Display Navigation.”

35.5 SP/OP Tolerance Check
Tolerance Check
Tolerance Limit is described as the maximum delta value by which the
setpoint or output of a process point can be manually changed in either
a plus or minus direction without causing a violation warning.
Two new parameters, $SPTOL and $OPTOL, in the R530 function

“Setpoint /Output Tolerance Check,” will check to see if the tolerance
is violated in either a negative or positive direction from the current
value of the SP or OP. The operator is alerted by a beep from the
keyboard and a warning message on the second line of the screen in an
operating display. If there is a violation, operator confirmation is
required before the value is stored (see Process Operations Manual).
Manually entered tolerance values require a key access of ENGR.
Tolerance checks are made in the Detail/Group displays and the

RS_SYS, CHG_ZONE, and USER_CZ actors in schematics. A value
of 0.0 disables this check. Default values for $SPTOL and $OPTOL
are zero. A NaN or negative value is not allowed.
DEB configuration
The Data Entity Builder supports configuration of the $SPTOL and
$OPTOL parameters in the following sections of the builder.
$SPTOL
• AM (RegCtl) Reg Setpoint Display
• HG (RegCtl) Operating Configuration
• NIM (RegCtl) Setpoint Display Regulatory Control
$OPTOL
• AM (RegCtl) Reg Ctrl Output Connections
• HG (RegCtl, AO, AC) Operating Configuration
• NIM (RegCtl) Output Configuration Regulatory Control
• NIM (AO) Operating Configuration Analog Output
Points checked
Manually entered SP and OP values for the following points are
tolerance-checked against the engineer-specified tolerance value:
• SP and OP values for the AM, HG, and NIM RegCtl points
• OP values for HG and NIM Analog Output points
• OP values for HG Analog Composite points

35.5 SP/OP Tolerance Check, Continued
Error Handling
Error condition notifications occur as follows:
From the Data Entity Builder:

Error Condition Error Message
Entering an out of range value LMT OR RANGE ERROR
Entering a value of NaN VALUE ERR
From the Detail and Schematic Display:

Entering an out of range value LMT OR RANGE ERROR
Entering a value of NaN VALUE ERR
Attempting to enter a value when the ACCESS LEVEL ERR
key is in any position other than ENGR
References
function “SP/OP Tolerance Check.”
• AM Control Functions & Algorithms
• AM Forms
• AM Parameter Reference Dictionary
• APM Configuration Forms
• APM Control Functions & Algorithms
• PM Family Parameter Reference Dictionary
• Data Hiway, Bx/Slt, Data Pt Forms
• Engineer’s Reference Manual
• HG Control Functions & Algorithms
• HG Parameter Reference Dictionary
• HPM Configuration Forms
• HPM Control Functions & Algorithms
• HPM Family Parameter Reference Dictionary
• PM Configuration Forms
• PM Control Functions & Algorithms
• PM Family Parameter Reference Dictionary

Section 36 – R610 Periodic Pre-Defined Documentation Tool
Query
36.0 Overview
Overview
This function provides the ability to trigger and cancel pre-defined
Documentation Tool queries through CL or scheduled ECs and have
the query results output to a file or printer automatically.
Refer to Command Processor Operation for a discussion of

Documentation Tool Query commands.
Target Platforms
Nodes affected are the UNP, OPR and GUS Native LCN Window.
AM, CG, NIM and HG are indirectly affected in that CL hosted by
these nodes or by control processors on their control networks have
new pre-defined keywords and associated values in CL SEND
statements.
CL Send
Statement
You can automatically trigger or cancel a pre-built Doc Tool query on
a periodic basis. The query runs in background mode.
This is accomplished through a CL SEND message that specifies the

US node on which to run the query, the pre-build query descriptor, and
the destination for the results. The destination can be either a printer
ID or a pathname to a file. For the AM/CL, the query can be made
periodic by configuring the point to which the CL is linked to be
processed on a specified cycle. For Process Network node (NIM and
HG boxes), the query can be made periodic by writing a CL program
which executes periodically.
ATTENTION The AM CL commands – QFILE, QPRINT and QCANCEL – cannot

be used for invoking prebuilt queries with historized journal access.

36.1 Implementation
Command
examples
There are three new keywords added to invoke a pre-defined query
from CL using a specially formatted “SEND” message. They are used
as follows:
SEND:”$QFILE <Node Number> <Descriptor> <Pathname> <XX>
SEND:”$QPRINT <Node Number> <Descriptor> $P<n> <XX>
SEND:”$QCANCEL <Node Number> <YY>
Where:
$QFILE This is the keyword to specify a query whose result is to be
output to a file.
$QPRINT This is a keyword to specify a query whose result is to be
output to a printer.
$QCANCEL This is a keyword to cancel the running query being
executed by a Doc Tool background task.
<Node Number> This is a required field, and specifies the LCN US node,
which is to process the request.
<Descriptor> This is a required field, and specifies the name of the pre-
defined query (maximum of 16 characters and no spaces).
<Pathname> This is a required field, and specifies the path to the file to
which the result should be output.
$P<n> This is a required field, and specifies the printer ID on
which to query results are to be printed.

36.1 Implementation, Continued
Where:
<XX> and <YY> These are option fields which can take the values given
below:
XX [$BYPASS | $SORT | $BYSORT | $SORTF |
$BYSORTF | $NSORT | $BYNSORT]
YY [$BYPASS]
If specified, they achieve the following:
$BYPASS Allows you to specify that the CL Send
message itself is not to be output to the Real Time Journal
nor put into the Operator Message Summary Display (the
message will still go into Event History on the HM).
$SORT
Sorts the Query Result by the Entity Name.
$BYSORT
Facilitates both $SORTF and $BYPASS operations
($BYPASS + $SORT).
$SORTF
Sorts the Query Result by the user specified first field.
$BYSORTF
Facilitates both $SORTF and $BYPASS operations
($BYPASS + $SORTF).
$NSORT
Explicitly does not sort the Query Result.
$BYNSORT
Facilitates both $SORT and $BYPASS operations
($BYPASS + $SORT).
Global values may not be selected for the QRYSORT PSDP.
This is because the global value in the QRYSORT PSDEP
overrides the sort directive in the send message.

NOTES:
1. In xPM and MC CL, the content of a SEND message has a
limitation of 7 fields of 8 characters each, therefore a SEND
message for $QFILE is constructed as follows.
$QFILE [node #] [descriptor 1…8] [descriptor 9…16] [pathname 17…24]
When a field is used for the XX or YY option, then the descriptor is
limited to 8 characters.
The same limitation applies to the messages initiated by the ACPs
from CM50s, which are connected to the CG. This message length
limitation is 72 characters. If the destination is “CRT only”, the
message limitation is 60 characters.
2. All the above mentioned sort operations will be over ridden if the
QRYSORT PSDP value has been set to Node Global type.
3. The QRYSORT functionality for CL programs and the Command

Processor (CP) is extended to support the schematics, therefore
schematics that use the query actors can use the sort capabilities.
The query results will be sorted or not sorted depending on the
value of the QRYSORT parameter. The possible modes are as
follows in the table on following page.
4. If there is a CL problem, try QFILE from the Command Processor.
5. A problem occurs if a CL program tries to do two or more queries

consecutively. There is contention on the SYSQRY.EC file. Delay
the CL program at least 10 seconds between queries.

QRYSORT
functions
TYPE QRYSORT Definition

Value
Temporary 0 “No Sort.” The Sort Directive in the CL/CP (Command
Processor) query will override this option.
1 “Sort by Entity Name.” Automatically reset to ‘No Sort’ at

completion of Query. The Sort Directive in the CL/CP will
override this option.
. 2 . “Sort by user specified first field.” Automatically reset to ‘No

Sort’ at completion of Query. The Sort Directive in the CL/CP
will override this option.
Node Global . 3 . “No Sort.” This option overrides the CL/CP Sort Directive.
This value is not automatically reset. Once set, this option
can only be changed to another Node Global type or Reset.
. 4 . “Sort by Entity Name.” This option overrides the CL/CP Sort

Directive. This value is not automatically reset. Once set, this
option can only be changed to another Node Global type or
Reset.
. 5 . “Sort by first user specified field.” This option overrides the

CL/CP Sort Directive. This value is not automatically reset.
Once set, this option can only be changed to another Node
Global type or Reset.
Reset . 6 . Used to Reset the Node Global options. Once a Node

Global option is set, it can be changed to a temporary type
only by setting this option. Setting this option, resets the
PSDP value to 0.

Notes on
QRYSORT results
1. Global values can only be changed to another global value or reset
(6).
2. Reset (Value of 6, as in the above table) clears out the value (global
or temporary).
3. Temporary value can be changed to another temporary value.
4. Temporary value cannot change a global value.
5. CL/CP Sort Directive is treated like a temporary value.
6. CL/CP Command with no specific sort directive switch and
Schematic actor access are equivalent (PSDP rules).
7. If Query occurs with a temporary value, the value is reset after the
query completes.
8. If Query occurs with a Node Global value, the value is not reset
after the query completes.
9. The sort mode will be initialized to temporary “No_Sort” at system
startup.
Individual versus
node global sorts
You may use the sort option on an individual query basis (by setting to
temporary type) or on a node global basis as follows:
Sort mode set to temporary value

• The CL/CP query commands can use an optional sort switch when a
sort is desired.
• If the Sort option is set to temporary type (through Schematic actors
or by writing to the PSDP directly, or by any means), and a CLCP
desires “No Sort” then the NSORT switch must be used in the
command.
• Users with schematics that use query actors and want them to
operate just like the CL and CP commands can do so by adding a
line of code that sets the sort mode to one of the temporary values.
This setting must be made in each schematic in which they want the
query results to be sorted.

Sort mode set on a node global type

• The sort mode value must be set. You must specify the desired
value of the QRYSORT PSDP because it is initialized to zero (0) at
node startup.
• When the QRYSORT parameter is in a node global mode, it
overrides sort switches in CL/CP commands. In this case, no matter
what Sort Directive is used in the CL/CP command, the sort
operation on all query requests from CL/CP would operate in the
same manner.
• When a node global mode has to be changed to a node local mode,
the mode must first be Reset. Then the desired temporary value can
be selected.
Note: When sort by “first user specified field” is selected and the first
user specified field does not exist, the query results are sorted by the
point name
Query actor status

check
The program can interrogate the station's PSDP parameters QSTS(1),
QSTS(2), and QSTS(3). Because this is an array of strings, the
AM/CL program must run in the background.
QSTS(1) contains the name of the last query initiated.

QSTS(2) contains the status of that query.
QSTS(3) contains the invocation date/time of the last requested query.
The status strings contained in QSTS(2) are as follows:

"query in progress"
"query complete"
"query complete but not displayable"
"printer failure - printout aborted"
"canceled"
"device unavailable"
"fatal error occured"
"no match found"
"printing results"
"multiple errors ocurred"
"__________" blanks, when no query has yet been initiated
A problem occurs

36.2 Periodic Pre-Defined Query Scenarios
Specify node CL
send message
Scenario 1
To invoke a pre-defined query from CL, a user must specify the node
number where the query is to run, the descriptor of the pre-built query
and the pathname or printer number. For example, if the pre-built
query, HGPOINTS is to be run on node (US) 35 with the result being
output into file hgpoints.xx, the command is as follows.
AM CL:
SEND:”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $BYPASS”
xPM/MC CL:
SEND:” $QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $BYPASS”
Notice that the query descriptor and pathname for xPM/MC CL are
split into eight characters per word.
AM/CL with Custom Data Segments:

SEND: “$QFILE 35”,str1(1),str3(25),”$BYPASS”
Where,
str1(1) has the string value of HGPOINTS,
STR3(25) has the string value of NET>TEMP>HGPOINTS.XX
The optional keyword “$BYPASS” is used to prevent this CL message

from going to the Operator Message Summary display and the RTJ
printer.
Scenario 2
To request the same query as above but direct the results to be output
on printer $P2, the CL command is:
SEND: “$QPRINT 35 HGPOINTS $P2 $BYPASS”
Scenario 3
To cancel the query being executed by the background task on node
35, the C: command is: SEND: “$QCANCEL 35”
Scenario 4
To invoke the sort query results, any of the optional Sort Directives
may be used, as follows:

36.2 Periodic Pre-Defined Query Scenarios, Continued
Specify node CL
send message,
continued
To sort the Query Result by point name
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $SORT”
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $BYSORT”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $SORT”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $BYSORT”
To sort the Query Result by user specified first field
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $SORTF”
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX
$BYSORTF”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $SORTF”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $BYSORTF”
To Not sort the Query Result
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $NSORT”
• SEND: ”$QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX
$BYNSORT”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $NSORT”
• SEND: ”$QPRINT 35 HGPOINTS $P2 $BYNSORT”
Notice the following about the above cases:

1. In all of them, the query results depends on the Sort Directive used;
however, if the node global sort value is set in the QRYSORT PSDP,
it overrides the Sort Directive set in the query initiated from the CL
Send Messages.
2. When a combination of $BYPASS and Sort Directive is used in CL
Send Message Query, then the query results will be sorted/not sorted
based on the Sort Directive, and the message will not be sent to the
Operator Message Summary display and the RTJ printer.
3. In order to make an AM/CL initiated pre-defined query run on a
periodic basis, the following steps need to be taken.
• Include the CL Send message in a CL program
• Attach the CL program to a process point
• Configure the CL program to a process point
• Configure the processing rate of the process point to the periodic
rate desired for the pre-defined query
• Load the process point and set it active

36.2 Periodic Pre-Defined Query Scenarios, Continued
SEND MESSAGES
The format of the SEND MESSAGE (initiated by ACPs from upper
level processors (CM50s) connected to the CG) will be the same as the
Message sent by the CL SEND messages. That is, the same keywords
used in the CL SEND messages will be used here.
FORTRAN call for Send Message example

return_status = CM50_STOREMSG
(%REF(msg).
msg_len,
confirm,
timeout,
dest)
PASCAL call for Send Message example
return_status = CM50_STOREMSG
(msg.
msg_len,
confirm,
timeout,
dest)
“C” call for Send Message example
return_status = cm50_storemsg
(msg.
&msg_len,
&confirm,
&timeout,
&dest)
Where,
msg = “QFILE 35 HGPOINTS NET>TEMP>HGPOINTS.XX $BYPASS”
msg_len = 47
confirm = 1
timeout = 180
dest = 2

Section 37 – R660 Finding Point Interconnections
37.0 Overview
Introduction With TPN R660, an optional feature added to a Universal Station can
search the system database within standard operating displays for
connection references to a selected point. Although this feature uses
the Find Names function, not many Find Names options are available
and the operator does not see the Find Names interfaces.
The Finding Point Interconnections function is similar to the Find
Names function available through the Command Processor in that
they both search for point interconnections in checkpoint files.
However, the Command Processor Find Names function has an
engineer keylock, and the Operator Find Names function has an
operator keylock.
The Finding Point Interconnections function allows the engineer to
use the Documentation Tool FNM Query to narrow the operator’s
search parameters to only the checkpoints of concern.
Using the predefined queries and the $INTRCON schematic, an

operator can find data points that are interconnected with AM, HG,
and UCN data points and associated CL programs and sequences in
the control strategy.
The $INTRCON schematic is an electronic form. Using this page the

operator can start a point interconnections search, cancel a search
that is in progress, see the status of a request in progress, or see the
search results as the search is in progress.
The point interconnection option uses Universal Station memory and

processor resources to perform checkpoint searches for references.
This section describes the engineer’s implementation of the optional
OPFNAM (operator personality) and UPFNAM (universal / GUS
personality) external load module to support this feature.

37.1 Implementation
Introduction Implementing the Operator Find Names function consists of:
• Modifying the NCF to include the Operator Find Names external

load module.
• Using the Documentation Tool to build predefined queries that
can be entered into the $INTRCON schematic by the operator to
search for point interconnections.
Modifying the NCF to The procedure for modifying the NCF is contained in Table 37-1.
include the Operator
Find Names external
load module
Table 37-1 Modifying the NCF
Step Action
1 From the Modify Volume Paths display in the Engineer or Universal
Personality, set the NCF Backup Path to a removable media
pathname.
$Fx>&ASY>
where x = drive number
Insert a backup &ASY disk in the removable media drive.

2 From the Engineering Main Menu, select the LCN NODES target.
The LCN Nodes display appears.
3 Verify that the NCF configurator is in the ON-LINE mode as shown
in the upper right corner of the display.
4 Select the target for the node number of the Universal Station that is
to be loaded with the OPFNAM and/or UPFNAM external load
modules. Use the PAGE FWD key to display the desired US node
number
5 Select the MODIFY NODE target.
6 Page 2 allows you to configure the external load modules on the
selected US. This display contains 24 entry ports for Module
Names, and 24 entry ports for Personality Types.
NOTE:
It is important that you do not use the ENTER key until instructed.
Use the TAB keys to move from port to port, or use the
touchscreen.

Modifying the NCF to

include the Find
Names external load
module, continued
Table 37-1 Modifying the NCF, continued
Step Action
7 If the US being configured is always in the Operator personality, key
in the name and personality type for the Operator personality. In
this case, the Universal personality module does not have to be
configured.If the Finding Point Interconnections feature is to be
enabled in the US, the names of the following external load module
must be entered as described in step 8:
Module Type Station Personality
OPFNAM OPR Operator
UPFNAM UP Universal
8 Key in the required External Load Module Names and the required
Personality Types (in the entry ports for the Associated Personality
Type), but—
do not press the ENTER key.
Select the NO target as the answer for USE DEFAULT

PERSONALITY TYPE?.
9 Press the [ENTER] key.
10 The network configuration file will determine the total size of the
software defined for each personality configured. The network
configuration file will show the size for each personality configured
next to the TOTAL (MODULES PLUS ADDITIONAL MEMORY) line.
Round-off each of the size numbers up to the next 1K.

Add 2K to the rounded-off numbers.
Key in the totals into the associated boxes next to the MAXIMUM
EXTERNAL MODULE MEMORY (WORDS) line.
For R660 and later versions, add 4,000 words for future
expansion.
This extra memory allows for possible future maintenance or
upgrade releases to be loaded without requiring an NCF change.
11 Press the [ENTER] key.

Table 37-1 Modifying the NCF, continued

Step Action
12 Press the CTL key and the 1 key at the same time to check the
revised NCF to ensure that the HM is not at 100% capacity.
13 Press the CTL key and the 2 key at the same time to install the
revised NCF.
14 Restart the US or GUS to ensure that it is reloaded with the revised
NCF.
Using the Use the Documentation Tool to build predefined queries that can be
Documentation Tool used by the operator to search for point interconnections.
to build predefined
(FNM) Finding Point Refer to the Documentation Tool manual for the procedure to build
Interconnections predefined FNM (Finding Point Interconnections) queries.
queries
Sizing and The external load modules (OPFNAM and UPFNAM) for the Finding
Performance Point Interconnections function use 130,000 words of US memory
space. They are approximately 126,000 words in size and 4,000 spare
words that provide space for possible changes. The configuration
provides 130,000 word sizes in the NCF. This sizing is adequate to
run in the minimum size Operator Personality, but may conflict with
US nodes that have existing external load modules configured.
The Universal Personality runs on the LCNP-4 GUS native window
when the LCN node was configured to have UPBASE, MSCHEM,
CSCHEM, YGOCX, GUSALA, GUSALG, and UPFNAM load
modules. In this case, the extra memory was set to 30,000, the total
memory was 270,645, and the maximum was set at 280,000.
The Finding Point Interconnections external load module operator
runtime uses approximately 122,000 words of heap memory
(HEAPFREE) with typical AM/NM/HG checkpoint databases
(116,000 was measured on a GUS).
The Finding Point Interconnections runtime on the operator can use
up to 60 percent of the available CPU time (CPUFREE) (40 percent
measured on the GUS), but runs at a lower priority than existing US
functions. When an existing US function is running at the same time
as the $INTRCON search, the existing US function has the priority
over CPU resources and the $INTRCON search takes longer.

Setup and Restart The Finding Point Interconnections function uses interfaces that are
available to the engineer but are not available in operator mode of
use. This includes configuring the external load module in the US
(NCF), building search Fnm query parameters (Documentation Tool),
viewing and deleting point interconnection file output (Command
Processor) and entering the Fnm query names used with $INTRCON
Default query point type options ($PICQRYA, $PICQRYU,
$PICQRYH).
The engineer performs the network configuration to implement this
function on a US. The engineer may add TPN changes through a
custom schematic or AM/CL program to allow the operator to initiate
the remaining actions.
The default Fnm query names ($PICQRYA, $PICQRYU,
$PICQRYH) are set to a ‘NULL’ value whenever the US is reloaded.

37.2 Operation
Introduction This section contains a brief description of how to initiate

interconnection searches using the Finding Interconnection Points
function.
Refer to the Process Operations Manual, section 3.2, for more

information about the use of the $INTRCON Schematic.
Finding point The operator uses the $INTRCON schematic shown in

connections Figure 37-1 to initiate searches for interconnected points.
Figure 37-1 $INTRCON Schematic

37.2 Operation, Continued
Finding point The $INTRCON schematic is an electronic form. The schematic can
connections, be accessed by the operator using any one of the following methods:
continued
• From a group display, select a point name. Press the SCHEM key,
enter $INTRCON, and press the ENTER key. The $INTRCON
schematic shown in Figure 37-1 appears.
• From a point detail display, press the $INTRCON page target and
the $INTRCON schematic appears.
NOTE: When the Status value is INACT (Inactive) the operator can
select the Request target and press ENTER to initiate a search of the
NET AM/UCN/HG checkpoints for references to the selected point.
These results are shown in the bottom portion of the $INTRCON
schematic.
To use the PRT/FILE/FNM Query/Default options the engineer needs
to configure documentation tool FNM query descriptors and supply
the values to the operator. FNM Query descriptors could then be used
by the operator as follows:
• Select the FNM Query target and enter the descriptor name (to
remove a FNM Query name enter the value (—) or NULL)
• If the named FNM Query provides a valid printer ID and/or file

name, the operator can select the PRT and/or the File target, press
ENTER and the next search request output is sent to the printer
and/or file along with the results shown on the bottom of the
screen.
• If the engineer has built FNM queries to specify a default for

AM/UCN/HG selected point types (parameters $PICQRYA,
$PICQRYU, $PICQRYH) then the operator may select the
Default target and press ENTER to use the search parameters
based on the defaults.
The operator can then enter a descriptor which can be from 1 to 64

characters in length in the FNM Query descriptor entry port of the
$INTRCON schematic.
The descriptor is the name of the Finding Interconnection Points
query that was assigned to the query it was built by an engineer using
the Documentation Tool. It contains the interconnection search limits.

37.2 Operation, Continued
Finding point The engineer can establish a default query for AM, HG, and UCN
connections, points by using PSDP parameters. The defaults are implemented
continued
using three PSDP parameters ($PICQRYA, $PICQRYH, and
$PICQRYU) for AM, HG, and UCN points, respectively. This can
be accomplished through the DATACHNG schematics or through
AM/CL write operations. These defaults are used by the operator
when the $INTRCON schematic Default target is set to ON.
NOTE: The default values are temporary values and must be re-
entered each time after the US/GUS node is restarted.

Index
Entity Data in the Data Entity Builder, 253

$ HM Local NVCF Data, 252
NCF Data, 251
$$NODE, 278 Schematic Data, 255
$INTRCON, 648 Unit, Area, and Console Names, 249
$LNMENU, 241 Bootload, 272
$QCANCEL, 634 Box/slot verification, 211
$QFILE, 634 BREAK key, 293, 294
$QPRINT, 634 Build, 272
Button LED Control, 566
Area Change, 567
& Area Change, CAUTION, 568
&ASY Bypass Option, 567
backup copy, 48 CL SEND statement, 566
maintaining backup copies, 50 Example, 566
two versions, 49 Error handling, 568
&CUS, 540, 544 RED/YEL keywords, 567
&OVG, 544 Button Primmod Assignment, 564
Actor
GET PRIMMOD, 565
“ Button Name File, 565
“C” call for Send Message, 642 CL SEND statement, 564
Example, 564
Error handling, 568
A Node Startup, 565
Actors
In Process Control, 259 C
use of, 259
what they do, 259 CANCEL, 634
Alarm Summary Enhancements (R610), 194 CHANINFO, 209
Alarm Summary Enhancements (R681), 195 Channel Information Display Description (R651), 221
Alias, 271 Checker Target, 208
ALTCBLA, 218 Checkpoint, 272, (checkpointing)
ALTCBLB, 218 rules, 266
AMCLDBUG, 209 Checkpoint Time, 211
AMCLDSPL, 209 CHKPTIME, 211
AMDETAIL, 209 CL Send Messages, 640
AMTREND, 209 CL SEND statement, 564, 566
Area Change CLOKCABL, 212
CAUTION, 568 CLOKCABL, 218
Area Database, 238 CLOKMODE, 212
Assigning Units to an Area, 240 CLOKSYNC, 212
Autoboot, 271 CLOKTRAN, 212
automatically trigger or cancel a pre-built Doc Tool, CLSNODE, 209
633 Compile, 272
Conceptual organization, 21
Configurable Access Level on Parameters, 615
B Access Level Configurable Options, 617
Back up Help Messages, 621
&ASY, 48 Parameter Access Level Revision Differences,
HM, 39 618
Bind, 271 Parameter change requests, 617
Binding System Wide Values, Console Data, 619
Data in CL Programs, 256 Configurable Access Level on Parameters:, 19, 616
Entities & Schematics into the Area Database, Configuration checks during startup, 48
257 Console defined, 56

Index
Continuous history, 80 files cannot be found, 52
Copy a floppy or cartridge, 39 File-system, 38
Copy files, 39 Format, 273
CPUCHKR, 210 FORTRAN call for Send Message, 642
CPUFREE, 214
Crash, 272 G
Crossed cables, 218
Current Display Parameter, 208 Generic Overlays, 544
Custom Software Guidelines and Warnings, 265
Backplane, 539
Directory, 541 H
D Heap displays, 210
HEAPCHKR, 211
Database Composition, 238 HEAPFRAG, 214
DATACHNG, 208 HEAPFRAG2, 214
Definitions of CHANINFO display items, 222 HEAPFREE, 214
Delete files, 39 HEAPMIN, 211, 214
Detail Display Navigation, 615 HM
Custom Data Segments, 630 Assigning Units, 76
DIGSYNCH, 212, 219 Configuring History Groups, 77
Directories, 37 Configuring Redundant Disk Drives, 129
Directory, 272, 273 Continuous History
Displaying the channel information for a node, 222 configuration, 80
Documentation Tool, 633 saving/restoring, 135
Drives, 67 Estimating volume sizes, 89
Fragmentation, 147
E Initialization, 133
Load, 273
Engineering Personality Setting a Disk Drive Off Line, 131
Generic Overlays, 544 Types of Data, 69
Requirements, 59 Volume Configuration Example, 95
Entity, 273 Volumes required, 72
Error, 273 HMDETAIL, 209
Establish, 273 HMTREND, 209
Event-Initiated Reports
Area, 528 I
Error Handling, 537
History, 531 IDF. (Intermediate Data File)
Implementation, 562 IDF, 274
Message-Source Considerations, 527, 563 Initialize, 274
Operation, 536 Intermediate Data File, 274
Exception Build, 273 Invoke, 274
invoke pre-defined query form CL, 640
F
Fast-Load
K
Feature, 53, 281 KB, 274
Guidelines, 285 keywords to invoke pre-defined query, 634
Implementation, 285 Kilobyte, 274
Scenario, 281
Fast-Load Cartridge L
contents, 288, 289, 297
Maintenance, 288, 289 LCN
File access on startup, 48 cable diagnostics, 210
File-system crossed cables, 218
abbreviations, 38 LCN (Local Control Network), 274
commands, 38

Index
LCN Node Version/Revision Logging function, 28, NONTRNS, 212

569 Not sort the Query Result, 641
Call Up Display, 586 NOTSYNC, 212
Directory, Find a, 579 np, 275
Distributed Files, 578
Errors,non-recoverable, 611 O
Errors,recoverable, 613
Export File Format Option, 591 On-Line Reconfiguration, 276
Export File LVRLOG.RE, 606 Overlays
Field Descriptors, 572 Generic, 544
Installation,Initial, 580 Owning Node, 276
LCN ID,Enter, 589
Performance Displays Menu P
LVRLOG, 208
Printer number, Enter, 600 PARCHKR, 209
Printing, Cancel PARSEC, 215
WARNING, 602 PASCAL call for Send Message, 642
Report Display,Initiate, 597 Pathname, 32
Report Format, 571 PED (Parameter Entry Display), 276
Report Generation,Initiate, 593 PERFMENU, 200
Requirements Performance cluster, 71
Hardware, 576 Performance Displays Menu, 205
Memory, 576 Personality, 276
Software, 576 Picks, 23
Site ID, Enter, 587 Picture Editor
Universal Station Configuration, 581 reference, 52
LCN Node Version/Revision Logging function:, 579 tips, 226
LCNPERF, 209 point connections, 648
LDID (Logical Device Identifier), 274 PRECREF, 212
Link, 274 pre-defined Documentation Tool, 29, 633
List files, 38 Preparation for use, 45
Load, 275 PRIMMOD, 177
LOAD FAIL message Printer availability, 56
Clearing a, 279 Processor free-time, 210
Local Volume, 69 Processor Status Data Point, 213
Logical Device Identifier, 274 PSDP parameters
LVRLOG, 574 Application Module, 339
Application Processing Platform (APP) Node,
M 434, 437
Computer Gateway, 360
MB, 275 History Module, 365
Megabyte, 275 Hiway Gateway, 369
Megaword, 275 HM60, 407
Mw, 275 Network Gateway, 380
Network InterfaceModule, 418
N Overview, 325
Parameters on every point in the system, 439
NCF, 275 PSDP Parameters in all nodes, 328
NET, 33 Purpose of PSDPs, 326
Network Configuration File Remote User Link Adaptor, 417
Purpose, 62 Universal Station, 388
NGDETAIL, 209 Purchased Options
NGTREND, 209 Hardware, 500
Node, 275 Application Module, 501
Node Loading Failures, 278
NODEPERF, 209, 214
Node-related displays, 209

Index
Sort mode set to temporary value, 638
Q sort Query Result by user specified first field, 641
sort the Query Result by point name, 641
QCANCEL, 634 SP/OP Tolerance Check, 615
QFILE, 634 SPARSEC, 215
QPRINT, 634 Startup
QRYSORT parameter, 636 &ASY, two versions, 49
Quick Trend, 210 &ASY’s Role;, 48
QUIKTRND, 210, 217 after HM configuration, 129
after power failure, history collection loss, 88
configuration checks during, 48
R denied if mismatch of critical data, 269
Reconfigure, 276 file access on, 48
Reconstitute, 276 filename consistency, 234
Redundant drives, 67 HM, 68
Release HM autoboot, 134, 271
What is it?, 485 HM initialization, 133
Release 530 Functions, 28 HM overload message, 87
Configurable Access Levels on Parameters, 615 of node prevented, 268
Detail Display Navigation, 615 Option
One Key Call Up of a Point Trend, 615, 633 Enhanced Hiway Gateway, 506
Save/Restore Trend Data, 615 HG Point Display Ranges, 494
SP/OP Tolerance Check, 615 Redundant disk drives, 127, 128, 130, 131, 132
Removable Media, 276 Schematics loaded at, 231
Report to Output File, 545 Sequence, 266
Configuration, 548 Use of NCF, 61
Displaying Reports, 552 Station number, 56
Error Handling, 556 SUBSYNCH, 212
Error logic, 549 SYStem error, 556
FailOver, 550 System Volumes, 37
File descriptors, 551
Printer Assignments, 546 T
Purging Files, 559
REPORT_MEDIA, 553 TLK. (see Toolkit)
Status and error messages, 553 Toolkit, 199
VP CONFIG, 553 TREND
Writing Reports, 550 Save/Restore Trend Data, 615
Restore files, 39 Trends
ROF. (see Report to Output File) One Key Call Up of Point Trend, 615
RPARSEC, 215 Collectors, 623
Missing Default and Custom display error
messages/Error Handling, 623
S Standard Display, 622
SEND MESSAGE, 642 Toolkit (TLK2), 623
send pre-defined query, 634 TREND invocation - Custom schematic
Setpoint/Output Tolerance Check display, 622
$SPTOL,$OPTOL parameters, 631 TREND invocation - Default trend display,
DEB configuration, 631 622
Error Handling, 632 One Key Call Up of Point Trend:, 623
Points checked, 631 Save/Restore Trend Data
Tolerance Check, 631 Custom Schematics, 624
SEVERE status, 554 Error Handling, 628
SEVERE WARNING status, 68 Save Trend Data into ASCII files, 625
SLTCONFG, 211 Trend Graphs and Trend Ids, 627
Snapshots and User Averages, 84 trend setting elements, 624
Software Upgrade TRNSLTR, 212, 219
Process, 487
Sort mode set on a node global type, 639

Index
U Z
Universal personality Disk
Fast load, 53 &ASY Directories, 63
Generic overlays, 544 Access Name (LDID), 274
Successful backup, 49 Adding a Pathname, 243
Universal Personality Alternative Name in Early Releases, 271
Calling functions, 23 Autoload Targets, 282
Definition, 276 Backup .GD Files, 233
Memory requirement, 23 Configuration Terms, 272, 273
Universal Station configuration, 581 Content of Fast Load Cartridge, 288, 289, 297
Universal Work Station configuration, 59 Copying a disk, 39
Upgrades Copying Files to an HM, 242
AM, 501 Demand Checkpointing Caution, 309
CG to PLNM, 504 Distributed Files, 578
USER error, 556 Dump failures, 301, 302
Estimated Number To Fill HM, 90
V Fast Access User Volume, 99
Fast Load Feature, 281
Value Change, 208 Fast-Load Scenario, 284
Virtual printer. (see Report to Output File) Format Command, 38
Volume, 276 HM Backup Tool, 146
configuration, 95 Improving Subpicture Performance", 229
estimating sizes, 89 Initializing, 38
required on HM, 72 List File Command, 38
system, 37 Node Dumps, 301
Volume and directory, 33 Node Loading and Dumps, 277
access, 35 Part Numbers, 44
Back up files, 39 Preparation for use, 44
Copy files, 39 Preparing Fast-Load Disk, 291, 292
Delete a file, 39 Restoring HM Group Config, 141
hierarchy, 34 Separate Files and Subpictures, 230
List, 38 System software, 17
List files if names are not known, 39 Volume and Directories, 33
Restore files, 39 Volume vs. Directory, 276
suffixes, 41 drive
usage, 33 HM Upgrades, 516
Drive
W Engineering Function Efficiency, 59
Identification, 33
WARNING status, 68, 554 Part Numbers, 44
WDA. (see winchester drives) Upgrading To, 507, 508
Where to begin, 19 US hardware recommendations, 20
Why a node fails or crashes, 278 Using Two Drives, 234
Winchester drives, 66
Wren, 90, 95

Honeywell Process Solutions
1860 W. Rose Garden Lane
Phoenix, AZ 85027 USA

TPS Engineers Reference Manual

Uploaded by

Copyright:

Available Formats

TPS Engineers Reference Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TPS Engineers Reference Manual

Uploaded by

Copyright:

Available Formats

Implementation

Startup and Reconfiguration - 2

Copyright 2010 by Honeywell International Sárl.

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

Honeywell Process Solutions

ii Engineer’s Reference Manual 11/2010

11/2010 Engineer’s Reference Manual iii

Contact: Honeywell Solution Support Center

Europe, Middle East, and Africa (EMEA)

Contact: Honeywell TAC-EMEA

Contact: Honeywell Global TAC – Pacific

Contact: Honeywell Global TAC – India

Contact: Honeywell Global TAC – Korea

iv Engineer’s Reference Manual 11/2010

Contact: Honeywell Global TAC – China

Contact: Honeywell Global TAC – South East Asia

Contact: Honeywell Global TAC – Taiwan

Contact: Honeywell Global TAC – Japan

Call your nearest Honeywell office.

World Wide Web

Honeywell Solution Support Online:

Honeywell Automation College:

11/2010 Engineer’s Reference Manual v

SECTION 1 – ENGINEER’S REFERENCE MANUAL SUMMARY................................. 17

SECTION 2 – FILE SYSTEM OPERATIONS ................................................................. 31

SECTION 3 – THE &ASY SYSTEM DIRECTORY AND ITS SPECIAL

SECTION 4 – AREA (&D01-&D10) AND STANDARD ABSTRACT (&DSY)

SECTION 5 – CONSOLE ORGANIZATION.................................................................... 55

SECTION 6 – NETWORK CONFIGURATION FILE ....................................................... 61

SECTION 7 – HM CONFIGURATION AND USE ............................................................ 65

11/2010 Engineer’s Reference Manual vii

7.3 Continuous History Configuration .........................................................................80

SECTION 8 – ALARM MANAGEMENT ........................................................................ 151

SECTION 9 – DATA ENTITY BUILDER OPERATIONS............................................... 199

SECTION 10 – NATIVE WINDOW SYSTEM PERFORMANCE DISPLAYS ................ 201

viii Engineer’s Reference Manual 11/2010

SECTION 11 – SCHEMATIC FILES .............................................................................. 233

SECTION 12 – CONTROL LANGUAGE FILES............................................................ 241

SECTION 13 – AREA DATABASE, CONTENT, AND USE ......................................... 245

SECTION 14 – DATA BINDING IN THE TPS SYSTEM................................................ 253

SECTION 15 – ACTORS AND PROCESS CONTROL................................................. 267

SECTION 16 – AM CONFIGURATION GUIDELINES .................................................. 269

SECTION 17 – DATA TO BE USED DURING CONFIGURATION .............................. 271

SECTION 18 – AVOIDING MISTAKES AND ERRORS................................................ 273

SECTION 19 – GLOSSARY OF TPS CONFIGURATION TERMS ............................... 279

11/2010 Engineer’s Reference Manual ix

SECTION 20 – NODE LOADING AND NODE DUMPS ................................................ 285

SECTION 21 – CHECKPOINTING ............................................................................... 313

SECTION 22 – PROCESSOR STATUS DATA POINT ................................................ 333

SECTION 23 – CONFIGURING FOR PERFORMANCE .............................................. 453

x Engineer’s Reference Manual 11/2010

SECTION 24 – NCF AND LCN STATUS DISPLAYS .................................................. 485

SECTION 25 – LCN RECONNECTION........................................................................ 487

SECTION 26 – LCN/DATA HIWAY HARDWARE COMPATIBILITY .......................... 489

SECTION 27 – HOW TO MOVE TO A NEW TPS RELEASE...................................... 491

SECTION 28 – PURCHASED OPTIONS ..................................................................... 495

SECTION 29 – LCN CABLE DIAGNOSIS ................................................................... 529

11/2010 Engineer’s Reference Manual xi

SECTION 30 – EVENT-INITIATED REPORTS—IMPLEMENTATION AND USE....... 531