GEH-6422 Turbine Historian System Guide PDF

GEH-6422
*(,QGXVWULDO6\VWHPV
Turbine Historian
System Guide
Publication:
Issued:
GEH-6422
1999-08-31
Turbine Historian
System Guide
1999 General Electric Company, USA.

All rights reserved.
Printed in the United States of America.
These instructions do not purport to cover all details or variations in equipment, nor to provide
every possible contingency to be met during installation, operation, and maintenance. If further
information is desired or if particular problems arise that are not covered sufficiently for the
purchasers purpose, the matter should be referred to GE Industrial Systems, Salem, Virginia,
USA.
This document contains proprietary information of General Electric Company, USA and is
furnished to its customer solely to assist that customer in the installation, testing, operation,
and/or maintenance of the equipment described. This document shall not be reproduced in whole
or in part nor shall its contents be disclosed to any third party without the written approval of GE
Industrial Systems.
ARCNET is a registered trademark of Datapoint Corporation.

CIMPLICITY is a trademark of GE Fanuc Automation North America, Inc.
Ethernet is a trademark of Xerox Corporation.
IBM is a registered trademark of International Business Machines Corporation.
Intel is a registered trademark of Intel Corporation.
Modbus is trademark of Gould Inc.
PC is a registered trademark of International Business Machines Corporation.
PI-ProcessBook is a registered trademark of OSI Software Inc.
PI-Data Archive and PI-DataLink are trademarks of OSI Software Inc.
SPEEDTRONIC is a trademark of General Electric Company, USA.
Windows is a registered trademark of Microsoft Corporation.
Windows NT is a registered trademark of Microsoft Corporation.
Safety Symbol Legend
Indicates a procedure or condition that, if not

strictly observed, could result in personal injury or
death.
Indicates a procedure or condition that, if not

strictly observed, could result in damage to or
destruction of equipment.
Indicates a procedure or condition that should be

strictly followed in order to optimize these
applications.
Note Indicates an essential or important procedure, condition, or statement.
This equipment contains a potential hazard of

electric shock or burn. Only personnel who are
adequately trained and thoroughly familiar with
the equipment and the instructions should install,
or maintain this equipment.
To prevent personal injury or equipment damage
caused by equipment malfunction, only adequately
trained personnel should modify any
programmable machine.
The example and setup screens in this manual do

not reflect the actual application configurations. Be
sure to follow the correct setup procedures for
your application.
Contents
Chapter 1 Overview
1-1
Introduction............................................................................................................................ 1-1
Historian Summary ................................................................................................................ 1-1
System Configuration .............................................................................................. 1-1
Data Flow................................................................................................................. 1-3
Historian Tools ........................................................................................................ 1-4
Manual Outline....................................................................................................................... 1-6
Conventions ........................................................................................................................... 1-6
Related Publications............................................................................................................... 1-7
Getting Assistance.................................................................................................................. 1-7
Chapter 2 Quick Start
2-1
Introduction................................................................................................................... ......... 2-1

Logging On ............................................................................................................................ 2-1
Viewing Analog Trend Data .................................................................................................. 2-3
Opening PI-ProcessBook ......................................................................................... 2-3
Opening a Display.................................................................................................... 2-4
Changing the Time Range ....................................................................................... 2-5
Using the Trend Cursor............................................................................................ 2-6
Viewing Alarms, Events, SOEs ............................................................................................. 2-9
Other Functions.................................................................................................................... 2-13
Cross Plot............................................................................................................... 2-13
Searching for Event Triggers ................................................................................. 2-16
Chapter 3 Users Guide
3-1
Introduction............................................................................................................................ 3-1
Historian Client Toolset ......................................................................................................... 3-1
PI-ProcessBook...................................................................................................................... 3-1
Opening PI-ProcessBook ......................................................................................... 3-2
Creating a New PI-ProcessBook.............................................................................. 3-2
Historian Menu (Web Browser) ........................................................................................... 3-18
Historical Alarm and Event Report........................................................................ 3-19
Historical Alarm and Event Exception Report....................................................... 3-22
Historical Alarm and Event Summary Report ....................................................... 3-24
Historical Cross Plot .............................................................................................. 3-28
Event/Trigger Search ............................................................................................. 3-35
ARCWHO.............................................................................................................. 3-41
The PI Point Data Base Browser............................................................................ 3-43
HST Startup Log.................................................................................................... 3-47
PI-DataLink.......................................................................................................................... 3-49
GEH-6422 Turbine Historian System Guide
Contents i
Chapter 4 Maintenance Guide
4-1
Introduction............................................................................................................................ 4-1
Architecture............................................................................................................................ 4-1
Basic Data Flow....................................................................................................... 4-2
Communication Layer Details ................................................................................. 4-2
Front End Programs ................................................................................................. 4-4
Data Layer ............................................................................................................... 4-6
Application Layer .................................................................................................... 4-7
System Management .............................................................................................................. 4-8
Historian Accounts .................................................................................................. 4-9
Setting Time Zone, Date, and Time....................................................................... 4-16
Starting/Stopping Historian Software .................................................................... 4-17
Starting/Stopping PI Software ............................................................................... 4-18
Rebooting the Historian ......................................................................................... 4-19
Shutting Down the Historian ................................................................................. 4-19
Saving and Restoring Files using NT Backup ....................................................... 4-20
System Backup & Restore using NT Backup ........................................................ 4-22
PI Configuration (Theory)................................................................................................. 4-28
PI Data Archives.................................................................................................... 4-28
Compression .......................................................................................................... 4-29
PI Point Database................................................................................................... 4-30
PI Database Configuration (Practical).................................................................................. 4-34
Historian Database Unit Level - HSTDBU.EXE................................................... 4-35
Historian Database System Level - HSTDBS.EXE ............................................... 4-44
Web Server Configuration ................................................................................................... 4-51
Historian Home Page ............................................................................................. 4-52
Ethernet Configuration......................................................................................................... 4-53
Historian Configuration Files............................................................................................... 4-57
Unit Types ............................................................................................................. 4-57
Configuration Files in the F:\ Directory................................................................. 4-58
Configuration Files in the F:\UNITn Directory ..................................................... 4-59
Configuration File in the Windows Directory ....................................................... 4-61
Historian Configuration ....................................................................................................... 4-61
TCI Control Panel Applet ...................................................................................... 4-81
Unit Configuration ............................................................................................................... 4-82
Modbus Configuration (Master Only) ................................................................... 4-83
Modbus Configuration ........................................................................................... 4-86
Data Dump Configuration.................................................................................... 4-104
Mark IV Configuration ........................................................................................ 4-112
Mark V & Mark V LM Configuration ................................................................. 4-115
Mark VI Unit Configuration ................................................................................ 4-119
Off Line Storage................................................................................................................. 4-127
Archiving Historical Data .................................................................................... 4-127
Restoring History Files ........................................................................................ 4-137
PI-DataLink........................................................................................................................ 4-140
Installing PI-DataLink ......................................................................................... 4-140
Configuring Excel to Use PI-DataLink................................................................ 4-141
ii Contents
Chapter 5 Installation Guide
5-1
Introduction............................................................................................................................ 5-1
Receiving & Handling............................................................................................................ 5-1
Unpacking & Storage............................................................................................................. 5-2
Equipment Overview.............................................................................................................. 5-2
Installation Instructions .......................................................................................................... 5-3
Configuration ......................................................................................................................... 5-4
Chapter 6 Application Notes
6-1
Introduction............................................................................................................................ 6-1
Accessing the Historian from a Client PC via LAN............................................................... 6-1
Installing PI-ProcessBook........................................................................................ 6-3
Configuring Remote Access .................................................................................... 6-3
Starting the Remote Access Service ........................................................................ 6-7
Resolving Communication Problems between a PI Client and a PI Server ........................... 6-7
Diagnostic Tools .................................................................................................................... 6-8
Basic Generic Questions .......................................................................................... 6-8
Overview of Approach............................................................................................. 6-9
Debugging Details ................................................................................................... 6-9
CHECKCRC.......................................................................................................... 6-23
VIEW0 - View One Second Data .......................................................................... 6-24
VIEWPIA - View PI Archive Data........................................................................ 6-25
VIEWPIS - View PI Snapshot Data....................................................................... 6-26
Ethernet Printer Setup on the Historian................................................................................ 6-28
Parallel Port Printer Setup on the Historian ......................................................................... 6-29
Facts about UTC .................................................................................................................. 6-30
WEB Browser Information .................................................................................................. 6-31
Procedures............................................................................................................................ 6-32
History File Archive Procedure ............................................................................. 6-32
History Files Restore Procedure ............................................................................ 6-33
Configuring Data Collection.................................................................................. 6-34
Glossary of Terms
G-1
Contents iii
Chapter 1 Overview
Introduction
This manual describes the Historian data archival systems used with GEs
SPEEDTRONIC Turbine Control Systems. Emphasis in this document is on how
the Historian is used by the operator, and how it is configured by the engineer. The
communication options for the different versions of turbine control, and the means of
providing remote PC access to the Historian, are discussed.
Historian Summary
The Historian is a data archival system based on client-server technology, providing
data collection, storage, and display of power island and auxiliary process data.
Depending on the requirements, the product can be configured for just turbinerelated data, or for broader applications that include balance of plant process data.
The Historian combines high-resolution digital event data from the turbine controller
with process analog data to create a sophisticated tool for investigating cause-effect
relationships. The product integrates the high performance archive products from
OSI Software Inc. (PI Data Archive and PI-ProcessBook ), with GE-developed
data management functions for the high-speed turbine event digital data. Advanced
data compression techniques greatly reduce the data storage media requirements.
The Historian provides a menu of predefined database query forms for typical
calculations and analysis relating to the turbine operations. PI-ProcessBook and PIDataLink are flexible tools that enable the operator to quickly generate custom
trends and reports from the archived process data.
System Configuration
The GE Historian provides historical data archiving and retrieval functions within
the power island control and monitoring system architecture. When required, the
system architecture provides time synchronization to ensure time coherent data.
The Historian accesses turbine controller data via different networks, depending on
the turbine controllers capabilities. A summary of GE turbine control types and
supported networks follows:
Chapter 1 Overview 1-1
GE Turbine Control
Supported Communication Networks
Mark IV
Control System Freeway (CSF) Arcnet-based network

RS-232C link using Message Service Protocol (MSP)
RS-232C link using Modbus protocol
RS-232C link using Predefined Data Dump
Mark V
Stagelink (Arcnet-based network)
Mark V LM
Stagelink (Arcnet-based network)
Mark VI
Unit Data Highway (UDH) Ethernet-based network
Additional Historian data acquisition is performed through Modbus and/or Ethernet

based interfaces. Data from third party devices such as Bently Nevada monitors, or
non-GE PLCs is usually obtained via Modbus, while Ethernet is the preferred
communication channel for GE/Fanuc PLC products.
The HMI (Human Machine Interface) and other operator interface devices
communicate with the Historian through the Ethernet-based Plant Data Highway
(PDH), through Stagelink, and through RS-232C lines. Network technology
provided by the Microsoft Windows NT Operating System allows interaction from
network computers, including query and view capabilities using the Historian Client
Tool Set. The interface options include the ability to export data into Microsoft
applications. At sites where multiple PI Servers are utilized, PI to PI exchange is
available with the GE Historian.
Plant Data Highway (Ethernet)
Data
Data
HMI Server # 1
HMI/Historian
Viewer(Client)
HMI Server # 2
Historian
Data Archive
DAT
Tape
TR
RS-232C
Line
Unit Data Highway (Ethernet)
Control System Freeway (CSF)

Stagelink
Mark VI
Turbine
Control
I/O
Mark IV
Turbine
Control
I/O
Mark V
Turbine
Control
I/O
Data Transmission to the Historian, and HMI Access to the Data Archive
1-2 Chapter 1 Overview
System Capability
The Historian provides an on-line historical database for collecting and storing data
from the controllers. Points can be collected from as many as eight turbine controls.
A typical turbine control application uses less than 1,000 points of time tagged
analog and discrete data per unit. The length of time that the data is stored on disk
before off-line archiving is required depends upon collection rate, dead-band,
process rate of change, and disk size.
Data Flow
The Historian has three main functions: data collection, data storage, and data
retrieval.
Data Collection is through the various networks.
Data Storage of Sequence of Events (SOE), events, and alarms is in the Digital
Exception Database; storage of analog and digital values is in the PI Archive.
Data Retrieval to a PC can be by way of a web browser, or PI-ProcessBook, or PIDataLink. The diagram below depicts these functions and data flow.
Alarm & Event Report

Event Scanner
Cross Plot
Web Browser
Excel for Reports

& Analysis
Process Data
(Trends)
PIProcessBook
PIDataLink
Viewers
Client Side
Server Side
Turbine
Control Digital
Exception
Database
CSF or serial
Stagelink
Data
Dictionary
Ethernet
Ethernet
PI
Archives
Historian
Modbus
Mark IV
Mark V
Mark VI
PLC
3rd Party
Devices
I/O
I/O
I/O
I/O
I/O
Controllers
Historian Functions & Data Flow
Details
Data is collected by various methods. For the Mark IV, Mark V, Mark V LM, and
Mark VI, the process is centered about the Control Signal Database (CSDB) which is
the real-time database in the controller. The control scans the CSDB for alarm and
event state changes. When a state change occurs, it is sent to the Historian. Contact
inputs, or Sequence of Event (SOE) changes are scanned, sent to the Historian, and
stored in the Exception Database with the alarms and event state changes. These
points are time-tagged by the controller.
The turbine control also distributes periodic data updates scanned from the CSDB.
The Historian receives these one-second periodic updates and stores the data in the
PI subsystems.
Time synchronization and time coherency are extremely important when the operator
or maintenance technician needs to analyze and determine the root cause of a
problem. To provide this, the controller time-tags the data, and offers system time-set
or time-synchronization functions as options to ensure that the data remain timecoherent.
Data points configured for collection in the PI Archives are sampled once per second
from the Data Dictionary. Analog data that exceeds an exception dead-band, and
digital data that changes state, are sent to the PI subsystem. PI uses the swinging
door compression method that filters on the slope of the value to determine when to
save a value. This allows the Historian to keep orders of magnitude more data online than in conventional scanned systems.
OSIs PI-ProcessBook is the graphical interface to the history stored in the PI
Archives. It provides historical and real-time trending of all process data, and can run
in the Historian and/or HMI Viewer.
The Web Browser interface provides access to the Alarm & Event Report, the CrossPlot, the Event Scanner, and several Historian status displays.
PI-DataLink provides a vehicle to extract data from the PI Archives into application
packages such as Excel for report generation and analysis.
Historian Tools
The Historian has a selection of tools, screens, and reports available to ensure that
the operator can make efficient use of the collected data. Examples of just a few of
these are illustrated below.
Alarm and Event Report

Turbine upsets can be
analyzed using highresolution (1 ms) contact
closure data.
The Alarm and Event Report is a tabular display of the alarms, events, and SOE for
all control units connected to the Historian. This report presents the following
information on a points status: time of pickup (or dropout), unit name, status,
processor drop number, and descriptive text. This is a valuable tool to aid in the
analysis of the system operation, especially after an upset.
Historical Cross-Plots
The Historical Cross Plot references the values of two signal points, and plots one
against another, for example temperature against RPM. This function permits visual
contrasting of operational data, and detection of correlations.
Event Scanner
The Event Scanner function uses logic point information (such as: start, trip,
shutdown, or user-defined) stored in the historical database to search and identify
specific situations in the unit control.
The Event/Trigger Query Results shows the users inputs and a tabular display of
results. The data in the TIME column represents the time-tag of the specified Event
Trigger. This can be used in the Historical Alarm and Event Report and PIProcessBook to retrieve data associated with the event.
Process Data (Trends)

The Historian can trend any analog or digital point. It is fully configurable and has
the ability to auto-range the scales or set fixed indexes. For accurate read out, the
trend cursor displays the exact value of all points trended at a given point in time.
The Historian can be set up to mimic strip chart recorders, analyze the performance
of particular parameters over time, or help troubleshoot root causes of a turbine
upset. The following trend display from the ProcessBook is an example of a turbine
start-up.
Typical Multi-Pen Process Trend Display
Reports
PI-DataLink provides a vehicle to extract data from the PI Archives into application
packages such as Excel. Excel, and other software packages such as Access, SQL,
and Minitab, can be used to generate reports and analyze data. Reports such as
maintenance and shift reports can be generated to provide the customer with needed
information to better manage his plant assets.
Manual Outline
The manual contains six chapters describing the installation, use, configuration, and
application of the Historian. The manual is organized as follows:
Chapter 1 Overview. Outline of the Historian features, contents of the manual, and
list of related publications.
Chapter 2 Quick Start. An introduction to get the user up and running the first
time, assuming the Historian is configured and has process data.
Chapter 3 Users Guide. A discussion of the Client Toolset used to access all the
process and discrete data in the Historian.
Chapter4 Maintenance Guide. A description of how to configure the Historian for
all the data collection, storage, and display functions.
Chapter 5 Installation Guide. Instructions on unpacking and setting up the
Historian.
Chapter 6 Application Notes. Special applications such as LAN access to the
Historian, diagnostic tools, and tape archiving procedures.
Glossary Definitions of Historian and turbine control terms.
Conventions
The following conventional terms, text formats, and symbols are used throughout
this document.
Convention
Meaning
Bold
Indicates that the word is being defined.
Arial Bold
Indicates the actual command or option that is chosen from a

menu or dialog box.
Italic
Indicates a word used as a word, or a letter used as a letter. For

example, the display should now read SDB has stopped. Italic
also indicates new terms, margin notes, and the titles of figures
and chapters in the guide.
UPPERCASE
Indicates a directory, filename, or block name. Lower case

letters can be used when typing names in a dialog box or at the
command prompt, unless otherwise indicated for a specific
application or utility.
Monospace
Represents examples of screen text, or words and characters that

are typed in a text box or at a command prompt.
Indicates a procedure.
Indicates a procedure with only one step.
Indicates a list of related information, not procedural steps.
Related Publications
In addition to this system guide, other related publications on the HMI and GEs
Turbine Control Systems are available as follows:
HMI for SPEEDTRONIC Turbine Controls Application Manual GEH-6126
System Guide for the SPEEDTRONIC Mark VI Turbine Control GEH-6421
SPEEDTRONIC Mark V Turbine Control Application Manual GEH-6195
Toolbox for Configuring a Mark VI Turbine Controller GEH-6403
MARK IV SPEEDTRONIC Gas Turbine Control Maintenance Manual
GEK-83886
Mark IV SPEEDTRONIC Gas Turbine Control Operator's Manual
GEK-83885
SPEEDTRONIC Mark V Turbine Control User's Manual
GEH-5979
SPEEDTRONIC Mark V Turbine Control Maintenance Manual GEH-5980

SPEEDTRONIC Turbine Control Panel Manual Overview
GEH-6354
Getting Assistance
If assistance is needed, please contact:
GE Industrial Systems
Product Service Engineering
1501 Roanoke Blvd.
Salem, VA 24153-6492 USA
Phone + 1 800-533-5885 or +1 540 378 3280
Fax + 1 540 387 8606
(replace + with international access code)
Notes
Chapter 2 Quick Start
Introduction
The chapter is an overview to get first-time users up and running quickly, starting
with a configured Historian containing process data. How to call up the trend
displays and digital event records is explained in simple terms. More detailed
description and instructions on how to use each of the client applications is covered
in Chapter 3 User Guide.
Logging On
To Logon to the OPER account
1.
Boot up the PC Historian. The Begin Logon window displays.
2.
Press the three keys, Ctrl+Alt+Delete, all at once. The GE License

Agreement Notice displays.
3.
From the GE License Agreement Notice, read the legal notice, then press
the Enter key.
Or, use the pointer device and click on the OK button to continue. The Logon
Information window displays.
4.
From the Logon Information window, enter oper at the User Name prompt.
There is no password for the oper account so the Password prompt remains
blank. Along the bottom of this window are four buttons. Click on the OK
button after entering your User ID and password to complete the log on.
The oper accounts Desktop displays.
Chapter 2 Quick Start 2-1
Click on the Cancel button to stop the log on. Click on the Help button for
information on how to log on. Click on the Shut Down button to halt the system
prior to powering down the computer.
Once logged in, the oper accounts Desktop displays with the icons and Start button
used to launch programs.
Desktop Display
2-2 Chapter 2 Quick Start
Viewing Analog Trend Data

PI-ProcessBook is the tool used to display analog and digital trend data stored in the
PI Data Archive.
Opening PI-ProcessBook
To open the PI-ProcessBook
On the Desktop display, double click on the PI Procbook icon,

Or, click on Start, then Programs, then GE Historian Menu, then
PI-ProcessBook. The PI-ProcessBook displays.
The user is presented with a list of predefined displays on the default PIProcessBook screen.
PI-ProcessBook Menu
Opening a Display
To view trend data
From the PI-ProcessBook menu of displays, double click on one of the

display titles. The selected PI-ProcessBook display opens.
Or, click on a display title, then click on the New button at the bottom of the
display. The display opens in a new window.
Or, click on a display title, then click on the open button at the bottom of the
display. The display opens in the last display window used, or in a new window
if none were open.
Trend displays open in

the Run mode with the
Run mode arrow pointer
selected
Changing the Time Range

Changing the time range is
sometimes called "zooming"
To change the time range displayed

1.
From the PI-ProcessBook, select the trend(s) using the Run mode pointer.
Select a trend by clicking on it, or select multiple trends by holding the Shift
key down and clicking on each trend,
2.
or, click and drag a box around all the trends in order to select them all. A gray
edge appears around the selected trends.
3.
Click on View located at the top of the screen. The View menu displays.
4.
From the View menu, choose Time Range. The Change Time Range
dialog box displays.
5.
Enter a new date and time for either the start (From:) or the end (To:). Select a
time from the drop down list, or type in a specific date and time.
6.
Click OK to accept the changes.
Change Trend End Time
Change Trend Start Time
By having * as the end time and *-8 Hour as the start time, the trend updates once
every five seconds and displays the last eight hours of data for the points in the trend.
In PI-ProcessBook, the * represents the current time.
Moving trends is referred to
as "Panning"
To move trends forward or backward
From the PI-ProcessBook, click the Time Forward or Time Backward

button. The trend moves one time period. The time period is defined by the
trends current start and end times.
To return to the original or previously saved time setting
Click on the Revert button,

Or, select Revert from the View menu. The trend displays the original time
setting.
To expand the Trend
Double click within a trend using the Run mode pointer. The trend expands to
fill the entire display window.
Using the Trend Cursor

The trend cursor displays tag values at any selected time.
To select the trend cursor
Click on the Trend Cursor button,
Or, select Trend Cursor from the View menu. The cursor displays.
Cursor Time
readout window
Cursor Tag Value

readout window
Full Screen Trend with Trend Cursor Selected
The cursor is located at the right hand side of the screen, with the time, date, and tag
values in two windows at the top and bottom.
To move the trend cursor
Place the Run mode pointer over the right axis of the trend. When the pointer
changes to a double-headed arrow, click and hold down the mouse button, and
move it to the left. Release the mouse button at the desired time shown in the
readout window.
Trend Cursor Repositioned
To add additional trend cursors
Place the Run mode pointer over the left axis of the trend. When the trend
cursor symbol appears, click and hold down the mouse pointer, then move it to
the right. A new cursor appears.
Multiple Trend Cursors
To resize an expanded trend
Double click on the any portion of the expanded trend. The expanded trend
returns to its regular size.
Normal Display with Trend Cursor Enabled
To close a display
From the PI-ProcessBook, click on the displays Close Window button.

Or, select Close in the File menu. The PI-ProcessBook menu displays. At
this point another display can be selected from the PI-ProcessBook menu.
To close PI-ProcessBook menu
From the PI-ProcessBook menu, click on the Close Window button

Or, in the File menu, select Exit. The PI-ProcessBook menu closes.
Viewing Alarms, Events, SOEs

The Historical Alarm and Event Report shows the Alarms, Events, and Sequence of
Events (SOE) for each unit over the specified time range.
To access the Historical Alarm and Event Report

1.
From the Desktop display, double click the Historian Menu icon. The
Historian Functions web browser screen displays, with a list of Historical
Data and Status Information.
Historian Menu
2.
From the Historian Functions display, single click the Alarm and Event
Report text. The Historical Alarm and Event Query Form displays. The
form is automatically filled in for the user, and is set up to display the last eight
hours of Alarms, Events, and SOEs for all units.
Historical Alarm and Event Query Form
3.
Modify the default query form fields as needed.
4.
When the form is complete, click the Submit button. The requested Alarm
and Event Exception Report displays.
Historical Alarm and Event Exception Report
The Alarm and Event output page contains the time of the pickup or drop out, the
unit name, the status, and either the processor and drop number for process alarms,
or point name for SOEs and Events, and the points descriptive text. It may be
printed and/or saved as a text file from the browser window.
To return to the Query form
1.
From the Alarm and Event Exception Report, click the Back button on
the web browser toolbar. The Historical Alarm and Event Report Query
form displays.
2.
Modify the query form to focus on times of interest.
To return to the Historian menu
From the Historical Alarm and Event Report Query form, click the Back
button on the web browser toolbar. The Historian Functions menu displays.
Other Functions
Cross Plot
Cross Plot can reveal
correlations between
variables
The Historical Cross Plot compares the values of two signal points against one
another in an X-Y plot. The function permits visual contrasting of operational
data.
To access Cross Plot
1.
From the Desktop, double click the Historian Menu icon. The Historian
Functions web browser screen displays.
Historian Functions Menu
2.
From the Historian Functions display, single click the Cross Plot
(Predefined Forms) text. The Historical Cross Plot Predefined Forms
displays. This page is used to store forms that serve as templates for convenient
reuse in analyzing data.
3.
From the Historical Cross Plot Predefined Forms display, choose a form
by clicking on its Form Name. The Modify Historical Cross Plot Form
displays.
Historical Cross Plot Predefined Forms

4.
From the Modify Historical Cross Plot Form, modify the fields as needed.
To override the Start Time parameter, check the Force Start Time to be
Current Time checkbox next to Form Option. This uses the current time at
the instant the plot is requested, and overrides the forms start time. Note that
this parameter is only useful when the elapsed time is negative.
Historical Cross Plot Form
5.
When the form fields have been modified, click the Draw Plot button. The
Historical Cross Plot Results graph displays.
Historical Cross Plot Graph
Searching for Event Triggers

The Event Scanner function uses logic point information stored in the historical
database to search and identify specific situations in the unit control, such as:
Start
Trip
Shutdown
User defined events
To view the Event Scanner

1.
From the Desktop display, double click the Historian Menu icon. The
Historian Functions web browser displays.
Historian Functions menu
2.
From the Historian Functions display, click the Event Scanner

(Predefined Forms) text. The Event/Trigger Query Predefined Forms
displays. The Predefined Forms page is used to store forms that serve as
templates for convenient reuse in finding data.
Event/Trigger Query Predefined Forms
3.
From the Event/Trigger Query Predefined Forms list, select a form and
click on its Form Name. The Event/Trigger Query form displays.
4.
From the Event/Trigger Query form, modify the fields as needed.
The Trigger (required) is a change in a points logic state
The Level (optional) is another points logic value
Event/Trigger Query Form
5.
When the Event/Trigger Query form is complete, click the Submit button.
The Event/Trigger Query Results displays with the requested data.
Event/Trigger Query Results
The Event/Trigger Query Results page shows the users inputs and a tabular
display of results. This section will be blank if no data was found matching the form
inputs. The data in the Time column represents the timetag of the specified Event
Trigger. This can be used in the Historical Alarm and Event Report and PIProcessBook to retrieve data associated with this event.
Chapter 3 Users Guide
Introduction
This chapter describes how to access historical data stored in the Historian using the
Historian Client Toolset. This toolset consists of the Web Browser for viewing
alarms and events, the PI-ProcessBook for viewing historical trends, and PIDataLink for access to spreadsheet programs.
Historian Client Toolset

The Historian Client Toolset is used to access both Analog and Digital data stored in
the Historian. The toolset consists of the following application programs:
PI-ProcessBook - OSIs PI-ProcessBook is the graphical interface to the history

stored in the PI Archives. It provides historical and real-time trending of all
process data.
Web Browser - This interface provides access to the Alarm & Event Report, the
Cross-Plot, the Event Scanner, and several Historian status displays.
PI-DataLink - PI-DataLink provides a vehicle to extract data from the PI

Archives into application packages such as Excel for report generation and
analysis. Excel or Lotus 123 is required.
The Historian Client Toolset is part of the Historian product. These application
programs may also run on any PC that has the proper license for the application and
has a network connection to the Historian.
PI-ProcessBook
This section is an overview of how to use PI-ProcessBook on the Historian. Refer to
OSIs PI-ProcessBook Users Guide for detailed information regarding the
capabilities of PI-ProcessBook.
See Accessing the Historian
from a Client PC via LAN in
the Application Notes for
information on installing PIProcessBook on an HMI or
client PC
PI-ProcessBook is a client tool used for displaying analog and digital data stored in
the PI Data Archive server. Both PI-ProcessBook and PI Data Archive are products
of OSI Software, Inc. PI-ProcessBook is licensed to run on the Historian. A second
license is included to run PI-ProcessBook on an HMI, or users Windows NT, or
Windows 95/98 PC. Additional PI-ProcessBook licenses can be purchased as
needed.
Chapter 3 Users Guide 3-1
PI-ProcessBook is the graphical interface to all data stored in the PI Data Archives.
It is a tool that allows the user to easily create trends and to quickly view data.
Opening PI-ProcessBook
PI-ProcessBook can be accessed from all three user accounts, Administrator, maint,
and oper.
To open PI-ProcessBook
From the Desktop, double click on the PI Procbook icon.

Or, click on Start, then Programs, then GE Historian Menu, and then PIProcessBook. The PI-ProcessBook opens.
If the PI Server Login window appears when opening PI-ProcessBook, then a

problem exists with the communication between the PI client and the PI server.
Refer to Resolving CommunicationProblems between a PI Client and a PI Server in
the Application Notes.
Once PI-ProcessBook is open, the user is presented with a list of PI-ProcessBook
entries (predefined displays) on the default PI-ProcessBook screen. Each PIProcessBook entry is set up for retrieval and display of a group of data points from
the historical database. Within one PI-ProcessBook entry multiple trends may be
defined. Each trend can have up to eight points defined. Each trend has its own time
range defined, which can be modified. Trends can be defined to simultaneously
display historical and real-time data. Additional trends can be added to a PIProcessBook entry, or new PI-ProcessBook entries can be added to the PIProcessBook.
Each Historian ships with its default PI-ProcessBook pre-configured for the
particular site. However, different users may want to create their own PIProcessBooks, set up to display the particular data they are interested in.
Creating a New PI-ProcessBook

To create a new PI-ProcessBook
1.
3-2 Chapter 3 Users Guide
Click on File, then New. The New dialog box displays.
2.
Under the Type section, select ProcessBook (.piw) File, and enter a name
under ProcessBook Name:
3.
Click on OK. The PI-ProcessBook displays.
New PI-ProcessBook with No Entries

To save the new PI-ProcessBook
1.
Click File, then Save As. The Save As dialog box displays.
2.
From the Save in: drop down box, select the target directory where the
ProcessBook file is to be saved. The File name: is automatically filled out.
3.
Click on Save. The file is saved in the selected directory (C:\SITE\PI ). To

cancel the save operation, click on Cancel.
Setting ProcessBook Preferences

PI-ProcessBook has default settings for color selection, font, view mode,
ProcessBook, time format, and each element of a trend. The default settings are
stored in either the directory C:\ or C:\Program Files under
\PIPC\DAT\PROCBOOK.INI. The user may want to make a backup copy of this file
so that, if required, the original default settings can be restored.
To open the ProcessBook Preferences
1.
From PI-ProcessBook, click on Tools, then Preferences The

ProcessBook Preferences dialog box displays.
2.
Select the Color tab. The Color preferences display.
The Color tab dialog box displays the sixteen current color settings.
To change a color selection
1.
From ProcessBook Preferences color tab dialog box, click on the Choose
Colors button. The Color dialog box displays.
2.
In the Color dialog box, select the color you wish to change in the Custom
colors: section, then select the new color and hue that you wish to use.
3.
Click on Add to Custom Colors to replace the color, and then click on OK to
save the changes. To avoid making any changes, click on Cancel .
The Book tab defines the fonts used in the PI-ProcessBook titles.
ProcessBook Preferences Dialog Box Book Tab

The Book tab configures the View Mode, used when a PI-ProcessBook is opened,
and configures the font attributes for each ProcessBook Entry level.
Opening in Book View Mode, ProcessBook Entries are listed on pages in

chapters. Each Level 1 ProcessBook Entry is seen as a separate chapter and
has its own tab. Level 2,3, ProcessBook Entries are listed on the pages of that
chapter with each level indented beneath the previous level.
The Outline View Mode lists all ProcessBook Entries in typical outline form
with all Level 1 entries treated as separate items in a list and not as separate
chapters. As in Book View Mode, Level 2 entries are indented under Level 1
entries, Level 3 entries are indented under Level 2 entries, and so on.
To change the font attributes for that level

1.
From ProcessBook Preferences, select the level and click on Choose

Font The Font dialog box displays.
In Book View Mode, only the first three font levels are used. Levels 4 through
10 use Level 3s font.
2.
In the Font dialog box, choose the Font:, the Font style:, and the Size:
desired. The Script: box is a feature of Windows 95 and should not be changed.
Font Dialog Box

3.
Click on OK to save the changes. To cancel making any changes, click on

Cancel
The Start tab defines the parameters used to start PI-ProcessBook.
ProcessBook Preferences Dialog Box Start Tab
The Start tab allows the user to specify the defaults used when PI-ProcessBook is
started.
To specify the PI-ProcessBook start defaults
1.
From the Start tab, enter the name for Author:. This is stored with each
display and ProcessBook created; it is an optional field.
2.
Enter the path and file name for ProcessBook:. This is the ProcessBook that
is opened whenever someone starts the PI-ProcessBook client.
3.
Enter the Symbol Library: field. This specifies the default symbol library used
by all ProcessBooks.
4.
If the display elements should change size in proportion to the window size,
select Preserve Aspect Ratio.
5.
If the cursor should automatically change from Build Mode to Run Mode after
drawing a new symbol, select Run Mode Bias.
6.
If backup files should be created as work proceeds, select Create Backup

Files.
7.
In the Time box, select the time format to use with trends and values. This only
affects how the time value is displayed. Either format can still be used for
entering a date.
8.
Click on OK to save the changes,

or, click on Cancel to cancel changes.
The Trend tab defines the defaults for new ProcessBook trends.
ProcessBook Preferences Dialog Box Trend Tab
To configure the trend defaults

1.
From the Trend tab, in the Plot Element: drop down box, select the plot
element. These have line styles, marker types, and/or color properties that can be
modified. The plot elements are as follows:
Pen 1, 2, 3, 4, 5, 6, 7, 8
Text
Backgound
Horizontal Axis
Vertical Axis
Horizontal Major Grid
Horizontal Minor Grid
Vertical Major Grid
Vertical Minor Grid
2.
From Plot Scale, in the Style: drop down box, select Full time stamp, Partial
time stamp, or Relative time stamp.
3.
In the Start: time drop down box, select either *-1 Hour, *-4 Hour, *-8 Hour,
*-1 Day, or *-7 Day. As an option, a custom time can be entered. (In the PI
system, when referencing time, the asterisk (*) means now. A start time of *-1
Hour means that the start time of the trend will always be one hour behind the
current time).
4.
In the End: time drop down box, the options are *, *-1 Hour, *-4 Hour, *-8
Hour, *-1 Day, and *-7 Day. As an option, a custom time can be entered, for
example *-0.5 Day or *-12 Hour.
5.
In the Legend box, select the tag attributes to display. These are Tag Name,
Value, Description, and/or Engineering Units.
6.
In the Display box, if it is required that the trends are scaled as tag values
change over time, select Autoscale:. If not selected, then trends, by default, are
scaled using the values defined in the database.
7.
If Plot Titles are desired, select the Plot Titles box. If not selected, there will be
no titles.
8.
If it is desired to display the tags scale on the inside of the axis, select Vertical
Scale Inside Axis.
9.
If grids are required, select Grids. If this is not selected there will be no grids.
10. To list each tags scales on the trend, select Multiple Scales.
11. To display a marker at each saved data point, select Markers. If not selected
then three markers will be displayed on each line to help identify that line.
12. Click on OK to save changes, or Cancel to cancel changes.
Creating a ProcessBook Entry

A new or existing ProcessBook can have individual entries added to it. There are five
types of entries: Display, Linked Display, Linked ProcessBook, Text Entry, and
Operating System command. The entries can be arranged in hierarchical form by
assigning different levels to the entries.
Text Entry and Display are addressed in this manual. Refer to the PI-ProcessBook
Users Guide for information on adding the other types of entries.
One way to organize a ProcessBook is to have the Level 1 entries be Text Entries
that describe the Level 2 Display entries that follow.
To create a new ProcessBook entry
1.
2.
In the New dialog box, under the Type section, select ProcessBook Entry,
and then click on OK. The Define ProcessBook Entry dialog box displays.
This dialog box is used to configure the basic elements of a ProcessBook entry.
3.
From Define ProcessBook Entry, to add a Text Entry, enter the Label
required for this entry, and select Text Entry from the Type drop down box.
The Level of the first entry in the ProcessBook is automatically set to 1, and
cannot be changed.
4.
Click on OK to create the entry. The PI-ProcessBook displays.
Note The new entry is highlighted. When a new ProcessBook entry is created it is
inserted before a highlighted entry. If no entry is highlighted, the new entry is placed
at the end of the ProcessBook entries. To un-highlight an entry, press the Esc key.
New Text Entry: 3rdShiftOperator Screens

To add a display entry under the Text Entry
1.
From the PI-ProcessBook, press the Esc key to un-highlight the entry
3rdShiftOperator Screens.
2.
3.
From the New dialog box, in the Type drop down box, select ProcessBook
Entry, and then click on OK. The Define ProcessBook Entry dialog box
displays.
4.
From the Define ProcessBook Entry dialog box, enter the desired Label
5.
From the Type drop down box, select Display .
6.
If Unit 1 4 MWatt Output should be indented under the 3rdShiftOperator

Screens, set the Level to 2, and click on OK. The PI-ProcessBook displays.
7.
Click on File, then Save. The empty PI-ProcessBook display is saved.
Performing a Tag Search

The Tag Search tool is used to search for tags configured in PI.
To use Tag Search
1.
From the Tools menu, click on Tag Search. The PI Tag Search dialog box
displays.
2.
The Tag Mask box accepts wildcards, and can be used to narrow the search
scope, as described in the examples below:
To search for all points configured in PI, use * as the tag mask.
To search for points configured for only unit T3, use T3:* as the tag mask.
To search for all speed tags, use *:TNH as the tag mask.
The results of the search are displayed in the Search Results window.
3.
To review the point attributes of each tag, highlight the tag in the Search
Results window, and then click on the Pt. Attr. button. The point attributes
display.
PI Tag Search Dialog Box with Search Completed
The Tag Search is also useful in configuring trends, as multiple tags can be
highlighted and added to the trend together.
Creating a New Trend

The most common method for viewing historical data is a trend. A trend displays the
value for one or more tags over a specified period of time. A tag refers to any point
defined in the PI database.
To create a Trend
1.
From the PI-ProcessBook, click on Draw, then Trend. The mouse pointer
changes to a trend pointer.
2.
On the displays background, click and drag a box large enough to contain the
trend. Release the mouse pointer. (Trends can be resized later). The Trend
Definition dialog box displays.
3.
In the Plot drop down box, enter the name for the trend.
4.
In the Server drop down box, select the appropriate server.
5.
In the Tags in Plot: box, type in the tag name of the point to add to the trend,
and press Enter. The point is added.
6.
To search for a specific set of tags to include in the trend, click on the Tag
Search button. The PI Tag Search window displays.
7.
In the Trend Definition dialog box, to configure the plotting limits to be

displayed on the left side of the trend, go to the Scale section of the dialog box:
The values assigned to Max: and Min: determine the high and low plot
values. The two options provided for each are Autorange and Database.
Autorange causes the limit to vary over time as the tag value changes.
Database uses the value defined in the PI database (Zero and Span) for
that tag as the plot limit.
In addition to the above two values, a number can be typed in for either the
Max: or the Min:. If multiple tags are used and Single Scale is selected,
the trends plotting limits are the highest Max: and the lowest Min: from all
the tags. If Multiple Scales is selected, each tags high plot and low plot
are displayed.
8.
To review the trend attributes (pen colors, line style, marker, background color),
or change them from the default, click the Format Trend button .
9.
To open a new Trend Definition dialog box to create multiple trends all at
once, click the New Plot button
10. To delete the current Trend Definition dialog box, if more than one Trend
Definition dialog box is open, click the Delete Plot button.
11. To delete highlighted tags from the trend definition, click the Delete Tag
button.
The following example is a trend definition called MWATTS that plots the tag
DWATT from each of four units. Since the End: time is * and the Start: time is
*-1 Hour, the trend continually updates showing the last hours worth of data for the
four tags. The default display update rate for PI-ProcessBook is five seconds,
although the data is of higher resolution.
To add tags
1.
From the Trend Definition window, type each tag name into the Tags in
Plot: box, and press the Enter key. The tags are added one at a time, up to a
maximum of eight.
Or, use the Tag Search with a Tag Mask: of *:DWATT, highlight the
four tags, and click on OK.
2.
Once all the points are added, click on OK. The PI-ProcessBook trend is
created.
3.
To save the PI-ProcessBook entry, click on File, then on Save.
4.
To close the entry and return to the PI-ProcessBook, click on File, then Close.
Unit 1 4 MWatt Output -- Level 2 Display
Menu Items
Refer to the PI-ProcessBook
User's Guide, or on-line Help
for more information.
Across the top of the trend display is a list of drop down menus. The following is a
review of some of the menu items emphasizing the more pertinent items of interest.
PI-ProcessBook Drop Down Menus
File. The File menu has typical file items such as New, Open, Close,
Save, Save As, Page Setup, Print Preview, Print, and Exit. The
menu item Connections manages connections to PI Servers.
Edit. The Edit menu has typical edit items plus Format, and Display.
Format configures the text font, object colors, and line styles for this display.
Display configures the background color of the display.
View. The View menu items include the ability to change between Book view
and Outline view, select Toolbars, select the Zoom scale factor for the
entire display, select the Time Range for the trends, and Revert a trend
back to its original time range. The Trend Cursor, which displays tag values at
a particular time, can be turned on and off, and the Trend Zoom performs a 2X
zoom-in, or zoom-out.
Display Color Dialog Box
Zoom Dialog Box
Draw. The Draw menu contains all the items that can be created in a display,
including trends, bar graphs, values, etc. These items are also displayed in the
Drawing toolbar.
Arrange. The Arrange menu has items to arrange drawn items in a display. The
Snap To Grid is a useful item that places a grid on the display. Items drawn or
moved anchor on the grid. This is useful for keeping items aligned. The Align
item also selects multiple drawn items and aligns them as follows:
-
To align with the leftmost item, click on Align, then Left
To align with the rightmost item, click on Align, then Right
To align with the center item, click on Align, then Center.
Other useful items are Bring To Front, Send To Back, Group, Ungroup,
and Regroup.
Historian Menu (Web Browser)

The Historian Functions
menu can be accessed by
other PCs that have a web
browser, and are connected
to the same network
The Historian has a web browser program, usually Microsoft Internet Explorer,
configured to access the Historian Functions menu. The Web Browser interface
provides access to the Alarm & Event Report, the Cross-Plot, the Event Scanner, and
several Historian status displays. These functions are not available through the PIProcessBook. Note that there are no turbine control functions on the Historian Menu.
Refer to Application Notes-Web Browser Information for minimum requirements for
the web browser.
Historian Functions Menu
To access the Historian Functions menu
On the Desktop, double click on the the Historian Menu icon.

Or, click on Start, then Programs, then GE Historian, and then Historian
Menu. The Historian Functions menu displays.
The Historian Functions menu can be accessed by other PCs that have a web browser
and are connected to the same network. The short cut used depends on the local
network configuration. In the first case, the shortcut uses the IP address of the
Historian:
http://192.168.1.40/default.htm
Your site may use a different

IP address
In the second case, the shortcut uses the name of the Historian:
http://hst1/default.htm
The name of the Historian is translated to the IP address by one of the following:
The HOSTS file on the client machine.
DNS, Domain Name Server on the network (not provided by GE).
DHCP, Dynamic Host Configuration Protocol on the network (not provided by

GE).
Historical Alarm and Event Report

The Historical Alarm and Event Report allows the user to view the unit control
Alarms, Events, and SOEs (Sequence of Events). The Sequence of Events record is
based on selected contact inputs scanned at high speed. Viewing of this data may be
customized by the user for any combination of point type, unit name, time range, and
report type using a query form. Reports are available by day and data type.

The most common method of viewing alarms is to design a custom display using the
Historical Alarm and Event Query Form .
To access the query form
From the Historian Functions display, single click the Alarm and Event
Report text. The Historical Alarm and Event Report Query form
displays. This form is automatically filled in for the user, and is set up to display
the last eight hours of Alarms, Events, and SOEs for all units.
To view the report

1.
On the Historical Alarm and Event Report Query form, modify the
default query form fields as needed.
2.
When the form is complete, click the Submit button. The Historical Alarm
and Event Exception Report displays.
The most common way to customize the report is to select the time range of interest.
The form is automatically filled in for the user, and is set up to display data from the
last eight hours. Report time ranges are specified by a Starting Time and Elapsed
Time, and whether the Elapsed Time is before or after the Starting Time. The report
contains the data within the user specified time range.
To customize the Time Range

1.
Enter the Starting Time in the following format:

YYYY.MM.DD HH:MM:SS.sss, where:
YYYY is the year.
MM is the month (1-12)
DD is the day of the month.
HH is the hour (0-23)
MM is the minute (0-59)
SS is the second (0-59)
sss are the subseconds.
The default time is the current time. Fields after the hours field are not required.
2.
Specify thedirection of the Elapsed Time. In the first box, + or - specifies

whether the Elapsed Time is after or before the Starting Time:
+ specifies After the Starting Time
- specifies Before the Starting Time (Default)
3.
Enter the Elapsed Time in the second box, using the following format:
dd HH:MM:SS.sss, where:
dd is the number of days (0-99)
sss are the subseconds.
Fields after the hours field are not required. The Days field is optional.
To select the Query/Report Times
From the Historical Alarm and Event Query form, use the radio buttons to
select the Time standard. The time used in the report may be one of two
standards:
Refer to Chapter 6
Application Notes Facts
about UTC
Site Local Time (Default) Most reports use Site Local Time as this
represents the time at the control location, and has the most meaning to the
user.
UTC (Coordinated Universal Time) - UTC time always moves forward and
does not make adjustments for Daylight Savings Time. As such, it is a
convenient standard for storing Alarms, Events, and SOEs as the data is
always in chronological order and never overlaps or contains time gaps.
UTC time for data display is used by customers infrequently, but may be
useful if other plant equipment uses the UTC time standard.
Selecting the Query/Report Times applies the selection to both the query and the
report so the two are coordinated. Note that Alarms, Events, and SOEs are time
tagged in the controller, and stored in UTC time format on the Historian.
To select the Unit IDs
Check the units of interest in the boxes. All units are selected as the default. The
Unit IDs displayed on the form are the Turbine Control units defined in the
Historian. Unit data from Modbus or Predefined Data Dump links do not appear
among the selections.
To select the Data Types
Check the Data Types of interest in the check boxes on the form. All Data
Types are selected as the default. The Data Types displayed on the form reflect
the types stored in the Historians data files, as follows.
Process Alarms
Events
SOEs Sequence of Events (Contact Inputs)
To select the Report Type
On the Query form, select the Report Type using the radio buttons. The
following Report Types are available:
Exception Report (Default selection) The Exception Report is the most

commonly used. It contains a header reflecting the users form entries, and
displays each occurrence in chronological order with the oldest at the top
and the newest at the bottom. See the example later in this section.
Summary Report This report is useful for identifying points that are
occurring frequently, such as nuisance alarms or toggling points. The report
displays the number of occurrences and is broken down by Unit ID and
Point Type. See the example later in this section.
To submit the Form
On the Query form, click the Submit button. Data is sent from the user form to
the Historian where it is processed. The Historical Alarm & Event Report
displays showing the requested data.
Note Occasionally users may make errors entering data on the form. Clicking the
Reset button sets the form fields back to the above default settings.

The Historical Alarm and Event Exception Report is the most useful report for
analyzing the discrete data stored on the Historian. An Exception occurs when one of
the Process Alarm, Event, or SOE points scanned by the unit control changes state. A
change in state is a point pickup or drop out, and for Process Alarms only, a change
in the lockout state. This data is communicated to the Historian when the change
occurs, and is stored for retrieval in the Historian data files.
The report contains a header which shows the users form input selections:
Site Name
Unit Names(s) selected
Data Type(s) selected
Time Format
Reports Start Time
Reports End Time
Report Type
The output page contains the following data on each line:
Timetag of the exception This time comes from the unit control
Unit Name
Status
-
1 indicates Pickup
0 indicates Dropout
L indicates Lock
U indicates Unlock
Point name for SOEs and Events, or processor and drop number for alarms.
Data Type
ALM for Alarms
EVT for Events
SOE for Sequence of Events
Descriptive text
The report begins with the oldest data and has the newest data at the end. It may be
printed and/or saved as a text file from the browser window. To return to the query
form, use the Back button on the web browser toolbar.
Historical Alarm and Event Summary Report

The Historical Alarm and Event Summary Report is useful for analyzing the
frequency of digital data, especially nuisance alarms and edge conditions. It is
important to eliminate frequently occurring nuisance alarms and edge conditions,
since they crowd up the exception report, without adding much information, making
it difficult to interpret the relevant data.
Historical Alarm and Event Summary Report
The report contains a header which shows the users form input selections:
Site Name
Unit Names(s) selected
Data Type(s) selected
Time Format
Reports Start Time
Reports End Time
Report Type
The report data is listed separately for each unit, and each data type within that unit.
Data is listed in the order of drop number for alarms and events, and in point number
order for events and SOEs.
The output page contains the following data on each line for process alarms:
Number of pickups
Number of dropouts
Number of locks
Number of unlocks
Unit Name
Processor
Drop Number
Descriptive text
The output page contains the following data on each line for Events and SOEs:
Number of pickups
Number of dropouts
Unit Name
Point name for SOEs and Events
Descriptive text
It may be printed and/or saved as a text file from the browser window. To return to
the query form, use the Back button on the web browser toolbar.
Historical Alarm and Event Report by Day

The Historical Alarm and Event data is stored in a separate file for each day and data
type. The day is based on UTC time, not Site Local time, and begins and ends at
00:00:00. If no data type is collected on a given day, then no file for that data type is
created. The file names have the following format:
YYYYMMDD_***.DO3 where:
YYYY= Year in four digit format
MM
= Month in two digit format
DD
= Day of month in a two digit format
*** stands for one of the following:
ALM Process Alarms
EVT Event
SOE Sequence of Events
.D03 is the extension of the files used to store exception data.
To view the contents of a file
From the Historian Functions menu, click on Alarm, Event, and SOE
Files. The Historical Data Files at HSTLAB1 displays. Two modes of
listing are available, List Mode and Table Mode.
Exception Data File Shown in Table View
The table, shown above, lists each file stored on the disk. Three viewing options are
available as follows:
To View The file data is presented on the browser window with its data
formatted similar to the Exception Report described earlier. The data does not
have a header.
To Summarize The file data is presented in a Summary Report similar to

that previously described. The data has an abbreviated header.
To Download The user may download the file to a PC for storage.
Historical Cross Plot

The Historical Cross Plot references the values of two signal points against one
another. The function permits visual contrasting of operational data.
Historical Cross Plot Graph
Some examples of Cross Plots are as follows:
MW vs. MVAR to observe load and grid characteristics
MW vs. Ambient Temperature for a machine running at base load
Exhaust Temperature vs. Speed for a turbine startup
Vibration vs. Speed for a turbine startup.
The plot is generated in response to user inputs on the Modify Historical CrossPlot Form. The program features a Historical Cross Plot Predefined Forms
Page to preserve user configured templates for reuse.
Historical Cross Plot Predefined Forms Display

The Predefined Forms Display is used to store forms that serve as valuable templates
for convenient reuse in analyzing data, or for complete guides to data of interest
stored in the historical database. The Predefined Forms page serves as a place to :
Select a form
Create new forms
Manage existing forms.
Each entry consists of a Form Name, and the date/time the form was last used.
Historical Cross Plot Predefined Forms

To choose a Form
From the Historical Cross Plot Predefined Forms Page, choose a form
and click on its Form Name.
To delete one or more Forms
From the Forms Page, select the Mark Form For Deletion checkbox(s),
then select the Delete Selected Forms button at the bottom of the display.
Each form is initially listed in alphabetic order.
To change the order of the Forms
From the Predefined Forms display:

-
To display the forms in reverse alphabetic order, click on the Toggle Sort
Order hyperlink below the Form Name title.
To display the forms in order of last time used (oldest form at top of list),
click on the Sort By Form Date hyperlink below the Last Used Date
title.
To list forms starting with the newest form, click on the hyperlink again at
the top of the list.
To create a Historical Cross Plot Results display

1.
From the Historical Cross Plot Predefined Forms page, select a suitable
form. The form displays.
2.
Modify the selected Predefined Form as described below, and click the Draw
Plot button. The Historical Cross Plot Results displays.
Modify Historical Cross Plot Form

The Historical Cross Plot is used to lookup historical data on two variables over a
period of time, and plot one variable against the other. The program has a number of
options to allow the user to focus on specific data of interest. The Historical Cross
Plot Form provides user entry to a number of fields to both control the time range
and appearance of the plot, as well as preserve the query form for future reuse. The
form fields and their use are described here.
To access the Modify Historical Cross Plot Form
1.
2.
Single click the Cross Plot hyperlink, and the Modify Historical Cross
Plot Form displays.
Modify Historical Cross Plot Form
Modify Historical Cross Plot Form Field Descriptions

Form Name. The form name is used to identify predefined forms. Predefined forms
are used as templates with one or more fields filled in automatically. Any number of
predefined forms can be saved for future use.
A form name can be any combination of characters up to 40 characters long. Form
names are case insensitive, but are stored and displayed as they were last entered by
the user. Leading blanks are ignored on form names.
Query Time. This selection is used to identify the time base of the Start Time
parameter. It defaults to local time. UTC (Coordinated Universal Time) may be
selected for the plot. (See the Application Note Facts about UTC)
Start Time. The Start Time parameter determines the starting date and time for the
beginning (or end) of the Cross-Plot.
The syntax of the starting time is YYYY.MM.DD HH:MM:SS.sss, where:
YYYY is the year.
sss are the subseconds. Subseconds may be omitted.
For example, the start time 1997.07.31 12:00:00.0 is for a plot starting on 31st of
July, 1997, at 12 pm (midday).
Force Start Time to be Current Time. This checkbox is used to override the
Start Time parameter. It used to specify that the starting plot time will be the current
time at the instant the plot is requested. Note that this parameter is only useful when
the elapsed time is negative.
Elapsed Time. This parameter defines the direction and duration of the historical
data lookup. Hours, minutes, and seconds are normally used for this parameter, but
days may be optionally entered. Enter "+" for forward data searches or "-" for
backward data searches.
The syntax of the elapsed time string is ddd HH:MM:SS.sss, where:
ddd is the number of days. Days default to zero, and may be omitted.
For example, the elapsed time string: 1 01:00:00.0 is for a 25 hour plot.
Interval Sample Time. This parameter defines the amount of time between data
samples used to populate the Historical Cross Plot. For example, if a 24-hour plot is
requested, and this parameter is set to 6 minutes (10 samples per hour), then the
resulting plot will contain no more than 241 pairs of data values. Hours, minutes and
seconds are normally used for this parameter, but days may be optionally entered
(only for very long duration plots).
ddd are the number of days. Days default to zero, and may be omitted.
For example, the interval: 00:10:00.0 is for 10 minutes between successive data
samples.
X/Y Axis Point Names. Each axis requires the PI Database pointname to be
entered in this field. Point names are case insensitive, and may be up to 80 characters
long.
X/Y Axis Plotting Limits. These parameters define the upper and lower
engineering units for each axis. Suggested values for the low and high plotting limits
are the ZERO and SPAN values (respectively), as defined in the PI database.
(Suggested values for logic variables are -0.5 and +1.5 respectively.) Note that the
upper and lower plotting limits must be different from each other.
Output Options.
Check the Apply Grid on Plot box to enable grid lines along each tick on the
resulting cross plot.
Check the List Tabular Output box to itemize all data used to generate the
cross plot.
Check the Place Start Time Mark on Plot box results in a small circle
denoting the first pair of points plotted.
Draw Plot button. The Draw Plot button submits all plotting parameters to the
Historical Cross Plot program. All parameters are verified, and if they are correct,
the Historical Cross Plot Results displays, followed by the same form with all input
parameters listed.
If any parameters are incorrect, an error page is displayed informing the user. At this
point, select Back, modify the incorrect parameter on the form, and select Draw
Plot to resubmit the request.
Save Form button. The Save Form button saves all parameters on the current form
in the list of predefined forms. The Form Name parameter must be non-blank for
this function to complete successfully. Any number of predefined forms may be
saved for future use.
The form does not need to be completely filled out to be saved. Any parameter
which is not filled in shows up as blank when the form is selected from the list of
Predefined Forms.
Note If 100 forms are already defined, then the least recently used form (oldest
unused form) is replaced with the definition of this newest form.
If the Form Name already exists in the list, then that entry is updated with the latest
parameters.
Predefined Forms button. The Predefined Forms button presents a list of all
previously saved forms. A blank form is also selectable.
Reset button. The Reset button restores all parameters on the current form to their
initial values.
Help button. The Help button is used to display help on the use of this form.
Delete Form button. The Delete Form button is used to remove the current Form
Name from the list of predefined forms.
Error Pages. The Historical Cross Plot program attempts to validate all input
parameters. It checks to ensure that input timetags meet syntax checks, and that
variables are defined in the PI database. If any error is detected, an HTML page is
generated with a brief explanation of the error. If a syntax error occurs, the user may
hit the Back button on the browser, correct the entry on the form, and resubmit the
request.
Historical Cross Plot Results

The Historical Cross Plot Results page shows the following information :
Site Name
Start Time
End Time
Pointnames
Plot Graphic This is graph of the two signals plotted against one another. The
graph may appear empty if either the two points did not change in value over the
time range of the plot, or if the values were off the scale, or fell on an axis.
Tabular Display (optional) This is the data used to create the plot. It is very
useful for determining how to scale the plot and/or adjust the start time and
span. Four columns are used to display the data. The columns represented are:
Sample Number
Date & Time - this data is at one-second intervals.
X - Value
Y - Value
Historical Cross Plot Form - The form that was used to create the results is
provided so the user can make changes while still being able to view the
graphic.
A sample of the Historical Cross Plot Results page is shown at the beginning of this
section.
Historical Cross Plot Results Tabular Data PI Datalink
Event/Trigger Search
The Event Scanner function uses logic point information, stored in the historical
database, to search and identify specific situations in the unit control, such as:
Start
Trip
Shutdown
This tool is very useful for identifying time ranges of interest for further examination
using graphical screens, or Alarm and Event Reports.
The output data is generated in response to user inputs on the Event/Trigger Query
Form. The program features a Predefined Forms Page to preserve configured query
templates for reuse. Modifying a Predefined Form is the most common method of
creating an Event/Trigger Results page.
Event/Trigger Query Predefined Forms Display

Predefined forms can be
conveniently reused in
searching for turbine events
stored in the historical
database
The Event/Trigger Query Predefined Forms display is used to store template forms.
The Predefined Forms page serves as a place to :
Select a form
Create new forms
Manage existing forms.
Event/Trigger Query Predefined Forms
Each form has a Mark Form For Deletion checkbox.

To delete one or more forms
1.
From the Predefined Forms display, select the Mark Form For Deletion
checkboxes.
2.
Click the Delete Selected Forms button at the bottom of the display. The
selected forms are deleted.
Each form is initially listed in alphabetic order.

To change the order of the forms
To display the forms in reverse alphabetic order, click on the Toggle Sort
Order hyperlink below the Form Name title.
Or, to display the forms in order of last time used (oldest form at top of list),
click on the Sort By Form Date hyperlink below the Last Used Date title.
Or, to list forms starting with the newest form at the top of the list, click again
on the hyperlink below the Last Used Date.
Event/Trigger Query form

To choose a Query Form
From the Event/Trigger Query Predefined Forms, choose a form, and

click on its Form Name. The Event/Trigger Query form displays.
The data comes from exception data stored in the files used in the exception report.
Event/Trigger Query Form
Form Name. The form name is used to identify predefined forms. Predefined forms
are used as templates with one or more fields filled in automatically. Any number of
predefined forms may be saved for future use. A form name can be any combination
of characters up to 40 characters long. Form names are case insensitive, but are
stored and displayed as they were last entered by the user. Leading blanks are
ignored on form names.
Starting Time. This parameter determines the starting date and time for the
beginning (or end) of the Event/Trigger search.
The syntax of the starting time is YYYY.MM.DD HH:MM:SS.sss, where:
YYYY is the year.
For example, the start time: 1997.07.31 12:00:00.0 is for a search to begin on 31st of
July, 1997 at 12 pm (midday).
Elapsed Time. This parameter defines the direction and duration of the historical
data lookup. Hours, minutes, and seconds are normally used for this parameter, but
days may be optionally entered. Enter "+" for forward data searches, or "-" for data
searches where the elapsed time is negative.
ddd is the number of days. Days default to zero, and may be omitted.
sss is the subseconds. Subseconds may be omitted.
For example, the elapsed time: 1 01:00:00.0 is for a 25 hour search.

Query/Report Times. The Time Base selection identifies the time base of the
Start Time parameter. It defaults to local time. UTC (Coordinated Universal Time)
may be selected for the search. (See the Application Note Facts about UTC)
Condition #1 & 2. If the conditions, specified by the fields associated by either
Conditions, are met one or more times within in specified time range, then the results
page will contain entries showing the condition data and timetags of the occurrences.
Careful selection of the entries in the condition fields filters out the timetags of
special events from the large quantities of historical data. Each condition has two
criteria: Trigger and Level.
Trigger. The Trigger Fields tell the Historian to search the digital exception
database for an edge condition in the specified point. An edge condition is a
transition in the logic point value, either from a logic zero (0) to a logic one (1), or
logic one (1) to a logic zero (0). The point must be defined as an Event or SOE
(Contact Input).
Each Trigger has four fields associated with it:
Pickup A Pickup is a point value transition from logic zero (0) to logic one (1).
Dropout Dropout is a point value transition from logic one (1) to logic zero (0).
Unit Name The unit name is selectable from a drop down list.
Pointname The pointname is the name of a logic point in the unit control that
is defined as an Event or SOE (Contact Input).
Level. The Level Fields are optional. They specify a logic point and level, either
Low, logic zero (0), or High, logic one (1). The points level must be at the specified
Level when the Trigger point transition is found in order to return a valid entry on
the Results page.
The conditions specified in the level field are in addition to those in the Trigger
Fields.
Level The level of the point value can be specified as Low, logic zero (0), or
High, logic one (1).
Unit Name The unit name is entered by the user. An asterisk character, *, in
this field causes the field to default to the Trigger Unit ID.
Pointname The pointname is the name of a logic point in the unit control that
is defined in the PI historical database, usually an Event or SOE (Contact Input).
Note The Unit ID and Pointname fields are combined to create a PI Pointname.
These pointnames are usually in the format UU:Pointname.
Submit button. The Submit button submits all form parameters to the Event/Trigger
Search program. All parameters are verified and if they are correct, a page showing
the requested Event/Trigger Results is displayed.
If any parameters are incorrect, an error page is displayed informing the user. At this
point , correct the form.
To correct the Form
1.
From the Event/Trigger Query form, select Back
2.
Modify the incorrect parameter on the form, and select Submit. The form is
resubmitted.
Save Form button. The Save Form button saves all parameters on the current form
in the list of predefined forms. The Form Name parameter must be non-blank for this
function to complete successfully. Any number of predefined forms can be saved for
future use.
The form does not need to be completely filled out to be saved. Any parameter
which is not filled in shows up as blank when the form is selected from the list of
Predefined Forms.
Note that if 100 forms are already defined, then the least recently used form (oldest
unused form) will be replaced with the definition of the newest form.
If the Form Name already exists in the list, then that entry will be updated with the
latest parameters.
Predefined Forms button. The Predefined Forms button presents a list of all
previously saved forms. A blank form is also selectable.
Reset button. The Reset button restores all parameters on the current form to their
initial values.
Delete Form button. The Delete Form button is used to remove the current Form
Name from the list of predefined forms. This button is used as a maintenance feature
to remove unwanted forms from the list of Predefined Forms.
Error Pages. The Event Triggered Search program attempts to validate all input
parameters. It checks to ensure that input timetags meet syntax checks, and that
variables are defined in the PI database. If any error is detected, an error page is
generated with a brief explanation of the error. If a syntax error occurs, the user may
hit the Back button on the browser; correct the entry on the form, and resubmit the
request.
Event/Trigger Query Results. The Event/Trigger Query Results page shows the
following information :
Start Time
End Time
Conditions Requested
Tabular Display of Results This section is blank if no data was found matching
the form inputs. The columns represented are as follows:
-
Time - The time represents the timetag of the specified Event Trigger. Use
this timetag in the Historical Alarm and Event Report, and PI ProcessBook,
to retrieve data associated with this event.
Edge - Pickup is +, Dropout is -
Unit
Trigger (Pointname)
State - High is 1, Low is 0
Level (PI Pointname)
(Trigger)
Event/Trigger Query Results
ARCWHO
ARCWHO is a utility program that provides a list of the nodes found on the
Historian's ARCNET Stagelink, or CSF. It is used to verify the status of
communications on either link.
To access the ARCWHO utility

1.
Functions web browser screen displays, presenting choices.
2.
Single click the ARCWHO - ARCNET Map of Live Nodes text. The
ARCWHO utility runs and ARCWHO.TXT displays.
How ARCWHO Works

The Mark V family of Turbine Controls communicates with the Historian using an
industry standard ARCNET connection. Each device on the ARCNET is given a
unique address. This address is used in the F:\CONFIG.DAT file to match units with
ARCNET addresses.
The ARCWHO utility program uses the ARCNET driver in the Historian to poll for
nodes on the ARCNET. All nodes present on the ARCNET are listed, it does not
matter what type of node it is (for example, turbine control, HMI, Historian).
Historian product software, HST, versions 1.4 and higher support communications
over CSF to Mark IV Turbine Controls. It generates a list of nodes found on the CSF
by sending a message to each node, and then looking at the status of the message. If
the message was successful it adds the address to the list of valid addresses.
If no networks are reported, it probably means that the ARCNET device driver has
not been started.
ARCWHO Output
The ARCWHO Output

The above example shows the results of running ARCWHO on a Historian with HST
product software version earlier than 1.4. In this example, the Historian was assigned
the ARCNET address 8A. There are 12 ARCNET nodes visible, with their addresses.
The Network Reconfiguration Count increments when a node on the ARCNET starts
up or shuts down. If this number is climbing rapidly, it indicates some type of
network trouble.
HST product software version 1.4 and higher shows the network name also.
The PI Point Data Base Browser

The PI Point Database Browser allows the user to view a brief summary of the points
configured in the PI database. Users may customize the report to search for specific
points, recently modified points, or all points. The engineering units and long name
associated with the points in the report can be displayed.
Accessing the Point Data Base Browser form
1.
Functions web browser screen displays presenting choices.
2.
From Historian Functions, click the Point Browser (PI Database) text.
The PI Point Data Base Browser - Select Options form displays. The
form is automatically filled in for the user, and is set up to display the list of all
points with their associated engineering units and long name.
PI Point Data Base Browser Form
To view the PI Data Base Report

1.
From the PI Point Data Base Select Options browser, modify the default
form fields as needed. This is described in the sections below.
2.
When the form is complete, click the Submit button. The requested PI Data
Base Report displays.
The following sections describe the entries in the PI Point Data Base Browser
Select Options display.
Selecting the Points
All points or specific points based on the pointname can be chosen. A wildcard string
such as T1:TN* is allowed.
Customizing the Modification Date. Many times, users need to review recent
modifications to the PI point database. A quick way to determine which points have
been modified is by using the Modification Date field.
The After radio button with a date creates an output report, showing only those
points modified on or after the entered date and time.
The Date is entered in the format YYYY.MM.DD HH:MM:SS, where:
YYYY is the year.
The default time is the current time. Fields after the day field are not required.
Selecting the Data Types. Users may wish to reduce the amount of information
on the output report. The Engineering Units and Long Names are selected by default.
The user may uncheck these boxes to delete them from the output. A shorter version
of the longname can be selected by checking the Short radio button. This reduces
the number of characters in the report.
Selecting the Display Type. The default report type is Text. By checking the
CSV radio button, the output format will be a Comma Separated Variable format
used for loading in Spreadsheet and Database applications.
PI Point Data Base Browser Report

The report lists the Site Name and the time of the report in the header. Also, any
error messages appear in the header.
The data is displayed in column format with the PI Point Source in the first column.
The second column is the PI point name, which is usually in the format
UU:POINTNAME. If the engineering units field was specified, this is next. If either
longname format was requested, it appears last.
PI Data Base Report

The CSV format display is used for loading the data into Spreadsheets and Database
applications.
To load the CSV file into a spreadsheet
1.
From the CSV format PI Data Base Report, select the menu item File.
2.
From the File drop down menu, choose Save As. Save the file with a *.txt
extension.
3.
From the Spreadsheet application, open the saved file. The file displays
correctly in the spreadsheet.
The following example shows a part of a report displayed in a CSV format.
Unit,Name,Units,Long Name
L,BA:ACTIVE.1,STATE
,"
9,BA:CONC.1,DEG. C
,"(20,20) (21,23) (10,40) (20,44)
9,BA:LEVEL.1,
,"(10,20) ( 7,20) (21,40) (10,40) (10,30) (5,10) (8,0)
L,BA:PHASE.1,STATE
,"
9,BA:TEMP.1,
,"(10,20) (7,20) (21,20) (9,49) (11,20) (4,10) (9,0)
R,CDEP158,
,"
R,CDM158,STATE
,"
R,CDT158,DEG. C
,"
1,DS:DSKMGR,
,"
C,pipe:sine,units
,"( sinusoid -50 )*2
C,pipe:sine2,pct
,"(sinusoid-50) * (sinusoid-50) /25
C,pipe:sine2t,pct
,"event=sinusoid,(sinusoid-50) * (sinusoid-50) /25
C,pipe:sine3,units
,"(pipe:sine2 * (sinusoid-50)/50)
C,pipe:sine4,pct
,"(pipe:sine2 ^ 2 ) /100
C,pipe:sine5,pct
,"(pipe:sine2*pipe:sine2*pipe:sine ) /(100*100)
R,SINUSOID,
,"
R,SINUSOIDU,
,"
2,T8:CBS5501AX,mils
,"
2,T8:CBS5501AY,mils
,"
2,T8:CBS5502AX,mils
,"
2,T8:CBS5502AY,mils
,"
2,T8:CBT5401A,deg F
,"
2,T8:CBT5401B,deg F
,"
2,T8:CBT5401C,deg F
,"
2,T8:CBT5401D,deg F
,"
2,T8:CBT5402A,deg F
,"
2,T8:CBT5402B,deg F
,"
2,T8:CBT5402C,deg F
,"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
PI Data Base report in CSV Format
HST Startup Log

The HST.LOG file is written every time the Historian Service is started. The
following example shows some warnings about multiple longname definitions for
some points. The file is a valuable tool for the quick analysis of Historian
configuration problems.
To view the Startup Log.
1.
Functions web browser displays, showing choices.
2.
Click the HST Startup Log text. The HST.LOG text file displays.
HST Startup Log, HST.LOG
Log Browser
The HST.LOG file is written every time the Historian Service is started. The
HST1.LOG file is the log file from the previous Historian Service start up. The
example screen below shows warnings about multiple longname definitions for some
points.
Opening the Log Browser
1.
2.
Single click the Log Browser text. A page displays, containing a listing of the
files in the G:\LOG directory. This appears as /~hstlog/.
~hstlog display
The CHECKCRC.LOG file is written automatically when a user runs the

CHECKCRC utility program on the Historian. This file may or may not be current.
The CHECKCRC utility is not available on the Historian Menu.
CHECKCRC.LOG
Other Historian programs can write log files if they have something to report. These
files may or may not be current. Any current files written by other Historian
programs, as part of a Historian start up or operation, should be investigated. It is not
possible to delete these files from the Historian Menu.
PI-DataLink
This section is a brief overview of how to use PI-DataLink with the Historian. Refer
to OSIs PI-DataLink manual for detailed information regarding the capabilities.
PI-DataLink is a product of
OSI Software, Inc.
PI-DataLink provides a link between Excel or Lotus 1-2-3 spreadsheets and the data
in PI Data Archive. Two PI-DataLink licenses are supplied with each Historian.
They can be used on any PC that has either Excel or Lotus 1-2-3, and an Ethernet
connection to the Historian. A license can be used on the Historian if one of the
spreadsheet packages is also loaded.
PI-DataLink consists of two modules, an Add-In for Excel, and an Add-In for Lotus
1-2-3.
PI-DataLink provides functions for retrieving the following data:
The Current Value for a tag.
A tags value at a specific time.
A tags attributes.
Sampled Data evenly spaced over time.
Sampled Data while an expression is true.
Compressed Data only the values actually saved in the PI archive.
Compressed Data while an expression is true.
Sampled Data synchronized with an array of timestamps.
Over a given period, a tags Total value, Minimum value, Maximum value,
Average value, Mean value, Range of values, and the tags Standard Deviation.
Refer to the Maintenance Guide for installing PI-DataLink and configuring its use in
Excel. Refer to the PI-DataLink manual for details.
Chapter 4 Maintenance Guide
Introduction
This chapter is a maintenance guide describing how to configure the Historian for the
various data collection, storage, and display functions. It includes details of
configuration for acquiring data over Modbus, use of the Data Dump, and for
operation with the Mark IV, Mark V, Mark V LM, and Mark VI turbine controllers.
Architecture
The historian has two basic functions. The first is to collect a set of data from one or
more data sources and save it in the historical archive, and the second is to retrieve
that data for presentation and analysis.
HST Subsystem
Application
Layer
Application
Program
Application
Program
Data
Layer
Digital
Exception
Files
Communication
Layer
Alarm
Queue(s)
Front End
Communicat
- ions
Program
Data
Dictionary
Front End
Communicat
-ions
Program
PI Subsystem
PI
ProcessBook
Clients
PI
DataLink
Clients
PI
Snapshot
PI
Archive
Interface
Interface
Application
Layer
Data
Layer
PI Archive
Files
Communication
Layer
Historian Software Architecture
Chapter 4 Maintenance Guide 4-1
Basic Data Flow

Both the HST subsystem and the OSI PI subsystem software are organized into three
basic layers, the Communication Layer, the Data Layer, and the Application Layer.
Communication Layer
The Historian refers to these
programs as the Front-End
Communication programs.
The OSI PI software refers to
these programs as the
Interface programs.
This layer consists of a series of programs that communicate with specific devices to
obtain point value information. The communication layer supports many different
devices and many different protocols. This is usually accomplished by having
different programs available for the communication layer, and launching the
programs that are required for the mix of devices at any one site. The
communication layer programs then collect the information from the device, and
supply the data to the Data Layer.
Data Layer
The Data Layer typically consists of a series of data structures to hold the information
collected by the Communication Layer. The data format is standardized. By the time
the data arrives at the Data Layer, it no longer matters where the data came from or
how it was collected. This normalization of the data allows Application Layer
programs to access data without needing to know any device specific information.
The configuration information defining the available points is often considered part of
the Data Layer as well.
The Historian Data Layer uses the Data Dictionary for real time values and the
Alarm Queues for alarm information. Point configuration information is also
maintained in the Data Dictionary.
The OSI PI Data Layer uses the PI Snapshot table for real time values. Point
configuration information is predominantly held in the PIPoints table. The PI
Archives are often considered part of the Data Layer, which is where the
historical point information is stored.
Application Layer
The Application Layer consists of many different application programs that use the
data from the Data Layer. Users run these programs to provide information (real time
and historic), or to analyze plant information. In some cases these applications
retrieve data and make it available to other systems, such as Microsoft Excel
interfaces or WEB interfaces.
The Historian provides most of its application information through WEB pages.
This information includes limited special purpose plotting displays (such as
Cross Plot) as well as the high-speed alarm and event information.
The OSI Application layer uses the PI-ProcessBook client, which is the main
historical data viewing interface. Also supplied is the PI-DataLink interface,
which exports data into Excel Spreadsheets.
Communication Layer Details

Data is collected from devices using one or more of the Historian front end
communication programs. Front end programs use different protocols to talk to
devices, and each have slightly different capabilities
4-2 Chapter 4 Maintenance Guide
The following table displays the various front end communications programs, and
summarizes the type of information collected from the device.
Protocols
Controller
Data Layer
Storage
Alarms/
Events
Time
Tag
Time
Sync
Predefined Data Dump
Mark IV
Yes
No
Either
No
MODBUS over RS-232C
Mark IV, Foreign
Yes
No
Historian
No
MSP over CSF
Mark IV
Yes
Yes
Device
Low
MSP over RS-232C
Mark IV
Yes
Yes
Device
Low
BMS/MSP over ARCNET
Mark V, Mark V LM
Yes
Yes
Device
High
EGD/ALM over Ethernet
Mark VI, PLC
Alarms
Yes
Device
High
MODBUS over Ethernet
HMI, Foreign
Yes
No
Historian
No
Communication Protocols and Capabilities
Details of the Columns in the table are as follows:

Protocol is the name of the protocol or interface.
Controller is the type that can support this interface.
Data Layer indicates whether the information retrieved from the device is stored
in the Data Layer.
Alarms/Events indicates whether the interface supports digital exception report
messages.
Time Tag indicates the source of the timetag associated with the data value.
Time Sync indicates whether this interface supports a Time Sync or Time Set
function, and whether it is low or high resolution time.
Details of the Protocol terms describing the communication programs are:
ALM:
Alarm Protocol used for delivering Digital Exception Messages
including alarms, events, and SOE messages.
ARCNET: An industry standard token passing communication network typically
using COAX cabling, running at 2.5 MHz.
BMS:
Basic Message Service, a communication protocol.
CSF:
Control System Freeway, a high-speed token-passing communication
network typically using TWINAX cabling, running at 2.3 MHz.
Digital Exception Messages: A communication scheme where a device sends
reports of changes in digital points (alarms, events, or SOEs).
EGD:
Ethernet Global Data, a protocol used for delivering periodic data.
Ethernet: An industry standard high speed CSMA/CD communication network,

typically using COAX or Twisted Pair cabling.
MSP:
Message Service Protocol, a communication protocol.
RDS:
Reliable Datagram Service, a protocol used for delivering Digital
Exception Messages.
RS-232C: An industry standard serial communication interface.
SOE:
Sequence of Events, a category of Digital Exception Messages that
notify upon change of state of a contact input. These are typically scanned much
faster than the controllers base frame rate.
Front End Programs

A device supporting a Predefined Data Dump interface provides one or more RS232C links over which it sends periodic data lists. Part of the device configuration is
the specification of which points are to be sent out on the lists, and how often the lists
are to be sent. Multiple lists are often required, as each list is limited to about 256
bytes. A typical interface has one or more lists defined, with each list being sent once
per second.
The Historian is told the contents of the data lists, since only the actual raw data is
provided over the link. When the Historian receives a list, it extracts the data from the
list and places the values in the Data Layer, specifically in the Data Dictionary. Some
controllers support sending the controllers time in the list. If a list is specified with
the time, the Historian uses that time. If no time was supplied, it uses the Historians
time at the time the list was received as the data timetag .
MODBUS over RS-232C

A device supporting a Modbus over RS-232C interface provides one or more RS232C links over which it responds to requests for current data. Part of the
configuration of the device is mapping the internal signal values to Modbus register
numbers.
The historian is told which Modbus registers to fetch, which signals are stored in each
register, and what scaling is applied to the raw Modbus value to convert it to
engineering units. The Historian acts as a Modbus Master by requesting the register
values from the device. When the reply is received, it extracts the point values from
the message and puts them in the Data Layer, specifically the Data Dictionary. The
Modbus interface does not support a timetag, so the time associated with the value is
the time the Historian received the reply from the device.
MSP over CSF

A device supporting an MSP over CSF interface provides a high speed
communications interface for both requested periodic data messages and digital
exception report messages. The list of points to be periodically fetched is sent down
from the device requesting the information, so no lists have to be setup in advance for
periodic data. Because of this, any point in the control can be fetched without having
to reprogram the control. Digital Exception Messages are used to report the change in
state of alarms, events, and in some controllers, SOE signals. Some controllers
support downloading the list of digital signals to be scanned, and some require that
list as part of the controller configuration.
The Historian looks to see what signals are requested for historical storage, creates the
list of signals to be fetched, and downloads that list to the controller with a request for
one second updates. The controller returns the requested signal list each second.
When the Historian receives the periodic replies, it extracts the point values from the
message and places them in the Data Layer, specifically the Data Dictionary. All
MSP messages include a time tag from the controller, so this is the time tag used.
The Historian signs up to receive the controllers digital exception messages. Once
signed up, whenever an alarm, event, or SOE occurs, the controller sends a message
to the Historian indicating which point changed state, along with a high resolution
timetag. This information is used to update the Alarm Queues, and is fed into the
digital exception history files. The high resolution timetag from the unit follows the
data.
MSP over RS-232C

A device supporting an MSP over RS-232C interface provides one or more RS-232C
links over which MSP messages are exchanged. Other than the fact that the messages
are sent over a much slower point-to-point network, the functionality of MSP over
RS-232C is the same as the functionality of MSP over CSF.
BMS/MSP over ARCNET

A device supporting a BMS/MSP over ARCNET interface provides a high speed
communications interface supporting both requested periodic data messages and
digital exception report messages. The list of points to be periodically fetched is sent
down from the device requesting the information. No lists have to be setup in advance
for periodic data. Because of this, any point in the controller can be fetched without
having to reprogram the controller. Digital Exception Messages are used to report the
change in state of alarms, events, and in some controllers, SOE signals. Defining the
list of events and SOEs to be scanned is part of the unit configuration process.
The BMS protocol is used for periodic data; the MSP protocol is used for Digital
Exception Messages.
The Historian looks to see what signals are requested for historical storage, creates the
list of signals to be fetched, and downloads that list to the controller with a request for
one second updates. The controller then returns the requested signal list each second.
When the Historian receives the periodic replies, it extracts the point values from the
message and places them in the Data Layer, specifically the Data Dictionary. All of
these messages include a time tag from the controller, so this is the time tag used.
signed up, whenever an alarm, event, or SOE occurs the controller sends a message to
the Historian indicating what point changed state, along with a high resolution
timetag. This information is used to update the Alarm Queues, and is fed into the
digital exception history files. The high resolution timetag from the unit follows the
data.

A device supporting an EGD/ALM over Ethernet interface provides a high speed
communications interface supporting both periodic published data messages and
digital exception report messages. The list of points that is published (sent in a
message) along with the rate at which the data is published is part of the devices
configuration. One or more lists can be sent, with historian based lists typically being
produced once per second. Digital Exception Messages report the change in state of
alarm and SOE signals. The list of SOEs to be scanned is part of the unit
configuration process.
The EGD protocol is used for periodic data; the ALM protocol is used for the Digital
Exception Messages.
The Historian treats data published through EGD differently than the other periodic
data protocols by sending the data directly to the historical subsystem rather than
through the Data Dictionary. This is due in part to the fact that the Data Dictionary is
used for all other devices as the central means of keeping track of the signals in the
controller. EGD based devices have another method of keeping track of the signals,
so there is no Data Dictionary being built already for other reasons. (In other words,
all the other controllers already have a Data Dictionary built for them, so the
Historian simply uses it. The EGD based controllers do not already have a Data
Dictionary built for them). EGD supports a device-supplied high resolution timetag,
and this is passed along with the data into the historical data subsystem.
signed up, whenever an alarm or SOE occurs the controller sends a message to the
Historian indicating what point changed state, along with a high resolution timetag.
This information is used to update the Alarm Queues, and is fed into the digital
exception history files. The high resolution timetag from the unit follows the data.
Modbus over Ethernet

Devices that support a Modbus over Ethernet interface provide the same basic
information as Modbus over RS-232C, with the exception that the messages are
exchanged over an Ethernet link instead of an RS-232C link. This scheme is most
often used to increase the bandwidth between the two devices, although it can be used
to support multiple Modbus masters communicating with multiple Modbus slaves
over a single communication network. The limitations on the data are the same as are
listed in the Modbus over RS-232C section.
Data Layer
Data collected from the Communication Front End programs is typically placed in
the Data Layer, where application programs can get it without needing to know the
special protocols for talking to the devices directly. There are two Data Layers in the
Historian, one from the Historian Service and one from PI.
For the Historian

This service consists of two major pieces - the Data Dictionary and the Alarm
Queues. The alarm information history is also forwarded to a set of disk files.
The Data Dictionary is a data structure that contains the configuration information
required by the front end programs to collect the signals, and also the time and value
last received from the device. Combining the configuration information and the real
time database allows application programs to make one fetch of information and
retrieve all the information required to display the point, including its current value
and scaling information. The Data Dictionary is a memory resident data structure
created when the Historian service is started. The information to create the Data
Dictionary is found in the F:\CONFIG.DAT file, which points the Historian service to
the directories containing the individual unit configuration information.
The Alarm Queue holds the alarm information collected from each device. The
turbine control defines the contents of the alarm queue information, and the Historian
simply creates a single queue that is the union of all of the controllers queues. (The
Historian does not manufacture any alarms on its own.)
The Digital Exception History Files hold the information in the Digital Exception
messages received from each device. This information includes the point identifier,
the new state, and a high resolution timetag for the state transition. This information is
collected into one file per message type per day, and these files are stored in a
historical data directory as the *.D03 files. The file names represent the UTC date of
the information within the file, along with the type of digital information (Alarm,
Event, or SOE) stored within the file.
For the PI Software

The data layer for the PI software consists of four major pieces. (Please consult the
documentation that comes with the PI Data Archive product for more detailed
information - the information here is an overview summary only.)
PI Configuration is done through the definition of data tables. These tables define
the configuration of the points (or Tags) that are to be maintained by PI, and includes
information on how the points are to be collected, how they are to be stored, and how
they are to be displayed upon retrieval. The PICONFIG program is used to read and
write these tables, thereby defining the PI configuration.
The PI Snapshot is the real time database that contains the last piece of information
retrieved from the device. It can be accessed like any other table using PICONFIG,
but typically programs use the PI API (Application Program Interface) routines to
read and write the current values. All real time data entered into PI is entered through
the PI Snapshot database.
The PI Archives are the historical data files used to save historical data. Data is
entered into these archives when PI detects that data in the Snapshot meets the
requirements for being saved in historical data. These requirements are based partly
upon configuration (should this point be archived or not), and partly on the data itself
(did it meet the definition of a significant change). Data that is to be saved is written
into the current archive file in a highly compressed format.
The PI Archive Files contain the PI historical data. To prevent the archive files
growing to take up the entire disk, the archive files are created in advance as a set of
fixed sized files (GE typically uses 32 MB archive files). Once the archive files have
been created, PI uses an archive file until it fills, then switches to the next file in a
round-robin scheme. Each archive file has a Start Time and an End Time, which
cannot overlap the Start and End Times of any other archive file. Depending upon the
rate information is flowing into the historical archives, these archive files typically
last from a few days to a few weeks. The total amount of time that can be maintained
on-line is limited mainly by the size of the hard drive. The historian is usually
configured to hold a years worth of typical data.
Application Layer
The Application Layer includes the programs that retrieve and display the historical
data. Many different methods are used to access the historical data.
WEB Page Interface

Internet Explorer comes with
Windows NT
The GE Historian subsystem exposes its data as a set of WEB pages that can be
viewed from the Historian, from an HMI, or from any computer running a WEB
Browser connected to the Historian. The connection can be through a local network,
or via a dial-up phone line. The WEB interface presents a menu of options that are
available, including the following:
Alarm and Event Report: This provides either a summary or a detailed list of
the alarms and events that occurred between a user supplied start and end time.
Alarm, Event, and SOE Files: This provides a summary or a detailed list of the
contents of a Digital Exception History file. This is often used for remote
summaries of a days operation.
Cross Plot: This provides a simple plot of one point versus another over a user
specified time range. The result is normally a graph on a WEB page, but the raw
data that made the plot can also be retrieved for further analysis.
Event Scanner: This provides a scheme whereby the Digital Exception History
files can be scanned for occurrences of defined conditions, generating a list of
when certain actions took place. (For example: Scanning for the breaker opening
when no Shutdown was in progress would result in a list of the unit breaker
trips.)
Diagnostic and Configuration Information: There are various menu options
available for diagnostics and retrieving configuration information. This
information is most useful when using the Historian for remote debugging.
Information such as the health of the communications networks and the Historian
configuration can be obtained. Log files generated by the Historian during its
startup are also available.
PI-ProcessBook Client
PI-ProcessBook is designed
to display data, not to issue
process commands.
The PI-ProcessBook client package is the main method for displaying the historical
analog data saved in the PI Archives. It is well suited for plotting and graphing data
from the PI Archives, and it can even show real time information from the PI
Snapshot database. The PI-ProcessBook client package can be run from the
Historian, or it can be run from another computer connected to the Historian, either
through a local network, or via a dial-up phone line.
Note The PI-ProcessBook client is licensed software; it is illegal to load it on a PC

without first obtaining a valid license.
PI-DataLink Client
The PI-ProcessBook client package provides a method to retrieve data from the PI
Archives and use it to populate a Microsoft Excel spreadsheet. This data can then be
analyzed using any function available in Excel. As with the PI-ProcessBook client,
this client can be run on the Historian, or on other computers that have a networked
connection to the Historian.
Note The PI-DataLink client is licensed software; it is illegal to load it on a PC
without first obtaining a valid license.
System Management
Effective management of the Historian requires that the system manager understand
the system architecture and data flow. In addition, the system manager must be able to
perform the following tasks.
Manage accounts
Set time zone, date, and time
Start and stop the Historian software
Start and stop the PI software
Shutdown and reboot the Historian
Backup and restore files to and from tape
Update the unit configuration
Update the PI configuration
Manage the PI system
Refer to the PI Data Archive manual for suggested system management strategies for
the PI system.
Historian Accounts
The Historian has three separate User accounts, named oper, maint, and
Administrator. These accounts are discussed below. The User accounts are set up to
provide three levels of system privilege.
oper Account
The oper account has the lowest privilege level, and is usually for the operators for
viewing historical data. The oper account is a member of the Users group. The User
Name for the oper account is oper. There is no as-shipped password for the oper
account; it should be left blank.
maint Account
The maint account is used to update the F: drive configuration and to modify
historical data collection. It can also be used for viewing historical data. The maint
account is a member of the Maintenance, Users, and Power Users groups. The User
Name for the maint account is maint, and the as-shipped password for the maint
account is maint.
Administrator Account
The Administrator account has the highest privilege and is used to alter the system
configuration. Only persons experienced with Windows NT Operating System, OSIs
PI Data Archive, and the Historian software should access the Administrator account.
It can also be used to update the F: drive configuration, and to modify historical data
collection, along with viewing historical data. The User Name for the Administrator
account is Administrator, and the as-shipped password is either Administrator or
gepgc.
Accessing an Account
To access an account
1.
From the Begin Logon window, press the three keys, Ctrl+Alt+Delete, all at
once. (If a screen saver is displayed, move the mouse to stop it). The GE License
Agreement Notice is presented.
2.
After reading the legal notice, press the Enter key, or use the pointer device and
click on the OK button to continue. The Logon Information window displays.
3.
In the Logon Information window, enter the accounts User Name and
Password.
4.
Along the bottom of this window are four buttons. Click on the OK button to
complete the logon.
To exit the log on, click on the Cancel button.
For information on how to log on, click on the Help button.
To stop the system prior to powering down the computer, click on the Shut
Down button.
Logging Out of an Account

The user can log out of the current account in order to log on to another account, or to
leave the Historian in a secure mode. Logging out of an account does not stop the
collection of historical data.
To Log out of an Account
1.
Click on Start, then Shutdown. The Shut Down Windows dialog box
displays.
2.
Select Close all programs and log on as a different user?
3.
Click on Yes. The user is logged out.
Modifying an Accounts Attributes

The Windows NT utility User Manager allows the Administrator to modify an
accounts attributes such as its password or its user rights.
To access the User Manager
Click on Start, then Programs, then Administrative Tools (Common),

then User Manager. The User Manager displays.
To modify the properties of an account.

1. From the User Manager, highlight the Username
2.
Click on User , then Properties,

Or, double click on the Username. The User Properties window displays.
The password can be changed for an account by entering a new one in the Password
and Confirm Password fields. Passwords in Windows NT are case sensitive. If the
password is changed to Orange, then entering orange for the password at the
Logon Information window will not work. The user must enter Orange, with an
upper case O, for the password.
The customer should follow standard NT security procedures, and issue a new
password for the Administrator account.
Passwords should be difficult for others to decipher but easily recallable by the
customer. The customer must keep track of the administrator account(s) password(s).
As shipped, only the Administrator account can change the password for any other
account.
Each account is a member of at least one group.
Viewing Group Membership

To view the Group Membership list
In the User Properties window, click on the Groups button. The Group
Memberships window displays.
Group Membership Window for the Administrator Account
The Administrator account is a member of the Administrators group. The maint

account is a member of the Users, Maintenance, and Power Users groups. The oper
account is a member of the Users group. The table displays the User Rights assigned
to each Group used by the three accounts.
As-shipped Assignment of User Rights to Groups
User Rights
Access this computer from the network
Backup files and directories
Change the system time
Force a shutdown from a remote system
Load and unload device drivers
Log on locally
Manage audit and security log
Restore files and directories
Shutdown the System
Take ownership of files or other objects
User Groups
Administrators
X
X
X
X
X
X
X
X
X
X
Maintenance
Power Users
X
Users
X
X
X
Modify User Rights

The user rights assigned to a group can be modified by the Administrator account
using the User Manager. To add the ability for anyone logged onto the maint account
to be able to backup files and directories, grant that user right to the Maintenance
Group. Since the maint account is a member of the Maintenance Group, it inherits
that right the next time someone logs onto the maint account.
The following is an example, not a recommendation.
To modify the User Rights
1.
From the User Manager, click on Policies , then User Rights. The User
Rights Policy window displays.
2.
From the Right drop down box, select the Right to modify.
3.
Click on the Add button. The Add Users and Groups window displays.
4.
From the Add Users and Groups display, highlight the Group to add.
5.
Click on the Add button. The Group is added.
Add Users and Groups Window with Group Added

6.
Click on OK to accept the addition. The User Rights Policy window displays.
User Rights Policy Window with Right Granted to Maintenance Group

7.
Click on OK to accept the change. The User Manager window displays.
8.
From the User Manager utility, click on User, then Exit. The User Manager
is exited.
Maintenance group members now have the right to backup files and directories.
Setting Time Zone, Date, and Time

Refer to Facts about UTC in
the Application Notes
chapter.
Windows NT uses UTC time as its time base, and determines local time as a
correction to UTC time. By changing the Time Zone, the user changes the correction
to UTC. By changing the Date or Time the user changes the time base that Windows
NT believes to be UTC time.
The PI subsystem in the Historian is sensitive to UTC time moving backwards. The
PI subsystem uses a compression algorithm that requires data be entered in increasing
UTC time order. When data is entered into the PI subsystem with an UTC timetag
earlier than the last value entered, PI attempts to save the data in the primary archive
without compression. This is called backfilling data. Long periods of backfilling data
degrade system performance and use valuable archive space since no compression
can occur. In addition, backfilled data cannot span multiple archives. So, if the
primary archive fills up, data collection slows and stops.
Moving UTC time back can render the Historian inoperable.
If the Historians current time zone, for example (GMT-05:00) Eastern Time (US &
Canada), is changed to a time zone three hours earlier, for example (GMT-08:00)
Pacific Time (US & Canada); Tijuana, the PI subsystem does not go into backfill
mode since only the correction to UTC time has changed.
If UTC time is moved back from 4:00 P.M. to 1:00 P.M., the PI subsystem will go
into backfill for all data collected during that three-hour period.
When changing the time on a Historian, change the time zone first, then adjust the
date and time as necessary.
To set the Windows NT Time Zone, Date, and Time.
1.
Log on to either the maint account, or the Administrator account.
2.
Stop the Historian service, HST.
3.
Stop the PI services.
4.
Open the Control Panel applet, Date/Time, and click on the Time Zone tab.
Use the drop down window to select the correct time zone.
If the Automatically adjust clock for daylight savings time option is enabled,
and the Historian should adjust for daylight savings time, select this box (a
check mark displays).
If either the Time Zone or the Automatically adjust clock for daylight savings
time option is changed, click on the Apply button to enable the change.
5.
Click on the Date & Time tab, and make any necessary adjustments to the date
and the time.
6.
Click on the Apply button to enable the changes. Changes to either the Date or
the Time are rarely required.
Note When the time changes from Daylight Savings Time back to Daylight Standard
Time, the PI subsystem does not go into backfill mode because UTC time has not
changed, only the correction to UTC time has changed.
If either the Time Zone or the Automatically adjust clock for daylight savings time
option is changed, a new F:\TIMEZONE.DAT should be created. Refer to Historian
Configuration for information on creating a TIMEZONE.DAT.
Starting/Stopping Historian Software

The Historian service, HST is set for automatic startup when the Historian boots up.
However, sometimes the Historian service must be manually stopped and started,
such as if the F:\UNITn directory was updated from the HMI/, or if the PI
configuration was modified. The startup/shutdown of the Historian service can be
done from either the Administrator or maint account.
Starting the Historian Service

There are two methods to start the Historian service. Either method is equally
effective.
Starting the HST service using the Services applet
1.
Click on Start , then Settings, then Control Panel
2.
From Control Panel, double click on Services. The Services dialog box
displays.
3.
Locate and highlight the HST (Historian) service
4.
Click on Start. The HST Service starts.
5.
Click on Close.
Starting the HST service from a Command Prompt

1.
Click on Start, then Programs, then Command Prompt
2. From the Command Prompt, type:

net start hst
Press Enter. The HST Service starts.
Stopping the Historian Service

There are various reasons for shutting down the Historian software, such as service
requirements to the hardware or software, or preparing for a system backup. The
following two methods describe how to stop the Historian service. Both methods are
equally effective.
Stopping the HST service using the Services applet
1.
Click on Start, then Settings, then Control Panel
2.
From Control Panel, double click on Services
3.
Locate and highlight the HST (Historian) service
4.
Click on Stop. A Prompt dialog box displays.
5.
Click on Yes. The HST Services stops.
6.
Click on Close.
Stopping the HST service from a Command Prompt

1.
2.
From Command Prompt, type:

net stop hst
Press Enter. The HST service stops.

The procedure described above stops the Historian software. However, the Windows
NT operating system continues to function. The PI Services, unless previously
stopped, continues to run.
Starting/Stopping PI Software
The PI services are set for automatic startup when the Historian boots up. There are
rare occasions, however, when the PI services need to be manually stopped and
started. This can be done from either the Administrator or Maint account.
Starting the PI Services

Since there are multiple PI services that have to start and stop in a particular order, it
is recommended that the batch files pisrvstart.bat and pisrvstop.bat be used to start
and stop the PI services.
To start the PI Services from a Command Prompt
1.
2.

cd /d c:\pi\adm
Press Enter
pisrvstart
Press Enter. The PI Services start.
Stopping the PI Services

There are various reasons for shutting down the PI software, such as service
requirements to the hardware or software, or preparing for a system backup. The
following method describes how to stop the PI services.
To stop the PI services from a Command Prompt
1.
2.

cd /d c:\pi\adm
Press Enter
pisrvstop
Press Enter. The PI Services stop.

This procedure stops the PI software. However, the Windows NT operating system
continues to function. Unless previously stopped, the Historian software continues to
run but will not store data in the PI archives.
Rebooting the Historian

There are times when the Historian needs to be rebooted, such as after a software
update, or after a system backup. Rebooting is the process of shutting down all
running software, shutting down the operating system, and then automatically
restarting the operating system and services set for automatic startup, in an orderly
fashion.
Before initiating a reboot, close all open windows. This is not a requirement but is a
precaution so that the user does not lose any modifications to in-progress works.
There are two ways to initiate a reboot of the Historian.
To reboot when the user is logged on to an account
1.
Click on Start, then Shutdown
2.
From the Shut Down Windows dialog box, select Restart the computer?,
and then click on Yes. The Historian reboots.
To reboot whether or not the user is logged onto an account

1.
Press the Ctrl + Alt + Del keys all at once.
2.
When the Logon Information window appears, click on the Shutdown

button. The Shutdown Computer window displays.
3.
Select Shutdown and Restart, and then click on OK. The Historian reboots.
Shutting Down the Historian

There are times when the Historian needs to be shut down, such as when the Historian
needs to be moved, or in preparation for a power outage. In the process of shutting
down the Historian, cached data is written to disk, services are stopped in an orderly
fashion, and the operating system is stopped in preparation for powering down.
Before initiating a shutdown, close all open windows. This is not a requirement but is
a precaution so that the user does not lose any modifications to in-progress works.
There are two ways to initiate a shutdown of the Historian.
To Shutdown the Historian if user is already logged onto an account
1. Click on Start, then Shutdown
2.
From the Shut Down Windows dialog box, select Shut down the
computer?, and then click on Yes. The services and operating system shuts
down.
3.
Power down the Historian when the power down message is displayed.
To Shutdown whether or not the user is logged onto an account

1.
Press the Ctrl + Alt + Del keys all at once. The Logon Information window
displays.
2.
From Logon Information, click on the Shutdown button. The Shutdown

Computer window displays.
3.
Choose Shutdown, and then click on OK. The services and operating system
shuts down.
4.
Power down the Historian when the power down message is displayed.
Saving and Restoring Files using NT Backup

The Microsoft Windows NT Backup utility allows the user to preserve the contents of
a disk in case the disk becomes corrupted and data files need to be reloaded. In
Windows NT, the disk directories are in a tree structure, with subdirectories created
under other directories. Most software that spans multiple directories makes one
master directory with subdirectories under it to hold the different types of files. NT
Backup can save and restore these tree files.
In Windows NT, the file name has an extension to identify the type of file. The format
is NAME.EXT, where NAME is the file name, and EXT is the file extension
(identifying the type of file). When the contents of a directory (or directory tree) are
saved to tape, the directory usually contains many files. NT Backup merges all the
files into one master file, called a backup set. When backing up files to a tape, the
user enters the Backup Set Information section that identifies the set on the tape.
When restoring files from the tape to the disk, the user selects the set by the
description in the Backup Set Information. This avoids entering the name of each and
every file. NT Backup also allows you to select individual files from the backup set
instead of restoring the entire backup set.
To start NT backup
From the Command Prompt, type:

ntbackup
Press Enter
or, click on Start, then Programs, then Administrative Tools, then
Backup. The Backup dialog box displays
Select Append or Replace
from the Backup Information
screen.
When NT Backup writes a backup set to the tape, you must select whether to append
the backup set to whatever is already on the tape, or to replace the contents on the
tape and place this backup set at the beginning.
Selecting Replace causes NT Backup to overwrite any data

that is already on the tape.
Backup accuracy is assured

by verifying the taped data.
Select Verify After Backup
window.
Select Verify After Restore
from the Restore Information
window.
Select Backup Local Registry
window.
Select Restore Local Registry
from the Restore Information
window.
For greater protection, NT Backup is usually run with a Verify pass. When saving
from disk to tape, NT Backup reads from the disk and writes to the tape on the first
pass. If a Verify pass is requested, it rewinds the tape and makes a second pass,
where it reads both the tape and the disk and compares the two. If there are any
mismatches, NT Backup warns that the tape is not correct. A Verify pass is also used
when loading from a tape back onto a disk. In the first pass it reads from the tape and
writes to the disk, and on the second pass it reads from both the disk and the tape and
then compares the results.
The Registry is a tree structure that NT uses for storing system configuration
information and settings. It resides on the system disk. When backing up the system
drive to be used if a full system recovery is required, it is important to also backup
the Registry. When restoring for a full system recovery, it is important to restore the
Registry.
Note To limit access to the files on the tape, select the Restrict Access To Owner Or
Administrator check box in the Backup Information window.
Data written to tape can be compressed to increase the storage capacity of the tape.
Select Hardware Compression from the Backup Information window.
When restoring files from tape you have the option of letting the restored files inherit
the permissions of the directory into which they are restored, or using the original file
permissions. Select Restore File Permissions in the Restore Information window to
restore file permissions as they exist on the tape.
Saving Disk Files to Tape

The most common method of backing up files is to back them up one directory tree at
a time, placing all the files in that directory tree into one backup set. In order to write
them to tape, you must be logged on an account that has read access to the files, and
the Backup files and directories User Right.
To make a backup tape of a Directory
1.
Start NT Backup
2.
Expand the Drives window, and double-click on the drive where the files are
located.
3.
Click on the directory to highlight it.
4.
Click on the Select menu, and then Check, to display a check in the check box
next to the directory name.
5.
Click on the Operations menu, and then Backup. The backup starts.
To select contiguous files for backup

1.
Click on the first filename, press the Shift key, and click on the last filename.
The contiguous files are selected.
2.
Click on the Select menu, and then Check. This puts a check mark in the check
box next to each filename.
3.
To select non-contiguous files for backup

1.
Click on a filename, press the Ctrl key, and then click on each filename.
2.
Click on the Select menu, and then Check. This puts a check in the check box
next to each filename.
3.
Restoring Files from a Tape

To list the backup sets on a tape
1.
Start NT Backup, and expand the Tapes window.
2.
Click on the Operations menu, and then on Catalog. The entire tape is
scanned for backup sets, and the results are displayed in the Tapes window. The
Drive Name, Set Number, Tape Name, Backup Type, Creation Date, Creation
Time, and Description are listed for each backup set on the tape.
To select the entire backup set for Restore without reviewing the
contents
1.
Highlight the backup set, then click on the Select menu.
2.
Click on Check. A check mark is placed in the check box next to the backup set
icon.
3.
Click on the Operations menu, and then click on Restore. The restore starts.
To review the directories and files in a backup set

1.
Double-click on the icon for that backup set. The contents of the backup set
display in a separate window.
2.
Select and highlight the files and directories to restore.
3.
Click on the Select menu, and then Check.
4.
Click on the Operations menu, then click on Restore. The restore starts.
To select contiguous files for restore

1.
Click on the first filename, press the Shift key, and then click on the last
filename. The contiguous files are selected.
2.
Click on the Select menu, then Check. A check is placed in the check box next
to each filename.
3.
Click on the Operations menu, then click on Restore. The restore starts.
To select non-contiguous files for backup

1.
Click on a filename, press the Ctrl key, and then click on each filename.
2.
Click on the Select menu, then Check. A check is placed in the check box next
to each filename.
3.
Click on the Operations menu, then Restore. The restore starts.
System Backup & Restore using NT Backup

NT Backup is a windows-based utility that can be started from Windows, or from a
command prompt.
The following example shows the Drives window expanded within the Backup
window. The C: drive is selected.
To backup the C: drive

1.
From the Backup display with the Drives window expanded, select the C:
drive
2.
Click on the Operations menu, and then on Backup,

Or, click on the Backup button. The Backup starts, and the Backup
Information window displays.
3.
From the Backup Information window, enter the appropriate information, and
click on the OK button.
To exit the backup, click on Cancel. For more detailed information about the
backup procedure, click on Help .
Restoring a Set
For imformation about
Restore, click on Help.
The following screen is the Tapes window expanded within the Backup window,
with Set 1 selected.
To restore Set 1
1.
From the Backup screen, click on the Operations menu, and then Restore.
Or, click on the Restore button. The Restore Information window displays.
2.
From the Restore Information window, enter the appropriate information,

then click on OK. The set is restored.
To exit the restore click on Cancel.
NT Backup with Set 1 Selected in Tapes Window
Restore Information Window
System Backup Procedure

Having a system backup tape
is good system management
practice.
You should always keep a copy of the entire system and history disks available on a
magnetic tape. If something were to happen to the system disk, a new system disk
could be created from the tape, or from the system gold disk and the tape.
Additionally, individual files and directories can be retrieved from the system
backup.
To backup the system disk (C:) and the history disk (D:).
1.
If the tape drive is not connected, shutdown Windows NT and power down the
Historian (refer to Shutting Down the Historian in this chapter), connect the tape
drive to the SCSI port, power it on, and power on the Historian.
2.
Place an unused or spare tape in the tape drive. Log on to the Administrator
account on the Historian.
3.
Click on Start, then Programs, then Command Prompt.
4.

net stop hst
Press Enter
cd /d c:\pi\adm
Press Enter
pisrvstop
Press Enter. Information about the shutdown of services displays.

5.
When the information is complete, click on Start, then Programs, then

Administrative Tools (Common), then Backup.
6.
If minimized, expand the Drives window.
7.
Click on the box next to the C: drive. An X displays in the box.
8.
Click on Operations , then Backup. The Backup Information dialog box

displays.
9.
Select Backup Local Register.
10. Select Verify After Backup.

11. Select Hardware Compression.
12. Select Replace.
13. Select Summary Only.
14. Type in the description:
Historian C: DRIVE <yyyymmdd>
15. Click OK. The Backup Status dialog box displays giving information about
the backup. The backup takes about twenty to thirty minutes.
16. When complete, check the summary for the "0 FILES WERE DIFFERENT"
message, and click OK.
17. Click on the box next to the D: drive. An X displays in the box.
18. Click on Operations, then Backup. The Backup Information dialog box
displays.
20. Select Hardware Compression.
21. Select Append (Do NOT select Replace).

23. Type in description:
Historian D: DRIVE <yyyymmdd>
24. Click OK. The Backup Status dialog box displays information about the
backup. The backup may take up to an hour.
25. When complete, check the summary for the "0 FILES WERE DIFFERENT"
message.
26. Click OK.
27. Click Operations, then Eject Tape.
28. On the tape, push the tab to write protect the tape, and label the tape
appropriately with dates.
System Restore Procedure

There are certain situations when a complete system restore is required, such as a
corrupt or failed disk drive. All critical situations require the user to contact GE for
instructions on disk/system recovery.
GE Industrial Systems,
Product Service Engineering
1501 Roanoke Blvd.
Salem, VA 24153-6492 USA
Phone +1 800-533-5885 or 540-378-3280
If emergency measures are required to get the system to a bootable state, then the user
should restore the system backup tape in order to get the Historian back to its last
known stable configuration. As well as for a full system recovery, the system backup
tape can be used to recover individual files or directories.
To restore the system disk backup (C:) and history disk backup (D:)
1.
If the tape drive is not connected, exit Windows NT and power down the
Historian (refer to Shutting Down the Historian in this chapter), connect the tape
drive to the SCSI port, power it on, and power on the Historian.
2.
Place the tape containing the backup of the C: and D: drives in the tape drive, and
log on to the Administrator account on the PC Historian.
3.
Click on Start, then on Programs, then Command Prompt
4.

net stop hst
Press Enter
cd /d c:\pi\adm
Press Enter
pisrvstop
Press Enter. Information about the shutdown of services displays on the screen.
5.
When the information is complete, click on Start, then Programs, then

Administrative Tools (Common), then Backup.
6.
If the Tapes window is minimized, expand it.
7.
Click on Operations, and then Catalog. A list of all backup sets on the tape
displays.
8.
Click on the box next to the backup set that has the C: drive system backup. An
X displays in the box.
9.
Click on Operations, then Restore. The Restore Information dialog box

displays.
10. Select Restore Local Register.

11. Select Restore File Permissions.
14. Click OK. The Restore Status dialog box displays information about the
restore.
15. When the information is complete, check the summary for the "0 FILES WERE
DIFFERENT" message
16. Click OK
17. Click on the box next to the backup set that has the D: drive backup. An X
displays in the box.
18. Click on Operations, then Restore. The Restore Information dialog box
displays.
19. Select Restore File Permissions
20. Select Verify After Restore
21. Select Summary Only
22. Click OK. The Restore Status dialog box displays information about the
restore.
23. When the information is complete, check the summary for the "0 FILES WERE
DIFFERENT" message.
24. Click OK.
25. Click Operations, then Eject Tape.
26. If the system drive was restored, then reboot the Historian (refer to Rebooting the
Historian in this chapter).
PI Configuration (Theory)
This section discusses the configuration of the PI Data Archives on the Historian.
Please refer to the PI Data Archive manual for more information on this subject.
PI Data Archives
The PI archives are created as fixed length files, and are initially void of any data. The
archives are located on the history disk in the pi_arch directory, typically
D:\PI_ARCH. The archives are named PIARCH.nnn, where nnn equals 001, 002, and
003 The typical archive size is 32 MB, and PI archives use roughly 75% of the
history disk. The total number of archives depends on the size of the history disk.
In order for PI to use an archive, it must be registered with the PI system. The
Historian comes with all available archives registered. To see a list of archives, run
the OSI supplied tool, piartool, with the parameter al as follows. This program is
located in the C:\PI\ADM directory.
To view a list of the registered archives
1.

cd /d c:\pi\adm
Press Enter
piartool al >c:\temp\piarclist.txt
Press Enter
2.
Type:
notepad c:\temp\piarclist.txt
Press Enter. The list of registered archives displays in Notepad.

The list is displayed in reverse chronological order with the primary archive listed
first. Each archive listed has a Start Time and End Time associated with it. The
archive with a valid Start Time, for example 5-Nov-98 05:37:48, and the value
Current Time for the End Time, is the primary archive and should be the first archive
listed. An archive with a valid Start Time and a valid End Time was, at one point in
time, the primary archive. Archives with the value Current Time for the Start and End
Times have never had data written to them therefore they are empty.
Application programs residing on the Historian are the interface between the
controllers and the PI system. The application programs are responsible for adding
data to the PI system. As an archive begins to fill, the PI system shifts from the
primary archive to the next available archive, making it the new primary archive. The
next available archive will be an empty archive, if available, or the oldest used
archive. The PI system uses these archives in a circular queue. All data in the
registered archives is available to the PI and GE supplied clients.
Compression
The PI system has a real-time database controlled by the PI Snapshot subsystem, and
a historical database controlled by the PI Data Archive subsystem. The application
programs that write data to the PI system are configured to read a set of points once
per second from the controller. Each points value is compared to the previous value
written to the PI system for that point. If the value has changed by the points
exception deviation, EXCDEV (described below), then that points value is written to
the PI Snapshot database. The PI Snapshot database saves every point that is passed
to it in the Snapshot.
Whenever a point is passed into the PI Snapshot, the PI Data Archive subsystem has
to determine if the value that was in the PI Snapshot should be saved into the archive
or simply discarded. This is where the historical filtering is done.
The filter between the application programs and the PI Snapshot is based on the
value; the exception deviation is used as a deadband. The filter between the PI
Snapshot and the PI Data Archive is based on the slope of the value, or the first time
derivative of the value. PI uses the compression deviation, COMPDEV (described
below), in a swinging door compression algorithm to determine the current slope of
the value. If the previous value written to the PI Snapshot falls outside that slope it is
saved in the PI Data Archive subsystem. This greatly reduces the number of samples
saved during a constant ramp over time. As such, the filter is on the derivative of the
value, not on the value itself.
In summary, the exception deviation is a deadband on the value, but the compression
deviation is a deadband on the slope. More precisely, COMPDEV is how far away
from the projected slope you can get without saving another value, thereby projecting
a new slope.
PI Point Database
The batch mode configuration
is preferred for this
application.
The PI software uses a Point database to define and configure the points that it
maintains. This Point database can be created, either by running an interactive tool
or by using a batch processor. The batch processor is called PICONFIG, and is
distributed as part of the normal PI distribution. The following explains the setup of
the ASCII file PICONFIG.DIF that is redirected into the PICONFIG program to
create the PI Point Database.
Naming Conventions
In the Historian, a Unit Name and a Point Name uniquely identify points. This
scheme allows unit definitions to be duplicated easily by only changing the Unit
Name. The design of the PI database requires that each tag name be unique. An old
standard for PI indicated that two letter unit names should be used, with a colon
separating the unit name from the point name. The Point Name, however, is a simple
string. The Historian uses the units two-character unit name concatenated with a
colon and the Point Name to uniquely identify each tag, for example, T1:TNH is the
tag name for unit T1s speed point.
Four State Logicals

The PI system treats all digital points as enumerated state points. When the point is
defined, it is given an entry point into the Digital State table, which indicates the
ASCII string associated with each state.
The points make use of this to identify four possible states:
Zero
One
Forced to Zero
>0
Forced to One
>1
PI can show the forcing state of logic points, similar to the and HMI.
ASCII Point Definition File PICONFIG.DIF

Refer to PI Database
Configuration (Practical) in
this chapter for more
information on the tool
HSTDBS
The file used as the input to the PICONFIG program is an instance of a generic table
modification data file. This file must tell PICONFIG which table is being worked on,
and what format to find the input data in. This is a somewhat complicated procedure,
which is why the tool HSTDBS creates the file PICONFIG.DIF.
Section One Logic State Definition. The first section in the file selects the
Digital State table and adds the enumerated string table used for the forced logic
points. The section adds the LogicF table with entries of 0, 1, >0, and >1. This section
does not need to be edited or changed.
Section Two PIPOINT Table Preparation. This section selects the PIPOINT
table, which defines all the points. It runs in create,t mode, and creates a new point, or
edits the existing point if the name already exists.
Section Three Disk Manager Point Definition. This section defines the point
used by the DSKMGR program.
Section Four Analog Point Definitions. This section defines the list of analog
points that are used. For each point a set of attributes are defined. The input specifies
the attributes that are defined for each point. These attributes should not need to be
changed.
Refer to PI Database
Configuration (Practical) in
this chapter for information
on the tool HSTDBU
The rest of this section contains the list of points. Each point is defined on a single
line. Each line consists of a set of comma separated attributes for each point. The
order of these attributes on the line is critical. If an attribute is not needed it can be
skipped by indicating two commas in a row. White space on the line is ignored, so
careful use of indenting can be used (but is not needed) to make the file more human
readable.
The typical definition of each point consists of the following attributes in the
following order:
POINTTYPE PREDEFINED STRING. This is a string that indicates the type

of point that this is. For analog points this is almost always the string float32.
POINTSOURCE CHARACTER. This indicates the source of the data. It can

be almost any character, however a few characters are reserved to PI for internal
values. (For example: L is used for Lab Data that is entered manually, and R is
used for calculated points.). The Historian uses the string "1" for all data.
TAG STRING, UP TO 32 CHARACTERS. This is the actual Point Name,

which is the concatenation of the two-character unit name, a :, and the point
name defined in UNITDATA.DAT.
ENGUNITS STRING. This is the engineering units string associated with the
point. The engineering units string comes from the scale code file specified when
running the HSTDBU tool.
DISPLAYDIGITS INTEGER. This defines the number of places after the

decimal point to display. This is set to the value defined in the scale code file.
ZERO FLOAT32. This defines a point's minimum plotting value. This value
is given in the engineering units defined above.
SPAN FLOAT32. This added to the zero value (above) gives the point's
maximum plotting value. The value is given in the engineering units defined
above.
ARCHIVING BOOLEAN (0 OR 1). This flag indicates whether this point

should be saved in the ARCHIVE (Historical Data) or not. If set to a zero (0),
this point is not saved in the ARCHIVE. If set to a one (1) this point is saved in
the archive. HSTDBU sets this to 1 for each point.
STEP BOOLEAN (0 OR 1). This flag indicates whether the point should be
linearly interpolated or stepped when being displayed on graphs. HSTDBU sets
this to 1 for each point.
EXCDEV FLOAT32. The application programs use this value to decide

whether or not to send a value to the PI system. If a point has not changed by at
least this much the value is not reported. Per OSIs recommendation, this value is
set to one-half the compression deviation (defined below). The value is given in
the engineering units defined above.
COMPDEV FLOAT32. The Compression Deviation value is used by the PI

system, in its linear interpolation slope compression algorithm, to determine
when to save a point in the archive. The value is given in the engineering units
defined above.
DESCRIPTOR STRING. This is a description of the point taken from

LONGNAME.DAT. It contains, at minimum, the first 17 characters of the
description.
Section Five Analog Point Extended Description Definitions. Each

analog point is edited to modify its extended description field. Each points
POINTTYPE, POINTSOURCE, and TAG are used to identify the point in the
PIPOINT table. The EXDESC is listed after these fields.
EXDESC STRING. This is a description of the point taken from

LONGNAME.DAT. It is the first 80 characters of the description.
Section Six Logic Point Definitions. This section defines the list of LOGIC
(Digital) points that are used. It modifies the PIPOINT table, which is the table that
defines all the points. It runs in "create,t" mode, which means that it creates a new
point, or edits the existing point if the name already exists.
For each point, a set of attributes is defined. The input specifies the attributes that are
defined for each point. These attributes should not need to be changed.
The rest of this section contains the list of points. Each point is defined on a single
line. Each line consists of a set of comma separated attributes for each point. The
order of these attributes on the line is critical. If an attribute is not needed, it can be
skipped by indicating two commas in a row. White space on the line is ignored, so
careful use of indenting can be used (but is not needed) to make the file more human
readable.
The typical definition of each point consists of the following attributes in the
following order:
POINTTYPE PREDEFINED STRING. This is a string that indicates the type

of point that this is. For logic points this is always the string Digital.
DIGITALSET PREDEFINED STRING. Since all digital points are treated

like enumerated strings, this defines the set of strings that match this point's
states. For SPEEDTRONIC points this should always be the string LogicF.
The LogicF state strings include logic forcing values.
POINTSOURCE CHARACTER. This indicates the source of the data. It can

be almost any character, however a few characters are reserved by PI for internal
values. (For example: L is used for Lab Data that is entered manually, and R is
used for calculated points.)
The Historian uses the string "1" for all data.
TAG STRING, UP TO 32 CHARACTERS. This is the actual Point Name,

which is the concatenation of the two-character unit name, a :, and the point
name defined in UNITDATA.DAT.
DESCRIPTOR STRING. This is a description of the point taken from

LONGNAME.DAT. It contains, at minimum, the first 17 characters of the
description.
Section Seven Logic Point Extended Description Definitions. Each logic

point is edited to have its extended description field modified. Each points
POINTTYPE, DIGITALSET, POINTSOURCE, and TAG are used to identify the
point in the PIPOINT table. The EXDESC is listed after these fields.
EXDESC STRING. This is a description of the point taken from

LONGNAME.DAT. It is the first 80 characters of the description.
Importing the Data File

Refer to Configuring Data
Collection in Chapter 6
The PI server must be running to import the PI configuration input file. The file is
treated as input to the PICONFIG program.
The file can be imported using one of the following methods:
Command Line Interactive
Command Line with Input Redirected
Command Line with Input & Output Redirected
To run Command line interactive

1.

cd /d c:\pi\adm
Press Enter
PICONFIG
Press Enter, PICONFIG runs. A piconfig prompt displays.

2.
Type the command:

@INPUT f:\piconfig.dif
Press Enter
3.
Type the command:

@EXIT
Press Enter, PICONFIG is exited.

To run PICONFIG with input redirected
1.

cd /d c:\pi\adm
Press Enter
PICONFIG
<f:\piconfig.dif
Press Enter. The PICONFIG program runs, using f:\piconfig.dif as the standard
input.
2.
If the PICONFIG.DIF file does not have an "@EXIT" command at the end, then
type:
@EXIT
Press Enter. The PICONFIG program exits.
To run command Line with Input & Output Redirected

1.

cd /d c:\pi\adm
Press Enter
PICONFIG
<f:\piconfig.dif
>f:\piconfig.log
input, and f:\piconfig.log as standard output. The output from the PICONFIG
program (status and error messages) is redirected to the log file.
2.
If the PICONFIG.DIF file does not have an @EXIT command at the end, then
type:
@EXIT
PI Database Configuration (Practical)

These tools are used on
Modbus units, Predefined
Data Dump units, Serial and
CSF Mark IV units, Mark V
units, and Mark V LM units.
This section describes the use of the Historical Database Tools with Historians using
the PI software from OSI. These tools use the individual unit configuration
information contained in each unit directory to build the files needed to collect data
from the unit, and to configure the PI Point database.
The tool is in two parts:
HSTDBU.EXE configures the historical database for a single unit within the unit
configuration directory.
HSTDBS.EXE gathers the individual files from the unit directories and combines
them into historical database files for the site.
The resulting output files required by the HST data collection and PI, are:
F:\PICONFIG.DIF
F:\PI_PUSH.DAT
One of each file is required on a Historian. The files are located in the F:\ directory.
PI_PUSH.DAT is read by the HST program PI_PUSH.EXE, which collects the data
from the unit control and forwards it to the PI database. PICONFIG.DIF is a
configuration file for the PI database. The configuration of the PI database using the
PICONFIG.DIF file and PI configuration program, PICONFIG.EXE, is described in
this section. Refer to the PI documentation for further instructions on configuring the
PI database.
F:\UNITn> HSTDBU /SCALE=filename.SCA /LOG
F:\UNITn\CHNG_Q.SRC
F:\UNITn\EVENT_B.SRC
F:\UNITn\EVENT_Q.SRC
F:\UNITn\HSTPOINT.SRC
F:\UNITn\UNITDATA.DAT
F:\UNITn\LONGNAME.DAT
F:\UNITn\ENGLISH.SCA or
F:\UNITn\METRIC.SCA or
F:\UNITn\CUSTOM.SCA
HSTDBU.EXE
F:\UNITn\PI_PUSH.U
F:\UNITn\PICONFIG.U
F:\UNITn\HSTDBU.LOG
HSTDBU Input and Output Files
Historian Database Unit Level - HSTDBU.EXE

The Historical Database Unit program configures the historical database for a single
unit within the unit configuration directory. It should be used for each MODBUS unit,
Predefined Data Dump Unit, Serial and CSF Mark IV unit, Mark V unit, and Mark V
LM unit. It reads a number of configuration files for the individual unit and builds
two Historian files: a database configuration file, and a unit data collection file.
To use the HSTDBU tool
1.
From the Command Prompt, change the disk and directory to the desired
F:\UNITn directory.
2.
Type:
HSTDBU/SCALE=ENGLISH.SCA
with the appropriate parameters from the list below. Press Enter.
The command line parameter /SCALE=filename. SCA is required to define

which scale code file to use.
The command line parameter /HELP brings up the program help.
The command line parameter /LOG causes the program messages to go to a

log file, HSTDBU.LOG.
The points to be collected on a given unit are determined by the following input files:
CHNG_Q.SRC. Analog Change Cell information
EVENT_Q.SRC. Digital Event information.
EVENT_B.SRC. Digital Event information.
HSTPOINT.SRC. File may contain logic, analog, and accumulator points.
Further input needed to build the unit historical database is provided by the following
unit configuration files:
UNITDATA.DAT
ENGLISH.SCA
METRIC.SCA
CUSTOM.SCA
LONGNAME.DAT
The output files are located in the unit configuration directory, F:\UNITn. The output
files are as follows:
PICONFIG.U. Used to build PICONFIG.DIF at the site level later on. It

contains all the information needed by PI to configure the points for this unit.
PI_PUSH.U. Used to build PI_PUSH.DAT at the site level later on. It contains
the data needed by the Historian program PI_PUSH.EXE to collect data from the
unit control and forward it to PI.
The input files should be configured in each unit directory. All files in the F:\UNITn
directory should be copied over from the or HMI, except HSTPOINT.SRC,
which is unique to the Historian.
The tool needs to be run anytime there is a change to one of the input files listed
above. The tool should be run in each unit directory before running the system level
tool, HSTDBS.EXE.
The tool checks any PI point names for the characters * , ; ( ) { } [ ] | / \ " and
converts these characters to underscore characters _, so as to follow the PI naming
rules.
The tool converts logic database points (type L1) to PI type Digital. It converts
combined accumulators to PI type Float64. All other analog point types are converted
to PI type Float32.
HSTPOINT.SRC - File Format and Explanation

The F:\UNITn\HSTPOINT.SRC file forms the key to the data collection from
Modbus, Data Dump, Mark IV, Mark V, and Mark V LM units. Additional logic,
analog, timer, and counter points may be selected for collection, and configured for
the PI database, using this file. Its format and contents are shown in the sample file
below.
;----------------------------------------------------------------------------; HSTPOINT.SRC
;
;
- List of analog points for which change detection logging is
;
requested, with significant change bands governing when
;
data is saved to the historical database.
;
- May include a list of Logic points to be collected on
;
change detect
;
- May include a list of Accumulator points to be collected on
;
change detect, and combined into a single PI database point.
;
; This file is field/customer configurable.
; This file is read and processed by the Historian Database Tool, HSTDBU.EXE
;
; The file may contain lines of these four formats:
;
;
TTXM
160
; The line contains the point name and
;
; significant change in integer counts.
;
;
TNH
2
"%"
0 128
;
;
; The line contains the point name and
;
; significant change in engineering units,
;
; the engineering units enclosed in double
;
; quotes, the low plot value, the high plot
;
; value.
;
;
L4
; The line contains the point name of a
;
; Logic signal
;
;
(ACCUM_11_MSW, ACCUM_11_LSW) ACCUM_11 1.0 0.0 (*,*)
;
;
; The line contains the Accumulator names
;
; for the MSW & LSW enclosed in parentheses,
;
; the combined signal name for the PI
;
; Database, the gain and offset, and the min
;
; max values enclosed in parentheses.
;
;----------------------------------------------------------------------------;
;
;
ANALOG WITH SIGNIFICANT CHANGE IN INTEGER COUNTS EXAMPLE
;
========================================================
;
; Pointname Change ;
;
;
Pointname - text string
;
It is the Analog Signal name from the Control Signal
;
database.
;
;
Change - integer
;
The change is the significant change in Integer counts.
;
;
;
When an analog signal varies by as much as the count value, the
;
value is sent to the historical data storage for later retrieval
;
and display
;
;
Signal -> The analog signal name in the Data Dictionary.
;
Counts -> Effective deviation before PI will store a message of
;
the change to the its database.
;
;
To get Counts:
;
counts = (change in engineering units)*32768
;
----------------------------------;
Scale Code GAIN
;
; Example #1:
;
;
TNRPI
1280
;
;
;
TNRPI is in engineering units of %. If we wish to save the
;
value historically whenever the value changes by 5%, then
;
count = (5)*32768/GAIN. The GAIN is found by looking
;
in UNITDATA.DAT for TNPRI. The 3rd column of the file has
;
the value 0068. Searching ENGLISH.SCA for entry number 68
;
which is for % yields a GAIN value of 128.
;
count=(5)*32768/128=1280.
;
;
; Example #2:
;
;
TTXM 800
;
;
;
TTXM is in engineering units of deg F...
;
If the change of interest was 50 deg.F then
;
count = (50)*32768/GAIN
;
Looking in UNITDATA.DAT for TTXM has 98 in the 3rd column.
;
In ENGLISH.SCA, entry 98 yields a GAIN value
;
of 2048.
;
count=(50)*32768/2048 = 800
;
; The quick method involves printing ENGLISH.SCA and comparing the ASCII
; engineering units scale strings with that shown for the variable of
; interest as printed in the Control Sequence Program Cross Reference printout.
;
;-------------------;
; Analog Point List ;
;-------------------;
;
; change detected @ 0.08 in/sec (2.0 mm/sec) for vibrations (as examples)
;
; #scale_data 135
8.000000
0.000000
2
in/s
VIBVL
; 328 = .08 * 32768 / 8.000
;
;Signal
Count
;
;BB1
328
; Q -TBQB-051 Vibration sen
;BB2
328
;BB8
328
;BB9
328
;BB_MAX
328
; Max Vibration
;
; change detected @ 9 deg. F (5 deg. C) (as examples)
;
; #scale_data 121
2048.000000
0.000000
0
deg F
TC
; 144 = 9 * 32768 / 2048
;
;TTWS1AO1 144
; C -TBQA-035 Turbine tempe
;TTWS1AO2 144
;TTWS1FI1 144
;TTWS1FI2 144
;TTWS2AO1 144
;TTWS2AO2 144
;TTWS2FI1 144
;TTWS2FI2 144
;
;
;
ANALOG WITH SIGNIFICANT CHANGE IN ENGINEERING UNITS EXAMPLE
;
===========================================================
;
;
; Pointname Change "Units" [Low Plot, [High Plot]]
;
;
;
It is the Analog Signal name from the Data Dictionary
;
;
Change - float
;
The change is the significant change in an
;
engineering value corresponding to the engineering
;
units, below.
;
;
"Units" - Text string enclosed in double quotes
;
The Units are the corresponding engineering units.
;
and must correspond to a valid scale code for that
;
pointname.
;
;
Low Plot - [optional] float
;
This is the Low Plot value in the above engineering
;
units. Use * if the Low Plot is not supplied, but
;
High Plot is supplied.
;
The default value is the points Offset from the
;
Data Dictionary.
;
;
High Plot - [optional] float
;
This is the High Plot value in the above engineering
;
units.
;
The default value is the points Gain + Offset from the
;
Data Dictionary.
;
;
; Examples:
;
;
TTXM
5
"Deg F"
200
1200 ;
;
; This example includes Low & High
;
; Plot values.
;
;
TTXM
5
"Deg F"
*
1200
;
;
; This example skips the optional
;
; Low Plot value, but includes the
;
; High Plot value.
;
;
TTXM
5
"Deg F"
200
;
;
; This example skips the optional
;
; High Plot value, but includes the
;
; Low Plot value.
;
;
TTXM
5
"Deg F"
; This example skips Low & High
;
; Plot values
;
;
; change detected @ 9 deg. F (5 deg. C) (as examples)
;
; #scale_data 121
2048.000000
0.000000
0
deg F
TC
; 144 = 9 * 32768 / 2048
;
;Signal
Chg
Eng Units Low Plot High Plot
;
;TTXD1_1
9.0
"Deg F"
200
1200
; Exhaust Temp TC Array sort
;TTXD1_10 9.0
"Deg F"
200
1200
;TTXD1_11 9.0
"Deg F"
200
1200
;TTXD1_12 9.0
"Deg F"
200
1200
;TTXD1_13 9.0
"Deg F"
200
1200
;TTXD1_2
9.0
"Deg F"
200
1200
;TTXD1_3
9.0
"Deg F"
200
1200
;TTXD1_4
9.0
"Deg F"
200
1200
;TTXD1_5
9.0
"Deg F"
200
1200
;TTXD1_6
9.0
"Deg F"
200
1200
;TTXD1_7
9.0
"Deg F"
200
1200
;TTXD1_8
9.0
"Deg F"
200
1200
;TTXD1_9
9.0
"Deg F"
200
1200
;TTXM
9.0
"Deg F"
200
1200
; Ex Temp Median Corrected
;
;
;
;
;
LOGIC SIGNAL EXAMPLE
;
====================
;
; Pointname ;
;
;
;
It is the Analog Signal name from the Data Dictionary
;
;
;
;
;
;
;
Examples:
L4
L52GX
; This example shows a logic point

;
;
;
;--------------------;
; Digital Point List ;
;--------------------;
;
; Signal
;
;ASH81201
; CD -DTBA-023 Gas Alarm
;ASHH81201
; CD -DTBA-025 Gas Danger
;
;BSH81201
; CD -DTBB-001 Fire detection system alarm
;BSHH81201
; CD -DTBB-003 Fire detection system danger
;
;HS812001
; CD -DTBA-021 Turb. Thrust Brg. excess. Temp. by-pass
;HS812002
; CD -DTBA-027 Journal Brg. Excess. Temp. By-Pass
;HS812003
; CD -DTBB-011 Compr. Brg. excessive temp By-Pass
;HS812009
; CD -DTBA-059 Compr. Equilizing excess. temp. by-pass
;HS812016
; CD -DTBA-061 Compr. suction/discharge excess. temp by-pass
;HS812024
; CD -DTBA-087 Oil Vapour separator excess. press. by-pass
;HS812101
; CD -DTBA-065 Manual valves align to start
;HS812102
; CD -DTBA-067 Manual valves align to load
;HS812103
; CD -DTBA-075 Manual valves total close
;HS812104
; CD -DTBA-085 Valves control in auto mode
;HS81250
; QD1-DTBA-023 Oil coolers vibroswitches reset
;
;LSL81254
; CD -DTBA-013 Lube oil run-down tank low level
;
;
;
;
;
ACCUMULATOR EXAMPLE
;
===================
;
;
; I_name PI_name [gain [offset]] [(min,max)]
;
;
I_name - Text string, format:
;
(MSW, LSW) This is two data dictionary signals that are combined
;
into a single 32 bit value to put into one PI signal.
;
;
PI_name - Text string
;
name to be used in the PI database
;
;
gain - [optional] float
;
gain to be applied to the data dictionary value before it is put
;
into PI.
;
;
offset - [optional but must have gain if used] float
;
offset to be applied to the data dictionary value after the gain
;
is applied and before value is put into PI.
;
;
(min,max) - [optional] float or "*"
;
(NOT used on Historian. Available on OSM only.)
;
The PI value is compared to the min and max value and the "Questionable
;
flag" is set in PI when the value is less than the min value or greater
;
than the max value. An "*" can be use to show that the min or max value
;
is not used.
;
;
Examples:
;
;
;------------------------;
; Accumulator Point List ;
;------------------------;
;
;(--- MSW ---, ---- LSW ---) PI Name gain off (min,max)
;
;(ACCUM_11_MSW, ACCUM_11_LSW) ACCUM_11 1.0 0.0 (*,*)
;(ACCUM_13_MSW, ACCUM_13_LSW) ACCUM_13 0.1 0.0 (*,*)
;
[ASH81201]
[ASHH81201]
[BSH81201]
[BSHH81201]
[HS812001]
[HS812002]
[HS812003]
[HS812009]
[HS812016]
[HS812024]
[HS812101]
[HS812102]
[HS812103]
[HS812104]
[HS81250]
[LSL81254]
;
;
;
;Pointname
;----------BB1
BB3
BB4
BB5
BB_MAX
CNTR_02
CNTR_04
CNTR_05
CPD
CTD
CTDA1
CTDA2
CTIF1
CTIF2
CTIM
DPFM
DRPFM
DTGAI1
DTGAI2
DTGAO1
DTGAO2
DTGSF1
DTGSF2
DTGSF3
DTGSF4
DV
DVAR
DW
DWRESBA
DWRESPK
FSL
FSR
FTPI
FX1
L12H
L12HF
L14HA
L14HM
L14HR
L14HS
L14HSD
L14HT
L1START
L1STOP
L1X
L20ABX
L20CBX
L20CTX
L20FDX
L20FL1X2
L20HDX
L20TUX
L27DNY
L28FD
L28FDT
L28FD_A
L28FD_B
L2F
L2SFT
L2W
L3
L30D_B
SigChang
-------0.0800781
0.0800781
0.0800781
0.0800781
0.0800781
1
1
1
5
10
1
10
5
5
5
1.99994
1.99994
5
5
5
5
5
5
5
5
4.99878
1
1
0
0.4
1.00098
1.00098
2047.94
10.0006
Units
-------"IN/S"
"IN/S"
"IN/S"
"IN/S"
"IN/S"
"PSI"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"PF"
"PF"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"DEG F"
"V RMS"
"MVARS"
"MW"
"MW"
"MW"
"% FSL"
"% FSR"
"DEG F"
"% LIQ"
LowPlot
HighPlot ; Description
-------- -------- ;---------------------------0
1 ; VIBRATION TRANSDUCER # 1 {40n}
0
0
0
0
1 ; VIBRATION MAX SELECT {40E}
; TOTAL STARTS
; FIRED STARTS
; EMERG TRIPS
0
200 ; COMPRESSOR DISCHARGE PRESSURE {42S}
300
800 ; COMPRESSOR DISCHARGE TEMPERATURE {36L}
300
800 ; COMP DISCHARGE TEMP 1 {36E}
300
800 ; COMP DISCHARGE TEMP 2 {36E}
0
170 ; COMP INLET FLANGE TEMP 1 {36E}
0
170 ; COMP INLET FLANGE TEMP 2 {36E}
0
170 ; MAX COMP INLET FLANGE TEMPERATURE {36P}
0
0 ; POWER FACTOR CONTROL SIGNAL FEEDBACK {24V}
0
0 ; POWER FACTOR CONTROL MANUAL REFERENCE {24V}
0
150 ; RTD INPUTS {36n}
0
0
0
0
0
0
0
0
160 ; GENERATOR LINE VOLTS {24H}
-20
100 ; GENERATOR LOAD VARS (SCALED) {42S}
0
70 ; GENERATOR LOAD {42S}
0
60 ; MW Reserve to Base Temperature Control
0
60 ; MW Reserve to Peak Temperature Control
0
100 ; FUEL BYPASS VALVE STROKE
0
110 ; FUEL STROKE REFERENCE {26D}
0
0 ; LIQUID FUEL TEMP T.C. {36n}
0
150 ; FRACTION OF LIQUID FUEL {29A}
; [ALARM 140] ELECTRICAL OVERSPEED TRIP
; [ALARM 135] LOSS OF HP SET MAG PICKUP FEEDBACK TRIP
; [EVENT 1442] HP ACCELERATING SPEED SIGNAL {25A}
; [EVENT 1441] MINIMUM SPEED SIGNAL (APPROX. 20%)
; [EVENT 1440] HP ZERO SPEED SIGNAL {25A}
; [EVENT 1443] HP OPERATING SPEED SIGNAL {25A}
; FIRED SHUT DOWN SPEED RELAY
; TURNING GEAR SPEED RELAY
; [EVENT 12F0] MASTER START SIGNAL {03A}
; [EVENT 1300] MASTER STOP SIGNAL {03D}
; [EVENT 12F4] MASTER CONTROL - STARTUP PERMISSIVE
; ATOMIZING AIR BOOSTER PUMP SOLENOID {06C}
; COMPRESSOR BLEED VALVE CONTROL SIGNAL {06C}
; TURN GEAR CLUTCH CONTROL {05A}
; DRIVING RELAY FOR 20FD {07B}
; LIQUID FUEL STOP VALVE CONTROL SIGNAL {07D}
; HYDRAULIC TRIP OIL CONTROL SIGNAL 20HD-1 {04F}
; TORQUE CONVERTER UNLOADING (DRAIN) SOLENOID VLV
; [ALARM 161] BATTERY D.C. UNDERVOLTAGE
; [EVENT 1360] FLAME DETECTED IN EITHER CAN {10A}
; [ALARM 110] LOSS OF FLAME TRIP
; FLAME DETECTED CHANNEL #1 {39A}
; FLAME DETECTED CHANNEL #2 {39A}
; FIRING TIMER {07A}
; [ALARM 043] STARTUP FUEL FLOW EXCESSIVE TRIP
; TURBINE WARMUP TIMER {10B}
; TURBINE COMPLETE SEQUENCE {12A}
; BASE LOAD
L30EEDIF
BACKED UP
L30F_TMP
L30SPA
L30SPT
L30SPTA
L30TXA
L30TXDIF
L33CB1O
L33CB2O
L33CSE
L33CTE
L33FLC
L39VA
L39VT
L3COMFA
L3LFLT
L3MCSTOP
L3MCSTR
L3RS
L3SMT
L3SQ
L3TFLTX
L3Z
L4
L41FX
L41SX
L43A
L43B
L43C
L43DIAG
L43F
L43O
L43PBEN
L43PBMAN
L43PS
L43PSLS
L43PSRS
L43R
L48
L4CRT
L4FC
L4FD
L4QA_QCZ
L4QEZ
L4TG_A
L4_RLYT
L52GX
L52QA
L52SX
L52TGY
L60FSRG
L62TT2A
L63QTL
L6CR
L72QEX
L83B
L83HOST
L83P
L83PF
L83PK
L83PS
L83SRX
L84TG
L84TL
L86CB
L86CTIFT
L86HD
L86S
L86TFB
L86TV
; [ALARM 234] PRIMARY EEPROM CHANGED, NOT

;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
FSR TEMPERATURE CONTROL {26D}

[ALARM 112] COMBUSTION TROUBLE
[ALARM 119] EXCESSIVE COMBUSTION TROUBLE - TRIP
[ALARM 115] EXHAUST THERMOCOUPLE TROUBLE
[ALARM 116] EXHAUST TEMPERATURE HIGH
[ALARM 224] EXHAUST THERMOCOUPLE DISAGREEMENT
[DIGIN 11ED] COMPRESSOR BLEED VALVE #1 OPEN {02A}
[DIGIN 11EE] COMPRESSOR BLEED VALVE #2 OPEN {02A}
[DIGIN 11D9] STARTING CLUTCH ENGAGED {02C}
[DIGIN 121B] 88TG ENGAGED {02E}
[DIGIN 11E4] LIQUID FUEL STOP VALVE CLOSED {02C}
[ALARM 129] HIGH VIBRATION ALARM
[ALARM 133] HIGH VIBRATION TRIP
[ALARM 225] PROCESSOR LINK FAILURE
[ALARM 42] LIQUID FUEL CONTROL FAULT
STOP INDICATOR {03D}
NORMAL START INDICATOR {03A}
READY TO START {04A}
[ALARM 086] STARTING DEVICE TRIP
SEQUENCE IN PROGRESS {03E}
[ALARM 143] LOSS OF COMPRESSOR DISCHARGE PRESS B
[ALARM 172] FAILURE TO SYNCHRONIZE
[EVENT 1324] MASTER PROTECTIVE SIGNAL {04F}
GENERATOR FIELD FLASHING {22B}
AUX TO 41S {49E}
[EVENT 12E8] AUTO MODE SELECTED {01S}
BASE SELECTED {14A}
[EVENT 12E6] CRANK MODE SELECTED {01R}
[ALARM 142] OFF-LINE DIAGNOSTICS RUNNING
[EVENT 12E7] FIRE MODE SELECTED {01R}
[EVENT 12E5] OFF MODE SELECTED {01R}
Power Block Control Enabled
Power Block Control Selected
PRE-SELECTED LOAD SELECT {14B}
PRESELECTED LOAD SETPOINT - LOWER {01E}
PRESELECTED LOAD SETPOINT - RAISE {01E}
[EVENT 12E9] REMOTE MODE SELECTED {01S}
[ALARM 137] TURBINE INCOMPLETE SEQUENCE
[ALARM 94] STARTING MOTOR BREAKER OPEN
COOLING WATER FANS MASTER CONTROL {05S}
FUEL FORWARDING PUMP CONTROL SIGNAL {07B}
AUX LUBE OIL PUMP CONTROL SIGNAL {03F}
MASTER CONTROL SIGNAL FOR EMERGENCY LUBE OIL PUMP
TURNING GEAR MOTOR 88TG {05A}
[ALARM 122] RELAY 4 CKT TRIP
[DIGIN 1206] GENERATOR BREAKER CLOSURE {02A}
[DIGIN 11FB] AUXILIARY LUBE OIL PUMP RUNNING
AUTO SYNCHRONIZING PERMISSIVE {22B}
AUX TO 52TG {05A}
[ALARM 144] FSR GAG NOT AT MAX LIMIT
[ALARM 138] FAILURE TO START
[DIGIN 11D4] LUBE PRESSURE LOW {02A}
[DIGIN 11F0] CRANKING MOTOR START {03C}
[DIGIN 11F8] EMERGENCY LUBE OIL PUMP RUNNING
[EVENT 1379] BASE LOAD COMMAND {14A}
[ALARM 139] OVERSPEED TEST MODE SELECTED
PEAK LOAD COMMAND {14A}
POWER FACTOR CONTROL SELECTED {24T}
PEAK TEMPERATURE CONTROL SELECT {14A}
[EVENT 1378] PRE-SELECTED LOAD COMMAND {14B}
VOLTAGE REGULATION CONTROL TRANSFER {22A}
[EVENT 1481] 100% GAS FUEL SELECTED
[EVENT 1480] 100% LIQUID FUEL SELECTED
[ALARM 102] COMPRESSOR BLEED VALVE POSITION
[ALARM 114] COMPRESSOR INLET THERMOCOUPLES DISAG
[ALARM 017] HYDRAULIC PROTECTIVE TROUBLE
[ALARM 171] AUTO SYNCHRONIZING LOCKOUT
[ALARM 121] EXHAUST THERMOCOUPLE OPEN TRIP
[ALARM 101] INLET GUIDE VANE POSITION TROUBLE
L86TXT
;
L94T
;
L94X
;
LK90MAX
204.794 "MW"
0
0 ;
LK90PSEL
0.1 "MW"
0
60 ;
LK90SPIN
204.794 "MW"
0
0 ;
LMWMIN
;
LTB1D
10 "DEG F"
0
250 ;
LTB2D
10 "DEG F"
0
250 ;
LTB3D
10 "DEG F"
0
250 ;
LTG1D
10 "DEG F"
0
250 ;
LTG2D
10 "DEG F"
0
250 ;
LTTH1
10 "DEG F"
0
250 ;
PF_SEL
;
PWR_FACT
1.99994 "PF"
0
0 ;
REF_PF
1.99994 "PF"
0
0 ;
SVOLTS
0.999756 "KV"
0
20 ;
TFIB1
2047.94 "DEG F"
0
0 ;
TIMR_01
1
;
TIMR_02
1
;
TNH
0.999451 "% SPD"
0
120 ;
TNR
0.999451 "% SPD"
0
120 ;
TTWS1AO1
10 "DEG F"
200
1100 ;
TTWS1AO2
10 "DEG F"
200
1100 ;
TTWS1FO1
1 "DEG F"
200
1100 ;
TTWS1FO2
10 "DEG F"
200
1100 ;
TTWS2AO1
10 "DEG F"
200
1100 ;
TTWS2AO2
10 "DEG F"
200
1100 ;
TTWS2FO1
10 "DEG F"
200
1100 ;
TTWS2FO2
10 "DEG F"
200
1100 ;
TTWS3AO1
10 "DEG F"
200
1100 ;
TTWS3AO2
10 "DEG F"
200
1100 ;
TTWS3FO1
10 "DEG F"
200
1100 ;
TTWS3FO2
10 "DEG F"
200
1100 ;
TTXC
5 "DEG F"
200
1200 ;
TTXDC1
5 "DEG F"
200
1200 ;
TTXDC10
5 "DEG F"
200
1200 ;
TTXDC11
5 "DEG F"
200
1200 ;
TTXDC12
5 "DEG F"
200
1200 ;
TTXDC2
5 "DEG F"
200
1200 ;
TTXDC3
5 "DEG F"
200
1200 ;
TTXDC4
5 "DEG F"
200
1200 ;
TTXDC5
5 "DEG F"
200
1200 ;
TTXDC6
5 "DEG F"
200
1200 ;
TTXDC7
5 "DEG F"
200
1200 ;
TTXDC8
5 "DEG F"
200
1200 ;
TTXDC9
5 "DEG F"
200
1200 ;
TTXM
5 "DEG F"
200
1200 ;
TTXSP
10 "DEG F"
0
130 ;
TTXSP1
10 "DEG F"
0
130 ;
TTXSP2
10 "DEG F"
0
130 ;
TTXSP3
10 "DEG F"
0
130 ;
TTXSPL
10 "DEG F"
0
130 ;
FAL
0 "MA"
0
0 ;
;------------------------;
; Accumulator Point List ;
;------------------------;
;
;(--- MSW ---, ---- LSW ---) PI Name gain off (min,max)
[ALARM 120] EXHAUST OVERTEMPERATURE TRIP

FIRED SHUTDOWN {03E}
[EVENT 1301] NORMAL SHUTDOWN {03D}
LOAD CONTROL - MAXIMUM LOAD
LOAD CONTROL - PRESELECTED LEVEL
LOAD CONTROL - SPINNING RESERVE LEVEL
MINIMUM LOAD DURING SHUTDOWN
LUBE TEMP. NO. 1 TURB. BRG. DRAIN {36n}
LUBE TEMP. NO. 1 GEN. DRAIN {36E}
LUBE TEMP. NO. 2 GEN. DRAIN {36E}
LUBE TEMP TURBINE HEADER, GT/GG {36n}
POWER FACTOR CONTROL SELECTION INDICATOR {24T}
ACTUAL POWER FACTOR DISPLAY {24V}
POWER FACTOR DISPLAY REFERENCE {24V}
STATION LINE VOLTAGE {24L}
LOAD TUNNEL {37C}
FIRED HOURS
PEAK FIRED HOURS
TURBINE SPEED HP {42M}
SPEED CONTROL REFERENCE {24E}
TURB WHEELSPACE TEMP 1ST STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 1ST STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 1ST STG FWD OUTER {36D}
TURB WHEELSPACE TEMP 1ST STG FWD OUTER {36D}
TURB WHEELSPACE TEMP 2ND STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 2ND STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 2ND STG FWD OUTER {36D}
TURB WHEELSPACE TEMP 2ND STG FWD OUTER {36D}
TURB WHEELSPACE TEMP 3RD STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 3RD STG AFT OUTER {36D}
TURB WHEELSPACE TEMP 3RD STG FWD OUTER {36D}
TURB WHEELSPACE TEMP 3RD STG FWD OUTER {36D}
AVERAGE EXHAUST TEMPERATURE
<C> Exhaust Thermocouple
MEDIAN EXHAUST TEMPERATURE
COMBUSTION MONITOR SPREAD {36M}
COMBUSTION MONITOR ACTUAL SPREAD 1 {36M}
COMBUSTION MONITOR ACTUAL SPREAD 2 {36M}
COMBUSTION MONITOR SPREAD 3 {36M}
COMBUSTION MONITOR ALLOWABLE SPREAD {36L}
LIWUID FUEL SERVO CURRENT
Historian Database System Level - HSTDBS.EXE

The Historian Database System program builds the configuration file in the F:\
directory. It should run after HSTDBU.EXE is run for each unit configuration
directory. It combines each units PI_PUSH.U into a single PI_PUSH.DAT file to be
read by PI_PUSH.EXE. It also combines each units PICONFIG.U file into a single
PICONFIG.DIF file to configure the PI historical database through the PICONFIG
program.
F:\> HSTDBS /LOG
F:\UNITn\PI_PUSH.U
F:\UNITn\PICONFIG.U
F:\UNITn\PI_PUSH.U
F:\UNITn\PICONFIG.U
F:\CONFIG.DAT
F:\UNITn\PI_PUSH.U
F:\UNITn\PICONFIG.U
F:\UNITn\PI_PUSH.U
F:\UNITn\PICONFIG.U
HSTDBS.EXE
F:\PI_PUSH.DAT
F:\PICONFIG.DIF
F:\HSTDBS.LOG
HSTDBS Input and Output Files
To use the HSTDBS tool

1.
Open a Command line window, and change the disk and directory to the F:\
directory.
2.
From the Command Prompt, type

HSTDBS
with the appropriate command line parameters from the following list. Press Enter.
The command line parameter /HELP brings up the program help.
The command line parameter /LOG causes the program messages to go to a

log file HSTDBS.LOG.
The input files are:
F:\UNITn\PICONFIG.U. This units PI historical database configuration

information.
F:\UNITn\PI_PUSH.U. This units PI_PUSH historical data collection

information.
CONFIG.DAT. The site configuration directory. This contains the unit names
and directories.
The output files produced by this tool, required by the HST data collection and PI, are
as follows:
PICONFIG.DIF
PI_PUSH.DAT
This tool builds the required output file by writing any required header information,
then reading the .U from the unit configuration directory. It then modifies it with the
appropriate unit name data, and writes it into the output file. It repeats this step for
each unit configuration directory listed in CONFIG.DAT.
The tool needs to be run any time one or more of the .U files is modified. The .U files
are produced by HSTDBU.EXE.
The PI database should be reconfigured after running the tool. Refer to PI
Configuration Database PICONFIG.EXE in this chapter for instructions on
configuring the PI database with the PICONFIG.DIF file. Restart the historical data
collection system to collect and store the points after reconfiguring the
PI_PUSH.DAT and PICONFIG.DIF files.
PI_PUSH.U - File Format and Explanation

; F:\PI_PUSH.U
;
; This file defines the points that are "pushed" from the Data Dictionary
; into the PI snapshot database for a given unit.
;
; This file is a list of the points to be pushed. Each line should have the
; following format:
;
; I_name PI_name
;
;
Examples:
;
DWATT DWATT 1.0 0.0 (*,*)
;
(ACCUM_01_MSW, ACCUM_01_LSW) T1:ACCUM_01 0.1 0.0 (*,*)
;
;
TNH_RPM
TNH_RPM
TNR
TNR
TNRI
TNRI
TTRX
TTRX
TTXD1_1
TTXD1_1
TTXD1_10
TTXD1_10
TTXD1_11
TTXD1_11
TTXD1_12
TTXD1_12
TTXD1_13
TTXD1_13
TTXD1_14
TTXD1_14
TTXD1_15
TTXD1_15
TTXD1_16
TTXD1_16
TTXD1_17
TTXD1_17
TTXD1_18
TTXD1_18
TTXD1_2
TTXD1_2
TTXD1_3
TTXD1_4
TTXD1_5
TTXD1_6
TTXD1_7
TTXD1_8
TTXD1_9
L4
L1X
L94X
L52GX
L14HA
L14HM
L14HR
L14HS
L14HT
L1FX
L28FD
L28FDA
L28FDB
L28FDC
L28FDD
L2TV
L2TVX
HIS_AGE
TTXD1_3
TTXD1_4
TTXD1_5
TTXD1_6
TTXD1_7
TTXD1_8
TTXD1_9
L4
L1X
L94X
L52GX
L14HA
L14HM
L14HR
L14HS
L14HT
L1FX
L28FD
L28FDA
L28FDB
L28FDC
L28FDD
L2TV
L2TVX
HIS_AGE
PICONFIG.U - File Format and Explanation

@istr
pointtype,pointsource,tag,engunits,displaydigits,zero,span,typicalvalue,archiving,step,excdev,compdev,desc
*
*---------------------------------------------------------------------------*
* Now supply the point data
*
*
*Ptype S PointTag
EngUni D
Zero
Span Typical A S Excp Comp Description
*------ - ------------ ------ - ------- ------- ------- - - ---- ---- ---------------float32,1,TNH_RPM, RPM , 0,
-10,
6010,
5100, 1,0,
20, 50, SPEED
float32,1,TNR,
%
, 1,
-20,
160,
100, 1,0, 0.5, 1.2, SPEED CONTROL REFERENCE
float32,1,TNRI,
%
, 1,
-20,
160,
100, 1,0, 1.0, 2.5, ISOCHRONOUS SPEED CHANGER
float32,1,TTRX,
DEG F, 0,
-120,
1320,
900, 1,0, 5.0,12.5, TEMPERATURE CONTROL REFERE
float32,1,TTXD1_1, DEG F, 0,
-120,
1320,
900, 1,0, 5.0,12.5, EXHAUST TEMP TC ARRAY SORT
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
float32,1,HIS_AGE, CNTS , 0,
0, 65536,
100, 1,0,
1,
3, TIME SINCE LAST STARTUP
@endsection
*
*---------------------------------------------------------------------------*
* We do logic points just a little bit differently. In the future we may
* merge the analog and logic points into the same input structure, but for
* now this is the easier way.

*
@istr pointtype,digitalset,pointsource,tag,descriptor
*
Digital,LogicF,1,L4,
Master Protective
Digital,LogicF,1,L1X,
Startup in Progress
Digital,LogicF,1,L94X,
Shutdown in Progress
Digital,LogicF,1,L52GX,
Generator Breaker
Digital,LogicF,1,L14HA
,[EVENT 09CA] HP ACCELERATI
Digital,LogicF,1,L14HM
,[EVENT 09C9] MINIMUM SPEED
Digital,LogicF,1,L14HR
,[EVENT 09C6] HP ZERO SPEED
Digital,LogicF,1,L14HS
,[EVENT 09CB] HP OPERATING
Digital,LogicF,1,L14HT
,[EVENT 09CD] COOL DOWN SLO
Digital,LogicF,1,L1FX
,[EVENT 07E5] AUXILIARY TO
Digital,LogicF,1,L28FD
,[EVENT 0892] FLAME DETECTE
Digital,LogicF,1,L28FDA
,[EVENT 0020] FLAME DETECTO
Digital,LogicF,1,L28FDB
Digital,LogicF,1,L28FDC
Digital,LogicF,1,L28FDD
Digital,LogicF,1,L2TV
,[EVENT 0872] TURBINE VENT
Digital,LogicF,1,L2TVX
,[EVENT 0874] IGNITION PERM
@endsection
PI_PUSH.DAT - File Format and Explanation

;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
File: PI_PUSH.DAT
Created :25-AUG-1997 13:08:30.300
Site: Your Site
This file defines the points that are "pushed" from the Data Dictionary
into the PI snapshot database for a given unit.
This file is a list of the points to be pushed.
following format:
Each line should have the
I_name PI_name [gain [offset]] [(min,max)]

I_name - Text string, one of two formats:
1) A standard data dictionary name
2) (MSW, LSW) This is two data dictionary signals that are combined
into a single 32 bit value to put into one PI signal.
gain to be applied to the data dictionary value before it is put
into PI.
offset to be applied to the data dictionary value after the gain
is applied and before value is put into PI.
The PI value is compared to the min and max value and a flag is set
in PI when the value is less than the min value or greater than the
max value. An "*" can be use to show that the min or max value is not
used.
Examples:
DWATT DWATT 1.0 0.0 (*,*)
;
; To use a prefix on all following pointnames use a special line starting with
; the command "@I_PREFIX" or "@PI_PREFIX". These commands take one [optional]
; parameter, the prefix to use. If no parameter is given then no prefix will
; be used. Examples:
;
@I_PREFIX T1:
;
@PI_PREFIX T1:
;
DWATT
DWATT 1.0 0.0 (*,*)
;
DVAR
DVAR
;
;
@I_PREFIX
;
@PI_PREFIX
;
T1:L4
L4
;
T1:L1X
L1X
;
@I_PREFIX GS:
@PI_PREFIX GS:
TNH_RPM
TNH_RPM
TNR
TNR
TNRI
TNRI
TTRX
TTRX
TTXD1_1
TTXD1_1
TTXD1_10
TTXD1_10
TTXD1_11
TTXD1_11
TTXD1_12
TTXD1_12
TTXD1_13
TTXD1_13
TTXD1_14
TTXD1_14
TTXD1_15
TTXD1_15
TTXD1_16
TTXD1_16
TTXD1_17
TTXD1_17
TTXD1_18
TTXD1_18
TTXD1_2
TTXD1_2
TTXD1_3
TTXD1_3
TTXD1_4
TTXD1_4
TTXD1_5
TTXD1_5
TTXD1_6
TTXD1_6
TTXD1_7
TTXD1_7
TTXD1_8
TTXD1_8
TTXD1_9
TTXD1_9
L1X
L94X
L52GX
L14HA
L14HM
L14HR
L14HS
L14HT
L1FX
L28FD
L28FDA
L28FDB
L28FDC
L28FDD
L2TV
L2TVX
HIS_AGE
L1X
L94X
L52GX
L14HA
L14HM
L14HR
L14HS
L14HT
L1FX
L28FD
L28FDA
L28FDB
L28FDC
L28FDD
L2TV
L2TVX
HIS_AGE
PICONFIG.DIF - File Format and Explanation

*
*
*
File: PICONFIG.DIF
* Created: 25-AUG-1998 13:08:30.300

*
* Site: Your Site
*
* This file is used to create/edit the PI Point Database.
*
*---------------------------------------------------------------------------*
* Make sure that the definition of our Logic Forced points is available
*
@tabl pids
@mode create,t
@stype delimited
@istr set, state, ...
LogicF, 0, 1, >0, >1
@ends
*
*---------------------------------------------------------------------------*
* Switch to the Point Definitions and describe our input format
*
@tabl pipoint
@ptclas classic
@mode create,t
@modi ptclass=classic
@istr
pointtype,pointsource,tag,engunits,displaydigits,zero,span,typicalvalue,archiving,step,excdev,compdev,desc
*
*---------------------------------------------------------------------------*
* Now supply the point data
*
*
*Ptype S PointTag
EngUni D
Zero
Span Typical A S Excp Comp Description
*------ - ------------ ------ - ------- ------- ------- - - ---- ---- ---------------float32,1,GS:TNH_RPM, RPM , 0,
-10,
6010,
5100, 1,0,
20, 50, SPEED
float32,1,GS:TNR,
%
, 1,
-20,
160,
100, 1,0, 0.5, 1.2, SPEED CONTROL REFERENCE
float32,1,GS:TNRI,
%
, 1,
-20,
160,
100, 1,0, 1.0, 2.5, ISOCHRONOUS SPEED CHANGER
float32,1,GS:TTRX,
DEG F, 0,
-120,
1320,
900, 1,0, 5.0,12.5, TEMPERATURE CONTROL REFERE
float32,1,GS:TTXD1_1, DEG F, 0,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
-120,
1320,
int32 ,1,HIS_AGE ,CNTS , 0,
0, 65536,
100, 1,0,
1,
3, TIME SINCE LAST STARTUP
@endsection
*
*---------------------------------------------------------------------------*
* We do logic points just a little bit differently. In the future we may
* merge the analog and logic points into the same input structure, but for
* now this is the easier way.
*
*
Digital,LogicF,GS:1,L4,
Master Protective
Digital,LogicF,GS:1,L1X,
Startup in Progress
Digital,LogicF,GS:1,L94X,
Shutdown in Progress
Digital,LogicF,GS:1,L52GX,
Digital,LogicF,GS:1,L14HA
Digital,LogicF,GS:1,L14HM
Digital,LogicF,GS:1,L14HR
Digital,LogicF,GS:1,L14HS
Digital,LogicF,GS:1,L14HT
Digital,LogicF,GS:1,L1FX
Digital,LogicF,GS:1,L28FD
Digital,LogicF,GS:1,L28FDA
Digital,LogicF,GS:1,L28FDB
Digital,LogicF,GS:1,L28FDC
Digital,LogicF,GS:1,L28FDD
Digital,LogicF,GS:1,L2TV
Digital,LogicF,GS:1,L2TVX
@endsection
Generator Breaker
,[EVENT 09CA] HP ACCELERATI
,[EVENT 09C9] MINIMUM SPEED
,[EVENT 09C6] HP ZERO SPEED
,[EVENT 09CB] HP OPERATING
,[EVENT 09CD] COOL DOWN SLO
,[EVENT 07E5] AUXILIARY TO
,[EVENT 0892] FLAME DETECTE
,[EVENT 0872] TURBINE VENT
,[EVENT 0874] IGNITION PERM
PI Configuration Database - PICONFIG.EXE

This program must be run to configure the PI historical database for the Historian. It
should run after HSTDBU.EXE is run for each unit configuration directory, and after
running the HSTDBS.EXE program to build the F:\PICONFIG.DIF file. It uses the
PICONFIG.DIF to set up the PI historical database. It should be run any time
HSTDBU and HSTDBS cause changes in the PICONFIG.DIF file.
To use the PICONFIG tool
1.

Net stop HST
Press Enter
cd /d c:\pi\adm
Press Enter
PICONFIG
<f:\piconfig.dif
>f:\piconfig.log
input, and f:\piconfig.log as standard output. The output from the PICONFIG
program (status and error messages) is redirected to the log file.
2.
If the PICONFIG.DIF file does not have an "@EXIT" command at the end, then
type:
@EXIT

3.
Review the PICONFIG.LOG file to verify that there are no records with errors.
4.
From the Command Prompt, start the HST Service. Type:

Net start HST
Press Enter. The HST Service starts.
F:\> C:\PI\ADM\PICONFIG < F:\PICONFIG.DIF > F:\PICONFIG.LOG
F:\PICONFIG.DIF
PICONFIG.EXE
PI Archive Database
F:\PICONFIG.LOG
Modifying the PI Database Configuration
Web Server Configuration

The Historian (HST) gathers data from the turbine units as configured to establish a
database of historical data for the plant. Display programs are available locally to
display such data as alarms, events, and data plots.
In addition to locally displayed information for the operator, HST supplies all the
tools necessary to support a web-based display of this important information. HST
comes equipped with a web server, browser, and support displays and executables
necessary to make historical information available via remote browser. In case the
Web Server gets shut down, it can be restarted as follows.
To enable the Web server
1.
From the Desktop, click the Start button.
2.
From the Start menu, click Settings, and then Control Panel.
3.
From the Control Panel menu, click Services.
4.
Scroll to find World Wide Web Publishing Service.
5.
From the Services dialog box, click the Start button in the right-hand column.
6.
Use a browser such as Internet Explorer to verify proper operation. See below.
7.
If desired, make the World Wide Web Publishing Service startup permanent by
selecting the Startup button in the right-hand column of the Services dialog
box.
8.
Select automatic, and then OK. To disable automatic startup after processor
reboot, select manual, and then OK.
Historian Home Page

To specify the Historian Home Page
1.
Click on Start, then Program, then Microsoft Peer Web Services, then
Internet Service Manager. The Internet Service Manager displays.
2.
World Wide Web page server properties may be verified by selecting WWW.
3.
Click on Properties, then Service Properties
4.
The Internet Service Manager will have all three Password Authentication check
boxes checked. It is recommended to Enable Default Document as
Default.htm, and to check Directory Browsing Allowed.
5.
The Internet Service Manager is normally setup to specify a home directory of

c:\inetpub\wwwroot. The GE supplied Historian Home Page appears in
the directory below entitled: c:\inetpub\wwwroot\GEDS.
If the customer has established a home page, this normally displays as:
c:\inetpub\wwwroot\default.htm.
A link may be added to the GE Historian Home Page if desired. Use the
sample below as a model. Should customers not need their own page, they
may either substitute GEs page, or create a minimal page with a link to the
page supplied by GE for the historian.
To substitute the GE supplied page
copy c:\inetpub\wwwroot\geds\HST.htm c:\inetpub\wwwroot\default.htm
Press Enter. The file is copied.

To create a page with a link to GEs page
Create a file: c:\inetpub\wwwroot\default.htm,

with contents as follows:
<html>
<body>
<a href="GEDS/hst.htm">General Electric Historian Home Page</a>
</body>
</html>
When the Historian Home Page is invoked, the following screen displays:
Ethernet Configuration
The Historian comes with a pre-configured Ethernet interface. The default settings
specify 10Base2-coax media transceiver, and an IP address of 192.168.1.40. In most
applications the default settings do not need to be changed. However when
connecting the Historian to a plant wide network these settings may need to be
changed. In this case obtain an IP address, subnet mask, and default gateway IP
address from the network administrator.
To change the IP address
1.
Click on Start, then Settings, then Control Panel.
2.
Double click on the Network icon. The Network configuration dialog box
opens.
3.
From the Network dialog box, select the Protocols tab.
4.
Highlight the TCP/IP Protocol and select Properties. The Microsoft TCP/IP
Properties dialog is displayed at the IP address tab.
5.
Verify that the correct adapter is selected.
6.
Select the IP Address edit box, and type the desired IP address. If needed
change the Subnet Mask and Default Gateway.
7.
Click on the OK button. The Network Dialog box displays.
Note This example shows the 3Com Etherlink III Adapter Board Setup. Other board
setups may vary.
8.
From the Network configuration dialog, select the Adapters tab.
9.
Highlight the desired adapter, and select Properties.
10. The 3Com Etherlink III Adapter Board Setup dialog box displays. Note that
the Ethernet board has three transceivers: Thick net (AUI), Thin net (BNC) and
10 Base T (RJ45).
11. Choose the desired media transceiver from the Transceiver Type drop down
list box. Do not change the I/O Port Address or the Interrupt Number.
12. Click on OK. The Network dialog box displays.
13. From the Network dialog box, click OK. The system reconfigures the network
settings.
14. Restart the PC when the prompt Restart the PC displays.
Or, start the PC at a later time if you choose, however, the new settings will not
take effect until the system is restarted.
Historian Configuration Files

The Historian uses normal text (ASCII) files for most of its site specific configuration
information. This includes configuration information about the Historian itself, as
well as configuration information for the units or controllers from which the Historian
obtains information.
In many cases, the Historians unit configurations are obtained by copying the
configuration from an existing operator interface PC, either an or an HMI. The
Historian is designed to use the same configuration file structure as the operator
interface products, so unit configurations do not have to be redone. The unit
configuration for most Mark IV, Mark V, and Mark VI unit controllers can be copied
from the operator interface. The Predefined Data Dump and MODBUS
configurations, however, often need to be configured on the Historian, since these are
not available from an operator interface. (They are supported on an HMI, but
typically are not used that way.)
The Historian uses a pseudo-drive called F: to store all the site-specific configuration.
At the top level of the F: drive are all the files that configure the Historian itself, or
any subsystem that can span multiple units. The configuration of each unit is stored in
a subdirectory of the F: drive, one unit per subdirectory. The master configuration file
(F:\CONFIG.DAT) defines how many units exist, and for each unit, what type of unit
it is, and the name of its unit configuration subdirectory.
Unit Types
The Historian uses a unit type assigned to each unit to control how information is
collected from that unit. Depending on the unit type and how it is connected to the
Historian, different configuration files are required for communication with the unit.
The unit type definition is specified in the F:\CONFIG.DAT file, and the values that
are to be used for the various controller types and configurations are shown in the
following table. All versions of the Historian support using the unit type number, and,
starting with Historian version 1.4, the unit type symbolic name can be used instead.
Number
Name of Unit
Front-end Configuration Programs
MarkV
Mark V ( the default if none is specified)
INT (or HMI)
Internal Historian Points, MODBUS (Ethernet or Serial), and

Predefined Data Dump (PDD)
MarkVLM
Mark V LM
MarkIV
Mark IV over MSP (CSF or Serial)
MarkVI
Mark VI
Configuration Files in the F:\ Directory

The configuration files at the top level of the F: pseudo-drive configure the Historian
and subsystems that span multiple units. The following files are used:
File Name
Internal
Mark IV
Mark V
Mark V LM
Mark VI
CONFIG.DAT
All
communication
programs
All
communication
programs
All
communication
programs
All
communication
programs
All
communication
programs
DSKMGR.DAT
Optional file*
Optional file*
Optional file*
Optional file*
Optional file*
ENETALM.DAT
NA
NA
NA
NA
All
communication
programs
EGD_PUSH.DAT
NA
NA
NA
NA
All
communication
programs
IO_PORTS.DAT
All
communication
programs
Modbus, PDD,
Serial MSP
(or MSP over
RS-232C)
NA
NA
NA
PI_PUSH.DAT
All
communication
programs
All
communication
programs
All
communication
programs
All
communication
programs
NA
PICONFIG.DIF
All
communication
programs
All
communication
programs
All
communication
programs
All
communication
programs
All
communication
programs
TIMESYNC.DAT
Optional file*
Optional file*
Optional file*
Optional file*
Optional file*
TIMEZONE.DAT
Optional file*
Optional file*
Optional file*
Optional file*
Optional file*
- Not related to the communication method used.
All communication programs - used with all front end communication programs this controller supports.
CONFIG.DAT. This file defines the site configuration for the Historian. It
indicates the site name, number and types of units, and the number and types of
networks. For each unit, it defines the name of the unit configuration directory
that holds the unit specific information. This file is always needed.
DKSMGR.DAT. Defines the amount of free disk space requested on the

historical data drive. The Disk Manager program (DSKMGR) removes old
historical data files to provide the amount of free disk space requested in this data
file. If this data file does not exist, a value of 10 MB is used.
ENETALM.DAT. This file is used at sites with controllers that use the ALM
protocol over Ethernet, such as the Mark VI controller. This file maps network IP
addresses with unit controllers, allowing the Historian to associate received
Ethernet messages with the unit that sent them.
EGD_PUSH.DAT. This file is used at sites with controllers that use the EGD
protocol over Ethernet, such as the Mark VI controller. This file defines the list
of signals that are to be read from EGD and forwarded to the PI Snapshot. A gain
and offset is available for analog signals in case the engineering units in the EGD
page are not the same as are required in the PI Snapshot or Archive files.
IO_PORTS.DAT. Defines the I/O ports (or communication ports) used by the
Historian. Required for any front-end communication program that uses an RS232C port or an Ethernet port. This file must exist when using the PDD, Modbus,
or Serial MSP front-end communication programs.
PI_PUSH.DAT. Specifies the list of points that are to be sent to the PI Snapshot
Database, where they can also be forwarded to the PI Archive. A gain and offset
are provided for analog signals in case the engineering units in PI are different
than the engineering units defined in the Data Dictionary scale code file. This file
is used for all Data Dictionary based units, but is not used for EGD based
controllers.
This file is created as a result of running the Historian automation tools. The file
should not be edited by hand since changes will be overwritten the next time the
Historian automation tools are run.
PICONFIG.DIF. Defines for PI the points (called TAGS in PI) that are used.
This includes all information that PI needs to know about the point, including the
name, description, scaling, and information on how (or whether) each point
should be saved in the historical archives.
This file is created as a result of running the Historian automation tools. The file
should not be edited by hand since changes will be overwritten the next time the
Historian automation tools are run.
TIMESYNC.DAT. The Historian can act as a time synchronization master, a

time synchronization slave, or neither. This file is used to indicate the desired
options. The Historian can support a high-resolution time board, although they
are typically installed in an HMI or IDP instead of the Historian.
TIMEZONE.DAT. The Historian saves most of its historical data using UTC
(Coordinated Universal Time) time tags. This assures that historical data never
has discontinuities in it, since UTC never jumps. What does jump is the offset of
UTC to Local time when Daylight Savings is entered and left. The TIMEZONE
data file defines when a site entered and left Daylight Savings time, and the
associated offset between UTC and Local time.
This file is typically generated by setting the PCs time zone information using
the Control Panel Date/Time applet, then running the TZ_MAKE utility.
Configuration Files in the F:\UNITn Directory

Each unit has a unit configuration directory that contains all the information known
about each unit. The unit configuration directories can be copied to create a new
directory. (Address specific information about each unit is contained in the
F:\CONFIG.DAT or F:\ENETALM.DAT file). For the basic unit configuration
information, files can be copied from an existing IDP or HMI to provide the
configuration for the Historian.
While the Mark V, Mark V LM, and Mark VI unit configuration information can be
copied from an IDP or HMI, some configurations tend to exist only on the Historian.
These are typically units connected through a PDD interface or a Modbus interface.
For these unit configurations, the files are often created on the Historian, either
manually or through a set of configuration tools.
The following table shows a list of the files typically used by the Historian, based on
the unit type. This table does not show all possible files in the F: drive, since many
are there to configure and download the unit - something that the Historian is not
required to do. (Mark V and Mark V LM unit configuration directories have many
more files, but since the configuration is a copy from the IDP or HMI, it is not
necessary to go into each one in detail. The other interfaces may require more tuning
on the Historian, so they are outlined here.)
File Name
ALARM.DAT
Internal
Mark IV
Mark V
Mark V LM
Mark VI
NA
ENGLISH.SCA
NA
ENUMDATA.DAT
NA
EVENT_B.SRC
NA
NA
HSTPOINT.SRC
LONGNAME.DAT
MMODBUSn.DAT
Modbus Master
NA
NA
NA
NA
PDDUMP.DAT
PDD
NA
NA
NA
NA
SOEINV_B.SRC
NA
NA
NA
NA
UNITDATA.DAT
A = used with all front end communication programs this controller supports.
ALARM.DAT. Defines the alarm text associated with each controller alarm. It
is only required for front-end communication programs that collect alarm, and is
used to build the Digital Exception History files.
ENGLISH.SCA. Converts the raw data value retrieved from the controller to an
engineering units value. Each point is assigned a scale code number, and this file
matches that scale code number to a gain and offset required to convert to the
English scale set. (Other *.SCA files can be used to convert the value to other
units, such as Metric or a Custom set of engineering units). Used to convert the
raw values from the controller into the engineering units value shown on displays
and passed to the PI Snapshot.
ENUMDATA.DAT. Maps the enumerated data values (retrieved from the

controller as an integer) to their associated text strings for display. Turbine
controllers that populate the Data Dictionary with enumerated state values
require this value if the results are to be displayed as a text string.
EVENT_B.SRC. Defines the list of digital signals that are considered events.
The Mark IV MSP front-end communication programs download this list of
events to the panel. (The Mark V and Mark V LM front end programs do not
need to download this to the controller, as that is done during the configuration of
the Mark V or Mark V LM). Enables the collection of events from a Mark IV via
MSP. The Historian automation tools use this file to ensure that the unit points
that are events are saved in history.
HSTPOINT.SRC. Used only by the Historian automation tools to define a list

of signals to be included in the PI Configuration and PI Historical Data. The tools
include all points in this file in the PI Configuration, and configure PI_PUSH to
send the value to the PI Snapshot database. (The Historian automation tools use
this file to configure points that are passed into the PI Snapshot and Archive
subsystems).
LONGNAME.DAT. Defines a long name or signal description to each signal.

The long name is also used as the digital exception message text for signals that
are not alarms, such as Event and SOE signals. (The Historian automation tools
use the long name defined here as the PI description text for the PI tag).
MMODBUSn.DAT. Defines the list of signals the Modbus Master front end
needs to collect from a device. It is only required when using a Modbus Master
front end, either serial or Ethernet. (The Historian uses this as the list of points to
collect via Modbus).
PDDUMP.DAT. Defines the contents of the Predefined Data Dump messages

being received from this controller. It is only required when using a PDD front
end. (The Historian uses this to interpret the PDD messages received from the
controller).
SOEINV_B.SRC. Interprets the Mark IV SOE messages, specifically whether

the SOE input needs to be inverted to get the correct sense of the logic signal.
The Mark IV implements an inversion mask to flip the sense of digital signals
prior to adding them to the Control Signal Database, but the SOE messages are
reported prior to that inversion. This file, used for Mark IVs reporting SOE
messages, defines the inversion mask so that the Historian can record the correct
digital exception message state.
UNITDATA.DAT. Defines the list of points to be saved in the Data Dictionary

for this unit. Each point must have a unique name and unique address within the
controller. Each point also defines a point type, which is used to indicate both the
number of bytes the controller reports for the point, and the algorithm to be used
to convert the raw binary value into engineering units. Most analog conversions
include a scale code, which is an index into the *.SCA files, to define a gain and
offset for the engineering units conversion.
Configuration File in the Windows Directory
EGD.INI. Specifies units from which to accept EGD information, and how to
map these into the EGD address space. This is only required when dealing with
controllers that send EGD messages over Ethernet, such as the Mark VI.
Historian Configuration
The Historians HST service uses the information contained in the F: Drive to
determine which units to communicate with, what data to collect, and how it is
displayed.
Only qualified personnel should make changes to the configuration

files. Any changes can have an impact on the unit data collection
When the HST service starts up, it uses a pseudo F: drive if one has been defined.
Otherwise, it creates a pseudo F: drive at the location specified by the TCI Control
Panel Applet in the HST Site tab. This is usually the C:\SITE directory. Users must
configure these files in the top level of the F: drive:
CONFIG.DAT
Shown and described below.
IO_PORTS.DAT
DSKMGR.DAT
EGD_PUSH.DAT
Shown and described below (Mark VI only).
ENETALM.DAT
Shown and described below (Mark VI only).
TIMESYNC.DAT
TIMEZONE.DAT
PI_PUSH.DAT
Shown and described in the PI Configuration section.
PICONFIG.DIF
Shown and described in the PI Configuration section.
The above files govern which units the Historian is able to communicate with, how
time synchronization is handled, and how the data points are collected and stored.
Modifications include modifying the files at the top level of F: to configure the site
parameters and units with which the Historian communicates.
The unit configuration directories are also located on the F: Drive. The detailed
descriptions for each type of unit configuration are discussed elsewhere in this
document. To summarize; the files of each unit configuration must be set up,
modified, and tuned to collect the proper data for historical storage. This is
accomplished by copying some files from the HMI, followed by directly editing the
files and employing the various Historian tools (programs) to build the units
historical collection data files.
F:\CONFIG.DAT
The F:\CONFIG.DAT file, shown below, is a text file that contains information about
the units with which the Historian can communicate, and the networks and network
addresses used. Each Historian contains a single F:\CONFIG.DAT file. The lines in
this file that begin with a semi-colon "; " are comments which do not affect operation
and are ignored by Historian programs. The section of the file shown in the example
defines the unit information for the Historian. Information in the UNIT_DATA
section denotes the unit(s) with which an Historian can communicate. Each line in the
section represents a particular unit; that is, the unit number, the unit name, and the
path to the unit's configuration information (its unit-specific directory). This
information is necessary to determine where the unit-specific files for a particular unit
reside. The cautions specified in the comment should be observed when making
modifications to this section, and the HST service must be restarted in order for the
changes to take effect.
There are two versions of F:\CONFIG.DAT that the Historian uses. The first is used
most frequently on systems with only Mark V and Modbus units, and is shown below:
;
; F:\CONFIG.DAT - HMI CONFIGURATION FILE
;
SITENAME
Power Station
;
;
;
;------------------------------------------------------------------------;
;
Section 2 - UNIT DATA DEFINITION
;
; This section defines the unit numbers, unit names, the path to the
; directory that contains the unit information for each Mark V control
; panel this is to communicate with, and the unit type (required when
; the Plant Load Control Option is enabled). Each line contains the
; unit number (decimal), the unit name (2 char max), the path to the
; unit configuration data (64 char max), and the unit type (decimal).
; Valid unit types are: (0 = Mark V), (1 = This ), (2 = Mark VLM).
; The unit numbers must be in order starting with one (1), and if a unit
; number is repeated, the last entry wins.
;
;
; UNIT
UNIT
PATH TO UNIT
UNIT
; NUMBER
NAME
CONFIGURATION DATA
TYPE
; ----------------------------UNIT_DATA
1
T1
F:\UNIT1
0
2
T2
F:\UNIT2
2
;
;
;
;-------------------------------------------------------------------------;
;
Section 3 - NETWORK (STAGE LINK) CONFIGURATION DEFINITION
;
; This section defines the network configuration for each node this is
; to communicate with. Each line contains the unit number (decimal),
; processor ("C" or "D"), the network number (decimal value), and the
; Stage Link ID (hexadecimal value).
;
;
STAGE
;
NETWORK LINK
; UNIT#
PROC NUMBER
ID
; -------- ------- ----NETWORK_DATA
1
C
1
FF
2
R
1
FC
;
;
;
;------------------------------------------------------------------------;
;
Section 4 - OPTION DEFINITION
;
; This section defines which options will be enabled each time the is
; re-booted or started up. The enabling of options during boot-up/re-boot
; is reported in G:\LOG\STARTUP.LOG.
;
OPTIONS
;
EPA_LOG
=YES
;
GSM
=YES
;
;------------------------------------------------------------------------; End of file. Please do not remove this line.
F:\CONFIG.DAT (second version)

The second and newer version of the F:\CONFIG.DAT file, shown below, supports
additional networks besides ARCNET and Modbus. This allows Ethernet
communication with Mark VI units, and either CSF or RS-232C serial
communications with Mark IV units. The Historian software, HST, version 1.4 or
newer, supports this version of CONFIG.DAT. This F:\CONFIG.DAT file is shown
below.
;
; F:\CONFIG.DAT - HISTORIAN CONFIGURATION FILE
;
; CONFIG.DAT - This file defines the overall configuration of the system.
; After making any changes, you will have to reboot the PC in order for
; the change to take effect.
;
;-----------------------------------------------------------------------------;
; This section defines the site name (16 char max)
;
SITENAME
Power Station
;
;-----------------------------------------------------------------------------;
; NETWORK TYPE - A definition of the networks this PC is on.
;
Network Number...... Decimal number 1-n
;
Network Type........ (STAGELINK, CSF, SERIAL)
;
Device Driver....... Name of the network driver used
;
MY LUN.............. This PCs assigned HEX MSP LUN (CSF, SERIAL only)
;
;
NETWORK NETWORK
DEVICE
MY
;
NUMBER
TYPE
DRIVER
LUN
;
------- ----------------NETWORK_TYPE
1
CSF
AnetDev0
0A02
2
STAGELINK
AnetDev1
****
;-----------------------------------------------------------------------------;
; UNIT DATA - A definition of the units
;
Unit Number......... Decimal number from 1-n
;
Unit Name........... 1 or 2 character unit name
;
Path to Config...... Directory path of unit configuration directory
;
Unit Type........... (MARKIV, MARKV, MARKVLM, MARKVI, HMI)
;
;
UNIT
UNIT
PATH TO
UNIT
;
NUMBER
NAME
CONFIG DATA
TYPE
;
---------------------UNIT_DATA
;
1
T1
F:\UNIT01
MARKIV
2
T2
F:\UNIT02
MARKV
3
T3
F:\UNIT03
MARKVI
4
T4
F:\UNIT04
MARKVLM
5
T5
F:\UNIT05
HMI
;
;-----------------------------------------------------------------------------;
; NETWORK DATA - A list of the network nodes we need to talk to.
;
Unit Number......... The unit number associated with this node
;
Processor........... The identity of the processor at this node address
;
Network Number...... The network this node is on
;
Network Address..... The HEX address of the node on this network
;
MSP LUN............. The nodes assigned HEX MSP LUN (CSF, SERIAL only)
;
;
UNIT
NETWORK
NET
MSP
;
NUMBER
PROC NUMBER
ADDR
LUN
;
--------- -----------NETWORK_DATA
1
C
1
FE
0401
2
C
2
FC
***
4
R
2
F8
***
;
;-----------------------------------------------------------------------------OPTIONS
;
;
The F:\CONFIG.DAT file, shown above, is configured with unit T1 as a Mark IV

communication over CSF. The NETWORK_DATA section for CSF and SERIAL
communication must contain the LUN number used in the corresponding unit control.
Note the NETWORK_TYPE settings, which define the CSF, Serial, and Stagelink
Networks that are used. The LUN for the Historian must appear in the
NETWORK_TYPE section for CSF and SERIAL Mark IV communication.
Unit T2 is a Mark V communicating over Stagelink.
Unit T3 is a Mark VI, and requires no network information in the

NETWORK_DATA section.
Unit T4 is a Mark V LM communicating over Stagelink.
Unit T5 is a Modbus Unit. Its Unit type is defined as HMI.
For Serial MSP (MAMSP) communications to Mark IV units, a separate network and
device driver must be configured for each Mark IV in the NETWORK_TYPE section
of the F:CONFIG.DAT file. Consider the following example of a NETWORK_TYPE
section set up to communicate to a Mark V, a CSF Mark IV, and three Serial MSP
(MAMSP) Mark IVs:

;
;
;
;
;
;
NETWORK NETWORK
DEVICE
MY
;
NUMBER
TYPE
DRIVER
LUN
;
------- ----------------NETWORK_TYPE
1
STAGELINK
AnetDev0
****
2
CSF
AnetDev1
0A02
3
SERIAL
MSP_3
0B01
;0B01 = top RS-232C port on unit
4
SERIAL
MSP_4
0B02
;0B02 = bottom RS-232C port on unit
5
SERIAL
MSP_5
0B01
;0B01 = top RS-232C port on unit
;------------------------------------------------------------------------------
Stagelink needs to be defined only once if there are Mark V units, as it can
communicate with multiple Mark V and Mark V LM units. CSF needs to be defined
only once if there are Mark IV units, as it can communicate with multiple units over
CSF.
Each Serial network defined must have a corresponding section in the
IO_PORTS.DAT file as discussed below.
F:\IO_PORTS.DAT
The Mark IV Serial Interface programs, the Modbus Master program
(MModbus.exe), the Modbus Slave program (Modbus.exe), the Mark IV Predefined
Data Dump Interface (PDDUMP.EXE), and the Emissions Analysis program
(EM_ANA.EXE) share a common configuration file entitled F:\IO_PORTS.DAT.
This file specifies important site variable data such as port, baud rate, and Modbus
slave id. This is a max case file and not all functions listed in the file are available.
;------------------------------------------------------------------------;
;
<HMI> PORT DEFINITION FILE - F:\IO_PORTS.DAT
;
;
; This file defines the serial ports that exist on this PC
; and that are to be controlled by TCI services.
;
;------------------------------------------------------------------------;------------------------------------------------------------------------;
; This section defines MODBUS SLAVE port and hardware characteristics.
; This section can be duplicated up to 8 times.
;
[MODBUS_SLAVE_PORT]
;port com2
port none
baud 9600
parity 0
;0-4 (none,odd,even,mark,space)
databits 8
;5-8
stopbits 0
;0-2 (1, 1.5, 2 stop bits) (1.5 stop bits currently unsupported)
xonxoff 0
;0-1
port_it 100
;Timeout interval between characters, msec. Default=40
port_tt 200
;Timeout for total message, msec. Default=200
;
; This section defines that the MODBUS can receive requests over the
; ethernet. There can only be one of these sections.
;
[MODBUS_SLAVE_PORT]
;port ethernet
port none
timeout 60
; no activity disconnect time in minutes (0 = disable)
Max_Connections 10
; Maximum number of socket connections allowed
;
; This section defines MODBUS address and software characteristics
;
[MODBUS_ASSIGNMENT]
;
;format1:
SLAVE nnn
UNIT uu
MODE keyword
;format2:
SLAVE nnn
CIMPLICITY project MODE keyword
; where:
nnn is the SLAVE address (in decimal) to recognize when sent
;
a message from a modbus master.
;
uu is the two character unit name (defined in F:\CONFIG.DAT)
;
project is the name of a Cimplicity project on this computer.
;
keyword is either RS16, RU16, UN12, HW12, or NATIVE for Signed 16,
;
Unsigned 16, Unsigned 12, Honeywell 12, and Native data
;
respectively.
;
;
SLAVE and MODE are required entries. UNIT or CIMPLICITY must also be
;
on a valid line.
;
A new line should appear for each definition. Normally this is one
;
or two lines for typical data patterns. A maximum of 16
;
definition lines may appear.
;
;SLAVE 1 UNIT <unit_name> MODE RS16
;SLAVE 2 CIMPLICITY <project_name> MODE RU16
;
; This section defines MODBUS timeout and Nak characteristics
;
[MODBUS_SLAVE_TIMEOUT]
modbus_timeout
4000
modbus_timeout_nak 6
;Time (milliseconds) before we give up and send nak

;Nak code used if unit timeout occurs.
;To use timeout, specify 4 or 6 only.
;To disable timeout, specify 0.
;
; This section defines MODBUS MASTER port and hardware characteristics.
;
[MODBUS_MASTER_PORT]
;1
port none
;port ethernet
;port com1
baud 9600
parity 0
databits 8
;5-8
stopbits 0
xonxoff 0
;0-1
port_it 50
port_tt 300
; After we send a message, this is how long we wait for a response
; Default 2000 msec., Minimum 100 msec., Maximum 60000 msec.
modbus_timeout 500
;Time (milliseconds) before we give up
; After we send all messages, this is how long we wait before we start over
modbus_loop
5000
;Time (milliseconds) before we restart request
tcp_port
;tcp_addr
tcp_timeout
502
;Specify tcp port to use.

;range 1-65000, default 502
127.0.0.1
20
;Specify the tcp port address using

;dotted number format (example: 127.0.0.1)
;or name format (example: division.company.com)
;default is 127.0.0.1
;tcp timeout in seconds when using ethernet
;If no reply in this period, close connection
;range 10-120, default 20 seconds
;format:
MASTER mmm UNIT uu
MODE keyword
; where:
mmm is the SLAVE address (in decimal) to use when
;
communicating with unit uu.
;
;
keyword is either RS16 or RU16 for Signed & Unsigned data
;
respectively.
;
;
UNIT, MODE, and MASTER are required entries.
;
A new line should appear for each unit. Normally this is one
;
;
MASTER-UNIT-MODE lines may appear.
;MASTER 5 UNIT MM MODE RS16
;2
;port com2
port none
baud 9600
parity 0
databits 8
;5-8
stopbits 0
xonxoff 0
;0-1
port_it 50
port_tt 300
; After we send a message, this is how long we wait for a response

modbus_timeout 500
; After we send all messages, this is how long we wait before we start over
modbus_loop
5000
;Time (milliseconds) before we restart request
;format:
MASTER mmm UNIT uu
MODE keyword
; where:
mmm is the SLAVE address (in decimal) to use when
;
communicating with unit uu.
;
;
keyword is either RS16 or RU16 for Signed & Unsigned data
;
respectively.
;
;
UNIT, MODE, and MASTER are required entries.
;
A new line should appear for each unit. Normally this is one
;
;
MASTER-UNIT-MODE lines may appear.
;MASTER 3 UNIT MM MODE RS16
;MASTER 4 UNIT MM MODE RU16
;3
port none
;------------------------------------------------------------------------;
;
Mark IV Predefined Data Dump Interface
;
;The Mark IV Predefined Data Dump Program, PDDump, is a program that receives
;ASCII data over an RS-232C-C input port on a GE HMI processor, checks the
;received data, and then stores the data into the data dictionary.
;
[PDDump_SETUP]
;port com2
port none
unit T1
baud 9600
parity 2
databits 8
stopbits 0
xonxoff 0
ic_timeout 500
[PDDump_SETUP]
;port com3
port none
unit T2
baud 9600
parity 2
databits 8
stopbits 0
xonxoff 0
ic_timeout 500
;unit name as specified in f:\config.dat

;5-8
;0-1
;intercharacter timeout, character times. Default=500

;5-8
;0-1
;------------------------------------------------------------------------;
;
Mark V LM Emissions Analysis Interface
;
; This is the setup definition file for the RS-232C-c link
; between the HMI and the Emissions Analysis System.
[em_ana_setup]
;port com2
port none
baud 9600
parity 0
unit T1
databits 8
stopbits 0
xonxoff 0
trailer 1
port_it 40
port_tt 200
;Unit name
;5-8
;0-1
;1=Linefeed termination. 2=Carriage return,linefeed term.
;------------------------------------------------------------------------;
;
Setup for serial MSP (MA/MSP)
;
; This section of IO_PORTS.DAT is tendered as an example setup for serial
; MSP based on a NETWORK_TYPE section in the file F:\CONFIG.DAT that
; contains the line:
;
;
NETWORK NETWORK
DEVICE
MY
;
NUMBER
TYPE
DRIVER
LUN
;
------- ----------------; NETWORK_TYPE
;
3
SERIAL
MSP_3
0B01
;
; The entry above, MSP_3, must match the section header below, [MSP_3].
; The "3" that appears as the first entry on the line above to represent
; the network number does not have to match, but it may be less confusing
; if they do match. The "0B01" is a hexadecimal representation of the
; LUN desired for MSP to use when communicating over the serial link.
; This will usually be 0B01 or 0B02 when communicating with a Mark IV.
; Set as appropriate.
;
[MSP_3]
;port com2
port none
baud 9600
parity 2
stopbits 0
;port_it 1000
;intercharacter timeout, 10-60000ms. Default=1000ms.
The configuration file is an ASCII based text file that can be modified with any
standard text editor. Lines are not case sensitive. The configuration file is divided into
sections and each section begins with a title enclosed in brackets [ ].
The Modbus Master program is used to communicate with BOP controllers

such as PLCs, or other control equipment that can be configured as a Modbus
Slave. The Modbus link can be over a serial line or Ethernet network. The
Modbus Master program uses one section:
[MODBUS_MASTER_PORT] defines a serial or Ethernet port as a Modbus
Master port. There are as many of these as there are Modbus Master ports. This
section may appear multiple times to define multiple ports.
The Mark IV Predefined Data Dump program is used to communicate with a

Mark IV control Predefined Data Dump, coming from a serial port on the <C>
controller. Multiple ports may be configured to handle additional Mark IV
controllers. The Mark IV Predefined Data dump uses one section:
[PDDUMP_SETUP] defines a serial port as a Predefined Data Dump port.
There will be as many of these as there are Mark IV Predefined Data Dumps.
This section can appear multiple times to define multiple ports.
The Serial MSP (MAMSP) program is used to communicate with the MAMSP
protocol over a serial line to a Mark IV unit control <C> processor. Multiple
ports can be configured to handle additional Mark IV controllers. These should
match the NETWORK_TYPE section of the F:\CONFIG.DAT file, as previously
discussed.
[MSP_3] defines a serial port for communication with a Mark IV. Each port
should have the format [MSP_n] where n is replaced with a number
corresponding to the definition in the F:\CONFIG.DAT file.
Modbus Slave is not available on the Historian, though the sections for it are
shown in the sample file. The Modbus Slave program uses three sections:
-
[MODBUS_SLAVE_PORT] defines a modbus slave port and its

characteristics. There are as many of these sections as there are slave ports.
One of these sections defines the Ethernet port if the modbus slave is to
respond to Ethernet messages. This section can appear multiple times to
define multiple ports.
[MODBUS_ASSIGNMENT] defines slave addresses and modes. These

slaves can be either Mark V or Mark V LM units, or CIMPLICITY projects.
[MODBUS_SLAVE_TIMEOUT] defines the slave timeout value and

NAK code.
The Mark V Emissions Analysis program is not available on the Historian,

though sections of it are shown in the sample file. The Emissions Analysis
program uses one section:
[EM_ANA_SETUP] - defines the RS-232C link between the HMI and the Emissions
Analysis System. A sample configuration file is available on the Historian in:
g:\data\io_ports.dat.
F:\DSKMGR.DAT
This data file is used by the Disk Manager program (DSKMGR.EXE). The program
attempts to prevent the free space on the historical storage drive from falling below
the number of Mbytes specified in the data file. The file text gives specific details.
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
F:\DSKMGR.DAT
The Disk Manager (DSKMGR) will remove non-PI data files from the
historical data directory upon the following conditions:
1) The data file data is older than the oldest point in the PI archive
files. This is determined by looking at the DS:DSKMGR point in the
PI Archive files.
2) The historical data directory disk is running out of disk space.
The Disk Manager will remove the oldest files from the historical data
directory that follow the following naming convention:
yyyymmdd_*.*
where yyyy
mm
dd
_
*
=
=
=
=
=
year
month
day
underscore
wildboard
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
10
;
;
Examples of these files are as follows:

yyyymmdd_ALM.D0% - Process Alarms
yyyymmdd_EVT.D0% - Events
yyyymmdd_SOE.D0% - Digital Inputs (SOEs)
The default historical data directory on the PC Historian is D:\HSTDATA.
The default historical data directory on an OSM is D:\OSMDATA.
The Disk Manager does not delete history from the PI Database nor does
it delete the PI Data Archives.
When deleting files because the historical data directory disk is running
out of free space, it will continue to delete the oldest files until
sufficient free space is available. By default, the goal is to provide
10 MB of free space. This goal can be changed by entering a number
between 1 and 100 MB at the end of this file. The number must start in
the first column.
F:\EGD_PUSH.DAT
This file is used at sites with controllers that use the EGD protocol over Ethernet,
such as the Mark VI controller. This file defines the list of signals that are to be read
from EGD and forwarded to the PI Snapshot. A gain and offset is available for analog
signals in case the engineering units in the EGD page are not the same as is desired in
the PI Snapshot or Archive files. The data file text describes the specific details.
;
;
;
;
F:\EGD_PUSH.DAT
This file defines the points that are copied from the <EGD> into the PI snapshot
database.
; This file is a list of the points to be pushed. There should be a unit definition
; before any list of point definitions. The format is @UNIT name.
; The format for a point definition is as follows:
;
; exchange# Offset Rev SDB Type PI name Gain Offset Quality min,max
;
; A prefix can be added to the PI pointnames. Prefixes are usually used to
; indicate unit names, so that the list of point names can be cloned from
; unit to unit very easily - changing only the prefix for the unit name.
;
; To use a prefix on all following pointnames use a special line starting with
; the command @PI_PREFIX. These commands take one [optional]
; parameter, the prefix to use. If no parameter is given then no prefix will
; be used. Examples:
;
@PI_PREFIX T1:
;
1 0 1 FLOAT
DWATT
;
@PI_PREFIX
;
1 0 1 FLOAT
T1:L4
;
;exch# Offset Rev SDB Type PI name Gain Offset Quality min,max
;----- ------ --- ------------- ---- ------ --------------@UNIT T8:
@PI_PREFIX T8:
1
0
1
Lint
FLAME
1
0
[*,*]
1
4
1
LInt
GCPR
1
0
[*,*]
1
8
1
Lint
GQIET_CT
1
0
[*,*]
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
2
12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
88
92
96
100
104
108
112
116
120
124
128
130
131
132
133
134
135
136
137
138
139
140
141
142
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
LInt
LInt
LInt
LInt
LInt
LInt
LInt
LInt
LInt
LInt
Lint
Lint
Lint
Lint
Lint
Lint
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
Bool
GQIFS_CT
1
GQIMIS_CT
1
GQITFH_CT
1
GQITS_CT
1
GXT_NUM_TC 1
MSG_FLD1
1
MSG_FLD2
1
MSG_FLD3
1
NORMAL
1
STATUS_FLD 1
GFSR_CONTROL 1
GQISC
1
GTKTTV
1
GTKTW
1
SELECT2
1
SPEED_LVL
1
GMN5135
1
GMSRTMGV
1
GMS5130_B
1
GMS5131
1
GMSTMGV
1
GMV5120C
1
GMV5120D
1
GVT4649
1
GXTM
1
GXTRXB
1
GXTSP1
1
GXTSP2
1
GXTSP3
1
GXTSPL
1
GQILC
1
PQKLSYNC
1
CGMLTG2
1
GMILTML
1
GMILTMR
1
GMYLTMTV
1
GMYLTMBK
1
GMYLTMTG
1
COPLLIFT_N 1
GMYLTCM_EN 1
CGMLSTCK
1
GTMLCD
1
GTNLPM
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
F:\ENETALM.DAT
This file is used at sites with controllers that use the ALM protocol over Ethernet,
such as the Mark VI controller. This file maps network IP addresses with unit
controllers, allowing the Historian to associate Ethernet messages received with the
unit that sent them. The data file text describes the specific details.
;
;
;
;
;
;
;
;
;
ENETALM.DAT - This file is used by the Ethernet ALARM RECEIVER program

to define how to interpret the data received. (In the future this
information will probably be coming from the SDB.)
There should be one line per Ethernet Alarm Generator node that this
computer is supposed to monitor. Simplex turbine controls will have one
node per unit, TMR turbine controls will have three nodes per unit.
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
UNIT:
This is the unit number for the turbine, and must agree with
the unit number assignments in the F:\CONFIG.DAT file.
PROC:
This is the processor specification, ( R | S | T ).
IP_ADDRESS:
This is the IP address assigned to this Ethernet Alarm Generator.
DEVICE: (optional, unused at the current time)
This is the device number assigned to this node.
Note: (This is currently not used by any program.)
Example:
;Unit Proc IP_Address

Device
;---- ---- --------------- -----; 1
R
192.168.1.1
46
; 2
R
192.168.1.4
47
; 2
S
192.168.1.5
47
; 2
T
192.168.1.6
47
;
;
;--------------------------------------------------------------------------;
Device
;---- ---- --------------- -----1
R
192.168.1.1
46
TIMESYNC.DAT
This section describes the F:\TIMESYNC.DAT file and how it configures the
TIMSYNC.EXE program. This data file configures the Historian to be either a
Stagelink Time Master or a Stagelink Time Slave. A high-resolution time master
requires high accuracy time hardware. A low-resolution time master uses the
Windows NT system clock as the time reference. A time slave adjusts its time to
match the time distributed by the time master.
The Stagelink Time Master sends time to all turbine controllers and time slaves
connected to the ARCNET/Stagelink.
Multiple time masters can be defined on a single Stagelink but only one PC can be the
Stagelink Time Master at any particular time. High-resolution time masters have
priority over low-resolution time masters. Within the high-resolution or lowresolution time masters, the time master with the lowest ARCNET address is the
Stagelink Time Master. If the Stagelink Time Master is removed from the Stagelink
the next time master becomes Stagelink Time Master. A PC that is configured as a
time master but is not the Stagelink Time Master becomes a Stagelink Time Slave.
Typically, the operator interface, or HMI, is setup as the Stagelink Time Master
and the Historian is setup as a Stagelink Time Slave. If the Historian is set as a time
master, fields in the Time Sync tab of the Control Panel applet TCI must be filled out.
Reference the TCI Control Panel Applet section of this manual for more information
on this.
The key lines in F:\TIMESYNC.DAT are shown below:
---------------------------------------------------------TIMESYNC [<controller> MODE <mode> [LEVEL_SHIFT] | LOWRES | SLAVE]

LOCAL_TIMESET
[ENABLED | DISABLED]
I_TIME
[LOCAL
| UTC]
MARKV_TIME
[LOCAL
| UTC]
TIME_SOURCE
[LOCAL
| UTC]
TIME_LOAD
[MANUAL | LOCAL |NETWORK]
----------------------------------------------------------
A template file for timesync is in G:\DATA\TIMESYNC.DAT. This template file can

be copied to F:\TIMESYNC.DAT and edited as required. An example of the template
file TIMESYNC.DAT is shown below:
;-------------------------------------------------------------------------;
;
Windows NT Style TIMESYNC Parameters.
Last Update: 3-JUL-1997
;
;
For use on: <I+>, Mark V HMI, and OSM.
;
; Any line beginning with a semicolon (;) is treated as a comment. All
; keywords are case-insensitive.
;
; The line beginning with "TIMESYNC" indicates the type of time
; synchronization in use. Acceptable syntax is one of the following:
;
1.) TIMESYNC <controller> MODE <mode> [LEVEL_SHIFT]
;
2.) TIMESYNC LOWRES
;
3.) TIMESYNC SLAVE
;
; Example (1) indicates high accuracy time acquisition hardware is in use.
; Hardware parameters such as I/O addresses are stored in the Windows NT
; Registry. Node-to-node time errors of +/- 1 millisecond are possible
; using this type of time synchronization.
;
; Example (2) indicates low-resolution time synchronization will be used.
; In this case, the Windows NT system clock is used as the time reference.
; Node-to-node time errors of +/- 10 milliseconds are typical using this
; type of time synchronization.
;
; Example (3) indicates that this computer will not act as a time master,
; but may set its local time to that of other time masters on the Stagelink.
;
; <controller> in Example (1) is one of the following keywords:
;
;
"BC620AT"
(from Bancomm, Division of Datum Inc.)
;
"BC627AT"
(from Bancomm, Division of Datum Inc.)
;
"TPRO-PC"
(from KSI, Division of Odetics Inc.)
;
;
; <mode> in Example (1) is one of the following keywords:
;
;
"IRIG-A"
IRIG-A Timecode.
;
"IRIG-B"
IRIG-B Timecode.
;
"NASA-36"
Nasa 36 bit timecode.
;
"2137"
2137 Timecode.
;
"1PPS"
1 pulse per second.
;
"1PPM"
1 pulse per minute.
;
"1PPH"
1 pulse per hour.
;
"FLYWHEEL"
Free Running Clock.
;
;
"LEVEL_SHIFT" is specified if the timecode is DC Level Shifted
;
rather than modulated. DCLS is not supported for 2137 timecode
;
signals.
;
; Different timeboards do not support all <mode> selections. The
; following table defines available combinations of timeboards and
; mode combinations:
;
;
TimeBoard
External Time References Supported
;
-----------------------------------------;
BC620AT
IRIG-A (Modulated and DC Level Shifted)
;
IRIG-B (Modulated and DC Level Shifted)
;
NASA-36 (Modulated and DC Level Shifted)
;
2137
(Modulated only)
;
1PPS, 1PPM, and 1PPH
;
FLYWHEEL
;
;
BC627AT
GPS
(Normal Mode for this card)
;
IRIG-A (Modulated and DC Level Shifted)
;
IRIG-B (Modulated and DC Level Shifted)
;
NASA-36 (Modulated and DC Level Shifted)
;
2137
(Modulated only)
;
1PPS, 1PPM, and 1PPH
;
FLYWHEEL
;
;
TPRO-PC
IRIG-B (Modulated only)
;
NASA-36 (Modulated only)
;
1PPS
(Requires -m option on board)
;
1PPM and 1PPH
;
FLYWHEEL
;
TIMESYNC SLAVE
;
;
;
;
;
;
"LOCAL_TIMESET [ENABLED | DISABLED]" is used to allow this computers

time to be set to the same time as the Stagelink Time Master. Note
this computer does not require a time/frequency board in order to be a
time slave.
LOCAL_TIMESET
;
;
;
;
;
;
;
;
;
"I_TIME", "MARKV_TIME" and "TIME_SOURCE" identify what timebase is used

in /<G> computers, Mark V control panel, and the externally supplied
Global Time Source. Choices are UTC and LOCAL.
NOTE: MARK V LM control panels always have UTC as their timebase.
This is not changeable. <I+>, Mark V HMI and OSM computers use
UTC as their internal timebase.
I_TIME
MARKV_TIME
TIME_SOURCE
;
;
;
;
;
;
;
;
ENABLED
LOCAL
LOCAL
UTC
"TIME_LOAD [MANUAL | LOCAL | NETWORK]" defines whether major time elements

(year, day-of-year etc.) are derived from the PC automatically (i.e. LOCAL);
or obtained from other Stagelink Time Masters (i.e. NETWORK),
or whether TIMESYNC functions are disabled until major time is entered
manually via TIMEUTIL (i.e. MANUAL).
This parameter is only needed for Example (1) above.
;
TIME_LOAD
;
;
;
;
;
;
;
;
LOCAL
"TIMESET <node-address>" is used when Mark V panels with older versions

of firmware exist on the Stagelink that do not support the timesync
protocol. In this case, this computer can act as a "repeating timeset"
computer, transmitting time every hour. <node-address> is the Arcnet
address in HEX and must be in the range 01-FF. There may be up to
32 "TIMESET <node-address>" lines specified in this datafile.
The files key words and their significance are listed below:
TIMESYNC. If the TIMESYNC line is missing, the operator interface will not
have Stagelink Time Master functions. However, the other lines may be specified
such that the operator interface is a time slave.
The TIMESYNC line may be setup using one of the following:
TIMESYNC <controller> MODE <mode> [LEVEL_SHIFT]
TIMESYNC LOWRES
TIMESYNC SLAVE
<controller>. is the name of the Time/Frequency Processor board:

[BC620AT
| BC627AT | TPRO_PC]
MODE <mode>. The keyword <mode> defines the type of global time source,
and is one of the following:
IRIG-B
Modulated IRIG-B Time Code Signal
IRIG-A
Modulated IRIG-A Time Code Signal (N/A for TPRO_PC)
NASA-36
Modulated NASA-36 Time Code Signal
2137
Modulated 2137 Time Code Signal (N/A for TPRO_PC)
1PPS
One pulse per second time input
1PPM
One pulse per minute time input
1PPH
One pulse per hour time input
FLYWHEEL
Use the Time Processing Board itself as the GTS
GPS
GPS Reference Signal (bc627AT only)
LEVEL_SHIFT. This is used if IRIG-x, NASA-36, or 2137 timecodes are dc

Level Shifted instead of modulated signals. This applies to bc620AT only.
TIMESYNC LOWRES. This statement implies that the Lower Accuracy Time
Synchronization option with software implementation only has been selected.
TIMESYNC SLAVE. This statement implies that the Lower Accuracy Time
Synchronization option with software implementation only has been selected and
that this interface can only be a Slave, never a Master.
LOCAL_TIMESET [ENABLED | DISABLED]. This line defines whether the

operator interface time is set to the time defined by the Stagelink time master
(ENABLED), or follows the CMOS clock (DISABLED).
I_TIME [LOCAL | UTC]. I_TIME is only applicable if the line

LOCAL_TIMESET ENABLED (above) exists in the data file. This customerspecified parameter defines whether the internal time of the HMI or is set to
UTC or Local Time.
MARKV_TIME [LOCAL | UTC]. This customer-specified parameter defines

whether the Mark V panel time is UTC based or Local Time based.
TIME_SOURCE [LOCAL | UTC]. This line specifies whether the Global

Time Source (GTS) is UTC based or Local Time based. This parameter applies
only to timecode GTSs; it does not apply to pulse input time sources.
TIME_LOAD [MANUAL | LOCAL | NETWORK]. This line enables or

disables the automatic loading of initial major time fields. No Stagelink
Timemaster will send time until all major time elements are loaded, and time is
locked to the GTS.
-
MANUAL. This disables the operator interface as a Stagelink time master

until major time elements are manually entered.
LOCAL. This specifies that major time is loaded automatically from the
operator interfaces CMOS clock.
NETWORK. This specifies that major time is loaded from another

Stagelink Timemaster, assuming multiple operator interfaces on the
Stagelink have Time/Frequency processor boards installed.
For IRIG-A, IRIG-B and NASA-36 timecodes, major time elements consist only of
the year (since these are time-of-year timecodes).
For 2137 timecode, major time consists of current year, month and day, as this is a
time-of-day timecode.
For pulse input styles of GTS, major time consists of current year, month, day, hour,
minute, and seconds.
Note TIME_LOAD LOCAL is not recommended for 1 PPS Global Time Sources,
since the CMOS clock may have errors in time on the order of several seconds.
Note All operator interfaces in a system must be setup in F:\TIMESYNC.DAT in an
identical fashion, with the exception of those computers not having a Time Processing
board installed. Failure to have identical system setup can cause shifts in the
Stagelink Time Reference upon power down of the primary Stagelink Time Master.
Note Operator interfaces not containing a Time Processing board should have the
identical lines in F:\TIMESYNC.DAT, but with the "TIMESYNC..." line commented
out.
TIMEZONE.DAT
This section describes F:\TIMEZONE.DAT, and the use of the TimeZone Make
(TZ_MAKE.EXE) utility program.
TIMEZONE.DAT defines the UTC time of transitions between Standard Time and
Daylight Savings Time. Each line defines the UTC time of the transition, and the
number of minutes to add to or subtract from the UTC based time to get to the
LOCAL time.
TIMEZONE.DAT can contain up to 100 entries. A minimum of three entries are

required. This allows a span of 50 years to be used for UTC/LOCAL time conversion
lookup. Below is an abbreviated sample output for the Eastern Timezone of the USA.
;
; TZ_MAKE Generated File.
;
; This file was created on: 29-JUN-1999 13:43:13 (UTC)
;
; NOTE: This file was created using a day-of-week and week-of-month
;
algorithm. This file may require editing if local laws
;
caused changes in actual standard/daylight transition dates.
;
; Standard Time Name: Eastern Standard Time
; Standard Time is entered on the last Sunday in October
; at 02:00:00 (Local Time)
;
;
; Daylight Time Name: Eastern Daylight Time
; Daylight Time is entered on the first Sunday in April
;
;-------------------------------------------------------------------------;
; Time Offset Definition Table. Each entry defines number of minutes
; correction to use when Universal Time Coordinated (UTC) crosses:
;
;
-----------UTC---------Minutes Correction to LOCAL Time
TIME_OFFSET
03-APR-1994 07:00:00.000
-240
TIME_OFFSET
30-OCT-1994 06:00:00.000
-300
TIME_OFFSET
02-APR-1995 07:00:00.000
-240
TIME_OFFSET
29-OCT-1995 06:00:00.000
-300
TIME_OFFSET
07-APR-1996 07:00:00.000
-240
TIME_OFFSET
27-OCT-1996 06:00:00.000
-300
TIME_OFFSET
06-APR-1997 07:00:00.000
-240
TIME_OFFSET
26-OCT-1997 06:00:00.000
-300
TIME_OFFSET
05-APR-1998 07:00:00.000
-240
TIME_OFFSET
25-OCT-1998 06:00:00.000
-300
TIME_OFFSET
04-APR-1999 07:00:00.000
-240
TIME_OFFSET
31-OCT-1999 06:00:00.000
-300
TIME_OFFSET
02-APR-2000 07:00:00.000
-240
TIME_OFFSET
29-OCT-2000 06:00:00.000
-300
TIME_OFFSET
01-APR-2001 07:00:00.000
-240
TIME_OFFSET
28-OCT-2001 06:00:00.000
-300
TIME_OFFSET
07-APR-2002 07:00:00.000
-240
TIME_OFFSET
27-OCT-2002 06:00:00.000
-300
TIME_OFFSET
06-APR-2003 07:00:00.000
-240
TIME_OFFSET
26-OCT-2003 06:00:00.000
-300
TIME_OFFSET
04-APR-2004 07:00:00.000
-240
TIME_OFFSET
31-OCT-2004 06:00:00.000
-300
TIME_OFFSET
03-APR-2005 07:00:00.000
-240
TIME_OFFSET
30-OCT-2005 06:00:00.000
-300
TIME_OFFSET
02-APR-2006 07:00:00.000
-240
TIME_OFFSET
29-OCT-2006 06:00:00.000
-300
TIME_OFFSET
01-APR-2007 07:00:00.000
-240
TIME_OFFSET
28-OCT-2007 06:00:00.000
-300
TIME_OFFSET
06-APR-2008 07:00:00.000
-240
TIME_OFFSET
26-OCT-2008 06:00:00.000
-300
TIME_OFFSET
05-APR-2009 07:00:00.000
-240
[Full file not shown]
TZ_MAKE is a utility program that builds TIMEZONE.DAT. It is a rule-based

program that calculates past and future date/times for transitions to/from Standard
Time from/to Daylight Time. It generates entries starting five years before the year in
which it is run, and generates 100 entries. For example, if TZ_MAKE is run in 1996,
it will generate entries spanning from 1991 through 2040 inclusive.
By default, TZ_MAKE uses the PC site local timezone information. This is the
preferred method.
To create F:\TIMEZONE.DAT using TZ_MAKE and the PC site local
timezone information.
From the Command Prompt, run the TZ_Make utility as follows. Type:
cd /d f:\
Press Enter.
TZ_MAKE timezone.dat
Press Enter. The f:\timezone.dat file is created. (see the sample file above)
Optionally, the user can define a "TZ" parameter to define the rules used to calculate
Standard/Daylight transition date, as described below.
To Create a F:\TIMEZONE.DAT using TZ_MAKE and the TZ parameter
to define the time zone.
From the Command Prompt, run the TZ_Make utility as follows. Type:
cd /d f:\
Press Enter.
TZ_MAKE timezone.dat "TZ=<timezone definition>"
Press Enter. The f:\timezone.dat file is created (see the sample file below)
The TZ parameter is defined as follows:
TZ= is used to define the rules on daylight savings to standard time transitions.
If TZ=<timezone definition> is specified, it must be enclosed in double quotes.
If TZ= argument is omitted, local Windows NT timezone rules are used.
<timezone definition> takes the following form (spaces are for clarity only).
std offset dst offset, rule std, dst are strings containing three or more characters and
spaces.
std
is the name to use for Standard Time.
dst
is the name to use for Daylight Savings Time.
offset takes the form HH[:MM[:SS]], optionally preceded by "+" or "-"

These indicate the values to add to LOCAL time to arrive at Universal Time
Coordinated (UTC).
"-"
indicates the local area is East of the Prime Meridian.
"+"
indicates the local area is West of the Prime Meridian.
rule std, dst takes the form of date/time, date/time

Where the first date/time defines the transition from Standard Time to Daylight
Savings Time, and the second date/time defines the transition from Daylight Savings
Time to Standard Time.
date
is specified in the form Mm.n.d,

where:
m = month (1= January, 2 = February, .....12 = December)
n = week of the month (1 = 1 st week, 2 = 2nd week, 3 = 3rd week, 4 = 4th
week, 5 = last d day of the month)
d = day of the week (0 = Sunday, 1 = Monday, .....6 = Saturday)
time
takes the form HH[:MM[:SS]] as above, but may not have "+" or "-"
specified in front of HH.
The following is a sample definition for Central Timezone of the U.S.A:
TZ_MAKE timezone.dat "TZ=Central Standard Time6Central Daylight Time5,M4.1.0/2,M10.5.0/2"
This example used the "TZ=" construct to define the transitions for Central Time
USA. It shows that Central Standard Time is 6 hours earlier than UTC, and that
Central Daylight Time is 5 hours earlier than UTC.
Daylight Savings Time begins on the first Sunday in April at 02:00:00.
Standard Time begins on the last Sunday in October at 02:00:00.
An abbreviated sample output is as follows:
;
; TZ_MAKE Generated File.
;
; This file was created on: 20-NOV-1996 20:06:32 (UTC)
;
; NOTE: This file was created using a day-of-week and week-of-month
;
algorithm. This file may require editing if local laws
;
caused changes in actual standard/daylight transition dates.
;
; The TZ argument used to create this text file was:
;
;
"TZ=Central Standard Time6Central Daylight Time5,M4.1.0/2,M10.5.0/2"
;
; Standard Time Name: Central Standard Time
; Standard Time is entered on the last Sunday in October
;
;
; Daylight Time Name: Central Daylight Time
; Daylight Time is entered on the first Sunday in April
;
;-------------------------------------------------------------------------;
; Time Offset Definition Table. Each entry defines number of minutes
; correction to use when Universal Time Coordinated (UTC) crosses:
;
;
-----------UTC---------Minutes Correction to LOCAL Time
TIME_OFFSET
07-APR-1991 08:00:00.000
-300
TIME_OFFSET
27-OCT-1991 07:00:00.000
-360
TIME_OFFSET
05-APR-1992 08:00:00.000
-300
TIME_OFFSET
25-OCT-1992 07:00:00.000
-360
TIME_OFFSET
04-APR-1993 08:00:00.000
-300
TIME_OFFSET
31-OCT-1993 07:00:00.000
-360
TIME_OFFSET
03-APR-1994 08:00:00.000
-300
TIME_OFFSET
30-OCT-1994 07:00:00.000
-360
TIME_OFFSET
02-APR-1995 08:00:00.000
-300
TIME_OFFSET
29-OCT-1995 07:00:00.000
-360
TIME_OFFSET
07-APR-1996 08:00:00.000
-300
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
TIME_OFFSET
27-OCT-1996
06-APR-1997
26-OCT-1997
05-APR-1998
25-OCT-1998
04-APR-1999
31-OCT-1999
02-APR-2000
29-OCT-2000
08-APR-2001
28-OCT-2001
07:00:00.000
08:00:00.000
07:00:00.000
08:00:00.000
07:00:00.000
08:00:00.000
07:00:00.000
08:00:00.000
07:00:00.000
08:00:00.000
07:00:00.000
-360
-300
-360
-300
-360
-300
-360
-300
-360
-300
-360
[Full file not shown]
Note The resulting TIMEZONE.DAT file may require editing if local laws change
the actual transition times normally used by a given locale.
TCI Control Panel Applet

The Turbine Control Interface (TCI) Control Panel applet is used to adjust parameters
used by the Interface. Incorrect values in some of these entries can cause the Interface
to not work correctly. Most of the changes do not take affect until the system is
rebooted or the correct services are stopped and restarted.
To open the TCI Control Panel applet
1.
From the Desktop, click on Start, then Settings, then Control Panel.
2.
Double click on the TCI Turbine Interface icon. The Turbine Control
Interface dialog window displays with the following tabs.
Auto Login Tab

Auto Login causes the computer to login as the defined user when it is rebooted, or
when the current user logs off. To override the auto login when it is enabled, upon
reboot, pres and hold the shift key down after the desktop background displays, and
release when the login window displays.
Disabled/Enabled - If disabled is selected, the computer does not try to auto

login the user. If enabled is selected, the computer tries to automatically login the
user defined below.
Username is the name used to login if auto login is enabled.
Domain is used by the login if auto login is enabled. It is usually the computer
name assigned to this computer.
Password is used by the login if auto logon is enabled.
Password Verify must match the entry in Password. If they do not match, there
is a warning and request to enter them again.
ARCNET Tab
This tab configures the parameters the ARCNET driver uses to talk to the ARCNET
board. The jumpers on the board must be set to match these parameters for the
ARCNET driver to work. An ARCNET tab is shown on the Turbine Control Interface
Control Panel applet for each ARCNET board on the Historian.
Base IO Address is the IO Address set on the ARCNET board.
Base Memory Address is the memory address set on the ARCNET board.
Interrupt Number is the interrupt number set on the ARCNET board.
ARCNET Link Address is the address of the ARCNET board on the ARCNET
network. All boards on the network must have a unique address.
Type defines the type of Network used, either Stagelink, or CSF.
HST Site Tab

The TCI Site tab configures the default Site parameters for the Historian Service
(HST).
Site Directory is the directory for all the site information. The F: drive is set to
point to this directory.
Default Scale is used to display information. It can be set to any scale that is
defined in the data dictionary, but should match the scale type for the points
defined in the PI Database.
Time Sync Tab

This tab configures the type of time synchronization hardware on the Turbine Control
Interface. Each individual application has its own configuration information.
Time Acquisition Hardware configures the type of time synchronization

hardware to use:
-
None - This computer is not a time master.
Low Resolution - This computer can be a time master using the internal PC
clock.
High Resolution - This computer can be a time master using a highresolution time board. This option is only available if a high-resolution time
board was installed when the Historian was setup.
High Resolution Time Board configures the parameters for the high-resolution
time board. This section is only available if a high-resolution time board was
installed when the Historian was setup, and High Resolution is selected in the
section above.
-
Base IO Address - This is the base IO address set on the time board.
Board Type - This is the type of high-resolution time board installed.
Unit Configuration
The Historian can be configured to communicate to several different types of
controllers. It can be configured for internal units such as Modbus Master and PDD,
and for Mark IV units, both CSF and RS-232C interfaces. It can be configured for
Mark V and Mark V LM units, using an ARCNET interface, and for collecting data
from the Mark VI over Ethernet. The following sections describe these unit
configurations.
Modbus Configuration (Master Only)

The Modbus interface for the Historian acts as a master to a Modbus slave.
Modbus master mode supports RS-232C serial communications and Ethernet. In
Modbus master mode, the Historian gathers data from attached Modbus slaves. The
data gathered is requested and stored in the Historian data dictionary using points and
update rates specified in a Modbus data file.
The rate at which the data can be collected is limited by the transmission rate on the
RS-232C link or Ethernet, by the turn-around times of the computers on each end of
the link, and by the periodic rate specified in the configuration data file. The Modbus
master, configured with the appropriate address, requests data from a Modbus slave at
a specified rate. A single Historian can communicate with multiple slave addresses
over various communication ports. A maximum of eight communication ports may be
used to communicate with up to 48 separate slave addresses.
Specifications
The Modbus interface uses Gould Modicons Modbus Protocol. The following text
provides application information only, it does not specify Modbus protocol. Detailed
information on the Modbus protocol is available from Gould Inc.s Reference Guide
PI-MBUS-300 Rev B January 1985 (Note that this is not the Modbus Plus
specification). It is recommended that both this document and the Gould reference
guide be used together.
The Modbus slave can be located anywhere within the restrictions of the RS-232C
serial communication link, or anywhere on the Ethernet link.
External Communication Links

External communication links allow the Historian to communicate with Modbus
slaves over serial or Ethernet communication ports, up to eight. Communication is
possible with up to 48 different Modbus slaves. For each Modbus slave, the data
communicated is specified by the contents of a data file found in the unit directory.
This file specifies what data is read from the slave and stored in the data dictionary,
and also what data is sent (written) to the slave.
RS-232C and Modbus

The RS-232C link transmission rate makes it satisfactory for one or two units on a
single communication link, depending on the amount of data that is requested for
transmission. It has a 19,200-baud (bit/sec) transmission rate, but lacks individual
time tags for alarms and events.
The communication link load is a function of the amount of data that is requested and
how often it is transmitted. An evaluation of the link load for a specific application
requires a review of the amount and frequency of the data transmission(s), and the
specified baud rate, and verification that all is within the desired sampling rate.
Physical Link Layer/Format, RS-232C Communications

The followinf defines the physical link layer/format of the Modbus serial link.
Link Layer
Each Historian can provide up toeight point-to-point Modbus RS-232C serial links,
and a defined number of Ethernet connections. Since the master may communicate
with multiple slaves, each slave sends data upon request only. No periodic data
transmission from a slave is possible, except as a reply to a periodically transmitted
request sent from the Historian.
Physical Layer
The Historian communicates to the Modbus slaves using the Historians Ethernet or
serial communications ports. If a serial port is not available, a serial expander board
can be used to supply eight more serial ports. The port used is configured with a
DB9P plug connector as Data Terminal Equipment (DTE). Diagrams showing this
connection are provided below.
The system is asynchronous RS-232C compatible, 300 to 19,200 baud, programmable
parity. It is compatible with full duplex data sets (modems). Modem generated signals
such as CTS (Clear to Send), CD (Carrier Detect) and RI (Ring Indicator) are not
required to enable the transmitter. The RTS (Ready to Send) and the DTR (Data
Terminal Ready) signals on the Historian are always equal to 1 when the Historian is
powered up. This prohibits any multi-drop Modbus configurations, as these signals
cannot enable or disable communications. Hardware handshaking (flow control via
RTS/CTS signals) is not supported.
GE Industrial Systems does not recommend remote control of turbine products over a
telephone modem due to the inherent unreliability in this type of communication. If it
is necessary to collect data or operate over telephone modems, the maximum number
of bits that can be communicated is usually ten. Therefore the standard eight bits of
Modbus data and the two bits for start/stop is all that can be accommodated. This
means that PARITY is not typically supported over telephone modems. RS-232C
systems require two metallic shielded twisted pair wires to connect the short-haul
modems.
RS-232C Transmission Distances with Modems
Baud
Rate
26 Gauge
Miles
km
24 Gauge
Miles
km
22 Gauge
Miles
km
19 Gauge
Miles
km
300
10.0
16.1
12.0
19.3
15.0
24.1
25.0
40.2
1200
6.0
9.7
7.5
12.1
9.0
14.5
15.0
24.1
2400
4.5
7.2
5.5
8.9
7.5
12.1
11.0
17.7
4800
3.5
5.6
4.5
7.2
5.5
8.9
7.0
11.3
9600
2.2
3.5
3.2
5.1
4.0
6.4
5.0
8.0
19200
1.0
1.6
1.2
1.9
1.5
2.4
2.0
3.2
Note RS-232C connections are limited to 50 feet (15 meters) without the use of
modems.
While modems are supplied by GE Industrial Systems, the customer must supply the
cabling and terminations. The standard modems supplied by GE require power on pin
four. The modem connected to the Historian obtains its power from the serial port.
The other modem must receive power from pin four on the slave. If the slave device
cannot supply power, the optional modem set is required and must be specified when
ordering from GE. This set is powered by an external source.
Slave Device
DB25P (DTE)
Typical Historian
DB9P (DTE)
RXD
TXD
RTS
CTS
SCOM
CD
DTR
DSR
RI
(2)
(3)
(7)
(8)
(5)
(1)
(4)
(6)
(9)
Cable
TXD
RXD
RTS
CTS
SCOM
NC
NC
Common (not shielded)
NC
NC
NC
NC
(2)
(3)
(4)
(5)
(7)
RS-232C connection to DB9 serial port with no modems
In the above diagram, NC means there is No Connection.
Historian
DB9P (DTE)
RXD
TXD
DTR
SCOM
(2)
(3)
(4)
(5)
Data Set
(Modem)
(2)
(3)
(4)
(5)
S1-2
S2-1
R1-4
R2-3
Shielded
Twisted
Pair wire
Data Set
(Modem)
Slave Device
R1-4
R2-3
S1-2
S2-1
RXD
TXD
V+
SCOM
(2)
(3)
(4)
(5)
Cable
RS-232C connection to DB9 serial port with modems
In the above system, V+, the slave device power, is 3-5 mA at 10 V dc. It is
nominally 12 V dc, with a minimum 6 VDU, and maximum 25 V dc.
Typical Historian
DB9P (DTE)
RXD
TXD
RTS
CTS
SCOM
CD
DTR
DSR
RI
(2)
(3)
(7)
(8)
(5)
(1)
(4)
(6)
(9)
Data Set
LDDS
Data Set
LDDS
(3)
(2)
S1
S2
R1
R2
NC
NC
R1
R2
S1
S2
(3)
(2)
(4)
(5)
(7)
(8)
(7)
NC
NC
NC
NC
AC Power
Slave Device
DB25P (DTE)
RXD
TXD
RTS
CTS
SCOM
CD
(3)
(2)
(4)
(5)
(7)
(8)
AC Power
Optional RS-232C connection with Limited Distance Data Set (LDDS)
The LDDS Data Set is a short haul modem. The slave device and the cabling are
supplied by the customer. If a DB9 pin connector is used instead of a DB25 pin
connector, change the connections as shown below:
Typical Historian
DB9P (DTE)
RXD
(2)
TXD
(3)
RTS
(7)
CTS
(8)
SCOM (5)
CD
(1)
DTR
(4)
DSR
(6)
RI
(9)
Data Set
Data Set
Slave Device
LDDS
LDDS
DB9P (DTE)
(3)
(2)
NC
NC
S1
S2
R1
R2
R1
R2
S1
S2
(3)
(2)
(4)
(5)
(7)
(8)
(7)
NC
NC
NC
NC
AC Power
RXD
TXD
RTS
CTS
SCOM
CD
(2)
(3)
(7)
(8)
(5)
(1)
AC Power
RS-232C connection with Limited Distance Data Set (LDDS) & DB9 connector
Modbus Configuration
Additions and/or modifications to the configuration files on an Historian are used to
accomplish the following:
Enable and configure the Modbus task on the Historian.
Enable and configure a serial port for Modbus communication.
Set up the Modbus mapping tables.
F:\IO_PORTS.DAT: Modbus Link Definition

The Modbus Master program, MModbus.exe, uses a configuration file entitled
F:\IO_PORTS.DAT to specify important site variable data such as port, baud rate,
and Modbus slave id. The configuration file is an ASCII based text file that may be
modified with any standard text editor. Lines are not case sensitive. The configuration
file is divided into sections and each section begins with a title enclosed in brackets
[ ].
The Modbus Master program uses one section. Other sections are ignored. The
section is entitled: [MODBUS_MASTER_PORT].
This may appear multiple times to define multiple ports.
The F:\IO_PORTS.DAT file is used to define Modbus Master ports via RS-232C or
Ethernet. To customize F:\IO_PORTS.DAT, use the standard text file editor.
There is more detailed information available in a sample configuration file in
G:\DATA\IO_PORTS.DAT.
Modbus Master Setup

Refer to examples in Modbus
Master Configuration
This Modbus Master program first reads the section file called
MODBUS_SETUP_FILE file (filename F:\IO_PORTS.DAT) for information
specifying Modbus port and hardware characteristics. This section,
[MODBUS_MASTER_PORT], provides details such as:
Port, baud rate, parity, and other items, for example: port com2
MODBUS address and software characteristics. This provides details such as

slave address and unit number. Up to 48 master entries may be specified, for
example: MASTER 3 UNIT MM MODE RS16 FILE MMDATA.DAT
MODBUS timeout and loop characteristics, for example:

modbus_timeout 2000
This program ignores Modbus slave assignment entries in the

MODBUS_SETUP_FILE.
The program then reads a MODBUS_DATA_FILE (or several) in the unit directory
for information specifying a correspondence between Modbus data structures
(holding registers, holding coils, input registers, input coils) and the corresponding
data dictionary points and scaling information. The MODBUS_DATA_FILE resides
in the unit directory (F:\UNITn) and is specified either by default or by direct
specification. If the file is directly specified, the filename is taken following the string
FILE in the MASTER-UNIT-MODE line. If defaulted, the file has a filename in the
form MMBUSnnn.DAT where nnn is the slave address being referenced. Multiple
MMBUSnnn.DAT files may exist in the same directory. For example, if the
F:\IO_PORTS.DAT file specified that we communicate with slave address 3 and 4,
storing 16 bit signed data into the unit MM directory with a pair of lines such as:
MASTER 3 UNIT MM MODE RS16
MASTER 4 UNIT MM MODE RS16
Then the Modbus Master program reads file MMBUS3.DAT and MMBUS4.DAT
from the unit directory to determine the register and coil correspondence. Leading
zeros for nnn are not used.
If the default filename is overridden, the format is:

MASTER 3 UNIT MM MODE RS16 FILE MMDATA.DAT
and the Modbus Master program reads file MMDATA.DAT from the unit directory to
determine the register and coil correspondence. Only the filename is specified to
override the default filename; a directory such as F:\UNITn\ must not be specified.
Next, the program opens the port specified above, and uses the port to send messages
to one of its 48 slave addresses. The port may be serial or Ethernet.
Upon receiving a message reply, the program stores the data in the unit data
dictionary as appropriate.
Devices with Modbus

Slave over RS-232C
or Ethernet
Capability
Historian
MODBUS
MASTER
F:\IO_PORTS.DAT
F:\UNITn\MMBUSn.DAT
Data Dictionary
F:\CONFIG.DAT
F:\UNITn\ENGLISH.SCA
PI_PUSH
F:\PI_PUSH.DAT
PI Snapshot
Database
PI Archive Database
Modbus Master Configuration & Data Flow Diagram
Modbus Master Configuration

This section describes the Modbus Master sections in the port definition/configuration
file, F:\IO_PORTS.DAT, and in the data configuration files,
F:\UNITn\MMBUSnnn.DAT.
In the port definition/configuration file, F:\IO_PORTS.DAT, comments are specified
by a semicolon. Any semicolon makes the remainder of the line a comment and is
ignored.
There is only one section used by the Modbus Master entitled:
[MODBUS_MASTER_PORT], but this section may appear up to 8 times. Each
appearance should correspond to a separate communications port for the Modbus
Master. For example, the first [MODBUS_MASTER_PORT] section may be for
COM2 while the next section might be for COM3.
These sections should appear as above, including brackets. They may appear in any
order. Sections other than [MODBUS_MASTER_PORT] are ignored by this
program. Data lines following each section specify configuration information.
For the section [MODBUS_MASTER_PORT], example data lines are:
port
com2
;port ethernet
baud
9600
parity
0 ;0-4 (none,odd,even,mark,space)
databits 8 ;5-8
stopbits 0 ;0-2 (1, 1.5, 2 stop bits)
xonxoff
0 ;0-1
port_it
4 ;Timeout interval between characters, msec. Default=40
;Normally, port_it should specify 3.5 character times as
;defined by the Modbus Gould specification. At 9600 baud,
;and 8 data bits, 1 start, and 1 stop bit, this yields
;a character time of 1.04 msec. 3.5 character times would
;therefore be 3.125 msec.
port_tt 200 ;Timeout for total message, msec. Default=200
;This is time to receive message only, not process it.
modbus_timeout 2000
;waiting for a response from a slave.
;Default timeout is 2000 milliseconds.
;Minimum timeout is
100 milliseconds.
;Maximum timeout is 60000 milliseconds.
modbus_loop
5000
;Time (milliseconds) before we restart
;the request loop. This is the period
;between asking the slave(s) for all the
;data specified and the time we start
;over and reask.
;Default loop is
5000 milliseconds.
;Minimum loop is
100 milliseconds.
;Maximum loop is 86400000 milliseconds.
tcp_port
502
;Specify tcp port to use.
;range 1-65000, default 502
tcp_addr
127.0.0.1 ;Specify the tcp port address using
;dotted number format (example: 127.0.0.1)
;or name format (example: division.company.com)
;default is 127.0.0.1
tcp_timeout
20
;tcp timeout in seconds when using ethernet
;If no reply in this period, close connection
;range 10-120, default 20 seconds
MASTER 1 UNIT 62 MODE RS16 FILE filename1
MASTER 2 UNIT T3 MODE RS16 FILE filename2
port
com3
baud
9600
MASTER 7 UNIT 63 MODE RU16
The above example defines two ports for use with the Modbus Master. Both COM2
and COM3 are used. Modbus slave ids 1 and 2 are reached using COM2 and Modbus
slave id 7 is reached using COM3.
port,
-
Serial, specify COM1, COM2, ...COMn.
Modbus over Ethernet, specify "Ethernet"
disable, specify "none"
baud, specify baud rates supported by the operating system.

parity, specify 0 for none, 1 for odd, 2 for even, 3 for mark, or 4 for space.
databits, always specify 8
stop bits, specify 0 for 1 stop bit, 1 for 1.5 stop bits, or 2 for 2 stop bits.
xonxoff, specify 0 to disable.
port_it, specify intercharacter timeout as desired based on slave transmission.
The Modbus specification specifies 3.5 character times. For 9600 baud in the
example above, 4 msec is appropriate for strict Gould specification adherence.
port_tt, specify the total time permitted to RECEIVE a message from the slave,
starting from receipt of the first character. Normally it will be most convenient to
make this number high and use only the intercharacter timeout, port_it.
tcp_port, specify the tcp port to use. The range is 1-65000, and default 502.
tcp_addr, specify the tcp port address using dotted number format, for example:
127.0.0.1, or name format, for example:
division.company.com.
The default is 127.0.0.1
tcp_timeout, specify a tcp timeout in seconds when using Ethernet. If no reply is
received in this period, the connection will be closed and retried. The range is 10120, default 20 seconds.
The only required entries are port and MASTER-UNIT-MODE. Baud defaults to
9600. Parity, databits, stopbits, and xonxoff default as shown in the example above.
Port_it defaults to 40. Port_tt defaults to 200.
For the MASTER-UNIT-MODE line:
Format: MASTER mmm UNIT uu MODE keyword FILE filename,
where:
mmm is the SLAVE address (in decimal) used when communicating with unit
uu.
uu is the two-character unit name (defined in F:\CONFIG.DAT).
keyword is either RS16 or RU16 for Signed & Unsigned data respectively.
FILE filename is optional as discussed above.
MASTER, UNIT, and MODE are required entries. A new line should appear for
each unit or slave address. Normally this is one or two lines for typical data
patterns. A maximum of 48 MASTER-UNIT-MODE lines may appear.
Each line requires:
MASTER followed by a slave entry specifying a Modbus Slave id number.
UNIT followed by a two-character unit id. These IDs correspond to the units
already defined in F:\CONFIG.DAT.
MODE followed by RS16 or RU16. For analog data, use RS16 for signed mode,
RU16 for unsigned. RS16 specifies a signed result, ranging from a minimum of 32768 (hex 8000) to a maximum of 32767 (hex 7FFF). RU16 specifies an
unsigned result, ranging from a minimum of zero to a maximum of 65535 (hex
FFFF). Raw data from the slave will be rescaled based on the minimum and
maximum numbers provided in the F:\UNITn\MMBUSnnn.DAT (or specified
data file) and written to the Data Dictionary.
FILE followed by a filename overrides the default datafile,
F:\UNITn\MMBUSnnn.DAT
Modbus Configuration: Holding Coils, Input Coils, Holding

Registers, Input Registers
Each Historian that collects Modbus data must have a Modbus Mapping file
(MMbusnnn.dat) for each slave address. This file contains mapping tables to associate
the registers and coils with data dictionary pointnames.
There are two categories of point mapping tables, holding and input. The Modbus
protocol supports reading and writing of holding table points, and reading but not
writing of input table points. The Historian does not make any restrictions on what
pointnames can be in the input and holding tables.
The Modbus protocol defines two types of data: Coils and Registers. Coils are logic
or boolean signals that use a single bit to indicate the state. Registers are 16-bit values
used for analog signals or bit packed logic signals. The Modbus protocol also defines
two signal classes: Input and Holding. Input points are signals that can be read from
the slave device but not written. Holding points are signals that can be read from or
written to the slave device. Since Holding points can be read and written, the
Historian uses the term Holding to read holding class points, and the term Written to
write holding class points. (Historians seldom use the Written class, but it is available
as part of the Modbus Master program.)
HC, WC holding coils one bit logic signals that are both readable and
writable. To read from a slave, specify HC, to write, specify WC.
IC input coils one-bit logic signals that are readable but not writable.
HR, WR holding registers 16-bit analog signals that are both readable and
writable. To read from a slave, specify HR, to write, specify WR.
IR input registers 16-bit analog values that are readable but not writable.
A sample MMBUSnnn.DAT file is listed below:
;
;
MODBUS.DAT for Modbus Master
;---------------------------------------------------------;
;
;HOLDING COILS (1)

;------------HC9
L5
;
;
;INPUT COILS (2)
;----------IC0001
L1
IC0002
L2
IC0003
L3
;
;HOLDING REGISTERS (3)
;--------------;REGISTER
SIGNAL
;NUMBER
NAME
HR0002
ABC2
HR0003
ABC3
HR0004
ABC4
HR0005
ABC5
HR0006
ABC6
HR0007
ABC7
;
;INPUT REGISTERS (4)
;--------------;REGISTER
SIGNAL
;NUMBER
NAME
IR0001
ABC1
IR0005
DEF1
IR0006.1
L6
IR0006.2
L7
IR0006.3
L8
IR0006.4
L9
IR0006.5
L10
;
;WRITE HOLDING COIL (5)
;-----------------WC0004
L4
;
;WRITE HOLDING REGISTER
;---------------------WR0010
ABC10
WR0011
ABC11
MINIMUM
CDB VALUE
-200
-200
-200
-200
-200
-200
MAXIMUM
CDB VALUE
2000
2000
2000
2000
2000
2000
MINIMUM
CDB VALUE
-200
-2147483648
MAXIMUM
CDB VALUE
2000
2147483647
;SCALE TYPE
;TC
;TC
;TC
;TC
;TC
;TC
;SCALE TYPE
;TC
(6)
-200
-200
2000
2000
;TC
;TC
Use the following rules and guidelines when adding or modifying entries in this file:
It is not necessary to define all the table points in this file, only the ones that are
desired.
Never define a bit of a packed holding register (such as HR0001.1) as @SPARE.

Defining just one of the bits as packed defines the entire register as a packed
register. A "0" is returned for bits not mapped.
When a semi-colon is found in a line, the rest of the line is considered a

comment.
Add scaling information or definitions in this file for analog registers.
Never add page breaks (form feeds) in this file.
The table entries may be in any order.
Do not map any one register to both packed logic pointnames and to an analog
pointname.
Do not have any one coil or register mapped more than once.
Group similar points together, such as temperatures, speed signals, or command

feedback signals.
From the example, not all table points are defined or in order, comments are added
using a semi-colon ( ; ), and there are no duplicate table point definitions. However,
the rules outlined above were followed and the file can therefore be considered
correct.
The HST Service must be restarted for changes to take effect. After the service has
restarted, look for error and warning messages reported in the MMODBUS.LOG or
MMODBUSn.LOG files in the G:\LOG directory.
Description of Modbus_Data_File
Comments are specified by a semicolon. Any semicolon makes the remainder of the
line a comment and is ignored. Each line has three required entries and two
conditional entries:
Format: Table_Type Table_Point Pointname [MIN_VALUE] [MAX_VALUE]
where:
Table_Type is one of six kinds: HC IC HR IR WC WR
Table_Point is 1 through 65536 with a maximum RANGE of 2000 permitted.
For example, if the lowest holding coil used is HC2001 and the highest holding
coil used is HC4000, then the range of 2000 points has not been exceeded. If the
highest holding coil used is HC4001, the range is exceeded and an error will be
logged.
Pointname is a valid data dictionary pointname.
MIN_VALUE represents the minimum data dictionary value corresponding to
the smallest possible Modbus value. This field is required for analog points but
cannot be used for logic points.
MAX_VALUE represents the maximum data dictionary value corresponding to
the largest possible Modbus value. This field is required for analog points but
cannot be used for logic points.
Table_Types WR and WC have been added for write register and write coil capability
to the Modbus slave.
Modbus Data Format and Scaling

Modbus Data Conversions: Logic Signals. Logic signals can be exchanged
with the slave using either coils or registers. Coil data conversion corresponds to a
single logic signal with the LSB indicating its state.
When registers are used to transmit logic signals , each bit corresponds to the state of
a logic signal. A register having 16 bits corresponds to a group of up to 16 logicals,
with the least significant bit being the first logic signal in the group, and the MSbit as
the last logic signal in the group. The two bytes are packed into the Modbus message
using the normal rules for MSB and LSB order. The values of undefined bits in a
packed register are transmitted as "0". Read carefully for details on the modes used in
transmission of data, as some modes may not be suitable for bit packed registers.
Modbus Data Conversions: Analog Signals. Analog signals are exchanged

using registers. Since slave devices handle analog signals in different ways, such as
12-bit positive numbers, the Historian may be configured to exchange analog data in
one of several modes. The following modes are currently supported to meet customer
needs. This section defines how to convert each data type to engineering units.
The conversion algorithms presented here define the conversion process at the most
understandable level. The implementation of these algorithms does not always follow
these algorithms directly as there are many different schemes used to prevent
mathematical overflows in computations. The choice of the final implementation is
left to the Modbus slave vendor.
RS16. If a point is of data type SIGN16, it is a signed 16-bit number. In this mode,
the most significant bit of the 16-bit analog signal is treated as a sign bit, where a one
is used for negative values. C2 type signals are transmitted modulo 32768 to prevent
the sign bit from being set. H2 and X2 types are transmitted directly with an assumed
value of (-32768 to +32767). The convention of assuming the raw value is a fraction
from -1.0 to +1.0 was used in defining the Modbus Gain and Offset. This allows the
Gain to indicate the maximum (and minimum) value when the Offset is zero. The
Modbus listing file defines the Modbus Gain and Offset required to convert the value
into engineering units, with the conversion being:
Engineering units = (Raw_value) / 32768 * GAIN + OFFSET
For example, Thermocouples are scaled with a gain of 2048 and an offset of 0 for
conversion to Degree F. If the register value is 1120, the conversion to engineering
units is:
Engineering units = (1120) / 32768 * 2048 + 0
Engineering units = 70 Deg F
RU16. If a point is of data type UNS16, it is an unsigned 16-bit number. This mode
transmits F2 analog signals as unsigned 16 bit numbers by adding 32768. The most
significant bit therefore turns from a sign bit into a bit with a weight of 32768. This
transforms the range of F2 signals to [0,+65535]. The Modbus listing file defines the
Modbus Gain and Offset required to convert the value into engineering units, with the
conversion being:
Engineering units = (Raw_value) / 65536 * GAIN + OFFSET
Example 1: If an UNS16 is used for a normal counter, the raw value is the value of
the counter. If a counter has the value of 418, it is converted as follows:
Engineering units = (418) / 65536 * 65536 + 0
Engineering units = 418
Example 2: A number that is normally a signed number in the Mark V is requested as
an unsigned number. If the register value of a thermocouple is requested, it shows that
in UNS16 mode the Modbus Gain is 4096, and the Offset is -2048 for Deg F. The
conversion of the raw data value of 33888 to engineering units is as follows:
Engineering units = (33888) / 65536 * 4096 2048
Engineering units = 70 DEG F
Converting a SIGN16 to an UNS16 causes no loss of resolution.
Modbus Command and Response Definition

This section describes the commands and responses supported by the Historian to
implement the required Modbus communications and control functions. The Historian
is a master station on an RS-232C or Ethernet data link, and expects a response from
the slave to commands. Messages are transmitted and received using the RTU
transmission mode, which is one of two Modbus transmission modes, where RTU
transmits data in eight bit bytes. The other mode, where characters are transmitted in
ASCII, is not supported. The RTU transmission mode uses the format below (where
slave address, function code, CRC-16 MSB, CRC-16 LSB are all bytes):
SLAVE
ADDRESS
FUNCTION
CODE
CRC=16
(MSB)
...DATA...
CRC=16
(LSB)
RTU Transmission Mode

slave address a number from 0 to 255, specifying the unit with which to
communicate (a slave address of zero is considered a broadcast message to all slaves).
function code specifies the purpose and format of the remaining message portion.
CRC-16 this is two bytes that complete each and every Modbus message. The
abbreviation CRC stands for Cycle Redundancy Check, MSB stands for Most
Significant Byte, and LSB stands for Least Significant Byte. These bytes are used for
error checking and are calculated for each transmitted and received message to insure
that no transmission error has occurred while the message was in transit. The method
for calculating the CRC-16 is a public protocol, and is described in numerous
textbooks and the Gould Modicon Modbus Protocol Reference Guide. Please refer to
these other documents for information on calculation of a correct CRC. Modbus over
Ethernet adds the header below to the message formats. All the same functions are
supported over Ethernet that are supported over the serial ports.
INV
INV
ID
ID
(MSB) (LSB)
PROTO PROTO
LEN
LEN
ID
ID
(MSB) (LSB)
(MSB) (LSB)
STANDARD SERIAL
FUNCTION MESSAGE
invocation id not used by the Historian Modbus.

proto id not used by the Historian Modbus.
length is the byte count of the remaining part of the message. This is used by the
Historian Modbus to receive the rest of the message. The rest of the message is
exactly what is sent and received over the serial connections.
Message Errors
Any messages that are misunderstood, incomplete, or altered in some manner, as
indicated by a framing error, parity error, or CRC-16 error, are always ignored. The
Historian detects this timeout condition and resends the message as necessary. The
timeout values are controlled in the F:\IO_PORTS.DAT file, refer to Modbus Master
Configuration above.
Any time a message receipt is in progress and an interval of time corresponding to 3.5
character times (based on the baud rate) occurs without receipt of a character, the
message receipt in progress is stopped and ignored. Message failures due to other
causes are handled through retries. The exception code responses that are supported,
when a normal response is impossible, are shown in the chart below.
Exception Code Responses

Exception
Code Name
Meaning
01
Illegal Function
The message function received is not supported
02
Illegal Data Address
The address referenced in the data field is not in a

permissible range.
03
Illegal Data Value
The value transmitted in the data field is illegal.
04
Failure in Associated
Device
Information requested cannot be provided due to a

communication failure with associated unit as
specified by the slave address.
06
Device Busy
Information requested cannot be provided due to a

communication time out with the associated unit as
specified by the slave address.
The format of the exception message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE
EXCEPTION
CODE
CRC=16
(MSB)
CRC=16
(LSB)
Exception Code Response Format

slave address must be in the range [1-255]. Zero is not allowed as a reply, as it is
only used in broadcast messages from the master.
function code is always equal to the masters function code with the most
significant bit set. Therefore, an exception response sent back to a master that has sent
a message with function code 02 hex would have a function code of 82 hex (or 130
decimal) in the exception reply.
exception code as shown in chart below.
Slave Device Function Codes
Function Code, Hex
Description
01
Read Holding Coils
02
Read Input Coils
03
Read Holding Registers
04
Read Input Registers
05
Force (Write) Single Holding Coil
06
Preset (Write) Single Holding Register
07
Read Exception Status
08
Diagnostic
0F
Force (Write) Multiple Holding Coils
10
Force (Write) Multiple Holding Registers
This chart lists the function codes supported by the Historian, included in the
messages sent from the Modbus slave. Six of the eight function codes implemented in
the Historian are used to read from, and/or write to, the four table types. See the
above sections regarding mapping tables. Each function code and the reply are
described below.
Function Code 01: Read Holding Coils. Function code 01 is used to read the
holding coil table.
The format of a message from the master is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 01
START
COIL #
(MSB)
START
COIL #
(LSB)
NUMB
COILS
(MSB)
NUMB
COILS
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)
slave address must be in the range [1-255], zero is not allowed.

starting holding coil number two bytes in length and may be any value less than
the highest holding coil number available in the holding coil table. The starting
holding coil number is equal to one less than the number of the first holding coil
returned in the normal response to this request; that is, to get the first holding coil,
holding coil number 1, enter 0 for the starting holding coil number. The high order
byte of the starting holding coil number field is sent as the first byte. The low order
byte is sent next.
number of holding coils value two bytes in length and must be in the range from 1
to 2000 inclusive. It specifies the number of holding coils returned in the normal
response. The sum of the starting holding coil value and the number of holding coils
value must be less than or equal to the highest holding coil number available in the
holding coil table. The high order byte of the number of holding coils field is sent as
the first byte. The low order byte is sent next.
The format of a normal message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 01
BYTE
COUNT
DATA
BYTE 1
DATA
BYTE 2
.....
DATA
BYTE n
CRC=16
(MSB)
CRC=16
(LSB)
byte count is a binary number from 1 to 250; the specified number of data bytes
follow.
data field is the packed holding coil status data. Each byte contains eight holding
coil values. The LSbit of the first byte contains the value of the holding coil whose
number is equal to the starting holding coil number plus one. The value of the holding
coils are ordered by number starting with the LSbit of the first byte of the data field
and ending with the MSbit of the last byte of the data field. If the number of the
holding coils is not a multiple of eight, then the last data byte contains zeros in one to
seven of its highest order bits.
Function Code 02: Read Input Coils. Function code 02 is used to read the input
coil table.
SLAVE
ADDRESS
FUNCTION
CODE 02
START
COIL#
(MSB)
START
COIL#
(LSB)
NUMB
COILS
(MSB)
NUMB
COILS
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)
starting input coil number two bytes in length and may be any value less than the
highest input coil available in the input coil table. The starting input coil number is
equal to one less than the number of the first input coil returned in the normal
response to this request, that is, to get the first input coil, input coil number one, enter
zero for the starting input coil number. The high order byte of the starting input coil
field is sent as the first byte. The low order byte is sent next.
number of input coils value two bytes in length and must be in the range from 1 to
2000 inclusive. It specifies the number of input coils returned in the normal response.
The sum of the starting input coil value and the number of input coils value must be
less than or equal to the highest input coil available in the input coil table. The high
order byte of the number of input coils field is sent as the first byte. The low order
byte is sent next.
The format of a normal message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 02
BYTE
COUNT
DATA
BYTE 1
DATA
BYTE 2
.....
DATA
BYTE n
CRC=16
(MSB)
CRC=16
(LSB)
byte count binary number from 1 to 250; the specified number of data bytes follow.
data field is packed input coil status data. Each byte contains eight input coil
values. The LSbit of the first byte contains the value of the input coil whose number
is equal to the starting input coil plus one. The value of the inputs are ordered by
number starting with the LSbit of the first byte of the data field and ending with the
MSbit of the last byte of the data field. If the number of the input coils is not a
multiple of eight, then the last data byte contains zeros in one to seven of its highest
order bits.
Function Code 03: Read Holding Registers. Function code 03 is used to read
holding registers.
SLAVE
ADDRESS
START
REG #
(MSB)
FUNCTION
CODE 03
START
REG #
(LSB)
NUMB
REGS
(MSB)
NUMB
REGS
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)

starting holding register number is two bytes in length and may be any value less
than the highest holding register number available in the holding register table. The
starting holding register number is equal to one less than the number of the first
holding register returned in the normal response to this request, that is, to get the first
holding register number, holding register number one, enter zero for the starting
holding register number. The high order byte of the starting holding register number
field is sent as the first byte. The low order byte is sent next.
number of holding registers value is two bytes in length and must be in the range
from 1 to 128 inclusive. It specifies that the number of holding registers returned in
the holding registers value must be less than or equal to the highest holding register
number available in the holding register table. The high order byte of the number of
holding registers field is sent as the first byte. The low order byte is sent next.
The format of normal message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 03
BYTE
COUNT
FIRST
REGSTR
(MSB)
FIRST
REGSTR
(LSB)
....
LAST
REGSTR
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)
byte count even binary number from 2 to 254, or zero. If the byte count is zero (0),
then the master assumes 256 data bytes follow. Otherwise, the specified number of
data bytes follow. The byte count specifies the total number of bytes in the message
following the byte count, not including the two CRC-16 bytes.
holding registers are returned in the data field in order of number with the lowest
number holding register in the first two bytes, and the highest number holding register
in the last two bytes of the data field. The number of the first holding register in the
data field is equal to the starting holding register number plus one. The high order
byte is sent before the low order byte of each holding register.
Function Code 04: Read Input Registers. Function code 04 is used to read
input registers.
SLAVE
ADDRESS
FUNCTION
CODE 04
START
REG #
(MSB)
START
REG #
(LSB)
NUMB
REGS
(MSB)
NUMB
REGS
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)

starting input register number is two bytes in length and may be any value less
than the highest input register number available in the input register table. The
starting input register number is equal to one less than the number of the first input
register returned in the normal response to this request, that is, to get the first input
register, input register number one, enter zero for the starting input register number.
The high order byte of the starting input register number field is sent as the first byte.
The low order byte is sent next.
number of input registers value is two bytes in length and must be in the range
from 1 to 128 inclusive. It specifies the number of input registers returned in the
normal response. The sum of the starting input register value and the number of input
registers value must be less than or equal to the highest input register number
available in the input register table. The high order byte of the number of input
registers field is sent as the first byte. The low order byte is sent next.
The format of normal message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 04
BYTE
COUNT
FIRST
REGSTR
(MSB)
FIRST
REGSTR
(LSB)
.....
LAST
REGSR
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)
byte count even binary number from 2 to 254, or zero. If the byte count is zero (0),
then the master is to assume 256 data bytes follow. Otherwise, the specified number
of data bytes follow. The byte count specifies the total number of bytes in the
message following the byte count, not including the two CRC-16 bytes.
input registers are returned in the data field in order of number with the lowest
number input register in the first two bytes, and the highest number input register in
the last two bytes of the data field. The number of the first input register in the data
field is equal to the starting input register number plus one. The high order byte is
sent before the low order byte of each input register.
Function Code 05: Force Single Holding Coil. Function code 05 is used to
force (or write) a single holding coil in the holding coil table.
SLAVE
ADDRESS
FUNCTION
CODE 05
HOLDING
COIL #
(MSB)
HOLDING
COIL #
(LSB)
STATE
00H OR
0FFH
00H
CRC=16
(MSB)
CRC=16
(LSB)

holding coil number is two bytes in length and may be any value less than the
highest holding coil number available in the holding coil table. The holding coil
number is equal to one less than the number of the holding coil forced, that is, to
change the first holding coil, holding coil number one, enter zero for the holding coil
number. The high order byte of the starting holding coil number field is sent as the
first byte. The low order byte is sent next.
state byte sent by the master with only two possible values. A zero is sent (00h) to
turn the specified holding coil off (set false). A value of 255 is sent (FFh) to turn the
specified holding coil on (set true). The state byte is always followed by a single byte
with value zero.
The format of a normal message reply from the slave is identical to the received
message.
Function Code 06: Preset Single Holding Register. Function code 06 is used
to preset (or write) to a single holding register.
SLAVE
ADDRESS
FUNCTION
CODE 06
HOLDING
REG #
(MSB)
HOLDING
REG #
(LSB)
REG
DATA
(MSB)
REG
DATA
(LSB)
CRC=16
(MSB)
CRC=16
(LSB)

holding register number is two bytes in length and may be any value less than the
highest holding register number available in the holding register table. The holding
register number is equal to one less than the number of the holding register changed
by this request, that is, to change the first holding register, holding register number
one (1), enter zero (0) for the holding register number. The high order byte of the
starting holding register number field is sent as the first byte. The low order byte is
sent next.
holding register data field is two bytes in length and contains the value to which
the holding register specified by the holding register number field is preset. The first
byte in the data field contains the high order byte of the preset value. The second byte
in the data field contains the low order byte.
The format of a normal message reply from the slave is identical to the received
message.
Function Code 07: Read Exception Status. Function code 07 is used to read
the exception status data, defined as the first eight holding coils. These can be used to
indicate slave controller status or condition of any other state. Function code 07 thus
provides a short form of request for the purpose of reading these first eight holding
coils, holding coils one through eight.
SLAVE
ADDRESS
FUNCTION
CODE 07
CRC=16
(MSB)
CRC=16
(LSB)

Format of normal message reply from the slave is shown below:
SLAVE
ADDRESS
FUNCTION
CODE 07
DATA
BYTE
CRC=16
(MSB)
CRC=16
(LSB)
data byte field the normal response is packed holding coil status data. The data
byte contains eight holding coil values. The LSbit of the byte contains the value of the
holding coil number one (1). The MSbit contains the value of holding coil number
eight.
Function Code 08: Diagnostic. Function code 08 is used to get diagnostic data.
The Historian does not use this function code.
Function Code 0F: Force Multiple Holding Coils. Function code 0F is used to
force (or write) multiple holding coils in the holding coil table.
START START
SLAVE FUNCTION
COIL# COIL#
ADDRESS CODE 0F
(MSB) (LSB)
NUMB
NUMB
BYTE
DATA
COILS COILS
COUNT BYTE 1
(MSB) (LSB)
DATA
BYTE
....
DATA CRC=16 CRC=16

BYTE n (MSB) (LSB)

start coil number is two bytes in length and may be any value less than the highest
holding coil number available in the holding coil table. The holding coil number is
equal to one less than the number of the holding coil forced, that is,. to change the
first holding coil, holding coil number one, enter zero for the holding coil number.
The high order byte of the starting holding coil number field is sent as the first byte.
The low order byte is sent next.
number of holding coils value two bytes in length. It specifies the number of
holding coils to set. The sum of the starting holding coil value and the number of
holding coils value must be less than or equal to the highest holding coil number in
the holding coil table. The high order byte of the number of holding coils field is sent
as the first byte. The low order byte is sent next.
byte count is the number of data bytes to follow.
data field is packed holding coil data. Each byte contains eight holding coil values.
The LS bit of the first byte contains the value of the holding coil whose number is
equal to the starting holding coil number plus one. The value of the holding coils are
ordered by number starting with the LSbit of the first byte of the data field and ending
with the MSbit of the last byte of the data field. If the number of the holding coils is
not a multiple of eight, then the last data byte contains unused data in its highest order
bits.
Format of normal message reply from the slave is identical to the received message
without the byte count or the data.
Function Code 10: Preset Multiple Holding Registers. Function code 10 is

used to preset (or write) to a multiple holding registers.
START START
SLAVE FUNCTION
REG # REG #
ADDRESS CODE 10
(MSB) (LSB)
REG
REG
NUMB
NUMB
BYTE
DATA 1 DATA 1
REGS
REGS
COUNT
(MSB) (LSB)
(MSB) (LSB)
....
REG
CRC=16 CRC=16
DATA n
(MSB) (LSB)
(LSB)

start register number is two bytes in length and may be any value less than the
highest holding register number available in the holding register table. The holding
register number is equal to one less than the number of the holding register changed
by this request, that is, to change the first holding register, holding register number
one (1), enter zero (0) for the holding register number. The high order byte of the
starting holding register number field is sent as the first byte. The low order byte is
sent next.
number of holding registers value two bytes in length. It specifies the number of
holding registers to set. The sum of the starting holding register value and the number
of holding registers value must be less than or equal to the highest holding register
number in the holding register table. The high order byte of the number of holding
registers field is sent as the first byte. The low order byte is sent next.
byte count is the number of data bytes to follow.
Register data field is two bytes for each holding register to set. The first byte in the
data field contains the high order byte of each preset value. The next byte contains the
low order byte.
Format of normal message reply from the slave is identical to the received message
without the byte count or the data.
Modbus Master Diagnostics

When debug is on (on by default), the global section trace buffer may be viewed with
the command:
gbl2file MModbus_trace# <some_file_name>
where # is 1,2,3,...8 depending on which [MODBUS_MASTER_PORT] section

corresponds to the information we want. If only one [MODBUS_MASTER_PORT]
section exists, then the global section trace command can be viewed with:
gbl2file MModbus_trace1 modbus1.log
This displays some debugging and program status information.

If the program encounters a serious error or warning, the result is placed into a log file
as well as the global section trace buffer. The user should check file
G:\LOG\MModbus#.log , where # is defined as above.
Statistics. The Modbus Master program gathers statistics and makes counters
available for diagnostic purposes. The program MM_stat.exe has been especially
designed as a console program to communicate with the Modbus Master program and
retrieve/control these diagnostic counters. Running MM_stat displays these counters as
shown:
mm_stat
Modbus Master statistical summary:

Modbus Master 1.
4815 = Count of messages sent by Modbus Master.
0 = Count of bad messages sent by Modbus Master.
4815 = Count of successful replies.
0 = Count of exception replies.
0 = Count of message timeouts.
0 = Count of buffer full, read error, etc..
0 = Count of CRC errors.
0 = Count of bad received messages.
Modbus Master 2.
4815 = Count of messages sent by Modbus Master.
0 = Count of bad messages sent by Modbus Master.
4745 = Count of successful replies.
0 = Count of exception replies.
45 = Count of message timeouts.
0 = Count of buffer full, read error, etc..
0 = Count of CRC errors.
25 = Count of bad received messages.
When multiple Modbus Masters appear, each group corresponds to a separate port as
specified in the F:\IO_PORTS.DAT file.
The counters can be reset by passing "reset" as a parameter to the MM_stat program.
The "reset" option is case insensitive and does not include the quotation marks.
Modifying Modbus Historical Data Collection and Storage

To modify the historical collection of Modbus data, modify the HSTPOINT.SRC data
file. This file contains the list of logic and analog points to be put in historical storage.
For HST versions 1.3 and earlier, it contains the significant change in counts for
analog points. For HST versions 1.4 and higher, it can contain the significant change
in Engineering Units and optional High and Low plot limits for analog points. Points
may be added to, or deleted from, the file. Significant change, High, and Low plot
limits may be modified for analog points.
The HSTPOINT.SRC file may contain all of the Modbus unit points, or a subset of
the points. A point must be listed in the UNITDATA.DAT file to be valid for storage
in the PI database. Any point in the UNITDATA.DAT file may be added to
HSTPOINT.SRC. These points should also have their associated longnames defined
in LONGNAME.DAT, and all points must reference a valid scale code in the
ENGLISH.SCA file.
To modify historical collection & storage of Modbus data

1.
Modify the HSTPOINT.SRC file as described previously in this chapter.
2.
From the command line prompt within the F:\UNITn directory, run the Historian
Database Tool Unit Level, G:\EXEC\HSTDBU.EXE. This creates new
PI_PUSH.U and PICONFIG.U files.
3.
From the command line prompt within the F:\ directory, run the Historian
Database Tool System Level, G:\EXEC\HSTDBS.EXE. This uses the unit level
files to create new PI_PUSH.DAT and PICONFIG.DIF files.
4.
Stop the HST service. The Historian data collection stops.
5.
Update the PI database with the new PICONFIG.DIF file.
6.
Start the HST service. The Historian data collection starts.
Refer to the section on Historian Database Tools for specifics on these steps. A step
by step procedure is available in the section Configuring Data Collection in the
Chapter Application Notes.
Data Dump Configuration

Communications with a Mark IV Turbine Control System is provided using several
available network types, including the MA/MSP serial communications package, and
the PDD.
The Mark IV PDD, when enabled, provides a periodic dump of data values
corresponding to a list of preconfigured data points. For example, a common Mark IV
PDD configuration provides a data dump every one second via an RS-232C port.
Each message contains approximately 256 bytes. This data message contains the
current status of alarms and important turbine data values such as speed, vibration,
and fuel flow.
The Historian Predefined Data Dump Interface allows the Historian to capture this
data. PDDump is a program that receives ASCII data over an RS-232C input port on
the Historian, checks the received data, and then stores the data in the data dictionary.
Mark IV Turbine Control Software Configuration

The PDD is predefined and cannot be modified by the customer. Changes are made
only by factory modification of the Programmable Read Only Memory (PROM) chips
in the Mark IV.
The Historian needs to be configured to be compatible with the data dump received
from the Mark IV. Data format as transmitted from the Mark IV Turbine Control is
specified in the as-shipped elementary diagrams, and should be referenced to
determine which data is transmitted.
HST Software Configuration

The PDD is configured through the data file entitled F:\IO_PORTS.DAT. This file is
created (or modified if it already exists) to specify port and data information. The file,
F:\IO_PORTS.DAT, is an ASCII text section file containing one or more primary
section headers. Each section is determined by a line in the file containing a section
title enclosed by square brackets, [ ]. The section header specifying the PDD is
[PDDUMP_SETUP].
Sample. The following is an example of the F:\IO_PORTS.DAT file.

[PDDUMP_SETUP]
port com2
unit M4
baud 9600
parity 0
databits 8
stopbits 0
xonxoff 0
ic_timeout 500

;5-8
;0-2 (1, 1.5, 2 stop bits)
;0-1
Port data consists of zero or more of these section headings entitled

[PDDUMP_SETUP]. If no file is found, or if zero port section headings are detected,
the program terminates and no Mark IV data dump function will be supported. Any
file changes do not become effective until restart of the HST Service. If one or more
port section headings are found, then the program runs and supports the specified
ports. A maximum of eight section headings may be specified; each port section
heading must specify a different port. Section headers are case insensitive.
Rules. The following rules should be followed when creating a
[PDDUMP_SETUP] section (or sections) in the F:\IO_PORTS.DAT file:
A semicolon is used as a comment character for the remainder of each line.
In the [PDDUMP_SETUP] section(s), several port and unit characteristics are

specified by including a keyword and a corresponding data value on a separate
line. Available keyword are:
PORT, UNIT, BAUD, PARITY, DATABITS, STOPBITS, XONXOFF,
IC_TIMEOUT
Keywords are case insensitive. Each keyword must appear on its own line
followed by one or more spaces and a corresponding data value. Extra spaces and
comments may be added as desired.
The keyword port specifies the name of the RS-232C port where data is
received. Do not follow the port name with a colon. This entry is required. It is
the responsibility of the user to insure that there is no port conflict between the
port specified for Mark IV Predefined Data Dump, and ports used by other
programs such as a mouse device, or a Modbus port.
The keyword unit specifies the data dictionary unit name where the data is to be
stored. The unit name is a maximum of two characters long. Specify the unit
desired for the possible units supported. See the UNIT_DATA section in
F:\CONFIG.DAT for valid unit names. This entry is required.
The keyword baud specifies the baud rate desired. Specify the baud rate as a
whole number, using any of the standard PC baud rates supported. Do not use the
letter K to mean a thousand. This entry is required.
The keyword parity specifies the parity used. Specify 0 when no parity bit is
used, specify 1 when odd parity is used, specify 2 when even parity is used,
specify 3 when mark (always 1) parity is used, and specify 4 when space (always
0) parity is used. This entry is required.
The keyword databit specifies the number of bits per character. Specify a
number between 5 and 8 inclusive. This entry is required.
The keyword stopbits specifies the number of stop bits used. Specify 0 to use 1
stop bit, specify 1 to use 1.5 stop bits, and specify 2 to use 2 stop bits. This entry
is required.
Mark IV with
Predefined Data
Dump Capability
PREDEFINED
DATA DUMP
Historian
F:\IO_PORTS.DAT
F:\UNITn\PDDUMP.DAT
Data Dictionary
F:\CONFIG.DAT
PI_PUSH
F:\PI_PUSH.DAT
PI Snapshot
Database
PI Archive Database
Predefined Data Dump Configuration & Data Flow Diagram
The keyword xonxoff enables or disables the control-S, control-Q flow control.
Specify 1 to enable. This entry is required.
The keyword ic_timeout specifies a timeout interval between characters. This

number represents the NUMBER OF CHARACTER TIMES before the message
is stoped and ignored. For example, if ic_timeout is 500 with a baud rate of 9600,
no parity and one stop bit, then we have:
Number of bits per character = 10 (8 data bits, 1 start, 1 stop, 0 parity bits)
One character time = 10 bits/9600 baud = 1.04 msec
500 character times = 521 msec
This does not affect timing BEFORE the first character. This entry defaults to 500.
Corresponding to each section heading in the F:\IO_PORTS.DAT file appears a

data file entitled PDDump.DAT in the appropriate unit directory. For example,
if F:\IO_PORTS.DAT has a [PDDUMP_SETUP] section that refers to unit T1,
and unit T1 is assigned to the directory F:\UNIT1 in the file F:\CONFIG.DAT,
then the PDDump program reads file F:\UNIT1\PDDump.DAT for a list of
points to be received from this Mark IV turbine control unit.
The following is an example portion of PDDump.DAT file.
;channel number_of_bytes DDname

1
6
TIME
1
4
TIMR_01
1
4
TIMR_02
1
4
CNTR_01
1
4
CNTR_02
1
4
CNTR_03
1
4
CNTR_04
1
4
CNTR_05
1
2
TTXD1_1
1
2
TTXD1_2
1
2
TTXD1_3
1
2
TTXD1_4
1
2
TTXD1_5
;time
;total fired hours
;peak fired hours
;manual initiated starts
;total starts
;fast load starts
;fired starts
;trips
1
1
1
1
1
1
1
1
BIT
BIT
BIT
BIT
BIT
BIT
BIT
BIT
L30SD
L30_SU
L30_RUN
L30D_RSZ
L30D_RS
L30D_STG
LB3SUFI
;bit packed, bit

;bit packed, bit
;bit packed, bit
;bit packed, bit
;bit packed, bit
;bit packed, bit
;we ignore bit 6
;bit packed, bit
0
1
2
3
4
5
1
1
BIT
BIT
L30D_ACN
L30D_FSN
;bit packed, next byte, bit 0

;bit packed, bit 1
2
2
2
2
6
2
2
2
TIME
B1
B2
;TEST
Data entries in a PDDump.DAT file are organized with one data point per line,
with each line containing three entries. The channel appears first, specifying the
channel number (1-8) to be used by the Mark IV Data Dump. If a given port
receives data from several channels, data must appear in the same file with
different channels specified. Usually channel 1 will be used for a Mark IV
turbine control that supplies data on only one channel.
The channel number is followed by the data size. Data size is the number of 8-bit
bytes used to contain the data, but when logic data is bit packed, BIT appears
instead. Bit packed data must appear in bit order, starting with bit 0. If Bit packed
data is followed by byte data, the byte data begins at the next byte. Insert spare
bits as necessary by specifying a channel number and BIT without a point
number.
The data dictionary point name follows the data size. This entry specifies where
the data is stored after the data is received from the Mark IV unit. If certain data
from the Mark IV unit is to be ignored, this may be accomplished by merely
leaving off the point name.
The user should be aware that a correspondence between the number of bytes
specified in the PDDump.DAT file, and the number of bytes received from the
Mark IV controller, must be maintained. If 72 bytes of data are received from the
Mark IV controller, then 72 bytes must be configured in the PDDump.DAT file.
Entries without pointnames may be specified, as in the last line of the example
above, when data from the Mark IV controller is not needed. If the number of
bytes received mismatches the configuration file, an entry is placed in the log file
G:\LOG\PDDump#.LOG file where # is a number 1 through 8. This log file
shows expected and actual message data sizes.
Data stream format. When data is received from the specified port, it is verified
for validity by checking the header, channel, checksum, and message length. If the
message header, channel, and checksum are valid, the message length is compared. If
the message length matches exactly, the data is moved into the specified units data
dictionary with a time tag as specified in the message. The Message format is as
follows:
data size
byte
byte
byte
byte
byte
byte
byte
byte
byte
byte
bytes
.
.
.
byte
byte
byte
data name
flag byte
channel #
sequence #
char. count
second
minute
hour
day
month
year
data
data
lsb checksum
msb checksum
example
0xAA
;offset 0
0x01
;offset 1
0x27
;offset 2
0x4B
;<== maximum value 253 (0xfd)
0x3B
;<== data begins at offset 4
0x3B
0x17
0x1F
0x0C
0x63
;Timetag for 31 Dec 1999 23:59:59
;<== last possible data at offset 256
The year timetag is transmitted as either modulo 100 or as actual year less 1900.
1900 or 2000 should be added to the result as appropriate to obtain the correct year.
PDDump performs this calculation automatically.
The Mark IV timetag (6 bytes) should always be used when available by inserting a
line in the configuration file specifying 6 bytes and the pointname TIME. See the
PDDump.DAT file above, for example. If the Mark IV timetag is not available, the
program uses system time instead, simply by leaving the TIME line out of the
configuration file. The Mark IV timetag is ignored if the clock has never been set, that
is if month is zero.
Data as specified by the data file PDDump.DAT is stored in the data dictionary
beginning with the data byte immediately following the char. count byte. Data is
stored in the data dictionary according to the data point specified. Data with no point
specified is ignored. See the Data Stream Message Format example above. Six byte
data labeled TIME, however, is not stored in a data point entitled TIME. Data stored
in the data dictionary is time tagged with the time tag received from the Mark IV unit.
If no time is received from the Mark IV unit for that port, current local time is used
instead.
Errors are logged to the file G:\LOG\PDDUMP#.LOG, where # may be 1 through 8
or null. Possible errors include failure to open a specified port, and message size
mismatch.
Diagnostic procedures. The program resides at G:\EXEC\PDDUMP.EXE. This

program is automatically run when the software is started.
As a debugging tool, a global section trace buffer can be viewed with the
command:
gbl2file pddump_trace# <some_file_name>
where # is 1,2,3,.... corresponding to the first, second, third, ...

[PDDUMP_SETUP] section of the F:\IO_PORTS.DAT file. For example, to
view program information about the first Predefined Data Dump port, the
following section trace command could be issued:
gbl2file pddump_trace1 pddump1.log
This creates a file with a snapshot of the operating condition of the program and
error conditions. Error message and time stamped data streams are placed in this
global section trace.
If the program encounters an error or terminates early due to a serious error in the
data file, an error message is placed in the global section. In addition, a log file
describing the problem is placed in the file G:\LOG\PDDUMP.LOG.
A statistical summary program, G:\EXEC\PDD_STAT.EXE is also available to

provide summary data for messages received from each port communicating with
a Mark IV Predefined Data Dump. An example follows:
Mark IV Predefined Data Dump statistical summary:

PDDump 1.
0 = Number of bytes we tossed while waiting for start of new message.
0 = Number of times we got a new message with a channel # above 8.
1 = Number of times we started a new message without finishing previous.
0 = Number of complete message received with a bad checksum.
0 = Number of messages stoped due to intercharacter timeout.
0 = Number of messages stoped due to buffer full.
217 = Number of good messages received.
0 = Number of good messages ignored due to mismatched message size.
217 = Number of good messages processed.
PDDump 2.
0 = Number of bytes we tossed while waiting for start of new message.
0 = Number of times we got a new message with a channel # above 8.
0 = Number of times we started a new message without finishing previous.
0 = Number of complete message received with a bad checksum.
0 = Number of messages stoped due to intercharacter timeout.
0 = Number of messages stoped due to buffer full.
220 = Number of good messages received.
0 = Number of good messages ignored due to mismatched message size.
220 = Number of good messages processed.
This example shows two statistical sections. Up to eight sections may be displayed,
one for each of the possible eight communication ports. Each section corresponds in
number to the [PDDUMP_SETUP] section number as configured in the
F:\IO_PORTS.DAT file.
Hardware Specification
Communications. These sections detail the physical link layer/format of the
Predefined Data Dump serial link. The physical link layer uses RS-232C
communications.
Link Layer. Each Historian can receive up to eight point-to-point PDD RS-232C
serial links from one or more Mark IV control units. Each link may consist of one or
more channels. Channel numbers are predefined in the Turbine Control and are
always numbered from 1 to 8. Refer to the channel rule above. Communication is
one-way, from the Turbine Control to the Historian, although full duplex RS-232C-C
lines are used.
Physical Layer. The Historian is used as the communications port for the PDD,
typically using the COM2 serial communications port. If the COM2 port is not
available, a serial expander board can be used to supply eight more serial ports. The
port used is configured with a DB9P (Male) connector as Data Terminal Equipment
(DTE). This connection is shown in the diagram below; NC means there is No
Connection.
.
Mark IV
Typical Historian
DB25P (DTE)
DB9P (DTE)
RXD
TXD
RTS
CTS
SCOM
CD
DTR
DSR
RI
Cable
(2)
(3)
(7)
(8)
(5)
(1)
(4)
(6)
(9)
TXD
RXD
RTS
CTS
SCOM
NC
NC
Common (not shielded)
NC
NC
NC
NC
(2)
(3)
(4)
(5)
(7)
RS-232C Communication without Modems
The system is asynchronous RS-232C compatible, 300 to 19,200 baud, programmable

parity. It is compatible with full duplex data sets (modems). Modem generated signals
such as CTS (Clear to Send), CD (Carrier Detect), and RI (Ring Indicator) are not
required to enable the transmitter. The RTS (Ready to Send) and DTR (Data Terminal
Ready) on the powered-up Historian are always equal to one. This prohibits any
multi-drop configurations, as these signals cannot enable or disable communications.
Predefined Data Dump communications with the Mark IV can be established by
either using a direct cable configured as a null-modem, by using short-haul
modems, or by using full modems over telephone or leased lines.
Historian
Data Set
Data Set
DB9P (DTE)
(Modem)
(Modem)
Mark IV
Control System
R1-4
R2-3
S1-2
S2-1
RXD
TXD
V+
SCOM
RXD
TXD
DTR
SCOM
(2)
(3)
(4)
(5)
(2)
(3)
(4)
(5)
S1-2
S2-1
R1-4
R2-3
Shielded
Twisted
Pair wire
(2)
(3)
(4)
(5)
Cable
RS-232C Communications using Modems
The Mark IV power, V+, is 3-5 mA at 10 V dc. The nominal voltage is 12 V dc, with
a maximum of 25 V dc and a minimum of 6 V dc.
If it is necessary to operate over telephone modems, most modems (with a few
exceptions) support a maximum number of 10 bits communicated. Therefore, the
standard eight bits of the Predefined Data Dump data, and the two bits for start/stop,
are all that can be accommodated. This implies that PARITY is not supported over
most telephone modems. RS-232C systems require two metallic shielded twisted pair
wires to connect the short-haul modems. RS-232C transmission distances are defined
in the table below:
RS-232C Transmission Distances with Modems
Baud
26 Gauge
Rate
24 Gauge
22 Gauge
19 Gauge
Miles (km)
Miles (km)
Miles (km)
Miles (km)
300
10.0 (16.1)
12.0 (19.3)
15.0 (24.1)
25.0 (40.2)
1200
6.0 (9.7)
7.5 (12.1)
9.0 (14.5)
15.0 (24.1)
2400
4.5 (7.2)
5.5 (8.9)
7.5 (12.1)
11.0 (17.7)
4800
3.5 (5.6)
4.5 (7.2)
5.5 (8.9)
7.0 (11.3)
9600
2.2 (3.5)
3.2 (5.1)
4.0 (6.4)
5.0 (8.0)
19200
1.0 (1.6)
1.2 (1.9)
1.5 (2.4)
2.0 (3.2)
Note RS-232C communications are limited to 50 feet (15 meters) without the use of
modems.
Typical Historian
DB9P (DTE)
RXD
(2)
TXD
(3)
RTS
(7)
CTS
(8)
SCOM (5)
CD
(1)
DTR
(4)
DSR
(6)
RI
(9)
Data Set
Data Set
LDDS
LDDS
(3)
(2)
NC
NC
S1
S2
R1
R2
(7)
NC
NC
NC
NC
AC Power
R1
R2
S1
S2
Mark IV
DB25P (DTE)
(3)
(2)
(4)
(5)
(7)
(8)
RXD
TXD
RTS
CTS
SCOM
CD
(3)
(2)
(4)
(5)
(7)
(8)
AC Power
RS-232C Communications using Limited Distance Data Set (short haul modem)
When modems are supplied by GE Industrial Systems, the customer must supply the
cabling and terminations. The standard modems supplied by GE require power on pin
four. The modem connected to the Historian obtains its power from the serial port.
The other modem must receive power on pin four from the Mark IV. An optional
externally powered Limited Distance Data Set (LDDS) can be ordered from GE if
desired.
Modifying Historical Data Collection and Storage for the

Predefined Data Dump Data
Refer to section on Historian
Database Tools. A step by
step procedure is in the
Application Notes chapter in
Configuring Data Collection.
The historical collection of PDD data is changed by modifying the HSTPOINT.SRC

data file. This file contains the list of logic and analog points to be put in historical
storage. For HST versions 1.3 and earlier, it contains the significant change in counts
for analog points. For HST versions 1.4 and higher, it can contain the significant
change in Engineering Units and optional High and Low plot limits for analog
points. Points may be added to or deleted from the file. Significant change, High,
and Low plot limits may be modified for analog points.
The HSTPOINT.SRC file contains all of the PDD unit points, or a subset of the
points. A point must be listed in the UNITDATA.DAT file to be valid for storage in
the PI database. Any point in the UNITDATA.DAT file may be added to
HSTPOINT.SRC. These points should also have their associated long names defined
in LONGNAME.DAT, and all points must reference a valid scale code in the
ENGLISH.SCA file.
To modify historical PDD data collection and storage
1.
Modify the HSTPOINT.SRC file as described previously.
2.
3.
4.
5.
6.
Mark IV Configuration
Mark IV Unit Directory
The Mark IV unit configuration files reside in a F:\UNITn directory. The
UNIT_DATA section of the Historians F:\CONFIG.DAT file specifies the specific
directory. The files within the Historians F:\UNITn directory are pre-configured in
the factory. Anytime changes are made to files in the HMIs F:\UNITn directory the
corresponding changes need to be made to the files in the Historians F:\UNITn
directory. To update the Historian, copy the files from the HMI.
The required files in the F:\UNITn directory are as follows:
ALARM.DAT
ENGLISH.SCA*
METRIC.SCA*
ENUMDATA.DAT
EVENT_B.SRC
LONGNAME.DAT
SOEINV_B.SRC
UNITDATA.DAT
* as needed.
The Mark IV F:\UNITn directory can be set up as a max-case where all of the used
control points defined in the Mark IV database are contained in the UNITDATA.DAT
file. This max-case file is configured when the Historian ships from the factory. The
max-case file is built from GE factory records for the Mark IV unit control, and files
downloaded from the Mark IV control and submitted to the factory prior to Historian
shipment.
Note Logic and analog points that have been added in the field since the Mark IV
original shipment should have their pointnames, point numbers, scale codes, and
longnames in the Historian verified against the Mark IV as part of the Historian
installation checkout. Use the procedure below.
Adding and Modifying Point Information
Whenever important control points are added to the Mark IV in the field, they should
be added to the HMI, and copied to the Historian F:\UNITn directory configuration
files.
The file HSTPOINT.SRC, in the Historian F:\UNITn
directory does not come from the HMI. Be sure not to
delete or overwrite this file as it is the base file used to
configure the historical database and data collection for
the unit.
Mark IV Unit Communications

The Historian communicates directly with the Mark IV unit control over the CSF
using the MSP protocol, or Serial Connection using the MAMSP protocol. The
communication network is defined in the F:\CONFIG.DAT file. The
F:\CONFIG.DAT file should be verified when setting up the Historian. It normally
does not require modification afterward except when adding a new unit. For Serial
(MAMSP) communications, the F:\IO_PORTS.DAT file defines and configures the
serial port. Refer to the section on Historian Configuration for more information on
this file. The CSF ARCNET board used for the CSF communications is defined in the
TCI Control Panel Applet. Please refer to the section TCI Control Panel Applet for
more information on configuring the CSF ARCNET board.
Modifying Historical Data Collection and Storage

Configuring Events. Modifications to the Event List begin in the HMI or
Historian by adding and deleting points from the EVENT_B.SRC file. Earlier Mark
IV versions do not support redefining the event list. This file can contain up to 64
logic points that are reported as events by the unit control. After modifying the file on
either the HMI or Historian, it should be copied to the other system so the two will
match. This is important because, on most Mark IV unit controls, the Event list is
downloaded from the HMI and Historian when these PCs begin their data collection
process.
Note The Mark IV uses the Event List from the last one of the HMI or Historian to
begin its data collection process. Differences in the EVENT_B.SRC files between the
two systems could result in some events not being reported to the Historian.
Mark IV
Communicating over
CSF or RS232
Historian
F:\CONFIG.DAT
F:\UNITn\ALARM.DAT
F:\UNITn\ENUMDATA.DAT
F:\UNITn\EVENT_B.SRC
F:\UNITn\SOEINV_B.SRC
Mark IV Periodic
Update I/F
Alarm/Event/
SOE Receiver
Data Dictionary
Digital Exception Database
PI_PUSH
F:\PI_PUSH.DAT
PI Snapshot
Database
PI Archive Database
Mark IV Interface Configuration & Data Flow Diagram
Events are listed in the EVENT_B.SRC file on the HMI and Historian. The files
should match between the HMI and Historian F:\UNITn directories. The Historian
Database Tool Unit Level reads the EVENT_B.SRC file so that event points are
automatically included in the PI database. The Historian receives the event messages
sent from the unit and stores them in the exception database (*.D03 files) so that the
Historical Alarm and Event Report can retrieve them later.
Refer to the next section for how to use the Historian Database tools to incorporate
source file changes into the historical database.
Configuring Logic, Analog, and Accumulator Points. The method for

modifying the historical collection for a Mark IV unit is by modifying the
HSTPOINT.SRC data file. This file is modified on the Historian in the F:\UNITn
directory. This file contains the list of logic and analog points to be put in historical
storage. It also contains the significant change and optional High and Low plot limits
for analog points. Points may be added to, or deleted from, the file. Significant
change, High, and Low plot limits may be modified for analog points. A point must
be listed in the UNITDATA.DAT file to be valid for storage in the PI historical
database. Any point in the UNITDATA.DAT may be added to HSTPOINT.SRC.
These points should also have their associated longnames defined in the
LONGNAME.DAT, and all points must reference a valid scale code in the scale code
files ENGLISH.SCA and METRIC.SCA.
Using the Historian Database Tools. The Historian Database Tool should be
run after modifying any of the following files:
LONGNAME.DAT - Point long names
ENGLISH.SCA, METRIC.SCA - Point scaling data
CHNG_Q.SRC
- Analog Change Cell information
EVENT_B.SRC - Digital Event information.

HSTPOINT.SRC - This file may contain logic, analog, and accumulator points.
To run the Historian Database Tool
1.
Modify the HSTPOINT.SRC file as described above.
2.
3.
4.
5.
6.
by step procedure is available in Configuring Data Collection in the Application
Notes chapter.
Mark V & Mark V LM Configuration

Mark V as it is used in this section applies to the Mark V and Mark V LM Turbine
Controls.
Mark V Unit Directory

The configuration files for the Mark V reside in the F:\UNITn directory specified for
the unit in the Historians F:\CONFIG.DAT file. The files within the Historian
F:\UNITn directory are copied from the HMI or . These files include the
F:\UNITn\PROM subdirectory files also. All of the files for a unit in the F:\UNITn
and F:\UNITn\PROM directories should be brought over from the HMI or 
anytime there is a major change that requires a MK5MAKE.BAT command, or file
compilation, or other change requiring a download to the unit control.
The required files from the F:\UNITn directory are:

ALARM.DAT
ENGLISH.SCA*
METRIC.SCA*
CUSTOM.SCA*
ENUMDATA.DAT
EVENT_Q.SRC
EVENT_B.SRC*
LONGNAME.DAT
UNITDATA.DAT
PROM\UNITDATA.TPL
PROM\UNITFREE.TPL
PROM\UNITMAP.TPL
* as needed.
The Additional files required for Mark V LM:
UNITIO.DAT
IOSCALE.DAT
Optional Files:
CHNG_Q.SRC
CHNG_B.SRC
The file HSTPOINT.SRC, in the Historian F:\UNITn

directory does not come from the HMI or . Be sure
not to delete or overwrite this file as it is the base file
used to configure the historical database and data
collection for the unit.
Mark V Unit Communications

The Historian communicates directly with the Mark V unit control over the ARCNET
Stagelink. The communication is defined in the F:\CONFIG.DAT file. Refer to the
section on Historian Configuration for more information on this file. The
F:\CONFIG.DAT file should be verified when setting up the Historian. It normally
does not require modification afterward except when adding a new unit. The
ARCNET board used by the Stagelink communications is defined in the TCI Control
Panel Applet. Refer to the section TCI Control Panel Applet for more information on
configuring the ARCNET board.
Mark V/Mark V LM
Communicating
over Arcnet
Historian
F:\CONFIG.DAT
From /<HMI>
F:\UNITn\*.*
F:\UNITn\PROM\*.*
Mark IV
Periodic
Update I/F
Alarm/Event/
SOE Receiver
Data Dictionary
Digital Exception
Database
PI_PUSH
F:\PI_PUSH.DAT
PI Snapshot
Database
PI Archive Database
Mark V & Mark V LM Interface Configuration
Modifying Historical Data Collection and Storage

Configuring Events. Modifications to the Event List begin in the HMI or by
adding and deleting points from the EVENT_Q.SRC file. This file can contain up to
64 logic points that are reported as events by the unit control. After modifying the
file, it must be compiled with the Table Compiler and downloaded to the unit control.
When the unit control is rebooted, the new Event List becomes active.
Events are listed in the EVENT_Q.SRC file on the HMI or . This file needs to be
copied over from the HMI or F:\UNITn directory to the corresponding directory
on the Historian. The Historian Database Tool Unit Level reads the EVENT_Q.SRC
file, so that event points are automatically included in the PI database. The Historian
receives the event messages sent from the unit and stores them in the Digital
Exception Database (*.D03 files) so that the Historical Alarm and Event Report can
retrieve them later.
The EVENT_B.SRC file may be modified on Large Steam Mark V applications also.
Read below on how to use the Historian Database tools to incorporate source file
changes into the historical database.
Configuring Logic, Analog, and Accumulator Points. Changes to the
historical collection for a Mark V unit is by modifying the HSTPOINT.SRC data file.
This file is modified on the Historian in the F:\UNITn directory. This file contains the
list of logic and analog points to be put in historical storage. It also contains the
significant change and optional High and Low plot limits for analog points. Points
may be added to, or deleted from, the file. Significant change, High, and Low plot
limits may be modified for analog points. A point must be listed in the
UNITDATA.DAT file to be valid for storage in the PI historical database. Any point
in UNITDATA.DAT may be added to HSTPOINT.SRC. These points should also
have their associated longnames defined in the LONGNAME.DAT, and all points
must reference a valid scale code in the scale code files ENGLISH.SCA and
METRIC.SCA.
Using the Historian Database Tools. Run the Historian Database Tool Unit
Level after modifying any of the following files:
LONGNAME.DAT - Point long names
ENGLISH.SCA, METRIC.SCA, CUSTOM.SCA - Point scaling data
CHNG_Q.SRC
- Analog Change Cell information
EVENT_Q.SRC
- Digital Event information.
EVENT_B.SRC
- Digital Event information.
HSTPOINT.SRC - This file may contain logic, analog, and accumulator points.
To run the Historian database tool
1.
Modify the HSTPOINT.SRC file as described above.
2.
3.
4.
5.
6.
Notes chapter.
Mark VI Unit Configuration

The Mark VI interface uses EGD (Ethernet Global Data) messages for periodic data,
and the ALM protocol for alarms and SOE messages. The EGD information is
transferred directly from the EGD global memory into PI, and the Digital Exception
Messages go through the Historian System Service (HST).
Mark VI
Communicating
over Ethernet
Historian
EGD Service
Alarm/SOE
Receiver
EGD Global
Section
Digital Exception
Database
C:\WINNT\EGD.INI
F:\ENETALM.DAT
EGD_PUSH
F:\EGD_PUSH.DAT
PI Snapshot
Database
PI Archive Database
Data
Dictionary
F:\CONFIG.DAT
F:\UNITn\ALARM.DAT
Mark VI Interface Configuration & Data Flow Diagram
Configuration of the Historian to handle a Mark VI includes the following:

For periodic data:
Define the EGD exchanges required from the unit.
Define the points within the EGD exchange that should be extracted.
Configure the points in PI to receive the information.
For the Digital Exception Messages:
Define the Ethernet Addresses associated with the unit.
Define the number of alarms, and for each alarm, the alarm text.
Define the SOE points, and for each SOE point, the description.
Some of these steps are performed by copying files from an HMI, some are done by
hand, and some have automation tools to help in the process.
Configuration Files
Configuration for the Mark VI is primarily through a set of ASCII text files. These
text files are spread out across a number of directories according to the functions
performed. Using the outline from the previous section, the following are the files
required to support a Mark VI.
Defining the Mark VI as a Unit
The Historian uses an ASCII file to define which units the Historian is being asked to
support. Each Mark VI unit that this Historian is asked to support must have an entry
in this file:
F:\CONFIG.DAT
The Mark VI must have a line in the UNIT_DATA section that defines the unit
number, unit name, unit configuration directory, and the unit type. Unit numbers are
assigned sequentially from 1 to the number of units that the Historian supports. The
unit name is a one or two character unit name used to identify the unit. The unit
configuration directory is the F: subdirectory that holds the unit configuration
information. The unit type for a Mark VI can be specified as MARKVI, or as the
number four (4). A typical UNIT_DATA section appears as follows:
;
;
UNIT
;
NUMBER
;
-----UNIT_DATA
;
1
UNIT
NAME
----
T1
PATH TO
CONFIG DATA
-----------
F:\UNIT1
UNIT
TYPE
----
MARKVI
The Mark VI interfaces through Ethernet, so there does not have to be any entry in the
NETWORK_TYPE or NETWORK_DATA sections for a Mark VI. (These are used
for devices that interface through Stagelink, CSF, or Serial MSP interfaces). The
Ethernet configuration for the Mark VI is specified in the EGD and ALM
configuration files, defined in the following sections.
Defining the EGD Interface

The periodic data that the Historian collects is obtained through the EGD interface.
Mark VI broadcasts data packets that any PC can choose to receive and process. For
the Historian to collect and save this data, it must define which EGD exchanges to
listen to, define points to extract from those exchanges, and configure PI to receive
the information.
C:\WINNT\EGD.INI
The EGD system service is in charge of listening for EGD messages on Ethernet, and
copying them into an EGD global section if it finds an EGD message that it has been
configured to receive. The EGD.INI file indicates which EGD messages are supposed
to be received into this box. There is a slight CPU saving in not receiving and
processing messages that are not used by the Historian. For each EGD message that is
desired, a line of data is added to the EGD.INI file. This line contains the EGD page
number, the length of the page, the expected period (in msec), the source of the page,
and the destination of the page. (An optional FLAGS field is supported, but not
currently used by the Historian software).
This file can typically be copied from an HMI, and any EGD messages that are not
required by the Historian can be removed for a minor efficiency gain. (Unused pages
with a high transmission rate are good candidates for removal.)
The following is a typical EGD.INI file:
# EGD Static Initialization File
#
#------------------------------------------------------------------#
# Entries in this file are used to predefine static Ethernet
# Global Data exchanges for the EGD Service. The file is read
# only when the services is started, either Manually or at
# startup. This file contains a keyword section, followed by
# a line for each pre-defined exchange. The exchange line
# must include a valid page number (unique for the whole EGD
# network, a length in bytes, Period in Milliseconds, source
# (producer) node followed by destination address. Node addresses
# can be in either symbolic or doted decimal format. Multiple
# destination address are not supported unless the address specified
# is a IP Multicast address. The Multicast keyword specifies a
# multicast address to which this node will listen.
#
#------------------------------------------------------------------#
INTERFACE=192.168.1.40
#PAGE LENGTH PERIOD
SOURCE
DESTINATION FLAGS
1
616
500
192.168.1.10
192.168.1.40
M
2
21
500
192.168.1.10
192.168.1.40
M
3
6
500
192.168.1.10
192.168.1.40
M
4
28
500
192.168.1.10
192.168.1.40
M
5
356
500
192.168.1.10
192.168.1.40
M
F:\EGD_PUSH.DAT
The EGD_PUSH.DAT file defines the list of points that are to be copied from the
EGD messages to the PI real time and historical subsystems. These points are copied
once per second with an optional gain and offset if the point is to be rescaled between
the two systems.
Each line in this file defines a point to be transferred. The line starts with the
information required to retrieve the point from the EGD global memory section specifically the exchange number, offset within the exchange, exchange revision
number, and data format of the point. The name of the PI point that receives this value
is next, where the actual name is the concatenation of the PI_PREFIX and the listed
point name. (Using a point name prefix like this allows for easy duplication of the
unit definitions within this file, only the prefix needs to be changed on a unit-by-unit
basis). The rest of the line is optional, and consists of a gain and offset that can be
applied to the point to rescale it, and an expected range of operation.
Note The rescaling option is used in some product lines to force a standardized set of
engineering units in the PI subsystem. This is handy for maintaining fleet-wide
databases, or running common algorithms with common control constants. This
option is typically not used by the Historian, as users expect the historical data to be
formatted in the same engineering units as the real time displays.
Note The Quality attribute is not used in the Historian - the Historian records its
view of the plant conditions with no modifications based upon a configured quality
range. The Historian does not pass judgement on signal conditions, it faithfully
records the values that the control system reports.
A typical EGD_PUSH.DAT file appears as follows:
;
; EGD_PUSH Configuration File
;
@UNIT T1
@PI_PREFIX T1:
;
;Exc Offset Rev
Type
PI name
;--- ------ --- -------- -----------1
0
4 Float
BB1
1
4
4 Float
BB2
1
8
4 Float
BB3
2
0
2 Bool
L1Z
2
1
2 Bool
L1S
2
2
2 Bool
L1FX
2
3
2 Bool
L94X
Gain
-------1.0
1.0
1.0
1
1
1
1
Offset
-------0.0
0.0
0.0
0
0
0
0
Quality
---------[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
[*,*]
F:\PICONFIG.DIF and F:\UNITn\PICONFIG.U

Each point to be transferred to the PI subsystem needs to be defined within the PI
subsystem. Ultimately this is done through the F:\PICONFIG.DIF file. To create this
file, each unit has its own definitions defined in a PICONFIG.U file in the unit
configuration directory. Automation tools then merge the individual unit
configuration files to create the F:\PICONFIG.DIF file. One advantage of this scheme
is for sites with multiple units, as the individual unit configuration file (PICONFIG.U)
can be duplicated from unit to unit. The automation tools add the unit name identifiers
as they merge the PICONFIG.U files to create the PICONFIG.DIF file. As
automation support grows in the future, the PICONFIG.U file becomes the target for
all the unit level automation, allowing the existing automation tools to build the
PICONFIG.DIF file. Unit configuration changes should always be applied to
PICONFIG.U, then the system level automation tools should be run.
The PICONFIG.DIF file is an input file to the PICONFIG utility supplied as part of
the PI subsystem. It is the primary method used to configure the points that PI will
maintain. Typically the as shipped list is a good starting place, with only incremental
additions or modifications required. (Creating this file from scratch is rather difficult.
Unit configuration automation tools are used at the factory to create the as shipped
file). Follow the format of the existing file to create new points or modify settings for
existing points. The PI manuals have a good definition of each field in the point
record.
Note The algorithm used to determine which values get placed in the PI Archive,
and which get filtered, are based in part on a slope-interpolation scheme. Points that
are changing at a constant rate do not generate as many values in the historical
database as expected, based on experience with value (not slope) based filters. This
has lead many people to believe there is a problem when in fact there is not. Read
about the algorithms used in the PI manuals before making too many fine adjustments
to the points historical compression settings.
After changes are made to the units PICONFIG.U file, the Historian Database Tool
System Level (HSTDBS.EXE) is run to merge all the PICONFIG.U files into the
F:\PICONFIG.DIF file. Refer to the section on the Historian automation tools later in
this chapter for this procedure.
The fllowing is a typical PICONFIG.U file:
*
@istr pointtype,pointsource,tag,engunits,displaydigits,zero,span,archiving,step,excdev,compdev,descrip
*
float32,1,BB1, IN/S, 2, 0.00, 8.00, 1,0, 0.0320, 0.0800,Vibration sensor
*
@istr pointtype,pointsource,tag,exdesc
*
float32,1,BB1,Vibration sensor
*
*
,HP Speed - Zero Speed
,HP Speed - Minimum Firing Spd
,HP Speed - Accelerating speed
*
@istr pointtype,digitalset,pointsource,tag,exdesc
*
,HP Speed - Zero Speed
,HP Speed - Minimum Firing Spd
,HP Speed - Accelerating speed
Defining the Digital Exception Message Interface

The Digital Exception Message data that the Historian collects is obtained through the
ALM (Alarm Protocol) interface. The Mark VI broadcasts digital exception messages,
and the Historian indicates that it is an intended recipient. Intended recipients
acknowledge reception of the messages, and the Mark VI includes message retry
logic to assure that messages are not missed. For the Historian to collect, save, and
present this data, it is necessary to define which units to collect messages from, and
for each unit sending messages, to define the text (alarm or SOE) associated with
each reported event.
F:\ENETALM.DAT
When the Mark VI sends a digital exception message, it indicates the source of the
message by sending the Ethernet IP address. The Historian receives all messages
broadcast from each Mark VI, and it needs to know whether it should save messages
from this unit or not. It also needs to know which unit is associated with the sending
Ethernet IP address. (The units were defined in the F:\CONFIG.DAT file). This
mapping of Ethernet IP addresses to units is configured in the F:\ENETALM.DAT
file.
For Simplex controls there is one Ethernet IP address for each unit. For TMR (Triple
Modular Redundant) controls there can be up to three addresses associated with each
unit. Each Ethernet IP address is associated with a unit and a controller. When the
ALM Receiver program receives a digital exception message from an IP address, it
first tries to match it with the unit. If the address is not contained in the
F:\ENETALM.DAT file, then it does not process the message. If it finds a match, it
saves it as being a message from the given unit.
A Device ID is included in this file to assist automation tools to verify that the correct
unit configuration is being supplied to the correct unit. (This allows the unit
configuration to be completed before the site configuration is complete). This is not
used by the runtime code, so it is not a requirement, and if this is wrong the runtime
code will not malfunction in any way. (Future automation tools may issue a warning
if there is a mismatch here, but it will not effect operation). The Device ID specified
here is the Device ID assigned by the SDB (System Database) Utility when
configuring the site.
The following is a typical F:\ENETALM.DAT file:
;
; ENETALM.DAT - This file is used by the Ethernet ALARM RECEIVER program
; to define how to interpret the data received.
;
; There should be one line per Ethernet Alarm Generator node that this
; computer is supposed to monitor. Simplex turbine controls will have one
; node per unit, TMR turbine controls will have three nodes per unit.
;
; UNIT:
;
This is the XD unit number for the turbine, and must agree with
;
the unit number assignments in the F:\CONFIG.DAT file.
;
; PROC:
;
This is the processor specification, ( R | S | T ).
;
; IP_ADDRESS:
;
This is the IP address assigned to this Ethernet Alarm Generator.
;
; DEVICE: (optional, unused at the current time)
;
This is the device number assigned to this node.
;
; Example:
;
Device
;---- ---- --------------- -----; 1
R
192.168.1.1
46
; 2
R
192.168.1.4
47
; 2
S
192.168.1.5
47
; 2
T
192.168.1.6
47
;
;
;--------------------------------------------------------------------------;
Device
;---1
1
1
---- --------------R
192.168.1.10
S
192.168.1.11
T
192.168.1.12
-----49
49
49
F:\UNITn\ALARM.DAT
This file, located in the unit configuration directory, maps the alarm numbers to the
alarm text associated with that alarm. The digital exception messages report an alarm
as a number, with zero (0) being the first alarm from the unit. This file is used to
associate an alarm text string with the alarm number (sometimes called the drop
number) reported from the unit.
This file follows the same format used for the other controller types, starting with a
processor designation column. The Q processor designation is used indicating that
the alarm is generated by the R, S, and T processors. (QP means a <Q> Process
alarm). In a Mark VI all processors generate alarms using the same alarm translation
tables, so drop number n from the <R> processor is the same alarm as drop number
n from the <S> and <T> processors. Therefore, all alarms in a Mark VI
ALARM.DAT file should be defined as being QP alarms.
This file does not have to be a max case file. If an alarm is received and there is no
associated alarm text, the alarm is still recorded and logged with a text string of NO
TEXT. The alarm information is not lost, and the alarm number can be used to
identify the alarm. In other words, not having an alarm text string does not cause the
alarm to be dropped - it is still processed and recorded but the alarm number must be
used for identification, not the text string.
The following is the format for a typical ALARM.DAT file:
QP
QP
QP
QP
QP
123
124
125
126
127
GAS STOP VLVS POSITION TROUBLE

ISOCHRONOUS SPEED SETPOINT AT MAXIMUM
ISOCHRONOUS SPEED SETPOINT AT MINIMUM
HIGH VIBRATION TRIP OR SHUTDOWN
HIGH VIBRATION ALARM
The LONGNAME.DAT file associates a long name (or description) with a signal.
This long name is often used in displays or printed logs to provide the user with a
more descriptive definition of the signal.
The Mark VI uses the long name as the descriptive text for its SOE reports. When a
contact input signal is enabled for SOE reporting, the digital exception message from
the controller reports it as a signal number. This signal number is translated into a
signal name using the offset defined in the UNITDATA.DAT file, and the long name
for that signal is used as the descriptive text in the digital exception message report.
The format of the LONGNAME.DAT file is just two columns. The first is the name
of the signal, and the rest of the line is the long name. The points can be defined in
any order. This can be a max case file - no error is generated if a point name found in
LONGNAME.DAT is not defined for this unit. Similarly, a point that is defined but
not given a long name is not an error. A warning is given in the Historian startup log
if a signal name appears twice in the file, and the first definition is used by the
runtime system.
A typical LONGNAME.DAT file appears as follows:

BB1
BB2
BB3
L14HA
L14HM
L14HR
L14HS
TURBINE VIBRATION TRANSDUCER # 1 (39V-1A)

TURBINE VIBRATION TRANSDUCER # 2 (39V-1B)
TURBINE VIBRATION TRANSDUCER # 3 (39V-2A)
HP ACCELERATING SPEED SIGNAL
MINIMUM SPEED SIGNAL (APPROX. 20%)
HP ZERO SPEED SIGNAL
HP OPERATING SPEED SIGNAL
For most unit types, the UNITDATA.DAT file is the key file that defines the points
available from the unit control. (This is true for the Mark IV, Mark V, Mark V LM
turbine controls, as well as the PDD and Modbus Master front end interfaces). The
Mark VI, however, uses the Control System Toolbox for its configuration and
programming, and EGD pages for its periodic data transmission. This means that the
Data Dictionary file UNITDATA.DAT does not need to exist to define all the signals
available from the controller. There are two reasons why the Historian still needs this
file for its handling of the Mark VI controller.
The UNITDATA.DAT file is needed to support the alarm subsystem - specifically it
is the combination of the UNITDATA.DAT and ALARM.DAT files that bind the
alarm text to each alarm. To support this, the UNITDATA.DAT file must have as
many alarms defined as the Mark VI can send. The alarms do not need to be assigned
any special addresses, since what comes from the unit is the alarm number, but a
block of alarms equal in size to the number of alarms that can be sent from the unit
must be defined. Typically this block of alarms contains either 768 or 1024 alarms
depending upon the complexity of the unit control, but this is not an architectural
limit.
The second use of the UNITDATA.DAT file is to bind the SOE point numbers to the
signal name. Here the offset specified in the UNITDATA.DAT file must match the
number in the SOE message reported by the Mark VI. When the Historian receives an
SOE message (a form of digital exception message) it looks for the number in the
message as the offset field in the UNITDATA.DAT file. If it finds it, it now knows
the name of the point to report. (It uses this name as the key into the
LONGNAME.DAT file to get the text description to be shown in the SOE report).
The UNITDATA.DAT file is created one of two ways depending upon the level of
software and functionality used in your Mark VI.
If SOE reporting is not used, a standard UNITDATA.DAT supplied as part of the

as shipped software can be used. For these units the only requirement is a block
of alarms, which are the same from site to site, unit to unit. (The ALARM.DAT
file is different from unit to unit, but the UNITDATA.DAT file only needs to
reserve space for the block of alarms). Once defined, this file never needs to be
changed unless the total number of alarms from the panel is increased.
If SOE reporting is being used with version 6.x or higher of the Control System
Toolbox, then one of the Data Dictionary Build automation tools can be used to
create both the UNITDATA.DAT and LONGNAME.DAT files. The Control
System Toolbox collects a list of all of the contact inputs that have been flagged
to generate SOE messages, and export it to a file of the format
<UnitName>.SOE. This file should be copied to the Historian, placed in the unit
configuration directory, and renamed to SOE.DAT. This file contains the signal
names, SOE numbers, and descriptive text for each of the SOE points. The Data
Dictionary Build #2 program (DDBUILD2) reads this SOE.DAT file and the
ALARM.DAT file, and generates the required UNITDATA.DAT and
LONGNAME.DAT files.
As changes are made in the unit control, either apply the changes by hand, or
rerun the DDBUILD2 program with the new SOE.DAT and ALARM.DAT files.
Since these files are only read when the unit configuration is loaded by the
historian, it is necessary to shut down and restart the Historian System Service in
order to see the effects of the change. (The PI subsystem does not need to be shut
down and restarted, only the Historian subsystem).
Historian DataBase System Level Automation
After the configuration for each unit is updated in the units configuration directory,
the system level files must be rebuilt by merging the unit files. The Historian
Database Tool System level (HSTDBS.EXE) performs this merge. The new system
level files are built, the Historian Service is shut down, the PI configuration is
updated, and the Historian Service is restarted. The following outline shows the steps.
To run the HSTDBS tool
1.
Database Tool System Level, G:\EXEC\HSTDBS.EXE. This uses the unit
level files to create new PI_PUSH.DAT and PICONFIG.DIF files.
2.
3.
4.
Notes chapter.
Off Line Storage

The PI Data Archive subsystem maintains a circular queue of archives. Eventually
data in the oldest archive will be overwritten. The program DSKMGR.EXE, which is
started as part of the HST service, monitors the oldest value of DS:DSKMGR in the
PI archives and deletes all alarm, event, and SOE Digital Exception files created
before that oldest value. In order to preserve the data, the archives and corresponding
Digital Exception files should be moved to an off line storage media.
Tapes are used for the long-term storage of historical data. When review or analysis
of stored data is required, the data can be restored and viewed on the Historian. This
section describes the process of archiving historical data sets to tape and retrieving
historical data sets from tape. A data set consists of a PI Archive and the
corresponding Digital Exception history files. All the PI and NT tools required to
provide off line storage are discussed in detail.
Archiving Historical Data

There are two types of history files stored on the Historian, PI data archives and
digital exception files. Each type has its own backup procedure.
The PI data archives are fixed-length files that exist in the D:\PI_ARCH directory.
The file name format for the PI data archives is PIARCH.nnn; where nnn is a threedigit number typically starting at 001.
The alarm, event, and SOE digital exception files (D03 files) are created on a daily
basis whenever an alarm, event, or SOE is generated in one of the control panels
monitored. They are stored in D:\HSTDATA. The file name format for D03 files is
yyyymmdd_typ.D03,
where:
yyyy is the four digit year.
mm is the two digit month.
dd is the two digit day.
typ is ALM for alarms, EVT for events, and SOE for Sequence of Events
(contact inputs).
Only qualified personnel should perform the

archiving procedure. An incomplete procedure
could leave the archives in an unusable state, or
could interfere with the running system.
To prepare the system disk
On the system disk C:, create the following directory to store intermediate files:
C:\BACKTEMP
Running the PI utility, PIARTOOL with the -al parameter, displays a list of all
registered PI archives. Additional information given helps determine which archives
have been used, which have been never used, and which one is the primary or current
archive.
To obtain a listing of all archives
From the Command Prompt, run the PI utility, PIARTOOL, and redirect the
output to a temporary file with the following commands. Type:
cd /d c:\backtemp
Press Enter.
c:\pi\adm\piartool -al >archive.txt
Press Enter. The file archive.txt is created in the default directory.

View archive.txt to get information about the target archive for backup. There are
three items listed with each archive that help determine the status of the archive. They
are Start Time:, End Time:, and Backup Time:.
The primary archive is the archive currently in use. It will have a valid Start Time and
the value Current Time listed as its End Time. Once the primary archive is full, and if
there are no unused archives available, PI shifts into the oldest, used, registered
archive. The archive that is shifted into will have all its data deleted, it will be
reinitialized, and it will become the primary archive. In the example below piarch.046
is the primary archive.
Used archives have a valid Start Time and a valid End Time. In the example below,
piarch.047 and piarch.048 have been used.
Unused archives have the value Current Time for both the Start Time and End Time.
In the example below, piarch.001, piarch.002, piarch.045 are unused.
The Backup Time is filled out when the piartool utility is run with the
-bs <archive #> parameter. This is done later during the backup procedure. The
value of Never for the Backup Time indicates that piartool bs has never been run
against the archive.
The following is an example of the archive.txt display providing archive information:
C:\BACKTEMP> notepad archive.txt
Archive: d:\pi_arch\piarch.046
PIarcfilehead [@(#)piarfile.cxx 1.87 06/17/97]:
Version: 4 Path: d:\pi_arch\piarch.046
State: 4 Type: 0 Write Flag: 1 Shift Flag: 1
Record Size: 1024 Count: 32768
Offsets: Primary: 1067/8192 Overflow: 32711/32768
Start Time: 28-Dec-98 09:29:47
End Time: Current Time
Backup Time: Never
Start Time: 25-Nov-98 12:53:32
End Time: 28-Dec-98 09:29:47
Backup Time: Never
Start Time: 28-Jul-98 13:59:07
End Time: 25-Nov-98 12:53:32
Backup Time: Never
Start Time: Current Time
Backup Time: Never
Backup Time: Never
.
.
.
Backup Time: Never
In the example above, piarch.048 is the oldest used archive and will be the target
archive for backup in the remaining procedure.
To determine <archive #> for each archive
<archive #>
0.
Archive numbers are assigned to archives in reverse chronological order. The

primary archive always has archive # 0. The next oldest archive is archive # 1,
and so on. To determine the archive number for the target archive for backup,
edit or print out archive.txt and count down to that archive. Remember the
primary archive has a valid Start Time and the value Current Time listed as its
End Time. The primary archive should be the first archive listed in archive.txt.
Based on the example above, the archive numbers are as follows.
Backup Time: Never
1.
End Time: 28-Dec-98 09:29:47
Backup Time: Never
2.
End Time: 25-Nov-98 12:53:32
Backup Time: Never
The remaining archive numbers are not important since those archives have not been
used. The <archive #> for piarch.048 is 2.
To copy the target archive to the temporary directory
1.
Verify that there is enough free space on the disk
2.
Change the default directory to C:\BACKTEMP as follows. Type:

cd /d c:\backtemp
Press Enter.
3. Flush the cache and take the archive offline as follows. Type:
c:\pi\adm\piartool -bs 2
Press Enter.
4.
Copy the file to the temporary directory as follows. Type:

copy d:\pi_arch\piarch.048 c:\backtemp
Press Enter.
5.
Put the archive back online. Type:

c:\pi\adm\piartool be
Press Enter.
If the user does not run piartool be after

running piartool bs ,then the archive will
remain off line and unusable by the system.
Convert Archive to Non-shiftable Archive

To reiterate, once the primary archive is full and, if there are no unused archives
available, PI shifts into the oldest registered archive. The archive that is shifted into
will have all its data deleted, it will be reinitialized, and it becomes the primary
archive.
If an archive restored from tape is older than the archives currently registered, which
should be the case, then, once registered, it will be the next primary archive. To keep
the restored archive from becoming the primary archive, it needs to be converted from
a shiftable archive to a non-shiftable archive. OSIs Offline Archive Utility is used to
do this conversion.
Registered archives need to have unique names so as to not confuse the PI system and
the user. The system uses the convention PIARCH.001 PIARCH.nnn for its useable,
shiftable, archive names. To maintain a system where only uniquely named archives
are registered, the following naming convention is suggested for the converted nonshiftable archives, yyyymmdd_nnn.ARC,
where:
yyyy is the four digit representation of the year from the archives Start Time.
mm is the two digit month from the archives Start Time.
dd is the two digit day from the archives Start Time.
nnn is the file name extension for this archive (for example 048).
Using the archives file name extension as part of the converted file name maintains
unique file names for the rare cases where more than one archive have Start Times for
the same day.
The Offline Archive Utility is a command line utility. Many command line programs
running under Windows NT use excessive CPU time. To avoid taking CPU time from
essential programs, run the conversion in the IDLE priority class.
To convert archive to non-shiftable archive
1.
Use the START command, with the parameters /low and /b, to run the Offline
Archive Utility. These parameters have the following functions:
/low
Starts the application in the IDLE priority class
/b
Starts the application without creating a new window
The Offline Archive Utility is part of the Archive Subsystem, PIARCHSS.

START /? displays help for the START command.
Running the Offline Archive Utility without

START /low will interfere with the data
collection subsystem.
2.
Start PIARCHSS.EXE interactively with the required parameters specified.

These parameters perform the following functions:
-if <full path name>
Input Archive File (Required)
-of <path name>
Output Archive File (Required)
-dup
Allow duplicate events
c:\pi\bin\piarchss /?
displays help for the Archive subsystem
Note The conversion process takes roughly 20 minutes for a 32 MB archive. This
time may vary depending on the loading of the machine.
The following example shows the conversion of a 32 MB archive:
C:\BACKTEMP> start /low /b c:\pi\bin\piarchss -if c:\backtemp\piarch.048 -of 19980728_048.arc -dup
...First pass...
...Sorting input archive...
Failed to unregister input archive: [-12001] Name Not Found in PInt
Archive subsystem not running - or archive not registered
Continue processing...
Processing record 1000 ...
...Output pass...
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
Processing record
1000 ...
2000 ...
3000 ...
4000 ...
5000 ...
6000 ...
7000 ...
8000 ...
9000 ...
10000 ...
11000 ...
12000 ...
13000 ...
14000 ...
15000 ...
16000 ...
17000 ...
18000 ...
19000 ...
20000 ...
21000 ...
22000 ...

5758372 Loaded in 1064( 226 + 838 ) Seconds 5412 Event/Sec.
25531 Archive Total seconds - ratio: 23
03/12/99 10:19:51 :-1 -1
PIarcmgr::addevent failed, mode: 1 ptid: 26 recno: 26
Target Time
3.
status:
[-11043] No Archive On-Line For
Press the Enter key to get to the Command Prompt. The following message
displays:
PIarcmgr::addevent failed, mode:

For Target Time
ptid:
26
recno:
26
status:
[-11043] No Archive On-Line
Ignore the following two error messages:

Failed to unregister input archive: [-12001] Name Not Found in PInt
Archive subsystem not running - or archive not registered
PIarcmgr::addevent failed, mode:
For Target Time
ptid:
26
recno:
26
status:
[-11043] No Archive On-Line
These messages are normal and do not indicate the success or failure of the
conversion.
To delete the shiftable archive
Once the conversion process is complete, delete the shiftable archive as follows.
Type:
cd /d c:\backtemp
Press Enter.
del c:\backtemp\piarch.048
Press Enter.
Note The user is deleting the copied archive and not the actual registered archive.
Copy Corresponding D03 Files
Refer to facts about UTC in
Application Notes
The data in the D03 files are stored using Coordinated Universal Time (UTC).
(UTC) is the international time standard. It is the current term for what was
commonly referred to as Greenwich Mean (Meridian) Time (GMT). Zero (0) hours
UTC is midnight in Greenwich, England, which lies on the zero longitudinal
meridian. If your timezone is after GMT, Eastern Standard Time is GMT-05:00
hours, then include the D03 file for the day after the End Time. If your timezone is
before GMT (GMT+hh:mm), for example Taipei Standard Time is GMT+08:00
hours, include the D03 files for the day before the Start Time.
For piarch.048, the Start Time is 28-Jul-98 13:59:07 and the End time is 25-Nov-98
12:53:32. Assuming the local time zone is Pacific Standard Time, GMT-08:00 hours,
copy all D03 files from 28-JUL-98 through 26-NOV-98. Note that D03 files do not
exist on days that the controllers were not communicating with the PC Historian.
The program DSKMGR automatically deletes the D03 files when their corresponding
PI archive becomes the primary archive.
To copy corresponding D03 files
1.
Verify that there is enough free space on the disk.
2.
Click on Start, then Programs, then Windows NT Explorer.
3.
In the All Folders window, click on the + in front of D: to expand its folders.
4.
Under D:, click on HSTDATA
5.
In the Contents of D:\HSTDATA window, select all D03 files that correspond
to the archives Start/End Times, adjusting the range depending on which side of
GMT you are on.
6.
Right click on one of the selected files, then click on Copy.
7.
Right click on C:\BACKTEMP, and then click on Paste.
To backup history files to tape

1.
If the tape drive is not connected, shutdown the Windows NT operating system,
power down the Historian, connect the tape drive to the SCSI port, power on the
tape drive, and power on the Historian. Verify that the tape is not write-protected.
Insert the tape into the tape drive, and log into the Administrator account.
2.

then Backup.
3.
Click on Window, then click on Drives.
4.
In the Drives window, double click on the C: drive. (Do not click on the
selection box next to the C:).
5.
In the C:\*.* window, click on the selection box next to the BACKTEMP
directory. An X appears in the selection box. An X with gray background appears
in the selection box next to \ in the C:\*.* window and in the selection box next to
C: in the Drives window.
6.
Click on Operations, then click on Backup. The Backup Information

window displays.
7.
Enter an appropriate Tape Name. If you want to compare the files written to tape
against the files on disk, select Verify After Backup. Do not select Backup
Local Registry. If you want to use compression, in order to get more data on
one tape, select Hardware Compression. If this is a new tape, or you want to
overwrite a used tape, select Replace, otherwise, select Append.
8.
Enter an appropriate Description.
9.
Select Normal as the Backup Type.
10. Enter the log file name that you want to create/append-to. It is suggested, but not
required, that you use the same log file for all history file backup/retrievals. This
file should be different from the default file, BACKUP.LOG that is used for other
backups. The example below uses ARCHIVE.LOG.
Select Full Detail if you want to have each backup operation performed on a file
listed in the log file. Select Summary Only if you only want to see the
summary of the entire event.
11. When ready to proceed with the backup, click on OK. The backup starts.
12. When the backup operation is complete, review the Summary display.
13. Click OK.
14. Click on Operations, click on Exit.
Note Properly label the tape so that a quick look can tell you the date range of the
history files on the tape.
Clean up the BACKTEMP Directory
To delete temporary files
Type:
cd /d c:\backtemp
Press Enter.
del c:\backtemp\*.*
Press Enter. All files in the C:\BACKTEMP directory are deleted.
del *.* deletes every file in the current

directory with no way to recover the files. Users
should verify that they are in the correct directory
before entering this command.
To review the current archive list

1.
Generate a new archive list file as follows. Type:

cd /d c:\backtemp
Press Enter.
Press Enter. The Backup Time for piarch.048 now has a valid timetag.
2.
To review the archive list file. Type:

notepad archive.txt
Press Enter.
Backup Time: Never
End Time: 28-Dec-98 09:29:47
Backup Time: Never
End Time: 25-Nov-98 12:53:32
Backup Time: 20-Jan-99 08:31:59
Backup Time: Never

Backup Time: Never
.
.
.
Backup Time: Never
Piarch.047, archive number 1, is the next target archive to back up. The same
procedure will be used on this archive.
Restoring History Files

Before restoring history files, make sure that the history does not already exist as part
of the active system. One way to do this is to use the piartool utility to get a list of
registered archives.
To list the registered archives

cd /d c:\backtemp
Press Enter.
c:\pi\adm\piartool al >archive.txt
Press Enter.
notepad archive.txt
Press Enter. The list of archives displays.

Another way is to plot a graph of a point in PI-ProcessBook for the period of time of
interest.
To determine if the required D03 files are available, use the Alarm & Event Report,
under the Historian Menu, to view data for the period of time of interest.
Verify that enough disk space exists on both the system and history drive to restore
the history. Each archive is typically 32 MB. The D03 files vary in size, so allow for
25% of the archive size, or 8 MB, for the D03 files.
Restore Files from Tape

If the tape drive is not connected, shutdown the Windows NT operating system,
power down the Historian, connect the tape drive to the SCSI port, power on the tape
drive, and power on the Historian.
To restore files from tape
1.
Insert the tape containing the backup of the history files into the tape drive. Log
into the Administrator account on the Historian
2.

then Backup.
3.
If the Tapes window is minimized, expand it.
4.
Expand the Backup window and Tapes window to full screen so that the
complete Set information is viewable.
5.
Click on the box next to all Set(s) to be restored.
6.
An X appears in each box selected.
7.
Click on Operations, then Restore. The Restore Information dialog box

displays.
8.
Select Restore File Permissions.
9.
Select Verify After Backup.
10. Enter the log file name that you want to create/append-to. It is suggested, but not
required, that you use the same log file for all history file backup/retrievals. This
file should be different from the default file, BACKUP.LOG that is used for other
backups. The example below uses ARCHIVE.LOG.
11. Select Full Detail to have each backup operation performed on a file listed in the
log file.
Or, select Summary Only to see the summary of the entire event.
12. Click OK. The Restore Status dialog box displays giving information about
the restore.
13. When complete, check summary for the 0 FILES WERE DIFFERENT message
14. Click OK
To complete the procedure, the archive must be moved to the history drive and
registered, and the DO3 files moved to the target directory.
To move and register the archive to the history drive
1.

cd d\ c:\backtemp
Press Enter.
copy 19980728_048.arc d:\pi_arch
Press Enter.
del c:\backtemp\19980728_048.arc
Press Enter.
c:\pi\adm\piartool ar d:\pi_arch\19980728_048.arc
Press Enter.
To move D03 files to the target directory
1.
From the Command Prompt, change the directory. Type:

cd /d c:\backtemp
Press Enter.
2.
Copy the D03 files. Type:

copy *.d03 d:\hstdata
Press Enter.
3.
Delete the old files. Type:

del c:\backtemp\*.d03
Press Enter.
To view the restored history
Use PI-ProcessBook and the Historian Menu to view the restored data.
Unregister and Remove Restored Archives

When the restored history is no longer required, archives should be removed.
To remove archives
1.
From the Command Prompt, unregister the archive. Type:

c:\pi\adm\piartool au d:\pi_arch\19980728_048.arc
Press Enter.
2.
Delete the archive. Type:

del d:\pi_arch\19980728_048.arc
Press Enter.
There is no need to delete the corresponding D03 files. The DSKMGR program
deletes these files the next time it runs.
Leaving old archives on line for long periods of

time uses up valuable disk space and impedes the
DSKMGR program from performing its main
function, which is purging D03 files.
PI-DataLink
PI-DataLink provides a link between Excel or Lotus 1-2-3 spreadsheets and the data
in PI Data Archives.
Installing PI-DataLink
The following steps are required to load PI-DataLink. First, collect the following
configuration information from the Historian before continuing with the installation.
To collect configuration information
1.
2.
Double-click on Network, then Identification tab.
3.
Record the Computer Name; it ships as HST1.
4.
Click on the Protocol tab, and highlight the TCP/IP Protocol.
5.
Click on Properties.
6.
Record the IP Address; it ships as 192.168.1.40
7.
Click on Cancel to exit.
Second, locate the PI DataLink Version CD, load it on the target PC, and run the
setup program, as follows:
To run SETUP.EXE
E:\cdsetup\setup.exe
Press Enter. The PI-DataLink installation window displays.

2.
From the PI-DataLink installation window, select Next.
3.
Select A stand-alone version to the PC, then select Next.
4.
Select Add-in for Microsoft Excel 5.0 (32bit) or higher
5.
Select Next.
6.
For the Destination Directory, accept the default.
7.
Select Next.
8.
If a message displays asking if you want to create the directory shown in step 6,
select Yes.
9.
Enter the name of your default PI Server, using the PC Historians Computer
Name, then select Next.
10. Enter your PI user name. Type:

pidemo
Press Enter.
11. Select Next. The PI-DataLink setup to PC is complete! message displays.
12. Select OK. The Remember to configure Excel to use PI-DataLink message
displays.
13. Select OK.
Third, modify the HOSTS file on the target PC as follows.
To modify the HOSTS file
1.

notepad
C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS
Press Enter. The HOSTS file displays.

2. Add the PC Historians TCP/IP address and PC Historians Computer Name,
recorded earlier, to the end of the HOSTS file. For example:
192.168.1.40
HST1
Configuring Excel to Use PI-DataLink

The final step is to configure Excel on the target PC for PI-DataLink as follows. This
configuration must be done in each account that will use it, for example
Administrator, maint, oper.
To configure Excel
1.
From the target PC, run Excel.
2.
If you are running Office97, then make sure you have the patch from Microsoft:
Click on Help.
Click on About Microsoft Excel.
Verify you are using Microsoft Excel 97 SR-1 or later.
3.
From the Tools Menu, click on Add-ins
4.
Click on Browse and then navigate to:

C:\PROGRAM FILES\PIPC\EXCEL (or C:\PIPC\EXCEL)
5.
Select: PIPC32.XLL
6.
Click on OK. The message PIPCXL Add-In DLL displays in the Add-Ins
window, with a check mark.
7.
Click on OK. The PI Menu pick displays at the top of the spreadsheet.
8.
Click on the PI Menu, and review the Help.
Notes
Chapter 5 Installation Guide
Introduction
This Chapter is a general guide to the installation of the Historian system. As a
guide, it does not cover all the details of every start-up, but does reference other
sections in this manual where necessary. Each installation is different, and the user
requires thorough system knowledge for a successful startup.
Receiving & Handling

GE carefully inspects and packs all equipment before shipping it from the factory. A
packing list itemizing the contents of each package is supplied with the equipment.
Immediately upon receiving the system, place it under adequate
cover to protect it from adverse conditions. Packing cases are not
suitable for outdoor or unprotected storage.
Shock caused by rough handling can damage electrical equipment.
To prevent such damage when moving the equipment, observe
normal precautions along with all handling instructions printed on
the case.
Upon receipt, carefully examine the contents of each shipment and check them with
the packing list. Immediately report any shortage, damage, or visual indication of
rough handling to the carrier. Then notify both the transportation company and GE
Industrial Control Systems. Be sure to include the serial number, part (model)
number, GE requisition number, and case number when identifying the missing or
damaged part. If assistance is needed, contact:
GE Industrial Systems
Product Service Engineering, Rm. 191
1501 Roanoke Blvd.
Salem, Virginia 24153-6592 USA
Phone: +1 (800) 533-5885 or +1 (540) 378-3280
Fax:
+1 (540) 387-8606
(+ indicates the international access code required when calling from

outside the USA).
Chapter 5 Installation Guide 5-1
Unpacking & Storage

Report any shortage or
damage to GE Industrial
Systems. Save all instruction
books, disks, and
documentation provided.
It is good practice to not completely unpack the equipment until it has been placed as
near as possible to its permanent location. When unpacking, check the contents of
each case against the packing list.
If the system is not installed immediately upon receipt, it must be stored properly to
prevent corrosion and deterioration. Since packing cases do not protect the
equipment for outdoor storage, the customer must provide a clean, dry place free of
temperature variations, high humidity, and dust.
Equipment Overview
A standard Historian consists of the items listed below.
5-2 Chapter 5 Installation Guide
IBM-compatible PC containing the following:

-
Windows NT operating system
OSI software
Historian software
Two hard drives (system and history)
CD-ROM
Floppy Drive
Ethernet interface with 50 ft.of RG-58C/U or IEEE 802.3 cable
SCSI controller board
PCI modem board
Two RS-232C serial ports
One parallel port
At least one of the following communication boards:
20 MHz ARCNET board with 50 ft. of RG-62/U cable (Mark V

Stagelink Interface)
18.432 MHz ARCNET board with 50 ft. RG-62/U cable and CSF
Adapter (Mark IV CSF Interface)
Ethernet board with 50 ft. of RG-58C/U or IEEE 802.3 cable (Mark VI)
Keyboard
Color monitor
Cursor Positioning Device (CPD), mouse
DAT Drive (tape drive)
Optional items may include any of the following:
Trackball
Serial port expander board
Laser printer.
Color printer.
Long distance data set(s) (LDDS).
Computer operator station such as a PC desk, or printer stand.
Installation Instructions
Danger of shock, burn or other trauma exists if necessary
safety precautions are not taken. Only personnel
knowledgeable about the Historian and the turbine
control system should do these startup procedures.
This Chapter does not cover every detail of all startups.
To install the Historian hardware
1.
Connect the monitor to the VGA port on the back of the computer case.
2.
If the tape drive is external, connect the tape drive to SCSI port on back of the
computer case, using the supplied SCSI cable.
3.
Ensure that the SCSI terminator is properly installed on the back of the tape
drive.
Check the nameplate of all devices for ac power frequency

and voltage. Verify that the devices supplied are designed
to operate on the sites ac power frequency and voltage.
Obtain replacements from GE Industrial Systems Product
Service if there are any discrepancies.
4.
Install the power cord on the monitor
5.
Install the power cord on the tape drive
6.
Install the power cord on the computer case.
7.
Connect the keyboard to the computer case.
8.
Connect the mouse to COM1 port on back of the CPU, unless it has a PS-2
connector, then connect it to the marked PS-2 port
9.
Do not connect the Historian to the ARCNET/CSF or ARCNET/Stagelink yet,

(Mark IV and Mark V).
10. Do not connect the Historian to the Ethernet.

11. Organize all the documentation and software (CDs and floppies) in a safe,
convenient place for reference.
Configuration
To configure the Historian hardware.
1.
Power up the equipment in the following sequence

a)
Tape Drive
b) Monitor
c)
CPU
2.
After the boot sequence completes, logon the Administrator account. The
User Name is Administrator, and the as shipped Password is either
Administrator, or gepgc.
3.
If necessary, adjust the monitor such that the START button is displayed in the
lower left corner of the screen and the My Computer icon is displayed in the
upper left comer of the screen. Refer to the monitors User Guide.
4.
It is important during startup to update the time for the local Time Zone. Refer
to Setting Time Zone, Date and Time in the Maintenance Guide section of this
manual, for instructions on how this is done. See Historian Configuration for
information on creating a F:\TIMEZONE.DAT.
ARCNET/CSF Setup for Mark IV

In the case of Mark IV CSF, the physical addresses are assigned to a Message
Service Protocol (MSP) Logical Unit Number (LUN) as follows:
Address
1F
1E
1D
1C
FE
FC
FA
F8
F6
F4
F2
F0
MSP LUN
0A01
0A02
0A03
0A04
0401
0402
0403
0404
0405
0406
0407
0408
Device
Historian/HMI/Smart Remote 1
Mark IV GT1
Mark IV GT2
Mark IV GT3
Mark IV GT4
Mark IV GT5
Mark IV GT6
Mark IV GT7
Mark IV GT8
The Historian typically ships with an ARCNET/CSF address of 1F. Smart Remotes
usually ship with a CSF address of 1F. If an existing Smart Remote is connected to
the CSF, it is most likely using the address 1F. Choose an appropriate address for the
Historian and modify the ARCNET/CSF address, a three-step process.
To modify the ARCNET/CSF address
1.
Change the address in the registry as follows:

a)
Click on Start, then Settings, then Control Panel, then double click on
TCI. The Turbine Control Interface applet displays.
b) From the Turbine Control Interface applet, select the ARCNET tab.
c)
Change the ARCNET Link Address from Ox1F to Oxnn, where nn is the
new address. Ensure that the Network Type is CSF. Do not change the
Base IO Address, Base Memory Address, or the Interrupt
Number. Settings shown are typical.
Turbine Control Interface applet, ARCNET tab, CSF Network
2.
Change the LUN assignment for the Historian in F:\CONFIG.DAT as follows.

Refer to Historian Configuration in the Maintenance Guide section of this
manual for detailed information about F:\CONFIG.DAT and other important
files.

;
;
;
;
;
;
NETWORK NETWORK
DEVICE
MY
;
NUMBER
TYPE
DRIVER
LUN
;
------- ----------------NETWORK_TYPE
1
CSF
AnetDev0
0A01 ;0A01 =ARCNET link address 0x1F
3.
Change the board address to match the address entered in the Turbine Control
Interface applet by modifying the dip switches on the board. This should be
done with the system powered off, as follows:
a)
Click on Start, then Shut Down, then select Shut down the
computer?, and click on Yes.
b) When prompted, turn the computer power switch off.

c)
The ARCNET/CSF dip switches are visible and adjustable from the back of
the computer. Change the switch positions to match the address entered in
the Turbine Control Interface applet.
d) Turn the computer power on. The computer boots up.
e)
After booting, verify that the ARCNET/CSF board dip switch settings are
correct by running ARCWHO from the command prompt as follows:
-

ARCWHO
Press Enter. The ARCWHO program runs. The output of ARCWHO

should show that the ARCNET/CSF is unstable, and it should show the
Historians ARCNET/CSF correct address.
If the ARCNET driver has a problem with duplicate node addresses, it puts an event
in the System Log. This can be accessed through the Event Viewer.
To open the Event Viewer.
1.

and then Event Viewer.
2.
Click on Log, then System. The System Log displays.
3.
Double click on individual entries to view the log messages.
ARCNET/Stagelink Setup for Mark V

The Historian typically ships with an ARCNET address of 1F. Run ARCWHO on a
 or HMI to determine which ARCNET addresses are in use. If 1F is in use then
change the Historians ARCNET address.
Note The IOS uses addresses 64 68, and the EX2000 uses addresses 01 - 05.
These devices are not visible to ARCWHO on the . These addresses should not
be used for the Historian.
To modify the ARCNET address

1.
Change the Address in the Registry as follows:

a)
Click on Start, then Settings, then Control Panel, then double click on
TCI.
b) From the Turbine Control Interface applet, select the ARCNET tab.
c)
2.
Modify the ARCNET Link Address from Ox1F to Oxnn, where nn is the
new address. On HST 1.4 and later, ensure that the Network Type is Stage
Link. Do not change the Base IO Address, Base Memory Address, or
the Interrupt Number.
Change the ARCNET Board Dip Switches as follows:

a)
Click on Start, then Shut Down, then select Shut down the
computer?, and click on Yes.
b) When prompted, turn the computer power switch off.

c)
The ARCNET/Stagelink dip switches are visible and adjustable from the
back of the computer. Change the switch positions to match the address
entered in the Turbine Control Interface applet.
d) Turn the computer power on. The computer boots.

e)
After booting, verify that the ARCNET/Stagelink board dip switch settings
are correct by running ARCWHO from the Command Prompt as follows:
-

ARCWHO
Press Enter. The ARCWHO program runs. The output of ARCWHO

should show that the ARCNET/Stagelink is unstable, and it should show the
Historians ARCNET/Stagelink correct address.
If the ARCNET driver has a problem with duplicate node addresses, it puts an event
in the System Log. This can be accessed through the Event Viewer.
To open the Event Viewer
1.

and then Event Viewer.
2.
Click on Log, then System. The System Log displays.
3.
Double click on individual entries to view the log messages.
Configure the Ethernet

For Mark IV and Mark V sites where Historian and HMI equipment are not part of a
larger plant-wide Ethernet, the following TCP/IP addresses are suggested.
Product
TCP/IP Address Range
Subnet Mask
HMIs
192.168.1.20 39
255.255.255.0
Historians
192.168.1.40 59
255.255.255.0
Printers
192.168.1.80 99
255.255.255.0
Refer to Ethernet Configuration in the Maintenance Guide section of this manual for
detailed information on modifying the TCP/IP address.
Mark VI sites should refer to UDH & PDH Ethernet IP Address Rules in GEH-6421
Mark VI System Guide documentation for suggested TCP/IP address assignments.
Connect the Historian to the ARCNET/CSF (Mark IV)

Each Historian with an ARCNET/CSF board ships with 50 ft of ARCNET cable
(RG-62/U), a T-connector, a 93-Ohm terminator, and a CSF adapter kit. Use the CSF
Adapter kit to connect the ARCNET cable to the CSF TWINAX cable. Connect the
ARCNET cable to the T-connector and the T-connector to the ARCNET/CSF board
on the back of the Historian. If the Historian is at the end of the CSF, ensure that it is
terminated at the T-connector with the 93-Ohm terminator.
Connect the Historian to the ARCNET (Mark V)

Each Historian with an ARCNET/Stagelink board ships with 50 ft of ARCNET cable
(RG-62/U), a T-connector, and a 93-Ohm terminator. Connect the ARCNET cable to
the T-connector and the T-connector to the ARCNET board on the back of the
Historian. If the Historian is at the end of the Stagelink, ensure that it is terminated at
the T-connector with the 93-Ohm terminator. Connect the other end of the ARCNET
cable to the Stagelink.
Connect the Historian to the Ethernet LAN (Mark VI and

Sites with HMIs)
Each Historian ships with 50 ft of Ethernet cable (RG-58C/U or IEEE 802.3), a Tconnector, and a 50-Ohm terminator. Connect the Ethernet cable to the T-connector,
and the T-connector to the Ethernet board, or the 10-Base-T to Thin Net converter. If
the Historian is at the end of the Ethernet, ensure that it is terminated at the Tconnector with the 50-Ohm terminator. Connect the other end of the Ethernet cable
to the LAN.
To start up the Historian
1.
Reboot PC Historian as follows:

a)
Click on Start, then Shut Down, then select Restart the computer?.
b) Click on Yes. The Historian reboots.

2.
Verify that the Historian is collecting data from the Mark IV or Mark V:
a)
After reboot, logon to the maint account. The Historian ships with three
accounts: Administrator (password: Administrator or gepgc), maint
(password: maint), and oper (no password). All passwords are case
sensitive.
b) From the Command Prompt, run VIEW0 <unitname>:<point>. Using

your unit name if different, type:
VIEW0 T1:TNH
Press Enter.
c)
Verify data collection by checking that the time-tagged value for TNH
updates once per second. If only one valid time-tagged value is displayed,
then data was collected but is not currently being collected. If the following
message appears: Failed time conversion, data is:...then data collection is
not occurring and the most likely culprit is an unstable ARCNET. Press
<Ctrl>C to exit the utility.
d) Repeat the above verification for each unit.
3.
Verify that the Historian is writing data to the PI Snapshot Database as follows:
a)
From the Command Prompt,, run VIEWPIS <unitname>:<point>.

Using your unit name if different, type:
VIEWPIS T1:TNH
Press Enter.
b) Verify data collection by checking that the time-tagged value for TNH
updates when it changes by the exception deviation.
c)
Repeat the above verification for each unit.
Software Configuration
The Historian is delivered configured for your site. Refer to Unit Configuration in
the Maintenance Guide section of this manual for details on updating the unit
directories. Reference PI Database Configuration in the Maintenance Guide section
of this manual for information on updating the data collection.
Chapter 6 Application Notes
Introduction
This chapter covers special application items, in particular diagnostics and
debugging procedures. Also covered is how to access the Historian from a remote
PC, how to set up a printer on Ethernet or a parallel port, how to make tape backups
of archive data, and to restore the tapes for viewing.
Accessing the Historian from a Client PC via LAN

The Historian uses a client-server arrangement to provide access to historical data.
There are two server programs that provide service to clients. The PI server software
provides access to data stored in the PI archive for PI-ProcessBook clients. The
World Wide Web (WWW) server provides access to alarm and event data for Web
Browser clients.
Any PC on the Plant Data
Highway can access the
Historian.
Both the PI server and the Web server use standard TCP/IP networking protocols for
communication with client programs. The Historian uses IEEE 802.3 Ethernet for
TCP/IP networking. There may be one or two Ethernet boards installed in the
Historian. Each board should be configured for a different TCP/IP network. If there
are two TCP/IP networks configured on the Historian, they are referred to as the
Plant Data Highway (PDH) and the Unit Data Highway (UDH). The UDH is
reserved for device (control) communications and should not be used for clientserver communications. The PDH should be used to connect to the PI server and the
WWW server. Any computer that is connected to the PDH can access the Historian.
In addition, since TCP/IP protocols are used, any computer on a network reachable
from the PDH has access to the Historian.
The default Web page for the Historian Web server can be accessed using the
following Uniform Resource Locator (URL):
http://HST1
http://192.168.1.40
Note The HST1 is the default computer name for the Historian and 192.168.1.40 is
the default IP address. Your Historian may have a different name and IP address.
Chapter 6 Application Notes 6-1
To access the PI server

1.
Copy the pilogin.ini file from the Historian to the client PC. This file is located
in the C:\PIPC\DAT directory, or the C:\Program Files\PIPC\DAT directory,
depending on which version of the PI software is installed on your Historian.
The file should be located in the same directory on the client PC.
2.
Create a host file entry for the Historian. For Windows NT this file is located in
C:\WINNT\system32\devices\etc\hosts. A sample entry would be as follows:
192.168.1.40 HST1
# GE Historian
After making the above configuration changes, the configured trend displays in PIProcessBook can be opened.
To open the trend display in PI-ProcessBook
1.
From the File menu in the PI-ProcessBook window, choose Open. An

Open file dialog displays.
2.
From the Open dialog box, open a PI-ProcessBook workbook file using one of
the following options:
Open a local workbook file by double clicking on the *.piw file desired. This
implies that the workbook file was copied from the Historian, or a local
workbook was created on the client PC.
Or, open a shared workbook on the Historian by entering the file name. The
name of the Historian computer and the workbook file may vary from site to
site.
\\HST1\\ShareName\\gehist.piw
This implies that the Historian created a share name for sharing its workbook(s).
The security settings on the Historian determine if this workbook file can be
accessed or not, and if changes are allowed.
Or, open a workbook on the Historian using Administrative Privileges by
entering the file name
\\HST1\\C$\\site\\pi\\gehist.piw
Note The user must be connected to the Historian with Administrator

privileges to use the C$ administrative share name.
6-2 Chapter 6 Application Notes
Installing PI-ProcessBook
The Setup program should run automatically when the PI-ProcessBook CD is
inserted in the CD ROM drive. If Autorun has been disabled on your PC, the setup
program can be run manually. This program is located in the top-level directory on
the CD in the file Msetup.exe.
To install PI-ProcessBook
1.
Insert the PI-ProcessBook CD into the CD-ROM drive. The Setup program
runs.
2.
During the setup process, follow the directions on screen and accept the default
settings when prompted. The Network Setup dialog box displays.
3.
From the Network Setup dialog box, enter the required information as shown
in the dialog box below, and click on Next.
Configuring Remote Access

The Historian is equipped with a modem, which enables a remote PC to access the
Historian via a dial-up connection. Before the Modem can be used for a dial-up
connection, the Remote Access Service (RAS) needs to be configured in Windows
NT.
To configure Remote Access (RAS)
1.
2.
Double click on the Network Configuration icon. The Network dialog box
displays.
3.
Select the Services tab.
4.
Highlight Remote Access Service, and click on the Properties button. The
Remote Access Setup dialog box displays.
5.
From the Remote Access Setup dialog box, click on the Configure
button. The Configure Port Usage dialog box displays.
6.
From the Configure Port Usage dialog box, select Dial out and Receive
calls, or Receive Calls only.
7.
Click on the OK button. The Remote Access Setup dialog box displays.
8.
Click on the Network button. The Network Configuration dialog box

displays.
9.
If dial out protocols were enabled, from the Network Configuration dialog
box, in the Dial out Protocols: box, select TCP/IP.
10. In the Server Settings: box, select TCP/IP and Require Microsoft
encrypted authentication.
11. Click on the TCP/IP Configure button. The RAS Server TCP/IP
Configuration dialog box displays.
12. From the RAS Server TCP/IP Configuration dialog box, select This
computer only.
13. Select Use static address pool: and enter 192.168.10.1 in the Begin: field,
and 192.168.10.10 in the End: field.
14. Click the OK button. The Network Configuration dialog box displays.
15. In the Network Configuration dialog box, click on the OK button. The
Remote Access Setup dialog box displays.
16. Click on the Continue button. The Network dialog box displays.
17. From the Network dialog box, click the Close button. This completes the
configuration.
18. After the Bindings update, the Network Settings Change dialog box
displays.
19. Click on the Yes button to restart your computer,

or, click on the No button to continue. (The settings will not take effect until the
system is rebooted).
Starting the Remote Access Service

Once the RAS is configured, it can be started.
To manually start RAS using Windows
1.

then Remote Access Admin.
2.
Click on Server, then Start Remote Access Server.... RAS starts.
To manually start RAS from a command prompt

net start "remote access server"
Press Enter. RAS starts.

To set up RAS to start after each reboot
1.
Click on Start, then Settings, then Control Panel, then Services.
2.
From the Services window, double click on Remote Access Server.
3.
Change Startup Type to be Automatic.
4.
Click on OK.
5.
Reboot the computer. RAS will start after each reboot.
Resolving Communication Problems between a PI Client

and a PI Server
If the following login window displays when opening PI-ProcessBook, then a
problem exists with communication between the PI client and the PI server.
To resolve the communication problem

1.
From the PI Server Login dialog box, click on Cancel, and then exit PIProcessBook.
2.
On the Historian, use Task Manager or the Control Panel applet Services
to verify that the PI Data Archive services are started. At a minimum, the
following PI services should be running:
PI Services Required to be Running on the Historian
PI Service
Program
PI Archive Subsystem
Piarchss.exe
PI Base Subsystem
Pibasess.exe
PI Message Subsystem
Pimsgss.exe
PI Network Manager
Pinetmgr.exe
PI Snapshot Subsystem
Pisnapss.exe
PI Update Manager
Piupdmgr.exe
3.
If the services are not running, see the section, Starting and Stopping the PI
Subsystems in the Maintenance Guide section of this manual, for information on
how to start the PI services.
4.
Verify the connectivity between the two PCs.
5.
If the user is attempting to run PI-ProcessBook from a PC other than the

Historian, verify the connectivity between the two PCs. Also verify that the
TCP\IP Address and Computer Name of the Historian are listed in the local PCs
%SystemRoot%\system32\drivers\etc\HOSTS file.
6.
Also verify that the C:\\PIPC\DAT\PILOGIN.INI file on the client PC

matches the C:\\PIPC\DAT\PILOGIN.INI file on the Historian.
Diagnostic Tools
The Historian provides diagnostic tools for basic troubleshooting.
Basic Generic Questions

The following basic questions can often help in determining where to start the
troubleshooting process. Sometimes the most productive tricks in debugging tell you
where not to spend your time.
Did the configuration stop functioning?
Yes: If this configuration has worked in the past, then concentrate on
communications links or device specific problems first. Do not alter the
configuration unless you know that something in the plant has changed, forcing
a change to the configuration, or else you might be compounding the problem.
No: If this configuration has never functioned, check the communications paths
first, then start looking at the configuration settings to see if there is a mismatch
causing the problem.
Has anything been changed?
Yes: If possible, undo the change and see if the problem disappears.
No: If it is certain that nothing has changed, look outside the PC for the source
of the problem, typically communications or device errors.
Are other PCs functioning correctly?

Yes: If the problem is loss of data from this PC, and all other PCs are still
getting the data OK, then the problem is probably related to this PCs
configuration or communication.
No: If the loss of data is across all PCs, then the problem is probably in the
device itself, or in a communication link to the PCs.
Overview of Approach
The Architecture Overview section of this manual, specifically the Basic Data Flow
section, provides a roadmap for following the data flow through the system. By
watching the data flow through the system, the point at which the problem appears
can be located. From this, the subsystem that needs to be addressed to solve the
problem is known.
The Basic Data Flow section indicates that there are essentially three major data
flow operations taking place in the Historian:
The data is collected from the device and placed in the Data Dictionary. (Note
that Mark VI data does not go through the Data Dictionary).
The data is read from the Data Dictionary and passed to the Historical Storage
subsystem.
The data is retrieved from the Historical Storage subsystem and presented to the
user.
While debugging, some people prefer to follow the data from the start to the end of
the data path. Others prefer to start at the end and work backward to the source.
Both of these procedures work, but with the transfers between the layers of the
Historian so well defined, the fastest way to get to the source of the Historian
problems tends to be to watch the transfers. By first looking at the transfers, large
areas of the Historian can be eliminated as the source of the problem, and the actual
subsystem experiencing the problem can be quickly located.
Once the subsystem experiencing the problem has been identified, the root cause can
usually be tracked down to the subsystem not receiving its input data, or to a
configuration error causing it to mishandle or ignore the data that it does receive.
Debugging Details
This section defines troubleshooting details and how to use various diagnostic tools
to observe the data flow through the Historian. In some cases, there will be reference
to other sections in this manual for additional details.
Most of the debugging tools are run from a command prompt window, and are
distributed in the G:\EXEC directory. That directory should be included in the PATH
statement, so simply typing the name of the program should start the debugging
program.
Error Logs
One of the first steps is to check for error log files generated by the Historian. Often
these error logs indicate the source of the problem without any further investigation
needed. This is typically true for configuration errors, but may also apply to
communication errors.
The Historian System Service (HST) creates its internal error logs as a set of files in
the G:\LOG directory. This should always be your first stop in troubleshooting any
problem. Most programs do not create an error log file unless they have something to
report. The primary exception to this is the Historian System Service itself, which
always generates a HST.LOG file. To allow for getting the system running again
quickly and troubleshooting the problem afterwards, the Historian System Service
generates a new HST.LOG when it starts, but preserves the previous version as
HST1.LOG. This means that if the Historian System Service is restarted after a
problem, the HST.LOG file is from the restart, and the HST1.LOG is the one to use
when troubleshooting the problem that required the restart.
If your site uses an ARCNET (for a Stagelink interface to a Mark V or Mark V LM,
or for a CSF interface to a Mark IV) then the ARCNET device driver is used. Device
drivers log errors into the Windows NT error log. If an ARCNET communication
problem is suspected of causing the loss of all data from an ARCNET, make sure to
check the Windows NT error log for any messages from the ARCNET driver. These
messages are under the System error log. This is also the case with the Ethernet
Global Data (EGD) System Service used when there are Mark VI or PLC devices
that support the EGD protocol.
Trace Global Sections

Many of the programs that move data or messages around the system keep a log of
the messages or data in a global section in memory. Normally this information is not
required, but during diagnostics and debugging this information can be valuable.
A global section is so called because it can be accessed by more than one program.
Obviously the program that is making the entries is accessing this global section, but
various diagnostic tools can also access this memory to print out or display the
information. Two tools are available for taking a snapshot of the global memory
contents. When the procedures here indicate that a global section is available, it gives
the name of the global section. With the name of the global section, use either tool to
access the data inside.
The first utility to take a snapshot of the global section runs as a command line utility
program. The Global Section To File program (GBL2FILE.EXE) reads a global
section of memory and writes it to a disk file. This file can then be viewed, printed,
Faxed, or E-mailed when diagnosing the problem. The contents of all global sections
listed here are ASCII text, so the resulting file can be easily viewed with Notepad,
or printed. The basic format for running GBL2FILE is as follows:
GBL2FILE
<global_section_name>
<filename>
Where:
<global_section_name> is the name of the global section given in the

instructions. The global section name is case specific, so be careful of which
letters are upper case and which are lower case.
<filename> is the name of the file selected to store the results. By convention,
usually a *.DMP extension is used to indicate that this is the dump of a global
section, but this is not a requirement. Some people use a *.TXT extension so
that double clicking on the file brings up an ASCII file viewer.
After Historian Product Code Version 1.4, a new method was introduced to simplify
accessing the global sections. A WEB interface was added to the global sections.
This is a smart WEB interface that scans for global sections and presents a menu of
the global sections found. Clicking on the desired global section displays its
contents. The results can then be saved to a file using the normal WEB browser
interface, typically by clicking File, then Save As. This global section utility is
normally not included on the Historian Menu, since it would only confuse most
users. The easiest way to access this display is to access the WEB Historian main
menu, and then append to the URL "/scripts/GEDS/wgblf.exe".
To access the Web Global Section Form
1.
From the preferred Web browser, access the Web Historian main menu.
2.
Add to the end of the URL:

/scripts/GEDS/wgblf.exe
The Web Global Section Form starts, providing the list of global sections
found, for example:
Historian Menu:
http://192.168.1.40
Global Section Form:
http://192.168.1.40/scripts/GEDS/wgblf.exe
Product Code Validation and Version Check

The Historian Product Code distribution contains many files spread out over a
number of different directories. While it is unlikely, the HST Product Code can
become corrupted by a hard drive error, or possibly even infected by a computer
virus. If this happens, all kinds of symptoms can occur and the troubleshooting of
these symptoms would be very difficult.
The Historian Product Code includes a utility program for checking the validity of
the Product Code files on the disk. This check only takes a few seconds to run, and
verifies that the programs on the disk are as distributed. When the Product Code
distribution was made, a CRC (Cyclic Redundancy Check) file was created and
included in the distribution. The CHECKCRC utility reads this CRC file and reports
on any files that are missing or have been corrupted.
To run CHECKCRC
From a Command Prompt window, type:

CHECKCRC
Press Enter. The resulting report displays, and a copy of the report is deposited
in the G:\LOG directory.
If a file is reported as missing or is a mismatch from the original distributed file, then
consider reinstalling the HST Product Code distribution to repair the problem.
Note Sites that are running beta copies of the HST Product Code should not expect
any missing or mismatched files reported, as all distributions (including beta
distributions) have valid CRC files when they ship. If code has been updated in the
field as a result of the beta test program, the updated files will show up as a
mismatch. This indicates that the system cannot be recreated by reinstalling the last
beta Product Code release. Under the beta tester software agreements, all beta code
users must update to the next official Product Code release when available.
If all files are reported to be in place and intact, then the particular version of the
HST Product Code that is running can be found in the file
G:\DATA\VERSION.DAT. This file is included in the CRC check, so if the CRC
checks pass, this will always define the version of the product code being used.
Communication Layer
The communication layer is responsible for communicating with the device in its
native format, retrieving the required data, and entering it into the Data Dictionary.
To verify that this layer is doing its job, check the Data Dictionary for periodic
updates of the point values.
The diagnostic tool VIEW0 is used to watch the Data Dictionary for point updates
and report them to the screen. It is run from a command prompt window, and
watches and reports on a single point. It shows the points timetag, value, and
engineering units. When things are working well, it shows the history of point
reports scrolling up through the window.
VIEW0 is usually the first diagnostic tool run when tracing down a problem because
of the amount of information that it presents. If the point is not being updated, it
indicates that the front-end communication system is the source of the problem. If
the point is being updated, it provides information on the points timetag and scaling,
either of which could be causing problems in the other subsystems.
Note Always check the time tag associated with the Data Dictionary point. The PI
historical data archives defend themselves against storing times that are more than
about 10 minutes into the future. If the time tag being reported by the unit is more
than 10 minutes into the future (as determined by the Historians PC clock) the PI
subsystem rejects the data.
If the data is being updated in the Data Dictionary correctly, proper communication
to the device and proper configuration of the Data Dictionary point is verified. Do
not spend any more time looking at the communications layer.
VIEW0 shows information as it enters the Data Dictionary. Two other tools exist for
watching information in the Digital Exception Message side of the front-end
programs. These programs can verify whether alarm, event, and SOE messages are
being received from the device. Verifying that the messages are being received limits
debugging to the configuration if the messages are not making it all the way to the
operator interface screens.
The first program is the Alarm Dump #1 program (ALMDUMP1.EXE). This

program watches for messages as they enter the Digital Exception Message side
of the Data Layer. As each message is received, it is formatted and displayed.
This program can also be used to generate commands back to the unit to test the
ability to send commands. ALMDUMP1 can be run with the "/?" qualifier for a
list of commands, and entering the "?" command while it is running produces a
screen with the list of commands that it will accept.
The second program is the Alarm Dump #2 program (ALMDUMP2.EXE). This

program displays a formatted copy of the current alarm queue entries in the PC.
The output can be sorted by time, or by unit and drop number. ALMDUMP2 can
be run with the "/?" qualifier for a list of command line options. This can be
used to verify the set of alarms that the Historian has received from the unit.
(Once again, if this list is correct but the operator interface screen is not, then the
problem is probably configuration - not communication.)
If the device is reporting data to many different PCs, such as an HMI or , first
check to verify that they are getting data OK. If not, the device or its communication
link would be the next place to look. If they are, then check to see if anything has
changed on the Historian. If someone has changed the configuration of the
communication front end (or this is a new installation) then debugging the
communication and its configuration is next. If there were no changes to a system
that worked, skip the configuration and check the communication link to see why
there is no longer communication with the device.
Different communication front ends have different tools for monitoring the
communication link status and health. After a quick check to make sure that the
communication links are still plugged into the PC, look into the communication front
end to try and isolate the problem.

The PDD front end receives messages over an RS-232C port, decodes the data
within the message, and places the results in the Data Dictionary. If the device sent a
time tag with the data, it is used, otherwise the Historian PC time is used.
The most common errors with new installations are with the configuration settings in
the F:\IO_PORTS.DAT file. These specify the Baud Rate, Parity, and number of
Stop Bits used for the RS-232C interface. If these values dont match what the device
is using, then no messages are received.
The PDD front end keeps a set of counters indicating the number of messages that
have been processed, and the number of errors encountered. The PDD Status
program (PDD_STAT.EXE) displays these counters. Running this program provides
an overview of the number of messages received, and error count information about
failed messages. Note that it is normal to generate an error or two during the startup
process, or if the link is unplugged and plugged back in. (Messages will be in
progress, complaints about incomplete messages or messages that start in the middle
will be logged.) Running this utility multiple times and looking at the change in the
counter values is a good way to verify that the messages are or are not being
received.
If the messages are being received but the data in the Data Dictionary does not match
the data in the device, then it is either a configuration error in the layout of the
message, or a problem with the scaling of the signal. The layout of the message must
be obtained from the people who did the device configuration, and this must match
the F:\UNITn\PDDUMP.DAT file. The scaling used for each signal is determined by
matching the scale code from the units UNITDATA.DAT file to the units
ENGLISH.SCA file.
Sometimes you can verify message layout problems by varying one point and
making sure that the correct point (and only that one point) changed in the Data
Dictionary. Make sure to check the signal before and after the signal of interest
to make sure that there is not a single byte offset while looking at two byte
values. If the correct signal is changing then there may be a scaling issue instead
of a data message layout issue.
The Predefined Data Dump keeps a log of the messages it receives and errors it
encounters in a global section of memory. This global section can be viewed to see
the message flow by looking at the pddump_trace<n> global section.
Refer to the Data Dump Configuration section in the Maintenance Guide for
additional information on debugging Predefined Data Dump links.
Modbus over RS-232C

The Modbus over RS-232C front-end exchanges messages over an RS-232C port,
decodes the data within the message, and places the results in the Data Dictionary.
The time tag is always the time in the Historian PC.
the F:\IO_PORTS.DAT file which specify the Baud Rate, Parity, and number of Stop
Bits used in the interface. This file also defines the link and slave address to be used.
If these values dont match what the device is using, then no messages are
exchanged. The arithmetic mode (signed 16 bit, unsigned 16 bit) in which the link
is running is also defined here. A mismatch in the link mode causes the data to be
misinterpreted.
The Modbus front end keeps a set of counters indicating the number of messages that
have been processed, and the number of errors encountered. The Modbus Master
Status program (MM_STAT.EXE) displays these counters. Running this program
gives an overview of the number of messages exchanged, and any error information
available about overall failed messages. Running this utility multiple times and
looking at the change in the counter values is a good way to verify that the messages
are or are not being exchanged.
Modbus registers or a problem with the scaling of the signal. The layout of the
Modbus registers must be obtained from the people who did the device
configuration, and this must match the F:\UNITn\MMbus<n>.DAT file. The scaling
used for each signal is determined by matching the scale code from the unit's
UNITDATA.DAT file to the unit's ENGLISH.SCA file.
Sometimes you can verify that it is a register assignment problem by varying

one point and making sure that the correct point (and only that one point)
changed in the Data Dictionary. If the correct signal is changing then there may
be a scaling issue instead of a register layout issue.
The Modbus front end keeps a log of the messages it exchanges and errors it
the message flow by looking at the MModbus_trace<n> global section.
Refer to the Modbus Configuration section in the Maintenance Guide for additional
information on debugging Modbus links.
MSP over CSF

The MSP over CSF front end exchanges messages over the CSF with the device.
The list of CSF networks and devices on that network is defined in the
F:\CONFIG.DAT file. Both periodic data and Digital Exception Messages are
supported.
To verify that the PC sees a stable CSF network, the ARCWHO utility is used.
ARCWHO reports on the networks being used, and the nodes that are present on
each network. If the node that supplies the data being debugged does not appear on
the ARCWHO list, then the device is either powered off, disconnected from the
network, or there is a problem with the network stability. ARCWHO reports on the
number of reconfigurations of the network. If this number is increasing then there is
a problem with the network stability. Reconfigurations should occur when a device
joins or leaves the network, which happens when it is restarted. (A one node network
is never stable, as this is a token passing network and there is no other node to
participate in the token exchange.)
Note Network stability issues can usually be traced to improper termination and/or
shield grounding on the network. The TWINAX portion of the network needs to
have the end of each run terminated (via hardware jumper on the MAUx), and for
each cable run, one and only one end of the cable runs shield should be grounded
(via hardware jumper on the MAUx). If HUB repeaters are used, the HUB acts as a
terminator. By convention, GE typically grounds the shield at the HUB repeater.
(The convention is to ground the end of each cable run closest to the HUB repeater.
This is not a requirement, only a convention.)
Note The coax portion of the CSF should use RG-62/U cable, and include a 93
Ohm termination resistor at the end of the cable run.
If ARCWHO shows an unstable network or a missing node, then communications is
the problem. If ARCWHO shows that the node is present and the network is stable,
then next verify that the configuration settings in F:\CONFIG.DAT match that node
to the correct unit.
For new installations, if ARCWHO does not show any information about the
network, or does not show any nodes at all, then it is possible that the
configuration information that tells the PC how to talk to the ARCNET board is
incorrect. The ARCNET board used for the CSF needs to be an 18.432 MHz
ARCNET board (not a 20 MHz board). If in doubt, look at the markings on the
crystal on the ARCNET board to verify the crystal frequency.
The PC interfaces to the ARCNET board using a section of dual ported memory,
a set of I/O registers, and an interrupt request line (IRQ). The TCI Control Panel
Applet is used to inform the ARCNET driver how to communicate with the
board, and which type of board it is. If the board settings and the Control Panel
Applet settings disagree, the board will not function correctly. Usually the
ARCNET driver detects the problem (when it cant contact the ARCNET board
using the settings given) and logs that fact to the NT System Event Log. Look
there for any ARCNET driver error messages.
If network or node stability is in question, there is another resource that may help
find the extent of the problem, or at least when the problem occurred. The Beacon
Monitor program exchanges heartbeats with each node that is assigned to a unit, and
keeps a log of the birth and death of each node. This log of the birth and death of
each node is kept in a global section of memory, and can be viewed as the
beacon_trace global section. Each entry indicates the time, network, node, and
transition (birth, death, restart) of the node. High transition rates indicate either a
node that is restarting often, or a communication link problem.
MSP over RS-232C

The MSP over RS-232C front end exchanges messages over an RS-232C link with
the device. The list of RS-232C based networks and devices on that network is
defined in the F:\CONFIG.DAT file. The settings to be used with the RS-232C link
(baud rate, parity) are defined in the F:\IO_PORTS.DAT file. Both periodic data
and Digital Exception Messages are supported.
the F:\IO_PORTS.DAT file which specify the Baud Rate, Parity, and number of Stop
Bits used in the interface. If these values dont match what the device is using, then
no messages are received. Next check the network and LUN assignments in the
F:\CONFIG.DAT file. If these do not match what the device expects, then messages
could be exchanged, but the messages are rejected as coming from a unit not
required for communication.
It is important to note that the RS-232C link to the turbine control must be plugged
into the correct RS-232C port on the device. Most devices support two ports for
serial MSP communication, but each port has its own unique address. The
F:\CONFIG.DAT file includes a MY LUN field which is used as the return address
for message exchanges with the panel. If the wrong port is used on the device, the
replies from the device are sent over the wrong RS-232C port, thereby preventing
communications. Do not switch the two RS-232C links on the device in an attempt to
determine if the problem is a failed port on the device, it will not work due to the
port addressing. (Typically the network MY LUN field must be 0B01 when using the
first port on the device, and 0B02 when using the second port on the device).
The MSP over RS-232C front end keeps a global section trace of the traffic across
the RS-232C link. To see this message trace, look at the serial_trace_<n> global
section. The format of this global section is complicated, but look for whether there
are messages being received from the device or not. (In other words, forget about the
content of the messages, and simply look to see that the panel is exchanging
messages with this PC.)
BMS/MSP over Stagelink

The BMS/MSP over Stagelink front end exchanges messages over the Stagelink with
the device. The list of Stagelink networks and devices on that network is defined in
the F:\CONFIG.DAT file. Both periodic data and Digital Exception Messages are
supported.
To verify that the PC sees a stable network, the ARCWHO utility is used. ARCWHO
reports on the networks being used and the nodes that are present on each network.
If the node that supplies the data that is being debugged does not show up on the
ARCWHO list, then the device is either powered off, disconnected from the network,
or there is a problem with the network stability. ARCWHO reports on the number of
reconfigurations of the network. If this number is increasing then there is a problem
with the network stability. Reconfigurations should occur when a device joins or
leaves the network, which will happen when it is restarted. (A one node network is
never stable, as this is a token passing network and there is no other node to
participate in the token exchange.)
Note Network stability issues can usually be traced to improper termination or

improper cable used. The coax network needs to have the end of each run terminated
with a 93-Ohm termination resister. The cabling should be RG-62/U coax cable. (A
common error in new installations is to use RG-58C/U Ethernet cables, or 50-Ohm
Ethernet terminators on the ARCNET. This often works on a two node network, but
causes instabilities when additional nodes are added.)
If ARCWHO shows an unstable network or a missing node, then communications is
the problem. If ARCWHO shows that the node is present and the network is stable,
then next verify that the configuration settings in F:\CONFIG.DAT match that node
to the correct unit.
For new installations, if ARCWHO does not show any information about the
network, or does not show any nodes at all, then it is possible that the
configuration information that tells the PC how to talk to the ARCNET board is
incorrect. The ARCNET board used for the Stagelink needs to be a 20 MHz
ARCNET board (not an 18.432 MHz board). If in doubt, you can look at the
markings on the crystal on the ARCNET board to verify the crystal frequency.
The PC interfaces to the ARCNET board using a section of dual ported memory,
a set of I/O registers, and an interrupt request line (IRQ). The TCI Control Panel
Applet is used to inform the ARCNET driver how to communicate with the
board, and which type of board it is. If the board settings and the Control Panel
Applet settings disagree, the board does not function correctly. Usually the
ARCNET driver detects the problem (when it cant contact the ARCNET board
using the settings given) and logs that fact to the NT System Event Log. Look
there for any ARCNET driver error messages.
If network or node stability is in question, there is another resource that can find the
extent of the problem, or at least when the problem occurred. The Beacon Monitor
program exchanges heartbeats with each node that is assigned to a unit, and keeps a
log of the birth and death of each node. This log of the birth and death of each node
is kept in a global section of memory, and can be viewed as the beacon_trace global
section. Each entry indicates the time, network, node, and transition (birth, death,
restart) of the node. High transition rates indicate either a node that is restarting often
or a communication link stability problem.

The EGD/ALM over Ethernet front end receives global broadcasts for periodic data,
and exchanges messages with the device for Digital Exception Reports over an
Ethernet link.
Configuration of the EGD message exchanges includes indicating what devices to
listen for, and what points from that device to save. The EGD.INI file indicates the
devices and EGD exchanges to receive, and the EGD_PUSH.DAT file indicates the
points within the page to save.
The EGD.INI file is located in the systems Windows Directory (typically
C:\WINNT). It defines the EGD exchanges that this box is to receive and place in the
EGD global memory section. Typically this file is obtained by copying it from an
HMI. In some cases, the file is edited to remove pages that the HMI uses for its
display but the Historian does not need. As such, it is often a proper subset of the
version on the HMI. (Removing unused or unneeded pages saves a little CPU time in
the Historian, especially if the unused pages are transmitted at a high rate). This file
is read by the EGD Server System Service, which logs any errors that it finds in the
Windows NT System Event Log.
Once the pages are received and placed in the EGD global memory section, the
EGD_PUSH program reads the individual points out of the pages and forwards them
in the PI Snapshot Database. The F:\EGD_PUSH.DAT file is used to control what
points are read out of the EGD exchanges and sent to PI. Each point must define the
EGD exchange number, offset with the exchange, point type, and PI point name. It
can optionally include a gain and offset for engineering units conversion between the
EGD page and the PI Database. (A quality bit definition is also supported, but is not
used by the Historian software). The EGD_PUSH program logs any errors that it
encounters to the G:\LOG directory EGD_PUSH.LOG file.
If no data is being received from a unit, basic communication can be verified by

using the PING command, such as PING 192.168.1.1. PING should report that it
was able to communicate with the device, a timeout indicates that the
communication link from the PC to the device has problems. If communication is
OK, check the Ethernet addresses and exchange information in the EGD.INI file to
verify that they are correct. (Verify this against an HMI that is receiving the data).
Often you will find that the definition of the EGD exchange was changed without
updating the Historian.
If some points are being received but other points are not, look in the
EGD_PUSH.DAT file for the exchange number containing the points in question. If
all the missing points are from the same exchange, make sure that the EGD.INI file
includes receiving that exchange.
If the data is being received but the value is incorrect, verify that the exchange
number, offset, and point type in the EGD_PUSH.DAT file is correct. (Once again,
comparing the location shown in the EGD_PUSH.DAT file against the location
configured in a working HMI is the best way to verify the correct offset and point
type). If a gain and offset is specified in the EGD_PUSH.DAT file, verify that it has
been defined correctly.
The Digital Exception Message subsystem can sometimes be used to track down
configuration problems. The Alarm Receiver program (ALMRCV.EXE) keeps track
of all Digital Exception Messages that it receives over the Ethernet. This message
history can be obtained from the global section named almrcv_enet. If this shows
reception of messages from the correct IP address, but the alarms do not show up in
the ALMDUMP1 program, then the mapping of the Ethernet IP address to the unit
number is probably incorrect. This mapping is done in the F:\ENETALM.DAT file.
Make sure that the unit number is the correct unit number, and that F:\CONFIG.DAT
file indicates that the unit with that unit number is a Mark VI turbine control. (If it
was configured with the wrong unit type, it does not expect messages from the
Ethernet and does not forward them if they are received.)
Modbus over Ethernet

The MODBUS over Ethernet front end exchanges messages over an Ethernet link,
decodes the data within the message, and places the results in the Data Dictionary.
The time tag is always the time in the Historian.
the F:\IO_PORTS.DAT file which specify the Ethernet address and port for the
Modbus slave device. If these values dont match what the device is using, then no
messages are exchanged.
The arithmetic mode (signed 16 bit, unsigned 16 bit) in which the link is running
is also defined here. A mismatch in the link mode causes the data to be
misinterpreted.
The Modbus front end keeps a set of counters indicating the number of messages that
have been processed, and the number of errors encountered. The Modbus Master
Status program (MM_STAT.EXE) displays these counters. Running this program
gives an overview of the number of messages exchanged, and any error information
available about overall failed messages. Running this utility multiple times and
looking at the change in the counter values is a good way to verify that the messages
are or are not being exchanged.
Modbus registers, or a problem with the scaling of the signal. The layout of the
Modbus registers must be obtained from the people who did the device
configuration, and this must match the F:\UNITn\MMbus<n>.DAT file. The scaling
used for each signal is determined by matching the scale code from the units
UNITDATA.DAT file to the units ENGLISH.SCA file.
Sometimes it can be verified that it is a register assignment problem by varying

one point and making sure that the correct point (and only that one point)
changed in the Data Dictionary. If the correct signal is changing then there may
be a scaling issue instead of a register layout issue.
The Modbus front end keeps a log of the messages it exchanges and errors it
the message flow by looking at the MModbus_trace<n> global section.
Refer to the section of this manual on Modbus Configuration for additional
information on debugging Modbus links.
Historical Storage Layer - Obtaining the Data

Data from the Data Dictionary is passed into the PI Historical Storage subsystem by
the PI_PUSH program. PI_PUSH uses the F:\PI_PUSH.DAT file as its definition of
the points that are read from the Data Dictionary, scaled, and passed into the PI
Snapshot Database. Make sure to check the G:\LOG directory for a PI_PUSH.LOG
file, which reports any errors that PI_PUSH has found.
Data from the EGD global memory section is passed into the PI Historical Storage
subsystem by the EGD_PUSH program. EGD_PUSH uses the F:\EGD_PUSH.DAT
file as its key to the points that have to be read from the EGD global memory
section, scaled, and passed into the PI Snapshot Database. Make sure to check the
G:\LOG directory for an EGD_PUSH.LOG file, which reports any errors that
EGD_PUSH has found.
A utility program is available to verify that the data has made it correctly into the PI
Snapshot Database. The View PI Snapshot program (VIEWPIS.EXE) is a command
line utility that watches a given point and reports when the point has changed in the
PI Snapshot Database. Watching the point arrive in the PI subsystem verifies the
points existence, configuration, and scaling. (This is often used with VIEW0 running
in another window to watch the data flow from the unit to the Data Dictionary, and
from the Data Dictionary to the PI Snapshot Database.)
A deadband filter is applied to the real time data in the process of moving it from the
Data Dictionary to the PI Snapshot Database. The PI_PUSH program uses the
Exception Deviation (EXCDEV) field defined in the PI configuration for the point to
only pass significant changes in values into the PI Snapshot Database. If the VIEW0
window shows that the point is not changing by more than this Exception Deviation
value, then the value in the PI Snapshot Database is not expected to be updated.
If VIEWPIS is unable to access the point in the PI Snapshot, then the point
probably was not created in the PI subsystem. Typically this would be fixed by
adding the point to the units HSTPOINT.SRC file and rerunning the automation
tools. (See the section on the configuration for the unit type for additional details
on making these updates).
If the point is updating in the VIEW0 window but not updating in the VIEWPIS
window, then make sure that the PI_PUSH.DAT file includes a line mapping the
point named in the Data Dictionary to the point named in PI. If PI_PUSH is
unable to locate a specified point in either the Data Dictionary or PI
configuration, it indicates it in the PI_PUSH.LOG file. (This test assumes that
the value of the point in the VIEW0 window is changing by more than the
Exception Deviation deadband defined for the point in the PI configuration
database.)
If the point is updating in the VIEWPIS window but has an incorrect value,
check the scaling of the point in PI, and any gain and offset supplied in the
PI_PUSH.DAT file.
If the point is updating in the VIEW0 window but not in the VIEWPIS window,
make sure to check the time reported by VIEW0. If the time is too far into the
future (10 minutes ahead of the Historian PC clock) the PI subsystem rejects the
point. (This is a safety feature to prevent incorrect data from corrupting the
historical data archives). If the point updates are being rejected, then PI_PUSH
or EGD_PUSH will record an error in their log file indicating that PI reported
the point as being invalid.
The Digital Exception Message historical storage subsystem reports any errors that it
finds to the G:\LOG directory in the ALARMDSK.LOG file. The Alarm Disk
program (ALARMDSK.EXE) uses the same interface to obtain the Digital Exception
Messages as the ALMDUMP1 program does, so if ALMDUMP1 is reporting the
messages, the ALARMDSK program should be storing them, or explaining why not
in its log file. A general increase in size of the historical data files should be seen as
messages are received, however, because of buffering and cluster sizes, do not
expect to see the files byte length go up upon receiving each individual alarm. Look
for the increase in the historical data directory as files with the generic format of
YYYYMMDD_typ.D03, where YYYYMMDD indicates the date of the file, "typ"
indicates the type (ALM = Alarm, EVT = Event, SOE = SOE) and the .D03
extension indicates that this is a Digital Exception Message history file. The date on
the file is after conversion to UTC timetags, so it is as far ahead or behind local time
as local time is off from UTC.
Historical Storage Layer - Saving the Data Historically

The PI subsystem stores the latest value of each point in the PI Snapshot Database.
When a new value of the point is received, PI must decide whether to move a copy
of the existing point value in the Snapshot to the historical archives before it
overwrites the Snapshot with the new value. One of PIs strengths is the algorithm
that it uses to make this determination and the associated data compression that is
obtained. (More information on this can be obtained from the PI manuals.)
On the same level of debugging as the View PI Snapshot utility program, a View PI
Archive program (VIEWPIA.EXE) is supplied for retrieving data from the PI
Archive. It is a command line utility program that prompts for the start time, end
time, and the PI point of interest. It then retrieves the raw records from the PI
Archive and displays them.
A typical test involves watching a point value change in the PI Snapshot using the
VIEWPIS program. After a known sequence, the data that was saved in the historical
archive is retrieved using the VIEWPIA program. If the data from the PI Snapshot
did not get moved into the PI Archive correctly, the PI configuration for the point
needs to be checked. Part of each points configuration is whether it should be saved
historically or not (ARCHIVE attribute), and the historical compression deadband
(COMPDEV). If the ARCHIVE attribute is not set, the point is not saved
historically. If the compression deadband is set to too high a value, the point is not
saved historically. These are the primary items to check for the point.
Note The algorithm that is used to determine which values get placed in the PI
Archive, and which get filtered, is based in part on a slope-interpolation scheme.
Points that are changing at a constant rate do not generate as many values in the
historical database as expected, based on experience with value (not slope) based
filters. This has lead many people to believe there is a problem when in fact there is
not. Read about the algorithms used in the PI manuals before making too many fine
adjustments to the points historical compression settings.
Historical Data Retrieval

Almost all of the problems associated with historical data retrieval are due to
configuration or communication errors. In some cases, security issues come into play
as the clients and servers have various schemes for protecting the visibility of the
data. Because all of the historical data access methods are true client-server schemes
(WEB interfaces, PI-ProcessBook and PI-DataLink) there is less actual configuration
of the data, leaving mostly communications and security settings as sources of
problems.
When there is a report of an error in retrieving data, usually one of the first steps is to
go to the Historian itself to see if the data is present. If the data is available from the
Historian, then concentrate on why the data is not making it to the client. If the data
is not available on the historian, then determine if the data was saved historically but
the client can not retrieve it, or if it was not saved in the first place.
When configuring a new site, it is not uncommon to find that data is available from
the Historian, but not available from any other PC. Often this is due to the method
that most of the clients use to get to the Historian in the first place. The front end
communication programs tend to use raw IP addresses to get from one computer or
device to another. This means that the name of the box (the Computer Name) is not
required, and therefore can be changed if desired. This works well for interfaces
where people configure it once and then never have to see it again. At the Historical
Data Client level though, names are much more common than the cryptic addresses.
Most of the clients use the name of the computer instead of its IP address when
configuring the client. There needs to be a way to translate from the computer name
to the network IP address. There are many ways to do this translation, the most
common is through the use of the HOSTS file. Typically a site creates a HOSTS file
that includes the names and addresses of all computers, and then distributes this file
to all computers. This file is located in a drivers\etc directory under the Windows
System32 directory, which on a typical Historian would translate to:
C:\WINNT\System32\drivers\etc\HOSTS
Note Larger networks typically do not use the HOSTS file in favor of using a
centralized name server. Each client contacts this name server when it wishes to do a
name to number translation. This is easier to manage for larger networks with many
changes, which is why most large networks use name servers. The Historian
networks (as shipped) tend to be smaller, static networks so the HOSTS file method
is adequate. The historian supports either method.
Note Some computer networks use Dynamic Host Configuration Protocol (DHCP)
to dynamically assign IP addresses to computers. Each computer contacts a DHCP
server and asks for an IP address to use. The Historian should not be configured to
use DHCP on the Unit Data Highway (UDH) to talk to the control devices. It can be
configured to use DHCP on the Plant Data Highway. This is only done when an
interconnection between the Plant Data Highway (PDH) and a larger network is
required. The Historian should be configured like any other Windows NT based
computer; there are no additional restrictions placed on the network configuration by
the Historian software.
The LAN Manager (Local Area Network Manager) software supplied as part of the
Windows NT operating system also supports a name-to-address translation file that
supports a few more features. Historian sites typically do not use this feature, but if it
is included and is wrong, it can interfere with the translations in the HOSTS file.
The typical Historian does not have a LAN Manager HOSTS file (LMHOSTS), but
check and make sure that one has not been defined which conflicts with the HOSTS
file.
The normal test for correct name-to-address translation is to use the PING command.
PING takes either an IP address or a computer name as its parameter and then reports
back on its ability to contact the computer. It can be asked it to show the name
associated with an address by running it with the "-a" parameter. Examples include:
PING 192.168.1.40
Checks for communication to the Historian
PING HST1
Checks for Historian name definition
PING -a 192.168.1.40
Checks the name associated with the Historian address
In addition to the Historians IP address, the port that each client connects to needs to
be defined for the client. (To contact a server, the client needs to be configured with
the computer and the Ethernet port on that computer.) The Historian uses the normal
standard Ethernet port addresses for each subsystem:
The WEB Server uses the standard HTTP port address of 80.
The PI Server uses the standard PI Data Archive port address of 5450.
If data is available from the Historian, and the client can see the Historian, but the
client can not retrieve the data, then often security is preventing access to the desired
data. The various client packages have various methods of controlling security, so
check the client documentation to determine what is needed to satisfy the security
issues. Clients with operator interfaces are usually pretty good about putting up
warning or error message boxes indicating the cause of the error, but clients that are
report oriented are not always as clear as to the cause of the problem. If there is a
report that can not access some data, try running a user interface client looking at the
same data. It may be able to produce a better indication of the source of the problem.
CHECKCRC
CHECKCRC is a Command Line utility program that checks the files distributed by
the HST Product Code to make sure that all the files exist on the PC, and that they
have not been corrupted or infected with any computer viruses. It is useful when
troubleshooting software problems to verify that all required Product Code files are
in place and intact.
Background
The HST Product Code consists of many computer files spread out over multiple
directories. When debugging software problems, it is helpful to know that all the
required files exist and have not been corrupted in any way.
When the HST Product Code distribution is made, one of the last steps is to create a
HST.CRC file that contains the CRCs of all files distributed by that product. This file
is used as the list of files that must exist and the CRC of each file. There is one
HST.CRC file in each directory that HST populates. This scheme allows multiple
Product Code distributions to populate the same directory; each one has a separate
*.CRC file associated with its distribution.
CHECKCRC is currently implemented as a batch file that checks all of the *.CRC
files that it finds in the product distribution directories. This means that running
CHECKCRC checks all products that support this type of CRC file checking.
Operation
CHECKCRC is normally run from a Command Prompt window. There are no
command line parameters. CHECKCRC does use the pseudo drive G:, so this needs
to be defined. This is typically done by starting the HST System Service. If the HST
System Service is running, then the G: drive is defined and can find the Product
Code files that need to be checked.
CHECKCRC reports problems by reporting files as one of the following:
MISSING - The file was listed in the *.CRC file, but not found in the directory.
MISMATCH - The file listed in the *.CRC file was found on the disk, but the
CRC of the file on the disk did not match the CRC in the *.CRC file. This
means that the file on the disk is not the same file that was distributed as part of
the Product Code.
The next example shows that CHECKCRC found one problem. The ALMRCV.EXE
file in the G:\EXEC directory is not the version that was distributed with the HST
Product Code. (The fact that it is checking the HST.CRC file means that the file is
distributed as part of the HST Product Code.)
G:\EXEC>CHECKCRC
CHECKING "G:\EXEC\HST.CRC" FILES IN "g:\exec\".
g:\exec\ALMRCV.EXE, MISMATCH
CHECKING "G:\DATA\HST.CRC" FILES IN "g:\data\".
...All files matched.
CHECKING "C:\WINNT\System32\HST.CRC" FILES IN "c:\winnt\system32\".
CHECKING "C:\InetPub\scripts\GEDS\HST.CRC" FILES IN "c:\inetpub\scripts\geds\".
CHECKING "C:\InetPub\wwwroot\GEDS\HST.CRC" FILES IN "c:\inetpub\wwwroot\geds\".
G:\EXEC>
VIEW0 - View One Second Data

VIEW0 is a command line utility that collects one point from the Data Dictionary
and writes it to the screen every second. The data continues until the user exits the
program by hitting any key on the keyboard. The data is time tagged with the time
from the unit. This is a useful program for verifying that the configuration
information is correct, communications is established with the unit, and the units
time is set. It is also a fast way to watch a single point and see a short history of its
values.
Background
Sometimes it is useful to be able to quickly display the value of a single point from a
unit, including its unit supplied timetag. VIEW0 displays a points time and value in
a scrolling DOS window.
Operation
VIEW0 is a command line utility program that is run from a Command Prompt
window. If run with the /? parameter, a help screen is provided. If run with no
parameters, it asks for the name of the point to monitor.
The following example shows a sample VIEW0 help screen:
F:\UNIT1>VIEW0 /?
VIEW0 is a simple console utility program to watch a point in the
Data Dictionary. If you enter a unit name and point name on the
command line it will look for that point, otherwise it will prompt for
the unit and point name.
COMMAND FORMAT:
VIEW0 [/SHOW]
[un:pointname]
The /SHOW option causes the program to use the 7 character XdShow() value
instead of the default display value.
F:\UNIT1>
In the following example, the point BB1 (a vibration measurement) was collected
from unit T1. It was stopped by pressing a key on the keyboard.
F:\UNIT1>VIEW0 T1:BB1
06-FEB-1998 13:55:12.187
06-FEB-1998 13:55:13.187
06-FEB-1998 13:55:14.187
06-FEB-1998 13:55:15.187
06-FEB-1998 13:55:16.187
06-FEB-1998 13:55:17.187
06-FEB-1998 13:55:18.187
06-FEB-1998 13:55:19.187
06-FEB-1998 13:55:20.187
06-FEB-1998 13:55:21.187
06-FEB-1998 13:55:22.187
06-FEB-1998 13:55:23.187
06-FEB-1998 13:55:24.187
06-FEB-1998 13:55:25.187
06-FEB-1998 13:55:26.187
06-FEB-1998 13:55:27.187
06-FEB-1998 13:55:28.218
06-FEB-1998 13:55:29.218
0.28
0.28
0.29
0.31
0.32
0.34
0.28
0.29
0.31
0.32
0.34
0.28
0.29
0.31
0.32
0.34
0.29
0.31
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
in/s
06-FEB-1998
06-FEB-1998
06-FEB-1998
06-FEB-1998
06-FEB-1998
13:55:30.218
13:55:31.218
13:55:32.218
13:55:33.218
13:55:34.218
0.32
0.34
0.28
0.29
0.31
in/s
in/s
in/s
in/s
in/s
F:\UNIT1>
VIEWPIA - View PI Archive Data

VIEWPIA is a command line utility that extracts and displays historical data for one
point from the PI Archive Database. It takes a starting and ending time along with a
point name, and displays the data from the PI Historical Archive in scrolling
command prompt window. For each record, the points timetag and value are shown.
VIEWPIA can retrieve data from the PI Archive Database on the local node, or can
fetch the data from a remote node.
This program provides a simple means to verify that the configuration is correct,
communications are established, and the PI system is receiving and saving historical
data. It is also useful as a quick way to view historical information about a single
point.
Operation
VIEWPIA is a command line utility program that is run from a command prompt
window. If run with the /? parameter, a help screen is provided.
By default it uses the PI Archive on the local computer. If run with the /NODE
parameter it fetches data from the PI Archive on a remote computer. If /NODE is
used, the IP address used to contact the remote computer is required, which can be a
name that translates to an IP address, or the address itself in dotted notation format.
For the NT platforms, the PI server typically uses socket 5450, so this needs to be
included in the remote node information.
Example using IP address:
VIEWPIA
/NODE=192.168.1.40:5450
Example assuming HOSTS entry, or name lookup capability:

VIEWPIA
/NODE=HST1:5450
The following example shows a sample VIEWPIA help screen:

F:\UNIT1>VIEWPIA /?
VIEWPIA - VIEW PI ARCHIVE DATA
This program will show all PI ARCHIVE entries for a given point
within a given time range. The program will prompt for the starting
date, starting time, ending date, and ending time. It will then prompt
for the name of the point. The default start time will be today, five
minutes ago. The default end time will be five minutes from now.
All times are SERVER LOCAL times.
COMMAND LINE: VIEWPIA [/NODE=hostname:<socket>]
By default the program will run connected to "localhost:5450", but
you can change which PI SERVER will supply the data by using the /NODE
option. If you supply a hostname make sure to include the :<socket>
part. (NT based PI SERVERS usually use socket 5450.)
F:\UNIT1>
In the following example, the TNH signal (Turbine speed, in percent of online speed)
is displayed with the data coming from the local node. The resulting information is
presented in both integer format and floating point format. The data is the raw data
records from the PI Archive Database, which include all filtering and slope
interpolation done inside the PI Archive Database.
F:\UNIT1>VIEWPIA
Enter starting date (YYYY MM DD) [1998 02 09]: 1998 02 05
Enter starting time: (HH MM SS) [09 33 43]: 10 00 00
Enter ending date (YYYY MM DD) [1998 02 05]:
Enter ending time: (HH MM SS) [09 43 43]: 10 20 00
Enter the point name: T1:TNH
>> Node: localhost:5450
>> From: 1998.02.05 10:00:00
>>
To: 1998.02.05 10:20:00
>> Point: T1:TNH
1998.02.05 10:06:26.842
1998.02.05 10:06:28.842
1998.02.05 10:06:33.842
1998.02.05 10:06:46.842
1998.02.05 10:06:53.842
1998.02.05 10:07:00.842
1998.02.05 10:07:25.842
1998.02.05 10:07:36.874
1998.02.05 10:07:40.874
1998.02.05 10:07:44.905
1998.02.05 10:07:47.936
1998.02.05 10:07:50.936
1998.02.05 10:07:52.936
1998.02.05 10:07:57.968
1998.02.05 10:08:00.968
1998.02.05 10:08:03.968
1998.02.05 10:08:07.000
1998.02.05 10:08:11.031
1998.02.05 10:08:14.062
1998.02.05 10:08:17.062
1998.02.05 10:09:26.187
1998.02.05 10:10:19.218
1998.02.05 10:10:38.218
...End of data.
0
2
5
14
19
22
16
15
18
23
26
30
32
39
42
46
49
54
57
61
81
97
100
0.230469
2.085938
5.339844
14.269531
19.007813
22.406250
16.730469
15.351563
18.121094
23.718750
26.500000
30.675781
32.085938
39.585938
42.394531
46.570313
49.351563
54.917969
57.652344
61.027344
81.347656
97.328125
100.097656
F:\UNIT1>
VIEWPIS - View PI Snapshot Data

VIEWPIS is a command line utility that watches the PI Snapshot Database and
shows the current time and value of a given point. It continues to update the value in
a scrolling window until terminated by hitting any key. This program provides the
same function as the VIEW0 program, but it uses the PI Snapshot Database instead
of the HST Data Dictionary as its source of information.
When evaluating the results of VIEWPIS, remember that the Historian uses the
Exception Deviation deadband defined for each point as a filter when populating the
PI Snapshot Database. Unless a point value changes by more than this deadband, the
existing value in the PI Snapshot Database will not be replaced by a new value.
VIEWPIS can watch the PI Snapshot Database on the local node, or a remote node.
This program provides a simple means to verify that the configuration is correct,
communications are established, and the PI system is receiving and processing data.
It is also useful as a quick way to watch a single point of data.
Operation
VIEWPIS is a command line utility program that is run from a command prompt
window. If run with no parameters or the /? parameter, a help screen is provided.
By default it uses the PI Snapshot on the local computer. If run with the /NODE
parameter it can be used to watch the PI Snapshot on a remote computer. If /NODE
is used, the IP address used to contact the remote computer is required, which can be
a name that translates to an IP address, or the address itself in dotted notation format.
For the NT platforms, the PI server typically uses socket 5450, so this needs to be
included in the remote node information.
An example using IP address:
VIEWPIS
/NODE=192.168.1.40:5450
An example assuming HOSTS entry, or name lookup capability:

VIEWPIS
/NODE=HST1:5450
The following example shows a sample VIEWPIS help screen:

F:\UNIT1>VIEWPIS /?
VIEWPIS - VIEW PI SNAPSHOT DATA
This program will monitor a single point in the PI SNAPSHOT and
print out a line when the time or the value changes. The program
runs until terminated with a key strike on the keyboard.
COMMAND LINE: VIEWPIS [/NODE=hostname:<socket>] [PI_PointName]
By default the program will run connected to "localhost:5450", but
you can change which PI SERVER will supply the data by using the /NODE
option. The name must translate to a valid IP address, or you can use
a dotted address for the hostname. If you supply a hostname make sure
to include the :<socket> part. (NT based PI SERVERS usually use
socket 5450.)
The PI_PointName parameter is optional. If supplied it must be the name
of a valid point in the PI Database. If not supplied, the user will be
prompted for the name of the point to watch.
F:\UNIT1>
In the following example, the DWATT signal was monitored on the local node. (The
DWATT Exception Deviation deadband was set to 0.3 MW). The resulting
information is presented below in both integer format and floating point format. The
display was terminated by pressing a key at the terminal.
F:\UNIT1>VIEWPIS T1:DWATT
1998.02.11 09:46:41.662
1998.02.11 09:48:21.554
1998.02.11 09:48:22.555
1998.02.11 09:48:23.567
1998.02.11 09:48:24.578
1998.02.11 09:48:25.590
1998.02.11 09:48:26.601
1998.02.11 09:48:27.603
0
5
7
7
6
6
5
5
0.000000
5.718750
7.796875
7.343750
6.765625
6.343750
5.875000
5.437500
1998.02.11
1998.02.11
1998.02.11
1998.02.11
1998.02.11
F:\UNIT1>
09:48:28.615
09:48:29.626
09:48:30.628
09:48:31.639
09:48:32.641
4
4
3
3
3
4.875000
4.453125
3.984375
3.390625
3.062500
Ethernet Printer Setup on the Historian

If the printer is to be placed
on the plant-wide Ethernet,
obtain a TCP/IP address from
the Information Management
Group..
This section describes how to set up the HMI or Historian to use a printer connected
over the Ethernet. Before configuring the printer communications, verify that the
printer has an Ethernet board. If it does not then it can only be connected to one PCs
parallel port. Refer to Parallel Port Printer Setup on the Historian below for
information.
To setup the printer
1.
Setup the printer, connect it to the Ethernet, and turn the power on.
2.
Reference the printer documentation to print printer setup.
3.
Reference the printer documentation for directions on how to set the TCP/IP
address to 192.168.1.70.
To add Microsoft TCP/IP printing to the Historian

1.
Log on to Administrator account.
2.
Click on Start, then Settings, then Control Panel, then double-click on

Network, and select the Services tab.
3.
Search for Microsoft TCP\IP Printing. If it is there, skip to To Adding the

printer to the Historian below.
4.
If Microsoft TCP\IP Printing cannot be found, place the Windows NT

Workstation CD in the CD-ROM drive.
5.
Click on Add. The Select Network Services dialog box displays.
6.
Choose Microsoft TCP\IP Printing.
7.
Click on OK. The Windows NT Setup dialog box displays.
8.
Click on Continue. Microsoft TCP/IP Printing is installed.
9.
Click on Close. Bindings are updated, and Network Settings Change

displays.
10. From the question Do you want to restart your computer now?, choose Yes.
The Historian reboots.
To add the printer to the Historian
1.
Log on to the Administrator account.
2.
Click on Start , then Settings, then Printers. The Printers window displays.
3.
Double-click on Add Printer. The Add Printer Wizard displays.
4.
From the Add Printer Wizard, select My Computer.
5.
Click on Next.
6.
Select Add Port. The Printer Ports dialog box displays.
7.
Select LPR Port, and click on New Port. The Add LPR Compatible
Printer dialog box displays.
8.
For the Name or address of server providing LPD, enter: <tcp/ip address>
9.
For the Name of printer or print queue on that server: (leave blank).
10. Click on OK. The Printer Ports dialog box displays.

11. Click on Close. The Add Printer Wizard displays.
12. Click on Next.
13. Find and click on Manufacturer HP (or appropriate manufacturer).
14. Find and click on printer model, for example HP Color LaserJet 5.
15. Click on Next.
16. Type in name of this printer: (use the default).
17. To the question: Do you want your Windows-based programs to use this printer
as the default printer?, choose Yes or No as appropriate.
18. Click on Next.
19. Choose Not Shared, to indicate that this printer will not be shared with other
network users.
20. Click on Next.
21. To the question: After would you like to print a test page?, choose Yes.
22. Click on Finish, and verify the page printed.
23. To the question: Did it print your test page correctly?, choose Yes.
After installing the driver, reinstall the Service Pack provided on the system disk.
This is typically found in a directory of the format C:\NT40_SPn, or C:\SPn.
The Historian is now ready for printing.
Parallel Port Printer Setup on the Historian

This section describes how to set up the Historian to use a printer connected to the
parallel port. Setup the printer, connect the parallel cable, and power on the printer.
Refer to the printer documentation to print printer setup.
To add the printer to the Historian
1.
Log into the Administrator account.
2.
Click on Start, then Settings , then Printers. The Printers window displays.
3.
Double click on Add Printer. The Add Printer Wizard appears.
4.
From the Add Printer Wizard, select My Computer.
5.
Click on Next.
6.
Choose LPT1.
7.
Click on Next.
8.
Find and click on Manufacturer HP (or appropriate manufacturer).
9.
Find and click on printer model, for example HP Color LaserJet 5.
10. Click on Next.

11. Type in the name of this printer: (use the default).
12. To the question: Do you want your Windows-based programs to use this printer
as the default printer?, choose Yes or No as appropriate.
13. Click on Next.
14. Choose Not Shared, to indicate that this printer will not be shared with other
network users.
15. Click on Next.
16. To the question: After would you like to print a test page?, choose Yes.
17. Click on Finish.
18. To the question: Did it print your test page correctly? , choose Yes.
After installing the driver, reinstall the Service Pack provided on the system disk.
This is typically found in a directory of the format C:\NT40_SPn, or C:\SPn.
The Historian is now ready for printing.
Facts about UTC

This section provides some information on the UTC time standard.
What is UTC?
Coordinated Universal Time (UTC) is the international time standard. It is the
current term for what was commonly referred to as Greenwich Mean Time (GMT).
Zero (0) hours UTC is midnight in Greenwich England, which lies on the zero
longitudinal meridian. Universal time is based on a 24 hour clock, therefore,
afternoon hours such as 4 pm UTC are expressed as 16:00 UTC (sixteen hours, zero
minutes).
Refer to: http://wwwghcc.msfc.nasa.gov/utc.html
Is UTC the same thing as Greenwich Mean Time (GMT)?

GMT is a 24 hour astronomical time system based on the local time at Greenwich,
England. GMT can be considered equivalent to UTC when fractions of a second are
not important. However, by international agreement, the term UTC is recommended
for all general timekeeping applications, and use of the term GMT is discouraged.
Refer to: http://www.boulder.nist.gov/timefreq/faq/q25.htm
Why is the abbreviation for Coordinated Universal Time

"UTC" instead of "CUT"?
In 1970 the UTC system was devised by an international advisory group of technical
experts within the International Telecommunication Union (ITU). The ITU felt it
was best to designate a single abbreviation for use in all languages in order to
minimize confusion. Since unanimous agreement could not be achieved on using
either the English word order, CUT, or the French word order, TUC, a compromise
of using neither, UTC, was adopted.
Refer to: http://www.bldrdoc.gov/timefreq/faq/q5.htm
Does the switch to Daylight Savings Time affect UTC?

No. UTC, which refers to time on the zero or Greenwich meridian, is not adjusted to
reflect either changes either to, or from, Daylight Savings Time.
Refer to: http://www.bldrdoc.gov/timefreq/faq/q11.htm
WEB Browser Information

Browser Requirements
The Historian Menu generates forms that utilize features documented in the HTML
V3.2 specification. Browsers that do not conform to HTML V3.2 will not display
predefined form information correctly. Netscape Navigator V3.0 or higher, or
Microsoft Internet Explorer V3.0 or higher, is required.
Browser Facts
What is a Web Browser?
A Web Browser is used to locate and display Web pages. It is a client software
application that retrieves HTML documents from a server via Internet HTTP
Protocol, and displays them. The two most popular browsers are Netscape Navigator
and Microsoft Internet Explorer. Both of these are graphical browsers, which means
that they can display graphics as well as text.
Where can I get Microsoft Internet Explorer?
This can be obtained from Microsoft Corporation. Refer to:
http://www.microsoft.com/windows/ie/default.htm
Where can I get Netscape Navigator?
This can be obtained from Netscape Corporation. Refer to:
http://www.netscape.com/navigator/
Procedures
History File Archive Procedure
This procedure explains how to create a tape backup of archived data. In the
following example piarch.048 (archive #2) and its corresponding D03 files are
backed up to tape. Refer to the Off Line Storage section of the Maintenance Guide
for detailed infomation on this procedure.
To create a tape backup
1.
Check if a temporary directory exists. If not create C:\BACKTEMP as follows.

From a Command Prompt, type:
mkdir c:\backtemp
Press Enter.
cd /d c:\backtemp
Press Enter.
2. Type:
Press Enter. A list of all archives is created.

3.
To determine which archive to backup, type:

notepad archive.txt
Press Enter. The list of archives displays in Notepad. Determine the archive
number, <archive #>, for the target archive. Archive numbers are assigned to
archives in reverse chronological order. The primary archive always has archive
# 0.
4.
Mark the archive as "backup in progress", copy the target archive to the
temporary directory, then unmark it as follows. Type:
c:\pi\adm\piartool -bs 2
Press Enter.
copy d:\pi_arch\piarch.048 c:\backtemp
Press Enter.
c:\pi\adm\piartool be
Press Enter.
5.
Convert the archive to a non-shiftable archive as follows. Type on one line:
start /low /b c:\pi\bin\piarchss -if c:\backtemp\piarch.048
-of 19980728_048.arc dup
Press Enter.
6.
Delete the shiftable archive as follows. Type:

del c:\backtemp\piarch.048
Press Enter.
7.
Copy the corresponding D03 files to the temporary directory. Use Windows NT
Explorer to select and copy the archives corresponding D03 files in
D:\HSTDATA to C:\BACKTEMP. Include the day before, or the day after D03
file based on the sites relationship to UTC.
8.
Backup the history files to tape as follows:

a)
Click on Start, then Programs, then Administrative Tools

(Common), then Backup.
b) Click on the Window menu option, then click on Drives. The Drives
window displays.
c)
In the Drives window, double click on the C: drive. (Do not click on the
selection box next to the "C:").
d) In the C:\*.* window, click on the selection box next to the BACKTEMP
directory.
e)
Click on Operations menu option, then click on Backup. The Backup

Information dialog box displays.
f)
From the Backup Information dialog box, enter the required information.
g) Click OK.
h) Exit the Backup utility when complete.
9.
Label the tape
10. Delete all the files in the temporary directory as follows. Type:
del c:\backtemp\*.*
Press Enter.
11. To backup additional archive data return to step two of this procedure.
History Files Restore Procedure

This procedure describes how to restore archived data from tape so the historical data
can be viewed. In the following example PI Archive 19980728_048.arc and its
corresponding D03 files are restored from tape. Refer to the Off Line Storage section
of the Maintenance Guide for detailed information on this procedure.
To restore and view files from tape
1.
Restore files from tape as follows:

a)
Click on Start, then Programs, then Administrative Tools

(Common), then Backup. The Backup window displays.
b) If minimized, expand the Tapes window.

c)
Expand the Backup window and Tapes window to full screen so that the
complete Set information is viewable.
d) Click on the box next to all the Sets to be restored. An X appears in each
box selected.
e)
Click on Operations, then on Restore. The Restore Information

dialog box displays.
f)
From the Restore Information dialog box, enter the required

information, and click OK.
2. Move the restored archive to the target directory and register it with the PI
subsystem as follows. From the Command Prompt, type:

cd /d c:\backtemp
Press Enter.
copy 19980728_048.arc d:\pi_arch
Press Enter.
del c:\backtemp\19980728_048.arc
Press Enter.
c:\pi\adm\piartool ar d:\pi_arch\19980728_048.arc
Press Enter.
3.
Move the D03 files to the target directory as follows. Type:

copy *.d03 d:\hstdata
Press Enter.
del c:\backtemp\*.d03
Press Enter.
4.
View the restored historical data.
5.
Unregister and remove the restored archives as follows. Type:

c:\pi\adm\piartool au d:\pi_arch\19980728_048.arc
Press Enter.
del d:\pi_arch\19980728_048.arc
Press Enter.
Configuring Data Collection

Analog, digital, and accumulator points (signals) can be set up for collection in the
Historian for the following unit types:
Modbus
Mark IV
Mark V
Mark VI
The following procedures describe how to:
Configure HSTPOINT.SRC for the various point types.
Use the tools, HSTDBU.EXE and HSTDBS.EXE to create the required data
files.
Configure the PI Database to reflect the changes made.
Delete points from the PI Database.
To configure HSTPOINT.SRC for an analog point using raw counts

all versions)
1.
In F:\UNITn\UNITDATA.DAT, locate the point and record its Scale Code

Type (column 4).
2.
In the appropriate scale code file (METRIC.SCA, ENGLISH.SCA, or

CUSTOM.SCA), use the Scale Code Type from UNITDATA.DAT, to locate
the Scale Code number (column 2), and record the Gain (Conversion Factor)
(column 3), and the Engineering Units string (column 6).
3.
Determine the Compression Deviation, also called significant change. The

Compression Deviation is the change in value of the analog point that is used by
PIs compression algorithm to determine when to save the point to archive. It is
defined in Engineering Units.
For example: 5 Degree C or 9 Degree F is a commonly used compression
deviation for exhaust thermocouples. The compression deviation should be
greater than the noise level of the point.
4.
Convert the compression deviation from engineering units to counts using the
following algorithm (Windows NT supplies a calculator under Accessories).
Counts = ((Compression Deviation) * 32768) / (Conversion Factor)
5.
Add the necessary information to F:\UNITn\HSTPOINT.SRC as follows:

a)

cd /d f:\unit1
Press Enter.
notepad hstpoint.src.
Press Enter. The hstpoint.src file displays in Notepad.

b) Scroll down through the file and add the point under the analog section. The
point name must start in the first column and there must be at least one
space between the point name and the counts.
The Format is: <point name> <counts>. The semi-colon ; denotes a
comment; these are ignored during the processing of this file. Use the other
points as examples.
c)
When the analog points have been added, click on File, then Save.
d) Click on File, then Exit.

To configure HSTPOINT.SRC for an analog point using engineering
units (HST version 1.4 and later)
1.
In F:\UNITn\UNITDATA.DAT, locate the point and record its Scale Code

Type (column 4).
2.
In the appropriate scale code file (METRIC.SCA, ENGLISH.SCA, or

CUSTOM.SCA), use the Scale Code Type from UNITDATA.DAT, to locate
the Scale Code number (column 2), and record the Engineering Units
string (column 6).
3.
Determine the Compression Deviation, also called significant change, in

Engineering Units.
4.
Determine the High and Low plot limits in the same Engineering Units as the
previous step.
5.

a)

cd /d f:\unit1
Press Enter.
b) Scroll down through the file and add the point under the analog section.
Format: <point name> <sigchg> "<eng units>" <low plot> <hi plot>
The point name must start in the first column and at least one space must
separate all fields, such as between the point name and the significant
change.
The Engineering Units should be surrounded by Double quotes as in deg
F. The semi-colon ; denotes a comment; these are ignored during the
processing of this file. Use the other points as examples.
Enter the optional Low Plot value in Engineering Units.
Enter the optional High Plot value in Engineering Units.
c)
When the analog points have been added, click on File, then Save.
d) Click on File , then Exit.

To configure HSTPOINT.SRC for a digital point
1.
Verify the Signal Name from F:\UNITn\UNITDATA.DAT
2.

a)

cd /d f:\unit1
Press Enter.

b) Scroll down through the file and add the point under the digital section. The
point name must start in the first column. Use the other defined digital
points as examples.
The semi-colon ; denotes a comment. Comments are ignored during the
processing of this file.
To set up a digital point for collection, list the <point name>
For example:
L4
c)
; Master Protective Logic
When the digital points have been added, click on File, then Save.

To configure HSTPOINT.SRC for an accumulator point (Mark V only)
1.
Verify the Signal Names from F:\UNITn\UNITDATA.DAT
2.

a)

cd /d f:\unit1
Press Enter.
b) Scroll down through the file and add the points under the accumulator
section. Accumulator points are stored in the Mark V as two separate
words. The point name must start in the first column. Use the other defined
accumulator points as examples.
The semi-colon ; denotes a comment. Comments are ignored during the
processing of this file.
To set up an accumulator point pair for collection, list the:
I_name PI_name [gain [offset]] [(min,max)]
I_name - Text string, format:
(MSW, LSW) This is two data dictionary signals that are combined into a
single 32 bit value to put into one PI signal.
gain to be applied to the data dictionary value before it is put into PI.
offset to be applied to the data dictionary value after the gain is applied
and before value is put into PI.
The PI value is compared to the min and max value and a flag is set in PI
when the value is less than the min value or greater than the max value.
An "*" can be use to show that the min or max value is not used.
Examples:
(ACCUM_01_MSW, ACCUM_01_LSW) T1:ACCUM_01 0.1 0.0 (*,*)
c)
When the accumulator points have been added, click on File, then Save.
Creating PI_PUSH.U and PICONFIG.U unit files

PI_PUSH.U and PICONFIG.U unit files must be created for the units that have been
modified. These are created using HSTDBU.EXE. The following example uses
METRIC.SCA as the scale code file. Use the scale code file appropriate for your site.
To create PI_PUSH.U and PICONFIG.U unit files using HSTDBU.EXE.
cd /d f:\unit1
Press Enter.
hstdbu /scale=metric.sca/log
Press Enter.
notepad hstdbu.log
Press Enter. The hstdbu.log file displays in Notepad.

2.
Review the file for warnings and errors. Warnings do not have to be corrected.
If you do correct something that caused a warning, re-run HSTDBU.EXE.
Errors must be corrected and HSTDBU.EXE re-run before proceeding.
3.
Click on File, then Exit to leave the file.
To create PI_PUSH.DAT and PICONFIG.DIF system files using

HSTDBS.EXE
From a Command Prompt at the root of F:, type:

cd /d f:\
Press Enter.
hstdbs
Press Enter. The system files are created.

To stop the Historian software.

net stop hst
Press Enter. The Historian software stops.

To configure the PI Database using PICONFIG.EXE
1.

cd /d f:\
Press Enter.
c:\pi\adm\piconfig.exe <piconfig.dif >piconfig.log
Press Enter.
notepad piconfig.log
Press Enter. The piconfig.log file displays in Notepad.

2.
Review the PICONFIG.LOG file for errors. At the very end of the file is status
information; a sample is shown below:
PIconfig
600 Data lines

23 Command lines
0 Records in error...
600
3.
Records Edited
It is mandatory that the message 0 Records in error... displays before

continuing. If errors are found, review the log file for the points which were in
error, then correct PICONFIG.DIF, and re-run the PICONFIG.EXE command.
To start the Historian software

net start hst
Press Enter. The Historian starts.
Verifying Data Collection

Use VIEW0.EXE to verify that the Data Dictionary is updating. This tool displays
the updates to a given point each time the Data Dictionary is updated by the
supporting unit communications. One second updates are expected.
To use VIEW0.EXE
1.

view0 t1:tnh
Press Enter. A list of point updates displays, as in the following example:

09-JUL-1998
09-JUL-1998
09-JUL-1998
09-JUL-1998
2.
10:04:44.735
10:04:45.747
10:04:46.805
10:04:47.818
98.5
98.6
98.6
98.7
%
%
%
%
Press any key to stop the updates.
Use VIEWPIS.EXE to verify that the PI Snapshot Database is being updated. This
tool displays the updates to a given point each time the PI Snapshot Database is
updated by either PI_PUSH or EGD.PUSH program. Updates are expected whenever
the points value changes by at least its Exception Deviation. In the following
example, TNH has an exception deviation of 0.2%.
To use VIEWPIS.EXE
1.

viewpis t1:tnh
Press Enter. A list of point updates displays, as in the following example:

09-JUL-1998 10:04:54.735
09-JUL-1998 10:05:07.818
2.
99.1 %
98.4 %
Press any key to stop the updates.
Deleting Points from the PI Database

Deleting a point makes that points previously stored data
inaccessible.
The PI Data Archive subsystem maintains some points for its
internal consistency checks. These points should not be
deleted. Refer to the PI Data Archive manual.
Note Prior to deleting a point from PI Database, remove that point from the units
historical configuration files. These include HSTPOINT.SRC, CHNG_Q.SRC,
CHNG_B.SRC, EVENT_Q.SRC, and EVENT_B.SRC. Failure to do so will cause
the point to be added back into the PI Database the next time the Historian
configuration tools are run.
To delete points from the PI Database using PICONFIG.EXE
1.
Create a F:\PIDELETE.DIF file like the sample file below. In this file, a *
denotes a comment.
* PIDELETE.DIF
* This following sample Data Input File (DIF) uses the commands
* required by PICONFIG.EXE to delete points from the PI database.
*
@tabl pipoint
@ptclas classic
@mode delete
@istr tag
*enter list of tags here

T1:ATID
T1:BB10
T1:BB11
T1:BB12
T1:BB7
T1:BB8
T1:BB9
@endsection
2.
Redirect PIDELETE.DIF through PICONFIG.EXE. From the Command

Prompt, type:
c:\pi\adm\piconfig.exe <pidelete.dif >pidelete.log
Press Enter.
notepad pidelete.log
Press Enter. The output of a successful run displays as follows:

*> T1:ATID
*> T1:BB10
*> T1:BB11
*> T1:BB12
*> T1:BB7
*> T1:BB8
*> T1:BB9
PIconfig
7 Data lines
5 Command lines
0 Records in error...
7
Records Deleted
3.
It is mandatory that the message 0 Records in error... displays before

continuing. If errors are found, review the log file for the points which were in
error, then correct PIDELETE.DIF, and re-run the PICONFIG.EXE command.
Glossary of Terms
ALM
Alarm Protocol, a communication protocol used by many GE devices for delivering
Digital Exception Messages including alarms, events, and SOEs.
application code
Software that controls the machine or process, specific to the application.
archive
A fixed length file used by the PI Data Archive subsystem for storing compressed
process data. These are created on the history drive and can be stored on tape.
ARCNET
Attached Resource Computer Network, a LAN communications protocol developed
by Datapoint Corporation. ARCNET defines the physical (coax and chip) and
datalink (token ring and board interface) layer of a 2.5 MHz communication
network.
ASCII
American Standard Code for Information Interchange. It is an 8-bit code used for
data.
baud
Unit of data transmission. Baud rate is the number of bits per second transmitted.
Bently Nevada
Manufacturer of shaft vibration monitoring equipment.
BIOS
Basic I/O System which performs the initial processor bootup.
Glossary of Terms 1
bit
Short for Binary Digit. This is the smallest unit of memory used to store only one
piece of information with two states, such as One/Zero or On/Off. Data requiring
more than two states, such as numerical values, requires multiple bits.
BMS
Basic Message Service, a communication protocol used by many GE devices.
board
Printed wiring board, or circuit board, used for electronic circuits.
boot
Start a controller or PC by applying power.
Boolean
Digital statement that expresses a condition that is either True or False, also called a
discrete, or logical signal.
bus
Electrical path for transmitting and receiving data, such as the backplane of a board
rack or a communication network.
byte
Group of binary digits (bits).
CIMPLICITY HMI
PC-based operator interface software configurable to work with a wide variety of
control and data acquisition equipment.
client-server
Software architecture where one software product makes requests on another
software product. For example, an arrangement of PCs with software making one a
data acquisition device and the other a data using device.
COM port
Serial communication port on a PC or controller, such as COM1 and COM2.
configure
Select specific options, either by editing disk files, or by setting the location of
hardware jumpers, or by loading software parameters into memory.
CRC
Cyclic Redundancy Check which is used to detect errors in data such as
transmissions or files on a disk.
2 Glossary of Terms
Cross Plot
Display of two variables, plotted one against the other over time, in an X-Y type plot
to detect signal correlations and to analyze performance.
CSDB
Control Signal Database, used in the turbine controller to store real time process data
used in the control calculations.
CSF
Control System Freeway, a token passing communication network, typically using
TWINAX cabling, running at 2.3 MHz. CSF is also called Control Signal Freeway.
DCS
Distributed Control System, used for process control applications including control
of boilers and other power plant equipment.
deadband
Range of values inside of which the incoming signal can be altered without changing
the output response. The Historian uses a sophisticated deadband algorithm to decide
whether to save or discard incoming data, as part of its data compression function.
EGD
Ethernet Global Data, a network protocol used by some controllers. Devices share
data through periodic EGD exchanges (pages of data).
Ethernet
LAN with a 10 or 100 Megabaud data rate, used to link one or more computers
and/or controllers together. It features a collision avoidance/collision detection
system. It uses TCP/IP and I/O services layers that conform to the IEEE 802.3
standard, developed by Xerox, Digital Equipment Corporation, and Intel.
event
Discrete signal generated by a change in a status of a logic signal in a controller.
EX2000
GE generator exciter control. It regulates the generator field current to control the
generator output voltage.
firmware
Set of executable software, stored in memory chips that hold their content without
electrical power, such as EPROM or Flash memory.
forcing
Setting a signal to a particular value, regardless of the value the blockware or I/O is
writing to that signal.
Glossary of Terms 3
frame rate
Basic scheduling rate of the controller. It encompasses one complete input-computeoutput cycle for the controller.
Global Time Source (GTS)

Worldwide system supplying UTC (Coordinated Universal Time) using a network of
satellites.
heartbeat
Signal emitted at regular intervals by software to demonstrate that it is still active.
hexadecimal (hex)
Base 16 numbering system using the digits 0-9 and letters A-F to represent the
decimal numbers 0-15. Two hex digits represent 1 byte.
Historian Client Toolset

Software package that allows a PC to become a client for the Historian data. This is
licensed software consisting of components from both GE and OSI Software, Inc.
HMI
Human Machine Interface. The GE HMI is a Windows NT based operator interface
to the turbine controllers and auxiliary power plant equipment. The HMI uses
CIMPLICITY as the operator interface, and supports the Historian Client Toolset for
viewing Historian data.
HRSG
Heat Recovery Steam Generator. This uses exhaust heat from a gas turbine to
generate steam.
HST
GE supplied software package, running as a system service, that implements the
Historian functions on a PC.
ICS
Integrated Control System. The GE ICS combines various power plant controls into
a single distributed control system.
IEEE
Institute of Electrical and Electronic Engineers. This is a United States-based society
that publishes standards.
initialize
Set values (addresses, counters, registers, and such) to a beginning value prior to the
rest of processing.
4 Glossary of Terms
I/O
Input/output interfaces that allow the flow of data into and out of a device.
IOS
Intelligent Operator Station.
LAN
Local Area Network.
logical
Statement of a true/false sense, such as a Boolean.
Mark IV, Mark V, Mark V LM, Mark VI

Versions of the GE turbine controls that perform turbine-specific speed control,
logic, sequencing, and protection functions.
MSP
Message Service Protocol, a communication protocol used by many GE devices.
Modbus
Serial communication protocol, initially developed by Gould Modicon for use
between PLCs and other computers.
OSI
Company that produces the PI-ProcessBook, the PI-DataLink, and the PI Data
Archive software used in the Historian.
PC
Personal Computer.
PDD
Predefined Data Dump, a communication protocol providing periodic data from a
turbine control.
PI Data Archive
OSI Software Inc. subsystem of the Historian which handles the storage and retrieval
of process data.
PI-DataLink
OSI Software Inc. subsystem of the Historian that provides data to spreadsheet
applications.
Glossary of Terms 5
PI-ProcessBook
OSI Software Inc. subsystem of the Historian that displays plant information stored
in the PI Data Archives.
PI Snapshot
OSI Software Inc. subsystem of the Historian that contains all the real time process
values.
Plant Data Highway

Ethernet communication network linking the Historian, HMI Servers, HMI Viewers,
workstation, and printers.
PLC
Programmable Logic Controller. These are designed for discrete (logic) control of
machinery, and they also computes math (analog) functions and perform regulatory
control.
point
Basic unit for variable information in the controller, also referred to as signal.
reboot
Restart the controller or PC after a controlled shutdown.
RDS
Reliable Datagram Service, a communication protocol used by many GE devices to
transport Digital Exception Messages.
Sequence of Events (SOE)

Record of high speed contact inputs. Most turbine controllers support a data
resolution of one millisecond.
signal
Basic unit for variable information in the controller, also referred to as point.
Simplex
Non-redundant controller or I/O channel.
Stagelink
ARCNET-based communication link used by many controllers.
Tag
Identifying name given to a process measurement point.
6 Glossary of Terms
TCI
Turbine Control Interface. It is the GE supplied software package on the HMI that
interfaces to the turbine control.
TCP/IP
Communication protocol developed for inter-processor communications.
TMR
Triple Modular Redundancy. This is an architecture that uses three identical sets of
control and I/O, and votes the results to obtain highly reliable output signals.
Toolbox (Control System Toolbox)

Windows-based software package used to configure the Mark VI controllers,
exciters, and drives.
trend
Time based screen plot showing the history of process values, available in the
Historian, HMI, and the Control System Toolbox.
Trigger
Transition in a discrete signal from 0 to 1, or from 1 to 0, initiating an action or
sequence.
Unit Data Highway

Connects the Mark VI controllers, generator panels, PLCs, and Bently Nevada
equipment to the Historian and HMI Servers.
UTC
Coordinated Universal Time, an international time reference standard.
web browser
PC software, such as Microsoft Internet Explorer or Netscape Navigator, allowing
screens and data to be viewed over a network from a server.
Windows NT
Windows New Technology, a 32-bit operating system from Microsoft.
Glossary of Terms 7
Notes
8 Glossary of Terms
7R
*(,QGXVWULDO6\VWHPV
13,'RFXPHQWDWLRQ'HVLJQ5P
5RDQRNH%OYG
6DOHP9$86$
5HDGHU&RPPHQWV
)D[
*(,QWHUQDO'&
*HQHUDO(OHFWULF&RPSDQ\
:HZHOFRPHFRPPHQWVDQGVXJJHVWLRQVWRPDNHWKLVSXEOLFDWLRQPRUHXVHIXO
<RXU1DPH
7RGD\V'DWH
<RXU&RPSDQ\V1DPHDQG$GGUHVV
-RE6LWH
*(5HTXLVLWLRQ1R
<RXU-RE)XQFWLRQ+RZ<RX8VH7KLV3XEOLFDWLRQ
3XEOLFDWLRQ1R
,IQHHGHGKRZFDQZHFRQWDFW\RX"
)D[1R
3KRQH1R
(PDLO
$GGUHVV
3XEOLFDWLRQ,VVXH5HYLVLRQ'DWH
*HQHUDO5DWLQJ
([FHOOHQW
&RQWHQWV
2UJDQL]DWLRQ
7HFKQLFDO$FFXUDF\
&ODULW\
&RPSOHWHQHVV
'UDZLQJV)LJXUHV
7DEOHV
5HIHUHQFLQJ
5HDGDELOLW\
*RRG
)DLU
3RRU
$GGLWLRQDO&RPPHQWV
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
6SHFLILF6XJJHVWLRQV&RUUHFWLRQVLQIRUPDWLRQWKDWFRXOGEHH[SDQGHGRQDQGVXFK
3DJH1R
&RPPHQWV
______
__________________________________________________________________________________
______
__________________________________________________________________________________
______
______
__________________________________________________________________________________
__________________________________________________________________________________
______
__________________________________________________________________________________
______
__________________________________________________________________________________
2WKHU&RPPHQWV:KDW\RXOLNHZKDWFRXOGEHDGGHGKRZWRLPSURYHDQGVXFK BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
___________________________________________________________________________________________
___________________________________________________________________________________________
___________________________________________________________________________________________
___________________________________________________________________________________________
___________________________________________________________________________________________
___________________________________________________________________________________________
2YHUDOOJUDGH&RPSDUHGWRSXEOLFDWLRQVIURPRWKHUPDQXIDFWXUHUVRIVLPLODUSURGXFWVKRZGR\RXUDWHWKLVSXEOLFDWLRQ"
6XSHULRU
&RPSDUDEOH
,QIHULRU
'HWDFKDQGID[RUPDLOWRWKHDGGUHVVQRWHGDERYH
'RQRWNQRZ
&RPPHQW BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
)ROGKHUHDQGFORVHZLWKVWDSOHRUWDSH
BBBBBBBBBBBBBBBBBBBBBBBBBBBB
3ODFH
VWDPS
KHUH
*(,QGXVWULDO6\VWHPV
13,'RFXPHQWDWLRQ'HVLJQ5P
5RDQRNH%OYG
6DOHP9$86$
)ROGKHUHILUVW
*(,QGXVWULDO6\VWHPV
*HQHUDO(OHFWULF&RPSDQ\

5RDQRNH%OYG
ZZZ*(LQGXVWULDOFRP
6DOHP9$86$

GEH-6422 Turbine Historian System Guide PDF

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

GEH-6422 Turbine Historian System Guide PDF

Uploaded by

Copyright:

Available Formats



1999 General Electric Company, USA.

ARCNET is a registered trademark of Datapoint Corporation.

Safety Symbol Legend

Indicates a procedure or condition that, if not

Indicates a procedure or condition that, if not

Indicates a procedure or condition that should be

Note Indicates an essential or important procedure, condition, or statement.

This equipment contains a potential hazard of

The example and setup screens in this manual do

Chapter 2 Quick Start

Introduction................................................................................................................... ......... 2-1

Chapter 3 Users Guide

GEH-6422 Turbine Historian System Guide

Chapter 4 Maintenance Guide

GEH-6422 Turbine Historian System Guide

Chapter 5 Installation Guide

Chapter 6 Application Notes

GEH-6422 Turbine Historian System Guide

GEH-6422 Turbine Historian System Guide

Chapter 1 Overview 1-1

Supported Communication Networks

Control System Freeway (CSF) Arcnet-based network

Stagelink (Arcnet-based network)

Stagelink (Arcnet-based network)

Unit Data Highway (UDH) Ethernet-based network

Additional Historian data acquisition is performed through Modbus and/or Ethernet

Unit Data Highway (Ethernet)

Control System Freeway (CSF)

1-2 Chapter 1 Overview

GEH-6422 Turbine Historian System Guide

Alarm & Event Report

Excel for Reports

Historian Functions & Data Flow

GEH-6422 Turbine Historian System Guide

Chapter 1 Overview 1-3

Alarm and Event Report

1-4 Chapter 1 Overview

GEH-6422 Turbine Historian System Guide

Process Data (Trends)

Typical Multi-Pen Process Trend Display

GEH-6422 Turbine Historian System Guide

Chapter 1 Overview 1-5

1-6 Chapter 1 Overview

Indicates that the word is being defined.

Indicates the actual command or option that is chosen from a

Indicates a word used as a word, or a letter used as a letter. For

Indicates a directory, filename, or block name. Lower case

Represents examples of screen text, or words and characters that

Indicates a procedure with only one step.

Indicates a list of related information, not procedural steps.

GEH-6422 Turbine Historian System Guide

SPEEDTRONIC Mark V Turbine Control Maintenance Manual GEH-5980

GEH-6422 Turbine Historian System Guide

Chapter 1 Overview 1-7

1-8 Chapter 1 Overview

GEH-6422 Turbine Historian System Guide

Chapter 2 Quick Start

Boot up the PC Historian. The Begin Logon window displays.

Press the three keys, Ctrl+Alt+Delete, all at once. The GE License

GEH-6422 Turbine Historian System Guide

Chapter 2 Quick Start 2-1

2-2 Chapter 2 Quick Start