PI Environmental Systems E-DAS Interface Manual
Environmental Systems E-DAS Interface to the PI System
Version 1.1.0.105
Rev I
How to Contact Us
| |
|OSIsoft, Inc. |Worldwide Offices |
|777 Davis St., Suite 250 |OSIsoft Australia |
|San Leandro, CA 94577 USA |Perth, Australia |
| |Auckland, New Zealand |
|Telephone |OSI Software GmbH |
|(01) 510-297-5800 (main phone) |Altenstadt, Germany |
|(01) 510-357-8136 (fax) |OSI Software Asia Pte Ltd. |
|(01) 510-297-5828 (support phone) |Singapore |
| |OSIsoft Canada ULC |
|techsupport@ |Montreal, Canada |
| |OSIsoft, Inc. Representative Office |
|Houston, TX |Shanghai, People’s Republic of China |
|Johnson City, TN |OSIsoft Japan KK |
|Mayfield Heights, OH |Tokyo, Japan |
|Phoenix, AZ |OSIsoft Mexico S. De R.L. De C.V. |
|Savannah, GA |Mexico City, Mexico |
|Seattle, WA | |
|Yardley, PA | |
|Sales Outlets and Distributors |
|Brazil |South America/Caribbean |
|Middle East/North Africa |Southeast Asia |
|Republic of South Africa |South Korea |
|Russia/Central Asia |Taiwan |
| |
|WWW. |
|OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI ProcessBook, Sequencia, |
|Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in this book that are known to be trademarks or service marks |
|have been appropriately capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the |
|property of its owner and use herein in no way indicates an endorsement, recommendation, or warranty of such party's |
|products or any affiliation with such party of any kind. |
| |
|RESTRICTED RIGHTS LEGEND |
|Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the |
|Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 |
| |
|Unpublished -- rights reserved under the copyright laws of the United States. |
| |
|© 2002-2006 OSIsoft, Inc. PI_ESCEDAS.doc |
Table of Contents
Introduction 1
Reference Manuals 1
Supported Features 2
Diagram of Hardware Connection 4
Principles of Operation 7
Installation Checklist 11
Interface Installation 13
Naming Conventions and Requirements 13
Interface Directories 14
The PIHOME Directory Tree 14
Interface Installation Directory 14
Interface Installation Procedure 14
Installing the Interface as a Windows Service 14
Installing the Interface Service with PI Interface Configuration Utility 15
Installing the Interface Service Manually 18
Connection Tool 19
Digital States 21
PointSource 23
PI 2 Server Nodes 23
PI 3 Server Nodes 24
PI Point Configuration 25
Point Attributes 25
Tag 25
PointSource 26
PointType 26
Location1 27
Location2 27
Location3 31
Location4 31
Location5 31
InstrumentTag 31
ExDesc 33
Scan 36
Shutdown 37
Sample PIConfig Script 37
Performance Point Configuration 39
Configuring Performance Points with PI ICU 39
Configuring Performance Points Manually 40
I/O Rate Tag Configuration 43
Monitoring I/O Rates on the Interface Node 43
Configuring I/O Rate Tags with PI ICU (Windows) 43
Configuring I/O Rate Tags Manually 44
Configuring the PI Point on the PI Server 45
Configuration on the Interface Node 45
Interface Status Tag 47
Configuring Interface Status Tag with PI ICU 47
Interface Status Tag 47
Watchdog Tag 47
Configuring Interface Status Tag Manually 49
Startup Command File 51
Configuring the Interface with PI ICU 51
escedas Interface Tab 53
Command-Line Parameters 57
Sample PIEDAS.bat 62
Interface Node Clock 63
Security 65
Windows 65
OpenVMS 66
Starting / Stopping the Interface 67
Starting Interface as a Service 67
Stopping Interface Running as a Service 67
Buffering 69
Configuring Buffering with PI ICU (Windows) 69
Configuring Buffering Manually 73
Example piclient.ini File 74
E-DAS to PI Reconciliation Utility (EPR) 75
Appendix A: Error and Informational Messages 77
Message Logs 77
Messages 77
System Errors and PI Errors 78
Error Descriptions 78
Appendix B: PI ESCEDAS Terminology 79
Revision History 81
Introduction
PI ESCEDAS is the interface from OSIsoft’s PI System to Environmental Systems Corporation (ESC) E-DAS software application. The PI ESCEDAS interface is available as a Windows NT or Windows 2000 application for Intel processors, and is compatible with PI Servers version 2.0 and later. This interface supports both inputs to PI and outputs to the E-DAS server. However outputs to the E-DAS server can be prohibited by use of a switch in the startup bat file and is discussed below. If further security is needed a read-only version of the interface is available.
The PI ESCEDAS interface has the following system requirements.
• Windows NT( 4.0/Windows XP/ Windows 2000 or later for Intel( Processors.
• 64 MB RAM (Windows NT systems), or 128 MB RAM (Windows 2000 systems).
• 1-2 MB available disk space (for buffering data).
• Intel Pentium( Processor.
• PI API.
• At least one remote E-DAS Expert for UNIX or E-DAS EMR for Windows Server and the E-DAS API.
• Environmental Systems Corp. software version requirements
Polling Computer Server:
SCO Version 5.0 or later
Windows NT 4.0 or later
Windows 2000
One of the two following ESC platforms:
• E-DAS Version R01 or later
• ESC StackVision 2.2 or later. ESC StackVision 2.3 requires SP1
Interface Node:
Windows NT 4.0/Windows XP or later
Windows 2000
Reference Manuals
OSIsoft
• UniInt End User Document
• PI Data Archive Manual
• PI API Installation Instructions
Environmental Systems Corporation
• E-DAS Expert for UNIX User's Guide, or E-DAS EMR for Windows User's Guide
• E-DAS API Installation Instructions
Supported Features
|Feature |Support |
|Part Number |PI-IN-ESC-EDAS-NT |
|*Platforms |Windows NTI 4.0/W2K/XP, Windows Server 2003 |
|APS Connector |No |
|Point Builder Utility |No |
|ICU Control |Yes |
|PI Point Types |Int16, Int32, Float16, Float32, Float64, String, |
| |Digital |
|Sub-second Timestamps |Yes |
|Sub-Second Scan Classes |No |
|Automatically Incorporates PI Point Attribute Changes |Yes |
|Exception Reporting |Yes |
|*Outputs from PI |Yes |
|Inputs to PI: Scan-Based / Unsolicited / Event Tags |Scan-based |
|Supports Questionable Bit |No |
|Supports Multi-character PointSource |Yes |
|Uses PI SDK |No |
|PINet to PI 3 String Support |N/A |
|* Source of Timestamps |E-DAS |
|* History Recovery |Yes |
|*UniInt-Based |Yes |
|Failover |No |
|* Vendor Software Required on PI API / PINet Node |Yes |
|Vendor Software Required on Foreign Device |No |
|Vendor Hardware Required |No |
|Additional PI Software Included with Interface |No |
|* Device Point Types |For more information, see the section below. |
* See paragraphs below for further explanation.
Platforms
The Interface is designed to run on Windows XP, Windows 2000, and Windows NT 4.0 SP6a operating systems. Because it is dependent on vendor software, newer platforms may not yet be supported.
Please contact OSIsoft Technical Support for more information.
Outputs From PI
The user can choose to prohibit the interface from being able to output data to the E-DAS server by specifying the switch /nooutputs in the interface startup file. This is also accomplished through use of the ICU control for the interface under the UniInt Tab - Data Handling Section and checking “Suppress all outputs”. You can also obtain a read-only version of the interface.
Source of Timestamps
Data is time-stamped using the time returned with the values from the E-DAS server. A discussion of the time stamps used for each data type is given in the Principles of Operation section. Time and date are converted to UTC time (GMT) for storage in PI. The E-DAS server returns the time zone bias used in this conversion when the interface starts up or when a Server Time Difference tag is updated. It is assumed that the interface (PI Interface node) is in the same time zone as the PI server. PI data clients are responsible for converting the time-stamps to the time zone in which they are running, as appropriate.
You must use a time synchronization program such as the Network Time Protocol (NTP) between the E-DAS server node, the PI Interface node and the PI server node. PI will not accept values with timestamps more than ten minutes in the future. If needed, you can configure a special Server Time Difference tag (type 255) to record any time zone adjusted drift, in seconds, between the E-DAS node and the PI Interface node
History Recovery
The E-DAS server stores weeks, months, or years of data depending upon the data type. When the interface starts and after dropped communication has been reestablished, the interface retrieves data from the E-DAS server that has been missed. It does this by querying for any data from the E-DAS server since the last value was stored in the PI snapshot, which could be the creation time of the PI tag.
UniInt-Based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by our developers, and is integrated into many interfaces, such as the PI ESCEDAS interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.
The UniInt End User Document is a supplement to this manual.
Vendor Software Required
The E-DAS API (provided by ESC) communicates only with the E-DAS Server. You must install the E-DAS API (edasapi.dll and supporting files) and the oncrpc.dll on the same PI Interface node as the PI ESCEDAS interface before installing this interface. Contact your Environmental Systems Corp. representative to obtain the required ESC components.
Device Point Types
The following point types are supported in the current release of this interface: Real, Integer, Digital, and String (PI 3 only).
Diagram of Hardware Connection
The following figures show the architecture of the PI ESCEDAS interface. Data is passed from the Data Logger to the E-DAS server. The PI Interface node uses the E-DAS Client DLL and the PI ESCEDAS interface to pass data to the PI Server. The figures illustrate two options.
• Using E-DAS Expert for UNIX Server.
• Using an E-DAS EMR for Windows Server.
[pic]
Figure 1. Architecture: PI ESCEDAS Interface Operating with the E-DAS Expert for UNIX
[pic]
Figure 2. Architecture: PI ESCEDAS Interface Operating with the E-DAS EMR for Windows
Note: Optionally, you can install the PI ESCEDAS Interface on the same node as the
E-DAS EMR for Windows Server.
Principles of Operation
E-DAS Data Types Supported
The E-DAS data types supported by the interface are listed in the following table. The inputs are scan-based; outputs are triggered by their source tag. Each data type is discussed under “Summary of Operation” below. For a detailed description of each data type, see section “Location2”.
|Data Type |Input or Output |Value |
|Average Value |*Input/Output |1 |
|Average Flag (String) |*Input/Output |2 |
|Average Flag (Int16) |*Input/Output |3 |
|Input Line Status |Input |4 |
|Calibration Value |Input |5 |
|Calibration Flag |Input |6 |
|Percent Monitor Availability (PMA) |Input |7 |
|Bias Adjustment Factor (BAF) |Input |8 |
|Digital Output Control |*Output |9 |
|Calibration Control |*Output |10 |
|Calibration Reference Value |Input |11 |
|Server Time Difference |Input |255 |
* Outputs are not allowed in the read-only version.
Summary of Operation
PI ESCEDAS is the interface from OSIsoft’s Plant Information (PI) System to Environmental Systems Corporation (ESC) E-DAS software application. The PI ESCEDAS interface is available as a Windows NT 4.0/Windows 2000 application for Intel processors, and is compatible with both PI 2 and PI 3 Servers. Each E-DAS server must be accessed via a separate PI ESCEDAS interface instance.
Each PI ESCEDAS interface establishes its working point lists from the PI server based upon a Point Source, ID Number and Location1 value. Points are then updated based on the scan class (schedule) to which it belongs, assigned in Location4. Outputs can also be periodic (scheduled), however they are normally processed when their source tag value changes. Outputs are not allowed in the read-only version.
The interface handles retrieving E-DAS inputs differently depending upon the E-DAS data type.
When the interface starts or after dropped communication has been reestablished, the interface attempts to retrieve data from the E-DAS server that has been missed during downtime. It does this by querying for any data from the E-DAS server since the last value was stored in the PI snapshot, which could simply be the creation time of the PI tag. Once the interface is scanning based on scan class schedules, it retrieves the most recent, memory resident, data from the E-DAS server. Therefore, your E-DAS tag Interval and the interface scan class must be the same. All values are time-stamped using the time returned with the value from the E-DAS server and adjusted to the GMT time zone. When outputting values from PI to the E-DAS server the time zone reported by the E-DAS server is added to the timestamp. When attempting to write a value to the E-DAS server whose source tag has an error the value will not be written, however the source tag error will be copied to the output tag as a record of the attempt. Writing to the E-DAS servers is not supported in the read-only version.
Average Flag String types convert the flags reported by the E-DAS server to one or more characters forming a string according to the rules described in the Location4. When output the string is converted back into the form required by the E-DAS server.
Calibration Flag Strings are a single character representing the Calibration Value’s status. See the Location4 section for details.
Note: If you are using a mix of these tags that have the same identifiers (i.e. ID1, ID2, Interval or Phase), if possible, you should assign them the same scan class. The interface will cache the result of duplicate requests to the E-DAS server that belong to the same scan class. This is done in order to reduce network traffic and E-DAS server query loading. Average types, Calibration types and PMA or BAF can be optimized in this fashion.
Input Line Status (ILS)
When the interface starts and after dropped communication has been reestablished, the interface reads only the current Line Status value. Once the interface is scanning based on scan class schedules, it queries for any data from the E-DAS server since the last value that it read. All values are time-stamped using the time returned from the E-DAS server and adjusted to the GMT time zone. Note that this is the opposite behavior of the Average Values.
Server Time Difference
The time delta between the E-DAS server and the PI server can be monitored with one of these tags. Whenever updated both servers’ times are read and the difference in seconds is stored as the value. If the E-DAS server is earlier the value will be negative. PI will not accept writing values more than ten minutes into the future. As an example, you can use compression on the tag to ignore values until some transition point, like nine minutes. The new stored value could then generate an alarm that the system is on the verge of missing data transfers into PI.
Digital Output Control and Calibration Control
These tags types are outputs only. When the tag’s source tag changes the source tag value is written to the E-DAS server. If the operation is successful the value is copied to the output tag. If the operation is unsuccessful the digital state “Failed” is written to the output tag. Control types are not supported in the read-only version.
Lost Connections to the E-DAS Server
If access to the E-DAS server fails at any time during operation “Can't connect to E-DAS server:servername” will be written to the log (PIHOME\dat\PIPC.log). The interface will continue to attempt server access for all tags in the current scan class. If the connection cannot be reestablished during processing of the current scan class, subsequent reconnect attempts will only be tried on a per scan class basis; that is when the scan class is scheduled. The interface will not attempt to update tags again until communications is reestablished. “E-DAS Server RECONNECTED” will be written to the log when the reconnect is successful.
Note: I/O Timeout is not written to the interface input tags since history can be retrieved. Therefore it is highly recommended that the PI Interface Status Check Utility be used so that you can be notified when either data is not being collected from the E-DAS server or data is being collected but it is not being brought into PI. The PI Interface Status Check Utility is a free utility that is available from the OSIsoft support web site.
Outputs
Outputs can be either periodic or based on changes to the source tag. Set Location3 to 1 for normal outputs or 3 for periodic outputs. Periodic outputs also require a scan class number in Location4. Outputs are not supported in the read-only version.
Installation Checklist
For those users who are familiar with running PI data collection interface programs, this checklist helps you get the PI ESCEDAS interface running. If you are not familiar with PI interfaces, you should return to this section after reading the rest of the manual in detail.
1. Verify the E-DAS API software has been installed on the Interface node. The interface requires the E-DAS API files; edasapi.dll and oncrpc.dll to be loaded for proper operation.
2. Install the PI Interface Configuration Utility, which installs PI SDK and PI API.
3. Verify that PI API has been installed on the PI API node.
4. Install the PI ESCEDAS interface.
5. Use the connector.exe utility to verify connection to the E-DAS server.
6. Configure the interface using the PI Interface Configuration Utility or edit the PIEDAS.bat and define scan classes, edasServer, etc. required as command line parameters for the interface. Whenever possible use the PI-Interface Confguration Utility.
7. Define the digital states that will be used by the digital tags.
8. Choose a point source. If the home node is a PI 2 system, you must define the point source in the point source table before defining individual points.
9. Configure the PI points.
Location1 specifies the interface ID number.
Location2 specifies the E-DAS data type.
Location3 specifies input, triggered output or periodic output.
Location4 specifies the scan class.
Location5 indicates whether or not average value will be over written with invalid states from state table.
PointType Real, Integer, Digital, or String (PI 3 only).
Source Tag Used for outputs.
ExDesc Specifies Primary ID, Secondary ID, Interval and phase
InstrumentTag Specifies invalidity codes and priorities for Average Value tags only and only if Location5=1.
10. Configure performance points.
11. Configure an I/O Rate tag.
12. Configure the interface using the PI ICU utility or edit startup command file manual. It is recommended to use PI ICU whenever possible.
13. Set interface node clock.
14. Set up security.
15. Start the interface without buffering.
16. Verify data.
17. Stop the interface, start buffering, start interface.
Interface Installation
OSIsoft recommends that interfaces be installed on PI Interface Nodes instead of directly on the PI Server node. A PI Interface Node is any node other than the PI Server node where the PI Application Programming Interface (PI API) has been installed (see the PI API manual). With this approach, the PI Server need not compete with interfaces for the machine’s resources. The primary function of the PI Server is to archive data and to service clients that request data.
The Read/Write version of the interface is installed in the interface directory \ESCEDAS and the Read-Only version is installed in the interface directory \ESCEDAS_Read-Only.
After the interface has been installed and tested, Bufserv should be enabled on the PI Interface Node (once again, see the PI API manual). Bufserv is distributed with the PI API. It is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when communication to the PI Server is lost. Communication will be lost when there are network problems or when the PI Server is shut down for maintenance, upgrades, backups, or unexpected failures.
In most cases, interfaces on PI API nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.
The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and interfaces as manual services that are launched by site-specific command files when the PI Server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI Server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI Server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI Server node. See the UniInt End User Document for special procedural information.
If you are using the E-DAS EMR for Windows, you can install the PI ESCEDAS interface on the same node as the E-DAS Server. However, it is recommended that you install the interface on a separate node from the E-DAS Server.
Naming Conventions and Requirements
The name of the interface executable is PIEDAS.exe and that the startup command file is called PIEDAS.bat.
You should rename the executable and the startup command file when multiple copies of the interface are run. For example, one would typically use PIEDAS1.exe and PIEDAS1.bat for interface number 1, PIEDAS2.exe and PIEDAS2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in the file that has the same root name.
Interface Directories
The PIHOME Directory Tree
The PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the %windir% directory. A typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=c:\pipc
The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
The Read/Write version of the interface will be installed in
PIHOME\Interfaces\ESCEDAS\.
The Read-Only version of the interface will be installed in
PIHOME\Interfaces\ESCEDAS_Read-Only\.
Replace PIHOME with the corresponding entry in the pipc.ini file.
Place all copies of the interface into the same directory.
Interface Installation Procedure
The PI ESCEDAS interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000. When running on Windows NT 4.0 systems, the PI ESCEDAS setup program will install the Windows Installer itself if necessary. To install, run the ESCEDAS_x.x.x.x.exe installation kit.
Installing the Interface as a Windows Service
The PI ESCEDAS interface service can be created, preferably, with the PI Interface Configuration Utility, or can be created manually.
Installing the Interface Service with PI Interface Configuration Utility
The PI Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service. For instance:
[pic]
Service Configuration
Service Name
The Service to Add box shows the name of the current interface service. This service name is obtained from the interface executable.
ID
This is the service id used to distinguish multiple instances of the same interface using the same executable.
Display Name
The Display Name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of the OSI suite of products.
Log on as
The Log on as text box shows the current “Log on as” Windows User Account of the interface service. If the service is configured to use the Local System account, the Log on as text box will show “LocalSystem.” Users may specify a different Windows User account for the service to use.
Password
If a Windows User account is entered in the Log on as text box, then a password must be provided in the Password text box, unless the account requires no password.
Confirm Password
If a password is entered in the Password text box, then it must be confirmed in the Confirm Password text box.
Service Type
The Service Type indicates whether the interface service will start automatically or need to be started manually on reboot.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, interface services are set to start automatically.
Dependencies
The Installed services list is a list of the services currently installed on this machine. Services upon which this Interface is dependant should be moved into the Dependencies list using the [pic] button. For example, if API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left. For this interface it is recommended that the PI API Buffering not be added. To remove a service from the list of dependencies, use the [pic] button, and the service name will be removed from the “Dependencies” list.
When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, the PI interface service will not run.
Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.
[pic] - Add Button
To add a dependency from the list of Installed services, select the dependency name, and click the Add button.
[pic] - Remove Button
To remove a selected dependency, highlight the service name in the Dependencies list, and click the Remove button.
The full name of the service selected in the Installed services list is displayed below the Installed services list box.
Create
The Create button adds the displayed service with the specified Dependencies and with the specified Startup Type.
Remove
The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out.
Start or Stop Service
To Start or Stop an interface service, use the Start button [pic] and a Stop button [pic] on the ICU toolbar. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.
The status of the Interface service is indicated in the lower portion of the PI ICU dialog.
[pic]
Installing the Interface Service Manually
One can get help for installing the interface as a service at any time with the command:
PIEDAS.exe –help
Read-Only:
PIESCEDAS_Read-Only -help
Change to the directory where the PIEDAS.exe or PIESCEDAS_Read-Only executable is located. Then, consult the following table to determine the appropriate service installation command.
|Windows Service Installation Commands on a PI Interface Node or a PI Server Node |
|with Bufserv implemented |
|Manual service |PIEDAS.exe –install –depend “tcpip bufserv” |
|Manual service |PIEDAS.exe –install –depend tcpip |
|Read-Only: |PIESCEDAS_Read-Only.exe –install –depend “tcpip bufserv” |
|Automatic service |PIEDAS.exe –install –auto –depend “tcpip bufserv” |
|Read-Only: |PIESCEDAS_Read-Only.exe –install –auto –depend “tcpip bufserv” |
|*Automatic service with service|PIEDAS.exe –serviceid X –install –auto –depend “tcpip bufserv” |
|id |PIESCEDAS_Read-Only.exe –serviceid X –install –auto –depend “tcpip bufserv” |
|Read-Only: | |
|Windows Service Installation Commands on a PI Interface Node or a PI Server Node |
|without Bufserv Implemented |
|Manual service |PIEDAS.exe –install –depend tcpip |
|Read-Only: |PIESCEDAS_Read-Only.exe –install –depend tcpip |
|Automatic service |PIEDAS.exe –install –auto –depend tcpip |
|Read-Only: |PIESCEDAS_Read-Only.exe –install –auto –depend tcpip |
|*Automatic service with service|PIEDAS.exe –serviceid X –install –auto –depend tcpip |
|id | |
|Read-Only |PIESCEDAS_Read-Only.exe –serviceid X –install –auto –depend tcpip |
*When specifying service id, the user must include an id number. It is suggested that this number correspond to the interface id (/id) or (/if) parameter found in the interface .bat file.
When the interface is installed as a service on the PI Server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will repeatedly attempt to connect to the PI Server until it is successful.
Note: Interfaces are not typically installed as automatic services when the interface is installed on the PI Server node.
Check the Microsoft Windows services control panel to verify that the service was added successfully. One can use the services control panel at any time to change the interface from an automatic service to a manual service or vice versa.
Connection Tool
The interface installs a connection tool called connector.exe. This tool is used to verify the connection to the E-DAS server. The tool can be either run from the command line or double-clicked. Enter the E-DAS server name and the tool will verify the connection and return either successful or failure.
Digital States
PI 2 Home Node
Digital states are defined by running the Digtl Stat display from the PI menu. The states must be contiguous for each status type and may be anywhere within the Digital State Table outside of the range 193 - 320, which is reserved for OSIsoft. The digital states need to be defined prior to point configuration. The digital state sets described in the PI 3 sections below should be entered into the PI 2 Digital State Table.
PI 3 Home Node
Digital State Sets
PI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI digital tags and editing digital state sets, see the PI Universal Data Server manual. Digital state tables can be edited or modified using the PI Point Builder application or piconfig.exe. The sample file EDASStateTables.txt is installed to assist in creation of the digital states.
An interface point that contains discrete data can be stored in PI as a digital tag. A Digital tag associates discrete data with a digital state set, as specified by the user. The following digital state sets should be defined for a PI 3 server:
Digital Output Control States
|Digital State Set Name |Digital States |Offset |
|Control_States |Deactivate |0 |
| |Activate |1 |
Digital Input States
|Digital State Set Name |Digital States |Offset |
|Off_On |Off |0 |
| |On |1 |
Calibration Control States
|Digital State Set Name |Digital States |Offset |
|Calibration |Start Calibration |0 |
| |Stop Calibration |1 |
These digital states must be entered into the System Digital State Table for a PI 2 server since PI 2 does not support digital state sets.
System Digital State Set
Similar to digital state sets is the system digital state set. This set is used for all tags, regardless of type to indicate the state of a tag at a particular time. The system digital state set has many unused states that can be used by the interface and other PI clients.
The following states need to be defined in the system state table. These can be defined in any unused contiguous area except in the range of 193 to 301. Each state must be in the order shown below but the text of the state can be anything desired.
The starting digital state code for Average Data Value states is passed in the interface startup file by the switch /avr_ds=X where X is the digital start code. If this switch is not passed the default starting state will be 500. A message will be printed in the pipc.log indicating the start code used.
Average Data Value States
|Offset |String |
|0 |Offline |
|1 |Calibration |
|2 |Maintenance |
|3 |Bad |
|4 |Maximum Exceeded |
|5 |Minimum Exceeded |
|6 |Out-Of-Control |
|7 |Missing |
|8 |Invalid |
|9 |Exceedance |
|10 |Shutdown |
|11 |Startup |
|12 |Suspect |
|13 |Floor Limit Exceeded |
|14 |Reserved for future use |
|15 |Reserved for future use |
PointSource
The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For example, the string Boiler1 may be used to identify points that belong to the MyInt Interface. To implement this, the PointSource attribute would be set to Boiler1 for every PI Point that is configured for the MyInt Interface. Then, if /ps=Boiler1 is used on the startup command-line of the MyInt Interface, the Interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of Boiler1. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps parameter.
PI 2 Server Nodes
The following point source characters are reserved on PI 2 systems and cannot be used as the point source character for an interface: C, ?, @, Q, T. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.
Before a PI point with a given point source can be created, the point source character must be added to the PI 2 point source table. For example, if point source E is not defined in the PI 2 point source table, a point with a point source of E cannot be created. This prevents the user from accidentally creating a point with an incorrect point source character.
Defining a Point Source Character in the PI 2 Point Source Table
1. Enter PI by typing the following command from a VMS command prompt:
@pisysexe:pi
2. Select the PointSrc option from the menu.
3. Select New from the menu.
4. Assign a point source next to the Code: field. Also, assign minimum and maximum values for the Location1 to Location5 attributes.
| |Location1 |Location2 |Location3 |Location4 |Location5 (not |
| |(Interface ID) |(E-DAS Data Type) |(Input or Output) |(Scan Class) |used) |
|Minimum |1 |0 |0 |1 |0 |
|Maximum |99 |255 |1 |256 |1 |
5. Select “Save” from the menu.
PI 3 Server Nodes
No point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character. Several subsystems and applications that ship with PI 3 are associated with default point source characters. The Totalizer Subsystem uses the point source character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Either do not use these point source characters or change the default point source characters for these applications. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.
PI Point Configuration
The PI point is the basic building block for controlling data flow to and from the PI Data Archive. A single point is configured for each measurement value that needs to be archived. Use the point attributes below to define what data to transfer.
PI points can be added or edited using one of these three methods:
• piconfig.exe – command line utility able to import or export point definitions
• PI Point Builder – Windows application used for adding or modifying small numbers of points
• PI-SMT – Microsoft Excel add used for creating or modifying large numbers of tags
Note: For example PI point configurations see the PIHOME\Interfaces\ESCEDAS\EDASSample.txt file.
Point Attributes
Use the point attributes below to define the PI Point configuration for the Interface, including specifically what data to transfer.
Tag
A tag is a label or name for a point. Any tag name can be used in accordance with the normal PI point naming conventions.
Length
The length of the Tag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |255 |
|Below 1.6 |3.4.370.x or higher |255 |
|Below 1.6 |Below 3.4.370.x |255 |
PointSource
The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line argument and the “Point Source” section.
PointType
Typically, device point types do not need to correspond to PI point types. For example, integer values from a device can be sent to floating point or digital PI tags. Similarly, a floating-point value from the device can be sent to integer or digital PI tags, although the values will be truncated. The PI point must match the parameter type in the foreign device.
PI 2 Server Nodes
Scaled real, full-precision real, integer, and digital point types are supported on PI 2 Servers. For more information on the individual point types, refer to the Data Archive (DA) section of PI System Manual I. The following table lists the PI point types supported for PI 2 Servers as they map to the E-DAS server data types.
|E-DAS Data Type |PI 2 Point Attribute |Description |
|Average Value |Real |Floating point number |
|Average Flag |Int16 |15-bit Bit Field |
|Input Line Status (ILS) |Digital |On/Off |
|Calibration Value |Real |Floating point number |
|Calibration Flag |Int16 |8-bit Bit Field |
|Percent Monitor Availability (PMA) |Real |Floating point number |
|Bias Adjustment Factor (BAF) |Real |Floating point number |
|Digital Output Control |Digital |Activate/Deactivate |
|Calibration Control |Digital |Start Cal / Abort Cal |
|Calibration Reference Value |Real |Floating point number |
|Server Time Difference |Int16 or Real |E-DAS/PI server difference |
PI 3 Server Nodes
Float16, float32, int16, int32, digital, string, and blob point types are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for Windows and UNIX.
The following table lists the PI point types supported for PI 3 Servers as they map to the E-DAS data types.
|E-DAS Data Type |PI 3 Point Data Type |Description |
|Average Value |Float32 |Floating point number |
|Average Flag (String) |String |String |
|Average Flag (Int16) |Int16 |15-bit Bit Field |
|Input Line Status (ILS) |Digital |On/Off |
|Calibration Value |Float32 |Floating point number |
|Calibration Flag |String |String |
|Percent Monitor Availability (PMA) |Float32 |Floating point number |
|Bias Adjustment Factor (BAF) |Float32 |Floating point number |
|Digital Output Control |Digital |Activate/Deactivate |
|Calibration Control |Digital |Start/Abort |
|Calibration Reference Value |Float32 |Floating point number |
|Server Time Difference |Int32 or Float32 |32 bit value |
Location1
Location1 is the ID number of the interface handling this point. The ID number of each instance of the interface is determined by the /id command line parameter at interface startup. The default ID is 0.
Location2
Use Location2 to specify the E-DAS data type, using the appropriate value listed in the following table. Detailed descriptions are given in the pages that follow.
See the “Operational Overview” section for further descriptions of the point types.
|Data Type |Value |Input or Output |
|Average Value |1 |*Input/Output |
|Average Flag (String) |2 |*Input/Output |
|Average Flag (Int16) |3 |*Input/Output |
|Input Line Status |4 |Input |
|Calibration Value |5 |Input |
|Calibration Flag |6 |Input |
|Percent Monitor Availability (PMA) |7 |Input |
|Bias Adjustment Factor (BAF) |8 |Input |
|Digital Output Control |9 |Input |
|Calibration Control |10 |*Output |
|Calibration Reference Value |11 |*Output |
|Server Time Difference |255 |Input |
* Outputs are not supported in the read-only version.
Average Value (Type 1)
You can use an Average Value tag to read or write data values for a particular E-DAS site, parameter, and averaging interval. The interface does not actually compute the averages for an Average Value tag. It either reads or writes the data as discrete PI tag values with the appropriate timestamp for each interval.
The timestamps recorded with E-DAS average data refer to the beginning of the averaging period. For example, the 03:00 time-stamped value for an hourly input tag refers to data collected for the hour beginning at 03:00, and thus is not collected from E-DAS until at least 04:00. Similarly, an hourly output tag for the data interval beginning at 03:00 is not sent to E-DAS until at least 04:00, and it is time-stamped with 03:00.
Average Flag (Types 2,3)
Average Flag tags are associated with Average Value (Type 1) tags. They are used to hold the data quality information for a particular E-DAS site, parameter, and averaging interval, and are marked with a timestamp for that interval. The average flag data can be represented in one of two tag types:
• Average Flag String - A string of one or more flags (Data Type 2, used with PI 3 only). Flags are defined in the table below.
• Average Flag Bit Field - A 15-bit bit field of one or more flags (Data Type 3). Bit positions are defined in the table below. These tag values are displayed as decimal integers by default. Programmatic bit mask processing on the PI display is required to represent individual flags.
|Average Data Flag Description |Character (PI 3) |Bit Field Position (PI 2 or PI 3) |
|E-DAS Offline |F |1 |
|E-DAS Calibration |C |2 |
|E-DAS Maintenance |N |3 |
|E-DAS Bad |B |4 |
|E-DAS Maximum Exceeded |+ |5 |
|E-DAS Minimum Exceeded |- |6 |
|E-DAS Out-of-Control |O |7 |
|E-DAS Missing |M |8 |
|E-DAS Invalid |I |9 |
|E-DAS Exceedance |E |10 |
|E-DAS Shutdown |H |11 |
|E-DAS Startup |T |12 |
|E-DAS Suspect |S |13 |
|E-DAS Floor Limit Exceeded |f |14 |
|Reserved |R |15 |
|Reserved |r |16 |
For example, to represent the E-DAS Exceedance flag, the string value will contain an "E" for PI 3 or the binary value 000 0010 0000 0000 for PI 2.
To represent the both the E-DAS Exceedance flag as well as the Suspect flag being set, the string value will contain an “ES” for PI 3 or the binary value 001 0010 0000 0000 for PI 2.
Input Line Status (Type 4)
You can store Input Line Status event data from a particular ESC data logger input line in a digital tag. Define the following digital states for this tag:
|Input Line Status |Input Line Status Digital |
| |State |
|Off |0 |
|On |1 |
Calibration Value Data (Type 5)
Use Calibration Value tags to show the actual values of calibrations for a particular E-DAS site, parameter, and calibration phase. Note that you can store calibration reference values in Calibration Reference tags (Type 11) described below.
Calibration Flag Data (Type 6)
You store Calibration Flag (PI 3 only) data in a string of one or more single-character flags. The following table describes how the flags are indicated within the tag.
|E-DAS Calibration Flag |Calibration Flag String |
|Description |(Character within String) |
|Low Point |L |
|Mid Point |M |
|High Point |H |
|Offline |F |
|Maintenance |N |
|Aborted |A |
|Drift Limit |D |
|Out-of-Control |O |
Percent Monitor Availability (Type 7) and Bias Adjustment Factor (Type 8)
Use an E-DAS Type 7 tag to read hourly Percent Monitor Availability (PMA) values for a particular E-DAS site and parameter. Use an E-DAS Type 8 tag to read hourly Bias Adjustment Factor (BAF) values for a particular E-DAS site and parameter. The timestamps recorded with PMA and BAF data refer to the beginning of the hour. For example, the 03:00 PMA tag value refers to the percent monitor availability for the hour beginning at 03:00.
PMA and BAF data is computed on the E-DAS Server as part of a data quality assurance (QA) procedure, which is typically performed manually by the user or scheduled to occur on a daily or quarterly basis. PMA and BAF data is not available on the E-DAS Server until this process is completed. It is recommended that you set up PMA and BAF tags to retrieve their values from E-DAS after the data QA process is complete, either manually or on a regular basis. To set this up, you must configure them as trigger-based inputs or define a suitable scan rate in the Location4 field. For more information, see sections "Location3" and "Location4".
Digital Output (Type 9)
Use a Digital Output Control tag for a PI output that activates or deactivates a particular data logger channel. The Digital Output Control tag is stored in a Digital tag. You must define the following digital states set for this tag:
|Digital Output |Digital Output State |
|Deactivate |0 |
|Activate |1 |
Calibration Control (Type 10)
Use a Calibration Control tag for a PI output that starts or aborts a particular calibration procedure on a data logger. The Calibration Control tag is stored in a Digital tag. You must define the following digital state set for this tag:
|Calibration Control Option |Calibration Control Digital State |
|Start Cal |0 |
|Abort Cal |1 |
Calibration Reference Data (Type 11)
Use a Calibration Reference tag to show the reference values of calibrations for a particular E-DAS site, parameter, and calibration phase. The Calibration Reference data is stored in a float.
Server Time Difference (Type 255)
The Server Time Difference data type is used to record the difference, in seconds, between the E-DAS server time and the PI server time. The formula used is: value = (PI server time + time-zone bias + daylight savings time bias) – (E-DAS server time + TimeZoneBias). Create a tag of this type and add it to a scan class with the frequency that you want to sample the servers. PI-Alarms can be used to notify an operator, engineer, etc. The Server Time Difference data is stored in an int32 or a float32.
Location3
Use the Location3 attribute to indicate whether the tag is a PI input or PI output. See the table in section ”Location2” for a list of the E-DAS data types and which ones are used for inputs and outputs. Set Location3 as follows:
• Use 0 for inputs
• Use 1 for outputs (event or trigger based)
• Use 3 for outputs (periodic)
Periodic outputs require a non-zero value for the associated scan class. Outputs are not supported in the read-only version.
Location4
Scan-Based Inputs and Outputs
The PI ESCEDAS interface supports scan-based collection of data and can also be used to specify the scan class for outputs to be executed on a periodic basis. Location4 defines the scan class for the PI point. The scan class determines the frequency at which input points are scanned for new values. For more information, see the description of the /f parameter in the section “Startup Command File” (page 51). For periodic outputs Location3 must be set to a 3. Outputs are not supported in the read-only version.
Trigger-Based Inputs and Event Output Points
Set Location4 to zero for these points. For trigger-based inputs, you must also configure a separate trigger point for inputs. Configure a SourceTag for outputs. See the section "Trigger-Based " under the ExDesc attribute for information about associating an input point with a trigger point and configuring event types for inputs and outputs. Outputs are not supported in the read-only version.
Location5
Location 5 is used to indicate whether average value flags will be used to over write the average value itself. Once the tag is set to a digital state that represents the invalidity condition the value is lost. You can use the flag types (2 and 3) to store invalidity conditions.
0 – do not over write tag’s value with invalidity state even if an invalid state exists
1 – overwrite value if invalid average flag condition exists
InstrumentTag
Length
The length of the InstrumentTag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |32 |
|Below 1.6 |3.4.370.x or higher |32 |
|Below 1.6 |Below 3.4.370.x |32 |
The InstrumentTag attribute is optional and only applies only to Average Values (data type 1).
Use the InstrumentTag to specify which invalidity flags and their priority that will be recorded in the PI tag. For example, to record only flags having the Exceedance or Out-of-Control condition, set the InstrumentTag to the following: Invalid=EO.
The following table describes how each flag is indicated within the InstrumentTag. It also shows the default order of importance of the flags in the bit field representation that determines by default which flag is displayed when the value is invalid. Offline takes precedence, followed by Calibration, etc.
|Table Offset |Average Data Flag Description |InstrumentTag Character |Source |
|0 |Offline |F |Logger |
|1 |Calibration |C |Logger |
|2 |Maintenance |N |Central |
|3 |Bad |B |Logger |
|4 |Maximum Exceeded |+ |Logger |
|5 |Minimum Exceeded |- |Logger |
|6 |Out-of-Control |O |Central |
|7 |Missing |M |Central |
|8 |Invalid |I |Central |
|9 |Exceedance |E |Central |
|10 |Shutdown |H |Central |
|11 |Startup |T |Central |
|12 |Suspect |S |Central |
|13 |Floor Limit Exceeded |f |Logger |
|14 |Reserved |R |n/a |
|15 |Reserved |r |n/a |
Average Value data (Type 1 tags) are invalid in PI when one of the following conditions is true:
• The value is –999.0 or -888.0. The flag specified to have the highest priority is written to the tag. The highest priority flag is the left most flag from the following list that is set: “FCNB+-OMIEHTSfRr”
• The Invalid flag list is not specified in the InstrumentTag field, but the E-DAS Invalid flag is active. The highest priority flag is the left most flag from the following list that is set: “FCNB+-OMIEHTSfRr”
• One or more of the Invalid flags specified in the InstrumentTag field is currently active. The flag specified to have the highest priority is written to the tag. The highest priority flag is the left most flag from the list that is specified in the InstrumentTag.
For example, to check for “Shutdown” first and then “Offline” set the Instrument tag to: Invalid=”HF”.
To check only for “Invalid” set the InstrumentTag to: Invalid=”I”.
To check for any of the possible conditions in the following priority “FCNB+-OMIEHTSfRr”, omit the Invalid= entry for the given tag.
ExDesc
Length
The length of the Extended Descriptor field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |80 |
|Below 1.6 |3.4.370.x or higher |80 |
|Below 1.6 |Below 3.4.370.x |80 |
Use the ExDesc attribute to specify the source (key information) and attributes of the E-DAS data. This attribute is limited to 80 characters. In the PI ESCEDAS Interface, you use the ExDesc attribute to configure a number of key fields, described below.
• ID1 — Primary ID (maximum length of 8 characters). Depending on the data type, ID1 represents one of the following:
An E-DAS site emission source, e.g., Unit1 or Unit2
An ESC data logger name
• ID2 — Secondary ID, (maximum length of 8 characters). Depending on the data type, ID2 represents one of the following secondary IDs:
An E-DAS parameter for values that are recorded, e.g., 'LOAD' 'SO2 PPM' 'FLOW'.
Line # of an ESC data logger
Channel number within an ESC data logger.
Calibration sequence name within an ESC data logger
• Interval — E-DAS averaging interval for data, (maximum length of 4 characters). Format is xxxU where xxx is the magnitude and U represents the units (m, h or d). For example, a value of 006m represents a six-minute average. The smallest average interval supported by this interface is one minute ('001m').
• Phase —E-DAS calibration phase number, (maximum length of 2 characters). Range is 00-99.
The arguments are specified by the attribute equated to a value. Multiple attributes should be separated by a space. For example:
ID1=UNIT1 ID2=NOXPPM interval=006m phase=60
The following table shows which ExDesc fields are required by each D-DAS data type.
|Data Type |Value |Required ExDesc Fields |Example |
|Average Value |1 |ID1={site} |ID1=UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Interval={xxxU} |Interval=001h |
|Average Flag (String) |2 |ID1={site} |ID1= UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Interval={xxxU} |Interval=001h |
|Average Flag (Int16) |3 |ID1={site} |ID1=UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Interval={xxxU} |Interval=001h |
|Input Line Status |4 |ID1={data logger name} |ID1=LOG1 |
| | |ID2={digital input line} |ID2=03 |
|Calibration Value |5 |ID1={site} |ID1=UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Phase={phase point} |PHASE=00 |
|Calibration Flag |6 |ID1={site} |ID1=UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Phase={phase point} |PHASE=00 |
|Percent Monitor Availability |7 |ID1={site} |ID1=STACKA |
| | |ID2={parameter} |ID2=FLOW |
|Bias Adjustment Factor |8 |ID1={site} |ID1=STACKA |
| | |ID2={parameter} |ID2=FLOW |
|Digital Output Control |9 |ID1={data logger name} |ID1=LOG1 |
| | |ID2={digital output line} |ID2=31 |
|Calibration Control |10 |ID1={data logger name} |ID1=LOG2 |
| | |ID2={calibration sequence} |ID2=DAYCAL |
|Calibration Reference Value |11 |ID1={site} |ID1=UNIT1 |
| | |ID2={parameter} |ID2=NOXPPM |
| | |Phase={phase point} |PHASE=00 |
Performance Points
You can include PERFORMANCE_POINT in the extended descriptor to treat the point as a performance point. See the section “Performance Point Configuration” for additional information.
Trigger-Based Tags
For trigger-based input points, a separate trigger point must be configured. An input point is associated with a trigger point by entering a case-insensitive string in the extended descriptor (ExDesc) PI point attribute of the input point of the form:
keyword=trigger_tag_name
where keyword is replaced by “event” or “trig” and trigger_tag_name is replaced by the name of the trigger point. The interface automatically assumes that an input point is trigger-based instead of scan-based when the keyword=trigger_tag_name string is found in the extended descriptor attribute.
An input is triggered when a new value is sent to the Snapshot of the trigger point. The new value does not need to be different from the previous Snapshot value to trigger an input, but the timestamp of the new value must be greater than (more recent than) or equal to the timestamp of the previous value.
You can place conditions on trigger events. Event conditions are specified in the extended descriptor as follows:
Event = ‘trigger_tag_name’ event_condition
The trigger tag name must be enclosed by single quotation marks. For example, the following line:
Event = ‘Sinuoid’ Anychange
triggers on any event to the PI Tag sinusoid as long as the next event is different from the last event. The initial event is read from the Snapshot.
Use the event condition keywords in the following table to specify trigger conditions.
|Event Condition |Description |
|Anychange |Trigger on any change as long as the value of the current event is different from the value of the |
| |previous event. System digital states also trigger Anychange events. For example, a value change |
| |from 0 to “Bad Input” or from “Bad Input” to 0 triggers an event. |
|Increment |Trigger on any increase in value. For example, a value change from 0 to 1 triggers an event. System |
| |digital states do not trigger Increment events. A value change from “Pt Created” to 0 or a value |
| |change from 0 to “Bad Input” does not trigger an event. |
|Decrement |Trigger on any decrease in value. For example, a value change from 1 to 0 triggers an event. System |
| |digital states do not trigger Decrement events. A value change from “Pt Created” to 0 or a value |
| |change from 0 to “Bad Input” does not trigger an event. |
|Nonzero |Trigger on any non-zero value. Events are not triggered when a system digital state is written to |
| |the trigger tag. For example, an event is triggered on a value change from “Pt Created” to 1, but |
| |is not triggered on a value change from 1 to “bad input.” |
Outputs are triggered when the SourceTag meets the Event Condition. For outputs you can specify any of the Event Conditions in the ExDesc field, which will be applied to the SourceTag. Omit the Event=TagName entry for outputs. The default is Anychange. Outputs are not supported in the read-only version.
Scan
By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.
There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.
Shutdown
Set each tag’s shutdown attribute to ‘0’. Shutdown should be disabled since the interface supports history recovery by default.
Sample PIConfig Script
You can use the PICONFIG file to configure and maintain PI databases. The following is an example of a PICONFIG file (EDASSample.txt) that contains definitions for several PI points with different E-DAS attributes.
Note: Other OSIsoft utilities are available for creating tags. These include the PI Point Builder or the PI-SMT add-in utility to Excel.
*PICONFIG structure file for loading PI points
@ptclas classic
@tabl pipoint
@mode create,t
@istr tag, exdesc, instrumanttag, pointtype, pointsource, location1, location2, location3, location4, Shutdown, SourceTag, DigitalSet, Shutdown, Compressing
***Inputs to PI
MyInAvg,ID1=Site1 ID2=123 Interval=001m,Invalid=HCEO,float32,E,0,1,0,1,0,,,0,0
MyInFlagStr,ID1=Site1 ID2=123 Interval=001h,,string,E,0,2,2,0,,,0,0
MyInFlags,ID1=Site1 ID2=123 Interval=001d,,int32,E,0,3,0,2,,,0,0
MyInILS,ID1=Logger1 ID2=123,Interval=001m,,digital,E,0,4,0,2,0, ,InputLineControlStates,0,0,0,0,0
MyInCalData,ID1=Site1 ID2=123 Phase=21,float32,E,0,5,0,1,0,,,0,0
MyInCalFlagStr,ID1=Site1 ID2=123 Phase=06,,string,E,0,6,0,1,0,,,0,0
MyInPMA,ID1=Site1 ID2=123 Interval=001m,float32,E,0,7,0,1,0,,,0,0
MyInBAF,ID1=Site1 ID2=123 Interval=001m,float32,E,0,8,0,1,0,,,0,0
MyInCalRefVal,ID1=Site1 ID2=123 Phase=03,float32,E,0,11,0,1,0,,,0,0
MyServerDiff,,Int32,E,0,255,0,1,0,,,0,0
*** Outputs to EDAS
MyOutAvg,ID1=Site1 ID2=123 Interval=001h,,float32,E,0,1,1,0,0,MyAvgSrc,,0,0
MyOutFlagStr,ID1=Site1 ID2=SO2STR Interval=002h,,string,E,0,2,1,0,0,MyFlagStrSrc,,0,0
MyOutFlags,ID1=Site1 ID2=SO2FLG Interval=001d,,int16,E,0,3,1,0,0,MyFlagsSrc,,0,0
MyOutDigCont,ID1=Logger1 ID2=188,,digital,E,0,9,1,0,0,MyDigCont,DigOutContStates,0,0
MyOutCal,ID1=Logger1 ID2=Seq01,,digital,E,0,10,1,0,0,MyCalCont,CalControlStates,0,0
Performance Point Configuration
One can configure performance points to monitor the amount of time in seconds that an interface takes to complete a scan for a particular scan class. The closer the scan completion time is to 0 seconds, the better the performance. The scan completion time is recorded to millisecond resolution
Configuring Performance Points with PI ICU
The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing Performance Points.
[pic]
Create
To create a Performance Point, right-click the line belonging to the tag to be created, and select Create.
Delete
To delete a Performance Point, right-click the line belonging to the tag to be deleted, and select Delete.
Correct
If the “Status” of a point is marked “Incorrect”, the point configuration can be automatically corrected by ICU by right-clicking on the line belonging to the tag to be corrected, and selecting Correct. The Performance Points are created with the following PI attribute values. If ICU detects that a Performance Point is not defined with the following, it will be marked Incorrect:
|Attribute |Details |
|Tag |Tag name that appears in the list box |
|Point Source |Point Source for tags for this interface, as specified on the first tab |
|Compressing |Off |
|Excmax |0 |
|Descriptor |Interface name + “ Scan Class # Performance Point” |
Rename
Right-click the line belonging to the tag and select “Rename” in order to rename the Performance Point.
Status
The Status column in the Performance Points table indicates whether the Performance Point exists for the scan class in column 2.
• Created – Indicates that the Performance Point does exist
• Not Created – Indicates that the Performance Point does not exist
• Deleted – Indicates that a Performance Point existed, but was just deleted by the user
Scan Class
The Scan Class column indicates which scan class the Performance Point in the Tagname column belongs to. There will be one scan class in the Scan Class column for each scan class listed in the Scan Classes combo box on the Uniint Parameters tab.
Tagname
The Tagname column holds the Performance Point tag name.
Snapshot
The Snapshot column holds the snapshot value of each Performance Point that exists in PI. The Snapshot column is updated when the Performance Points/Counters tab is clicked, and when the interface is first loaded.
Configuring Performance Points Manually
Performance point configuration is the same on all operating system platforms. Performance points are configured as follows.
1. Set the extended descriptor to:
PERFORMANCE_POINT
or to:
PERFORMANCE_POINT=interface_id
where interface_id corresponds to the identifier that is specified with the /id parameter on the startup command line of the interface. The character string PERFORMANCE_POINT is case insenstive. The interface_id does not need to be specified if there is only one copy of an interface that is associated with a particular point source.
2. Set Location4 to correspond to the scan class whose performance is to be monitored. For example, to monitor scan class 2, set Location4 to 2. See the /f parameter for a description of scan classes.
3. Set the PointSource attribute to correspond to the /ps parameter on the startup command line of the interface.
4. Set the PointType attribute to float32 (PI 3) or Real (PI 2).
I/O Rate Tag Configuration
An I/O Rate tag measures the throughput of an Interface. In particular, the value of an I/O Rate point represents a 10-minute average of the total number of values per minute that the Interface sends to the PI Server. Because values are averaged over a 10-minute interval, the first calculated value is not written to the PI Server until 10 minutes after the Interface has started. The user can configure one I/O Rate tag for each copy of the Interface that is in use.
Monitoring I/O Rates on the Interface Node
For Windows nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.
Configuring I/O Rate Tags with PI ICU (Windows)
The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing I/O Rates Tags.
[pic]
PI ICU currently allows for one I/O Rate tag to be configured for each copy of the interface that is in use. Some interfaces allow for multiple I/O Rates tags.
Enable IORates for this Interface
The Enable IORates for this interface check box enables or disables IORates for the current interface. To disable IORates for the selected interface, uncheck this box. To enable IORates for the selected interface, check this box.
Tag Status
The Tag Status column indicates whether the IORates tag exists in PI. The possible states are:
• Created – This status indicates that the tag exist in PI
• Not Created – This status indicates that the tag does not yet exist in PI
• Deleted – This status indicates that the tag has just been deleted
• Unknown – This status indicates that the ICU is not able to access the PI Server
In File
The In File column indicates whether the I/O Rates tag listed in the tag name and the event counter is in the IORates.dat file. The possible states are:
• Yes – This status indicates that the tag name and event counter are in the IORates.dat file
• No – This status indicates that the tag name and event counter are not in the IORates.dat file
Event Counter
The Event Counter correlates a tag specified in the iorates.dat file with this copy of the interface. The command line equivalent is /ec=x, where x is the same number that is assigned to a tag name in the iorates.dat file.
Tagname
The tag name listed under the Tagname column is the name of the I/O Rates tag.
Right Mouse Button Menu Options
Create
Create the suggested I/O Rates tag with the tag name indicated in the Tagname column.
Delete
Delete the I/O Rates tag listed in the Tagname column.
Rename
Allows the user to specify a new name for the I/O Rates tag listed in the Tagname column.
Add to File
Adds the tag to the IORates.dat file with the event counter listed in the Event Counter Column.
Search
Allows the user to search the PI Server for a previously defined I/O Rates tag.
Configuring I/O Rate Tags Manually
There are two configuration steps.
1. Configuring the PI Point on the PI Server
2. Configuration on the Interface Node
Configuring the PI Point on the PI Server
PI 2 Server Nodes
A listing of the I/O Rate Tags that are currently being monitored can be obtained with the command:
@PISysDat:
Create an I/O Rate Tag using one of the existing I/O Rate Tags as a template.
PI 3 Server Nodes
Create an I/O Rate Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |float32 |
|Compressing |0 |
|ExcDev |0 |
Configuration on the Interface Node
For the following examples, assume that the name of the PI tag is EDAS001, and that the name of the I/O Rate on the home node is EDAS001.
1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the %windir% directory. If both are specified, the PIPCSHARE entry takes precedence.
Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.
Add a line in the iorates.dat file of the form:
EDAS001, x
where EDAS001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x parameter in the startup command file. x can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.
2. Set the /ec=x parameter on the startup command file of the interface to match the event counter in the iorates.dat file.
The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.
Interface Status Tag
The PI Interface Status Utility provides a means of indicating to a user that data from a given interface is stale; i.e. that no fresh data is being sent from the interface to the PI Server. This can occur if one of the following scenarios occur:
• The interface is running but the PI API node cannot send data to the PI Server.
• The interface is not running and a system digital state was not written to indicate that the interface has been shut down.
One PI Interface Status tag is configured per monitored interface and each tag monitors a watchdog tag collecting data from the interface. If the watchdog tag’s value on the PI server hasn’t updated after a user-specified amount of time, the PI Interface Status tag’s status changes to a bad digital state status. PI Interface Status runs on a PI server, so it will continue to display the interface’s status even if the connection between the interface and PI home node goes down.
Configuring Interface Status Tag with PI ICU
Interface Status Tag
The Interface Status Tag is the name of the tag that belongs to the PI Interface Status Utility for each interface. If the tag name listed in this text box exists in PI, it will be displayed with black text. If it does not exist in PI, it will be displayed with gray text.
“…” (Browse)
If a PI Interface Status Utility tag has previously been defined, use the browse button “…” to search for this tag.
Suggest
The Suggest button causes a PI Interface Status Utility tag name with the default naming convention to be displayed in the Interface Status Tag field.
Create
Creates the Interface Status Tag.
Delete
Deletes the Interface Status Tag.
Watchdog Tag
The Watchdog tag is a tag that belongs to the current interface.
“…” (Browse)
Use the “…” button to search for a tag that belongs to the current interface that is to be used as the watchdog tag. The PI SDK Tag Search dialog will displayed connected to the Host PI Server. Search for the tag belonging to this interface that will act as the watch dog tag, select it, and press OK.
Choosing an Interface Watchdog Tag
PI Interface Status monitors a watchdog tag to determine the status of the monitored interface. When choosing an interface watchdog tag, several things should be taken into consideration:
• Update Rate of Watchdog Tag
The interface watchdog tag’s scan rate should reflect the scan rate of the majority of the monitored interface’s tags. For example, if the majority of the monitored interface’s tags have a scan rate of 10 seconds, the interface watchdog tag should have a scan rate of 10 seconds.
The interface watchdog tag’s scan rate should be slightly more frequent than the monitor frequency (location4) of the PI Interface Status tag. For example, if you want PI Interface Status to monitor an interface every 1 minute, its interface watchdog tag should be updating around every 30 seconds.
• Monitor Frequency of PI-Interface Status Utility Tag
The monitor frequency of the PI Interface Status tag should depend upon the scan rates of the monitored interface’s tags. A monitor frequency that’s a little less frequent that the majority of the scan rates for the monitored interface’s tags should be chosen. For example, an interface with most of its tags scanning every 30 seconds could have a monitor frequency of 1 minute. An interface with most of its tags scanning every second could have a monitor frequency of 10 seconds.
Scan Frequency
The scan frequencies listed are the scan frequencies currently defined for the PI-Interface Status Utility (PIIntStatus) service. Select the appropriate scan frequency for the tag selected. If a different scan frequency is required, the PIIntStatus configuration needs to be modified and a new Scan Class needs to be added before proceeding. Scan Classes are configured on the General Tab of PI ICU.
Write ‘bad’ Status to all Interface Tags when Data is Stale
If this option is selected, the PI-Interface Status Utility will write a ‘Bad’ status to all interface tags when data becomes stale.
Do Not Remove ‘bad’ Status when Communication Resumes
This option is only valid if the previous option has been checked. If this option is checked, then the PI-Interface Status Utility will remove the ‘Bad’ status that it has written after the data resumes.
Configuring Interface Status Tag Manually
Create an Interface Status Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |Digital |
|Compressing |1 |
|ExcDev |0 |
|Location1 |Interface copy number |
|Location2 |0: Do NOT write Bad status to interface tags |
|Location3 |0 |
|Location4 |Scan class: Check the startup file for the PI Interface |
| |Status Utility |
|Location5 |Don’t care |
|InstTag |Name of Watch Dog tag |
|ExDesc |/ps= |
|DigitalSet |Name of set (PI 3) (See below) |
|or | |
|DigStartCode |First digital state for this tag (PI 2) |
Digital States
DigitalSet defines the digital state set that specifies the status of the monitored interface. The digital state set should contain 3 digital states. The first digital state in the set should indicate a good interface status, the second digital state should indicate a bad interface status, and the third digital state should indicate that interface watchdog tag was deleted and that the PI Interface Status tag is invalid. An example is the DigitalSet InterfaceStatus containing the digital states:
• 0: Receiving Data
• 1: Not Receiving Data
• 2: Invalid
While DigitalSet is a PI 3 Point attribute only the same group or set of tags should be added to the Digital State Table for a PI 2 Home node.
Startup Command File
Use the Startup Command file to start the interface and define runtime parameters. Command-line arguments can begin with a / or with a -. For example, the /ps=M and -ps=M command-line arguments are equivalent.
For Windows, command file names have a .bat extension. The Windows continuation character (^) allows one to use multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of parameters is unlimited, and the maximum length of each parameter is 1024 characters.
Note: The UniInt End User Document includes details about other command line parameters, which may be useful.
Configuring the Interface with PI ICU
Note: PI ICU requires PI 3.3 or greater.
The PI Interface Configuration Utility provides a graphical user interface for configuring PI interfaces. If the interface is configured by the PI ICU, the batch file of the interface (PIEDAS.bat) will be maintained by the PI ICU and all configuration changes will be kept in that file and the module database. The procedure below describes the necessary steps for using PI ICU to configure the PI ESCEDAS Interface.
From the PI ICU menu, select Interface, then NewWindows Interface Instance from EXE..., and then Browse to the PIEDAS.exe executable file. Then, enter values for Point Source and Interface ID#. A window such as the following results:
[pic]
“Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name and it will be the display name in the services menu.
Click on Add.
The following display should appear:
[pic]
Note that in this example the Host PI System is localhost, which means that the interface will be configured to communicate with the local PI Server. However, to configure the interface to communicate with a remote PI Server, select ‘Interface => Connections…’ item from PI ICU menu and make it the default server. If the remote node is not present in the list of servers, it can be added.
Once the interface is added to PI ICU, near the top of the main PI ICU screen, the Interface Type should be escedas. If not, use the drop-down box to change the Interface Type to be escedas.
Click on Apply to enable the PI ICU to manage this copy of the PI ESCEDAS Interface.
[pic]
The next step is to make selections in the interface-specific tab (i.e. “escedas”) that allow the user to enter values for the startup parameters that are particular to the PI ESCEDAS Interface.
[pic]
Since the PI ESCEDAS Interface is a UniInt-based interface, in some cases the user will need to make appropriate selections in the UniInt tab. This tab allows the user to access UniInt features through the PI ICU and to make changes to the behavior of the interface.
To set up the interface as a Windows Service, use the Service tab. This tab allows configuration of the interface to run as a service as well as to starting and stopping of the interface. The interface can also be run interactively from the PI ICU. To do that go to menu, select the Interface item and then Start Interactive.
For more detailed information on how to use the above-mentioned and other PI ICU tabs and selections, please refer to the PI Interface Configuration Utility User Manual. The next section describes the selections that are available from the escedas tab. Once selections have been made on the PI ICU GUI, press the Apply button in order for PI ICU to make these changes to the interface’s startup file.
escedas Interface Tab
Since the startup file of the PI ESCEDAS Interface is maintained automatically by the PI ICU, use the escedas tab to configure the startup parameters and not make changes in the file manually. The following is the description of interface configuration parameters used in the PI ICU Control and corresponding manual parameters.
escedas
[pic]
Required Parameters
• ESC E-DAS server name
This specifies the name of the ESC E-DAS server from which data is to be collected. The command line equivalent is /edasserver=servername.
Optional Parameters
• Average value starting system digital state
This specifies the Average Value starting system digital state to use for interface specific error statuses. The command line equivalent is /avr_ds=#.
• Disable History Recovery
This parameter is used to specify whether history retrieval is ignored. The command line equivalent is /IH=#, default=0, disable=1.
ESC EDAS Debug Levels
This parameter defines values that cause further information to be reported. Using this parameter will generate a large number of messages. Each parameter determines what kind of information messages to report during operation of the interface. It is suggested that this parameter only be used for debugging in interactive mode. To trace multiple data types add the individual values together. The command line equivalent is /dbg=nnnn.
o Average Value
Checking this box will cause the interface to log all average value data exchanges with the E-DAS server to the log file. (/dbg=1)
o Average Flag String
Checking this box will cause the interface to log all average flag string data exchanges with the E-DAS server to the log file (/dbg=2)
o Average Flag Mask
Checking this box will cause the interface to log all average flag mask data exchanges with the E-DAS server to the log file (/dbg=4)
o Input Line Status
Checking this box will cause the interface to log all input line status data exchanges with the E-DAS server to the log file (/dbg=8)
o Calibration Value
Checking this box will cause the interface to log all calibration value data exchanges with the E-DAS server to the log file (/dbg=16)
o Calibration Flag String
Checking this box will cause the interface to log all calibration flag string data exchanges with the E-DAS server to the log file. (/dbg=32)
o Percent Monitor Availability
Checking this box will cause the interface to log all percent monitor availablity data exchanges with the E-DAS server to the log file (/dbg=64)
o Bias Adjustment Factor
Checking this box will cause the interface to log all bias adjustment factor data exchanges with the E-DAS server to the log file (/dbg=128)
o Digital Output Control
Checking this box will cause the interface to log all digital output control data exchanges with the E-DAS server to the log file (/dbg=256)
o Calibration Control
Checking this box will cause the interface to log all calibration control data exchanges with the E-DAS server to the log file. (/dbg=512)
o Calibration Reference Value
Checking this box will cause the interface to log all calibration reference value data exchanges with the E-DAS server to the log file (/dbg=1024)
o Server Time Delta
Checking this box will cause the interface to log all server time delta data exchanges with the E-DAS server to the log file (/dbg=2048)
Additional Parameters
The Additional Parameters section is provided for any parameters that may be required in the future and not currently support by the ICU Control.
Command-Line Parameters
|Parameter |Description |
|/avr_ds |/avr_ds=X. Specifies Average Value starting system digital state to use for interface|
|Optional |specific error statuses. The default is 500. |
|/dbg=nnnn |Note that this switch will generate a large number of messages. It is suggested that |
|Optional |you only use this parameter for debugging in interactive mode. |
| |This switch will generate a message indicating the data that is exchanged with the |
| |E-DAS server based on the data type. You can OR or add the values to trace multiple |
| |data types. Use the following table as a reference: |
| |Data Type Value |
| |Average Value 1 |
| |Average Flag String 2 |
| |Average Flag Mask 4 |
| |Input Line Status 8 |
| |Calibration Value 16 |
| |Calibration Flag String 32 |
| |Percent Monitor Availability 64 |
| |Bias Adjustment Factor 128 |
| |Digital Output Control 256 |
| |Calibration Control 512 |
| |Calibration Reference Value 1024 |
| |Server Time Delta 2048 |
| |Example: To monitor the Average Values and the BAF, set /dbg=129. |
| |Trace output includes information like the tag name, value and time/date of the data |
| |transferred. |
| |/dbg does not trace initial E-DAS database queries due to the potential of large |
| |numbers of values during startup or reconnect. |
|/ec=x |The first instance of the /ec parameter on the command line is used to specify a |
|Optional |counter number, x, for an I/O Rate point. If x is not specified, then the default |
| |event counter is 1. Also, if the /ec parameter is not specified at all, there is still|
| |a default event counter of 1 associated with the interface. If there is an I/O Rate |
| |point that is associated with an event counter of 1, each copy of the interface that |
| |is running without /ec=x explicitly defined will write to the same I/O Rate point. |
| |This means that one should either explicitly define an event counter other than 1 for |
| |each copy of the interface or one should not associate any I/O Rate points with event |
| |counter 1. Configuration of I/O Rate points is discussed in the section called “I/O |
| |Rate Tag Configuration,” p. 43. |
| |Subsequent instances of the /ec parameter may be used to keep track of various input |
| |or output operations. Subsequent instances of the /ec parameter can be of the form |
| |/ec*, where * is any ASCII character sequence. For example, /ecinput=10, /ecoutput=11,|
| |and /ec=12 are legitimate choices for the second, third, and fourth event counter |
| |strings. |
|/edasserver |Use this parameter to specify the ESC EDAS server name. |
|Required |Example: |
| |/edasserver=dahspc |
|/f=SS |The /f parameter defines the time period between scans in terms of hours (HH), minutes|
|or |(MM), and seconds (SS). The scans can be scheduled to occur at discrete moments in |
|/f=SS,SS |time with an optional time offset specified in terms of hours (hh), minutes (mm), and |
|or |seconds (ss). If HH and MM are omitted, then the time period that is specified is |
|/f=HH:MM:SS |assumed to be in seconds. |
|or |Each instance of the /f parameter on the command line defines a scan class for the |
|/f=HH:MM:SS,hh:mm:ss |interface. There is no limit to the number of scan classes that can be defined. The |
| |first occurrence of the /f parameter on the command line defines the first scan class |
|Required for reading |of the interface; the second occurrence defines the second scan class, and so on. PI |
|scan-based inputs |Points are associated with a particular scan class via the Location4 PI Point |
| |attribute. For example, all PI Points that have Location4 set to 1 will receive input |
| |values at the frequency defined by the first scan class. Similarly, all points that |
| |have Location4 set to 2 will receive input values at the frequency specified by the |
| |second scan class, and so on. |
| |Two scan classes are defined in the following example: |
| |/f=00:01:00,00:00:05 /f=00:00:07 |
| |or, equivalently: |
| |/f=60,5 /f=7 |
| |The first scan class has a scanning frequency of 1 minute with an offset of 5 seconds,|
| |and the second scan class has a scanning frequency of 7 seconds. When an offset is |
| |specified, the scans occur at discrete moments in time according to the formula: |
| |scan times = (reference time) + n(frequency) + offset |
| |where n is an integer and the reference time is midnight on the day that the interface|
| |was started. In the above example, frequency is 60 seconds and offset is 5 seconds for|
| |the first scan class. This means that if the interface was started at 05:06:06, the |
| |first scan would be at 05:07:05, the second scan would be at 05:08:05, and so on. |
| |Since no offset is specified for the second scan class, the absolute scan times are |
| |undefined. |
| |The definition of a scan class does not guarantee that the associated points will be |
| |scanned at the given frequency. If the interface is under a large load, then some |
| |scans may occur late or be skipped entirely. See the section called “Performance Point|
| |Configuration” for more information on skipped or missed scans. |
| |For E-DAS Average data inputs to PI, set up the scan rates according to the data |
| |average interval. Also, define the offsets respective of the polling schedule defined |
| |on the E-DAS Server. That is, the PI offset for scanning the inputs needs to be |
| |greater than the E-DAS offset for polling the data from the data logger. It is |
| |recommended that you set up the PI interface scan offset to a minimum of 30 seconds |
| |after polling is scheduled to occur on the E-DAS Server. |
| |For example, you want to retrieve hourly average data from E-DAS as inputs to PI. If |
| |hourly data polling is set up to occur at 1 minute after the hour, then use the |
| |following scan rate: /f=01:00:00,00:01:30. This causes PI to scan the data each hour, |
| |at one minute and thirty seconds after the hour. |
| |Wall Clock Scheduling |
| |Scan classes that strictly adhere to wall clock scheduling are now possible. This |
| |feature is available for interfaces that run on Windows and/or UNIX. Previously, wall |
| |clock scheduling was possible, but not across daylight savings time. For example, |
| |/f=24:00:00,08:00:00 corresponds to 1 scan a day starting at 8 AM. However, after a |
| |Daylight Savings Time change, the scan would occur either at 7 AM or 9 AM, depending |
| |upon the direction of the time shift. To schedule a scan once a day at 8 AM (even |
| |across daylight savings time), one should use /f=24:00:00,00:08:00,L. The L at the end|
| |of the scan class tells UniInt to use the new wall clock-scheduling algorithm. |
|/host=host:port |The /host parameter is used to specify the PI Home node. host is the IP address of |
|Optional |the PI Sever node or the domain name of the PI Server node. port is the port number |
| |for TCP/IP communication. The port is always 5450 for a PI 3 Server and 545 for a PI 2|
| |Server. It is recommended to explicitly define the host and port on the command line |
| |with the /host parameter. Nevertheless, if either the host or port is not specified, |
| |the interface will attempt to use defaults. |
| |Defaults: |
| |The default port name and server name is specified in the pilogin.ini or piclient.ini |
| |file. The piclient.ini file is ignored if a pilogin.ini file is found. Refer to the |
| |PI API Installation Instructions manual for more information on the piclient.ini and |
| |pilogin.ini files. |
| |Examples: |
| |The interface is running on a PI API node, the domain name of the PI 3 home node is |
| |Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host parameters would |
| |be: |
| |/host=marvin |
| |/host=marvin:5450 |
| |/host=206.79.198.30 |
| |/host=206.79.198.30:5450 |
|/id=x |The /id parameter is used to specify the interface identifier. |
|Optional |The interface identifier is a string that is up to nine characters in length. UniInt |
| |concatenates this string to the header that is used to identify error messages as |
| |belonging to a particular interface. See the Appendix “Error and Informational |
| |Messages” for more information, page 75. |
| |UniInt always uses the /id parameter in the fashion described above. This interface |
| |also uses the /id parameter to identify a particular interface copy number that |
| |corresponds to an integer value that is assigned to Location1. For this interface, one|
| |should use only numeric characters in the identifier. For example, |
| |/id=1 |
|/ih=x |The /ih parameter is used to specify whether history retrieval is ignored. |
|Optional |Setting /ih=1 specifies that history recovery will be skipped and at startup the |
|Default: /ih=0 |interface will only perform real-time data retrieval. The default is /ih=0 and history|
| |will be recovered. |
|/NoOutputs |If this parameter is specified, outputs are disabled. This is configured on the |
|Optional |Uniint tab of the PI ICU utility by checking the “Suppress all outputs” checkbox. |
| |If outputs are disabled, the message: |
| |/NoOutputs parameter detected. Outputs to PI disabled |
| |will be written to the message log when the interface starts. Optionally use the |
| |read-only version of the interface. |
|/ps=x |The /ps parameter specifies the point source for the interface. x is not case |
|Required |sensitive and can be any single character. For example, /ps=P and /ps=p are |
| |equivalent. |
| |The point source that is assigned with the /ps parameter corresponds to the |
| |PointSource attribute of individual PI Points. The interface will attempt to load only|
| |those PI points with the appropriate point source. |
|/q |When the /q parameter is present, Snapshots and exceptions are queued before they are |
|Optional |sent to the PI Server node. |
| |The maximum queue size is close to 4000 bytes. The queue is flushed between scans if |
| |it is not filled. |
|/sio |The /sio parameter stands for “suppress initial outputs.” The parameter applies only |
|Optional |for interfaces that support outputs. If the /sio parameter is not specified, the |
| |interface will behave in the following manner. |
| |When the interface is started, the interface determines the current Snapshot value of |
| |each output tag. Next, the interface writes this value to each output tag. In |
| |addition, whenever an individual output tag is edited while the interface is running, |
| |the interface will write the current Snapshot value to the edited output tag. |
| |This behavior is suppressed if the /sio parameter is specified on the command line. |
| |That is, outputs will not be written when the interface starts or when an output tag |
| |is edited. In other words, when the /sio parameter is specified, outputs will only be |
| |written when they are explicitly triggered. |
|/sn |The /sn parameter suppresses exception handling for all tags processed by the |
|Optional |interface. The exception checking attributes of the points are ignored. This |
| |interface should either use this switch or set all of the points’ exception handling |
| |attributes to zero to avoid missing or modifying data. |
|/stopstat |Not recommended with this interface. |
Sample PIEDAS.bat
REM ============================================================================
REM
REM PIEDAS.bat
REM
REM Sample startup file for the Environmental Systems Corp. E-DAS
REM Interface to the PI System
REM
REM ============================================================================
REM
REM OSIsoft strongly recommends using PI ICU to modify startup files.
REM
piedas /ps=E /ID=0 /host=piserver:5450 /edasServer="MyEdasServer" /sio ^
/sn /avr_ds=100 ^
/f=01:00:00,00:02:00 ^
/f=00:01:00,00:00:30 ^
/f=00:15:00,00:01:00 ^
/f=00:30:00,00:01:00 ^
/f=00:06:00,00:01:00 ^
/f=01:00:00,00:01:00 ^
/f=24:00:00,03:00:00,L
REM ---------------------------------------------------------------------------------
Interface Node Clock
Make sure that the time and time zone settings on the computer are correct. To confirm, run the Date/Time applet located in the Windows Control Panel. If the locale where the interface node resides observes Daylight Saving Time, check the box marked “Automatically adjust clock for daylight saving changes”. For example,
[pic]
In addition, make sure that the TZ environment variable is not defined. All of the currently defined environment variables can be viewed by opening a Command Prompt window and typing set. That is,
C:> set
Confirm that TZ is not in the resulting list. If it is, run the System applet of the Control Panel, click the Environment tab, and remove TZ from the list of environment variables.
The PI system typically observes local Daylight Savings Time. Since the E-DAS system always operates in local Standard Time, all timestamp information exchanged with the E-DAS system is in Standard Time local to E-DAS, even though the PI system may be operating in Daylight Savings Time. The interface will adjust the timestamps accordingly for PI inputs and outputs, so that they reflect the PI and E-DAS system times, respectively.
It is assumed that the interface node is in the same time zone as the PI server.
You must use a time synchronization program such as the Network Time Protocol (NTP) between the E-DAS server and the PI server. You can configure a special Server Time Difference tag to record the time zone adjusted drift between the E-DAS and PI servers. This tag records the delta in seconds. Use compression to eliminate the storing of insignificant values. If needed, use a PI-Alarm to notify the appropriate personnel. See the section on PI Point Types for more on the Server Time Difference tag.
Note: It is critical that the clocks on the PI Server, the PI API interface node, and the E-DAS Server maintain relative time synchronicity. This synchronization needs to be handled by an external time service on the E-DAS Server or the network. The PI ESCEDAS interface is not responsible for synchronizing these clocks.
Security
Windows
The PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Server. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Server manuals.
Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy Database used prior to PI version 3.3. The Trust Database maintains all the functionality of the proxy mechanism while being more secure.
See “Trust Login Security” in the chapter “PI System Management” of the PI Universal Data Server System Management Guide.
If the interface cannot write data to the PI Server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Serve, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.
PI Server v3.3 and Higher
Security configuration using piconfig
For PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust table:
C:\PI\adm> piconfig
@table pitrust
@mode create
@istr Trust,IPAddr,NetMask,PIUser
a_trust_name,192.168.100.11,255.255.255.255,piadmin
@quit
For the above,
Trust: An arbitrary name for the trust table entry; in the above example,
a_trust_name
IPAddr: the IP Address of the computer running the Interface; in the above example,
192.168.100.11
NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr
PIUser: the PI user the Interface to be entrusted as; piadmin is usually an appropriate user
Security Configuring using Trust Editor
The Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI Trust table.
See the PI System Management chapter in the PI Server manual for more details on security configuration.
PI Server v3.2
For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:
C:\PI\adm> piconfig
@table pi_gen,piproxy
@mode create
@istr host,proxyaccount
piapimachine,piadmin
@quit
In place of piapimachine, put the name of the PI Interface node as it is seen by PI Server.
OpenVMS
If the home node is a PI 2 Server, the read/write permissions should be set appropriately in the pisysdat:piserver.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the pibuild:piserver.txt file on the PI 2 home node. This paragraph should be deleted if the interface cannot talk to a PI 2 server.
If the interface cannot write data to a PI 2 or PI 3 Server owing to permission problems, error –10401 will be written to the PISysMgr:PIMesslog.txt file.
Starting / Stopping the Interface
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.
Starting Interface as a Service
If the interface was installed a service, it can be started from the services control panel or with the command:
PIEDAS.exe –start
A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. One is that the service may not be able to find the command-line arguments in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages.
Stopping Interface Running as a Service
If the interface was installed a service, it can be stopped at any time from the services control panel or with the command:
PIEDAS.exe –stop
The application can be uninstalled as a service by executing:
PIEDAS.exe –remove
Buffering
For complete information on buffering, please refer to the PI API Installation InstructionPI Environmental Systems E-DAS Interface Manual.
PI Interface Node buffering consists of a buffering process which runs continuously on the local node, a PI API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.
Note: Change the Local Security Policy on Windows XP.
1. Open "Administrative Tools" from the control panel.
2. Open "Local Security Policy" from administrative tools.
3. Browse to "Security Options" under "Local Policies."
4. Double click on "System Objects: Default owner for objects created by members of the Administrators group."
5. Change the dropdown from "Object Creator" to "Administrators group."
The behavior of Bufserv should now be the same on XP as it was for NT4 and 2000.
Configuring Buffering with PI ICU (Windows)
Buffering is enabled through the PI Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI API will not buffer data, sending data directly to the home node.
The API Buffering… dialog allows the user to view and configure the parameters associated with the API Buffering (bufserv) process. The user can start and stop the API Buffering process from the Service tab:
[pic]
Service Tab
The Service tab allows for some API Buffering service configuration. For further configuration changes, use the Services applet.
Service Name
The Service name displays the name of the API Buffering Service.
Display Name
The Display name displays the full name associated with the API Buffering service.
Log On As
Log on as indicates the Windows user account under which the API Buffering service is setup to start automatically on reboot, or manually.
Password
Password is the name of the password for the Windows user account entered in the Log on as:above.
Confirm password
You must reenter the password again to verify you have typed it correctly both times.
Dependencies
The Dependencies lists the Windows services on which the API Buffering service is dependent.
Dependent Services
The Dependent services area lists the Windows services that depend on bufserv to function correctly.
Start / Stop Service
The Start / Stop buttons allow for the API Buffering service to be started and stopped. If the service is not created this box will show Not Installed.
After a change is made to any of the settings on the Settings tab, the OK button must be clicked to save these settings, and then the service must be stopped and restarted for the changes to be picked up by bufserv.
Service Startup Type
The Startup Type indicates whether the API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, the API Buffering service is set to start automatically.
Create/Remove Service
The Create / Remove buttons allow for the creation or removal of the API Buffering service. Clicking the Create button will cause the service to be created using the Log on as and passwords given. Once the service is created the Start / Stop buttons will be activated.
Settings Tab
The Settings tab allows for configuration of the 7 configurable settings used by API Buffering. Default values are used if no other value is provided.
[pic]
Enable Buffering
Enables the API Buffering feature.
Maximum File Size
Maximum buffer file size in kilobytes before buffering fails and discards events. Default value is 100,000. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Send Rate
Send rate is the time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds). Default value is 100. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Primary Memory Buffer Size
Primary memory buffer size is the size in bytes of the Primary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Secondary Memory Buffer Size
Secondary memory buffer size is the size in bytes of the Secondary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Transfer Objects
Max transfer objects is the maximum number of events to send between each SENDRATE pause. Default value is 500. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Pause Rate
When buffers are empty the buffering process will wait for this number of seconds before attempting to send more data to the home node. Default value is 2. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Retry Rate
When the buffering process discovers the home node is unavailable it will wait this number of seconds before attempting to reconnect. Default value is 120. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Theoretical Send Rate
This is the theoretical max send rate which is calculated like this:
max = MAXTRANSFEROBJS / SENDRATE * 1000
Default value is 5000. This value is automatically calculated for the user and can not be changed.
There are no additional steps needed to install buffering after installing the PI API. The delivered PI API library supports both buffered and un-buffered calls.
Configuring Buffering Manually
Buffering is enabled through the use of a configuration file, piclient.ini. Unless this file is modified to explicitly enable buffering, the PI API will not buffer data, sending data directly to the home node.
There are no additional steps needed to install buffering after installing the PI API. The delivered PI API library supports both buffered and un-buffered calls.
Note: When buffering is configured to be on, the bufserv process must be started before other programs using the PI API, so that these programs can access the shared buffering resources. Any program that makes a connection to a PI Server has this requirement even if it does not write to PI.
Configuration of buffering is achieved through entries in the piclient.ini file. The file is found in the dat subdirectory of the PIHOME directory (typically c:\pipc\dat) under Windows NT. This file follows the conventions of Microsoft Windows initialization files with sections, keywords within sections, and values for keywords. All buffering settings are entered in a section called [APIBUFFER]. To modify settings, simply edit the piclient.ini file in a text editor (Notepad on Windows) to the desired values.
The following settings are available for buffering configuration:
|Keywords |Values |Default |Description |
|BUFFERING |0,1 |0 |Turn off/on buffering. OFF = 0, ON = 1, |
|PAUSERATE |0 - 2,000,000 |2 |When buffers are empty the buffering process |
| | | |will wait for this long before attempting to |
| | | |send more data to the home node (seconds) |
|RETRYRATE |0 - 2,000,000 |120 |When the buffering process discovers the home |
| | | |node is unavailable it will wait this long |
| | | |before attempting to reconnect (seconds) |
|MAXFILESIZE |1 - 2,000,000 |100,000 |Maximum buffer file size before buffering fails|
| | | |and discards events. (Kbytes) |
|MAXTRANSFEROBJS |1 - 2,000,000 |500 |Maximum number of events to send between each |
| | | |SENDRATE pause. |
|BUF1SIZE |64 - 2,000,000 |32768 |Primary memory buffer size. (bytes) |
|BUF2SIZE |64 - 2,000,000 |32768 |Secondary memory buffer size. (bytes) |
|SENDRATE |0 - 2,000,000 |100 |The time to wait between sending up to |
| | | |MAXTRANSFEROBJS to the server (milliseconds) |
In addition to the [APIBUFFER] section, the [PISERVER] section may be used to define the default PI server and an optional time offset change that may occur between the client and server.
|Keywords |Values |Default |Description |
|PIHOMENODE |string |None |Windows default server is in pilogin.ini |
|DSTMISMATCH |0 - 2,000,000 |0 |The time that the server and client local time |
| | | |offset is allowed to jump. Typically, 3600 if the |
| | | |nodes are in time zones whose DST rules differ |
| | | |(seconds) |
Example piclient.ini File
On Windows the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds meaning wait 10 minutes after losing a connection before retrying.
On Windows a piclient.ini file might look like:
[APIBUFFER]
BUFFERING=1
MAXFILESIZE=100000
; The PI API connection routines have a 1 minute default timeout.
RETRYRATE=600
E-DAS to PI Reconciliation Utility (EPR)
In the E-DAS system it is common practice to qualify data. For qualification, the user processes averaged data with a set of certified calculations and replaces the data for that time period. It is desirable to send this updated data to PI. The E-DAS to PI Data Reconciliation Utility (EPR) is the tool with which the user imports edited values from the E-DAS system into PI after making manual qualification adjustments to the existing data. With EPR, the user browses for the PI tags, given certain criteria and updates them, given a time range.
[pic]
To load the EPR, execute the install application EPRUtility_1.0.0.xxx.exe. Detailed information on the EPR is in the E-DAS to PI Reconciliation Utility manual.
Appendix A:
Error and Informational Messages
The string PIEDASID is pre-pended to error messages written to the message log. ID is a numeric value and is specified by the /id parameter on the startup command line.
Message Logs
The location of the message log depends upon the platform on which the interface is running. See the UniInt End User Document for more information.
Messages are written to PIHOME\dat\pipc.log at the following times.
• When the interface starts many informational messages are written to the log. These include the version of the interface, the version of UniInt, the command-line parameters used, and the number of points.
• As the interface retrieves points, messages are sent to the log if there are any problems with the configuration of the points.
• If the /db is used on the command line, then various informational messages are written to the log file.
• This interface supports an additional /dbg=nnn command line switch. See the section on command line startup switches for specific information.
Messages
Check the pipc.log file to verify the interface startup. Startup message examples:
Thu Dec 20 15:29:48 2001
PIEDAS> PIEDAS Interface Version: 1, 0, 0, 10
Thu Dec 20 15:29:48 2001
PIEDAS> EDASServer=SHACEM01
Thu Dec 20 15:29:49 2001
PIEDAS> AVR_DS=100
Thu Dec 20 15:29:52 2001
PIEDAS> Can't connect to E-DAS server:SHACEM01
Thu Dec 20 15:29:54 2001
PIEDAS>
ERROR - Unable to read initial E-DAS time-zone bias.
You must also check the pipc.log file for tag acceptance by the interface. A tag can be successfully created in PI but rejected by the interface. The following is a sample interface validation failure message.
Thu Dec 20 15:19:52 2001
PIEDAS>
ERROR validating tag: 'MyTag'
Missing fields or Phase out of range in extended descriptor
Requires ID1, ID2 and Phase (0-99)
The tag was rejected by the interface
Additional messages can be generated while running if errors are detected.
Most problems occur when you are initially configuring the interface. If your points are stuck at Pt Created, I/O Timeout, or Shutdown, check the following items:
• Look for –10401 errors in the PIPC.LOG file. Often, if the interface is running on a PI API node (or sometimes even the PI home node), it will not have a proxy account set up for it. If this is the case, the interface will get the -10401 error because it does not have permission to write to PI. To correct this, set up a proxy for the node where the interface is running. See the PI Data Archive Manual for information about how to do this.
System Errors and PI Errors
System errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers.
Error Descriptions
You can obtain descriptions of system and PI errors with the pidiag utility:
\PI\adm\pidiag –e error_number
Appendix B:
PI ESCEDAS Terminology
|Term |Description |
|E-DAS Server |The server that houses Environmental Systems Corporation’s (ESC) E-DAS software application. |
| |Except where noted in this document, “E-DAS Server” refers to either an E-DAS EMR for Windows |
| |system or an E-DAS Expert for UNIX system. |
|Polling Computer |The machine on which the E-DAS Server application runs and polls data from the Data Logger. |
|Data Logger |An ESC product that acquires/controls the monitoring of CEM and ambient air quality. |
|E-DAS API |A software application that exposes an API to the E-DAS Server, used to facilitate data transfer|
| |between the E-DAS server and the PI ESCEDAS interface. |
Revision History
|Date |Author |Comments |
|15-June-01 |ESB |Revision: updated to reflect latest changes to the skeleton |
| | |template version 1.09. Documented additional functionality. |
|22-October-01 |MDR |Updated. |
|20-December-01 |MDR |Major update. |
|08-January-02 |ESB |Completed an edit. |
|11-Feb-02 |JPM |Added PI ICU to Startup Command File section, I/O Rates section, |
| | |and Performance Points section. |
|21-Feb-02 |CG |Skeleton 1.11; added Interface Status Tag section; added PI ICU to|
| | |buffering; added version 1.0.0.38 |
|22-April-02 |MDR |Removed build number (38). Added ESC components’ required |
| | |versions. Allow reals for server difference tags. Added comment |
| | |on ESC contact information. |
|01-May-02 |JFZ |Added in information regarding prohibiting outputs by use of the |
| | |/nooutput switch in the command file. |
|10-May-02 |MDR |Added read-only references |
|07-March-03 |BPayne |Added accurate version to page 1. |
|25-March-04 |BPayne |Added update to show support of error -888.0 |
|09-Dec-04 |BPayne |Revision: updated to reflect latest changes to the skeleton |
| | |template version dated 11/9/04. |
|23-Mar-05 |MPK |Fixed interface directory name references, Removed duplicate |
| | |Interface Status Tag section, modified sample batch file, updated |
| | |buffering section. Updated manual to Skeleton 1.15. Fixed |
| | |headers and footer, TOC. |
|28-Mar-05 |BPayne |Added reference to EDASStateTables, interface ref to PI_ESCEDAS. |
|28-Mar-05 |MPK |Added new screenshot for ICU Control, performance points and I/O |
| | |rates. Fixed sample batch file – removed /u /pd and /db |
| | |command-line parameters. |
|20-Apr-05 |BPayne |Update manual to version 1.0.0.103 |
|21-Apr-05 |Chrys |Accepted all changes and made final |
|10-Nov-05 |BPayne |Update manual to version 1.0.0.104 |
|30-Nov-05 |Mkelly |Rev A. Modified the copyright page, put in section breaks for |
| | |connection tool, updated TOC, checked headers and footer. |
|2-Dec-05 |BPayne |Added Windows Service install section |
|16-May-05 |BPayne |Added doc for command line switch /ih – ignore history retrieval. |
| | |Version 1.1.0.105 |
|21-Jul-2006 |MKelly |Version 1.1.0.105 Rev D; Updated to current manual skeleton 2.5.2.|
| | |Fixed headers and footers. Updated screenshots for ICU section and|
| | |others. |
|01-Aug-2006 |BPayne |Version 1.1.0.105 Rev E; Updated Manual service Installation table|
| | |with Bufserv. Added enhanced documentation to the Point |
| | |Configuration section. |
|2-Aug-2006 |MKelly |Version 1.1.0.105 Rev F; Removed comments, made minor formatting |
| | |changes, saved at 100% and Final. |
|14-Aug-2006 |Janelle |Version 1.1.0.105 Rev G: Fixed headers; updated copyright; |
| | |alphabetized command line parameters, minor formatting changes |
|17-Aug-2006 |MKelly |Version 1.1.0.105 Rev H: Updated the Configuring the Interface |
| | |with the PI ICU. |
|14-Jan-2009 |MMoore |Version 1.1.0.105 Rev I: Added support of ESC StackVision 2.3 SP1 |
| | | |
| | | |
| | | |
| | | |
-----------------------
Service installed or uninstalled
Status of the Interface Service
Status of the ICU
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- fs 1 and fs 100s
- uscis ebiss customer service reference guide
- oap home academic personnelacademic personnel
- houston community college hcc
- pi environmental systems e das interface manual
- international students and scholars center arizona state
- home santa clara university
- physician s report
- kansas state university
- asista immigration assistance
Related searches
- information systems and e business management
- manual accounting systems pdf
- advanced environmental systems inc
- environmental systems examples
- e s manual pa dep
- environmental management system manual sample
- portal das financas e fatura
- e fatura portal das financas
- disadvantages of manual systems over automated systems
- environmental management systems inc
- environmental systems associates md
- environmental systems inc