PI Interface for Bailey Infi90 - OSIsoftcdn.osisoft.com/interfaces/3296/PI_BaInfi90_1.8.4.9.docx · Web viewABB/Bailey. Computer Interface ... a wall wart transformer) ... The interface

PI Interface for Bailey Infi90

Version 1.8.4.xRevision A

OSIsoft, LLC777 Davis St., Suite 250San Leandro, CA 94577 USATel: (01) 510-297-5800Fax: (01) 510-357-8136Web: http://www.osisoft.com

OSIsoft Australia • Perth, AustraliaOSIsoft Europe GmbH • Frankfurt, GermanyOSIsoft Asia Pte Ltd. • SingaporeOSIsoft Canada ULC • Montreal & Calgary, CanadaOSIsoft, LLC Representative Office • Shanghai, People’s Republic of ChinaOSIsoft Japan KK • Tokyo, JapanOSIsoft Mexico S. De R.L. De C.V. • Mexico City, MexicoOSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil

PI Interface for Bailey Infi90Copyright: © 1997-2013 OSIsoft, LLC. All rights reserved.No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset Framework (PI AF), IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Coresight, PI Data Services, PI Event Frames, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.

U.S. GOVERNMENT RIGHTSUse, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.

Published: 05/2013

http://www.osisoft.com/

Table of Contents

Chapter 1. Introduction...................................................................................................1Reference Manuals............................................................................................2Supported Operating Systems...........................................................................2Supported Features...........................................................................................2Diagram of Hardware Connection......................................................................5

Chapter 2. Principles of Operation................................................................................7Failover..............................................................................................................8

Chapter 3. Installation Checklist..................................................................................11Data Collection Steps.......................................................................................11Interface Diagnostics........................................................................................12

Chapter 4. Interface Installation...................................................................................13Naming Conventions and Requirements..........................................................13Interface Directories.........................................................................................14

PIHOME Directory Tree.........................................................................14Interface Installation Directory...............................................................14

Interface Installation Procedure.......................................................................14Installing Interface as a Windows Service........................................................14Installing Interface Service with PI Interface Configuration Utility....................15

Service Configuration............................................................................15Installing Interface Service Manually................................................................18

Chapter 5. Digital States...............................................................................................19

Chapter 6. PointSource.................................................................................................21

Chapter 7. PI Point Configuration................................................................................23Point Attributes.................................................................................................23

Tag........................................................................................................23PointSource...........................................................................................24PointType...............................................................................................24Location1...............................................................................................24Location2...............................................................................................24Location3...............................................................................................25Location4...............................................................................................25Location5...............................................................................................25InstrumentTag........................................................................................25ExDesc..................................................................................................25Scan......................................................................................................25Shutdown...............................................................................................25

Output Points...................................................................................................26SourceTag.............................................................................................26


Bailey Point Types.................................................................................26Digital Read...........................................................................................27Analog Report........................................................................................28

Bailey Database Conversion............................................................................29Tag........................................................................................................30Descriptor..............................................................................................30EngUnits................................................................................................30Zero.......................................................................................................30Span......................................................................................................30Location2...............................................................................................30Location3...............................................................................................30Location4...............................................................................................30Location5...............................................................................................30Digital Points..........................................................................................30

Chapter 8. Startup Command File...............................................................................31Configuring the Interface with PI ICU...............................................................31

bainfi90 Interface Page..........................................................................33Manual Maintenance of the Startup Command File...............................36

Manual Maintenance of the Startup Command File.........................................36Command-line Parameters..............................................................................37Sample i90.bat File..........................................................................................39Legacy Startup Command File.........................................................................40

Chapter 9. Interface Node Clock..................................................................................43

Chapter 10. Security....................................................................................................45

Chapter 11. Starting / Stopping the Interface...........................................................47Starting Interface as a Service.........................................................................47Stopping Interface Running as a Service.........................................................47

Chapter 12. Buffering..................................................................................................49Which Buffering Application to Use..................................................................49How Buffering Works.......................................................................................50Buffering and PI Server Security......................................................................50Enabling Buffering on an Interface Node with the ICU.....................................51

Choose Buffer Type...............................................................................51Buffering Settings..................................................................................52Buffered Servers....................................................................................54Installing Buffering as a Service.............................................................57

Configuring Buffering Manually........................................................................59Example piclient.ini File.........................................................................60

Chapter 13. Interface Diagnostics Configuration.....................................................61Scan Class Performance Points......................................................................61I/O Rate Point..................................................................................................62Interface Status Point.......................................................................................64Monitoring I/O Rates on the Interface Node.....................................................65

Appendix A. Error and Informational Messages......................................................67


Message Logs..................................................................................................67System Errors and PI Errors............................................................................67

Appendix B. PI SDK Options......................................................................................69

Appendix C. Troubleshooting....................................................................................71Hardware Configuration...................................................................................71Communication Problems................................................................................71Bailey Loop Problems......................................................................................72PI Configuration Problems...............................................................................73

Appendix D. User-defined Bit Mask for MSDD, DD and RCM Points.....................75Multi-state Device Driver Exception.................................................................75Device Driver Exception...................................................................................75Remote Switch (RCM) Exception.....................................................................76Example MSDD to PI Tag State Translation....................................................76

Appendix E. Terminology...........................................................................................77

Appendix F. Technical Support and Resources.......................................................81Before You Call or Write for Help...........................................................81Help Desk and Telephone Support........................................................81Search Support......................................................................................82Email-based Technical Support.............................................................82Online Technical Support.......................................................................82Remote Access......................................................................................83On-site Service......................................................................................83Knowledge Center.................................................................................83Upgrades...............................................................................................83OSIsoft Virtual Campus (vCampus).......................................................84

Appendix G. Revision History....................................................................................85


Chapter 1. Introduction

The PI Interface for Bailey Infi90 (hereafter referred to as BaInfi90 interface) transfers data between the PI System and a Bailey Network90 or a Bailey Infi90 distributed control system. The interface runs on the Windows Systems listed in section Supported Operating Systems. Unless otherwise noted, the remainder of this document uses the term "Windows" to refer to all these.

An RS-232C serial cable provides the physical connection between the Windows computer running the BaInfi90 interface and the Bailey control system. On the Windows side, the serial cable plugs into one of the standard COM ports. On the Bailey end, the serial cable is attached to a Network90 Computer Interface Unit (CIU) or the Infi90 ICI.

Communications across the serial line occurs by way of a binary protocol. This protocol is defined in the Bailey publication Computer Interface Unit Programmer's Reference Manual (E93-905). This protocol is based on exception reporting. That is, the CIU or ICI sends a value to the BaInfi90 interface only when the value has met exception specifications.

The communication parameters are 1200, 2400, 4800, 9600 or 19200 bits per second, 8 bits, 1 stop bit, and no parity. The interface supports both the enhanced (CIU02, CIU03, CIU04) and CIU01 versions of the computer interface module as well as the serial version of the ICI01. For the enhanced CIU, the interface supports exception report screening. The ICI01 is compatible with the CIU04.

Unless otherwise noted, the remainder of this document refers to the CIU and ICI computer gateways interchangeably.

The interface supports bi-directional data transfer. That is, the interface supports reading values from the Bailey control system into the PI Server, that is, inputs, as well as sending a value from the PI Server to the Bailey control system, outputs. The interface sends an output whenever the PI source point receives a new snapshot value.

The interface supports a failover configuration whereby a Primary copy of the interface collects data and a Secondary copy stands by in case primary data collection fails.

Note: The value of [PIHOME] variable for the 32-bit interface will depend on whether the interface is being installed on a 32-bit operating system (C:\Program Files\PIPC) or a 64-bit operating system (C:\Program Files (x86)\PIPC).

The value of [PIHOME64] variable for a 64-bit interface will be C:\Program Files\PIPC on the 64-bit operating system.

In this documentation [PIHOME] will be used to represent the value for either [PIHOME] or [PIHOME64]. The value of [PIHOME] is the directory which is the common location for PI client applications.


Reference Manuals

OSIsoft PI Server manuals

PI API Installation Instructions manual

UniInt Interface User Manual

ABB/Bailey Computer Interface Unit Programmer's Reference Manual (E93-905)

Supported Operating Systems

Platforms 32-bit application 64-bit application

Windows XP32-bit OS Yes No

64-bit OS Yes (Emulation Mode) No

Windows 2003 Server32-bit OS Yes No


Windows Vista32-bit OS Yes No


Windows 2008 32-bit OS Yes No

Windows 2008 R2 64-bit OS Yes (Emulation Mode) No

Windows 732-bit OS Yes No


Windows 8 32-bit OS Yes No


Windows 2012 64-bit OS Yes (Emulation Mode) No

The interface is designed to run on the above mentioned Microsoft Windows operating systems and their associated service packs.

Please contact OSIsoft Technical Support for more information.

Supported Features

Feature Support

Interface Part Number PI-IN-BA-I90-NTI

Auto Creates PI Points No

Point Builder Utility No

ICU Control Yes

PI Point Types Float32 / Float16 / Float64 / Digital / Int16 / Int32

Sub-second Timestamps No


Feature Support

Sub-second Scan Classes No

Automatically Incorporates PI Point Attribute Changes

Yes

* Exception Reporting Yes

Outputs from PI Yes

Inputs to PI: Unsolicited

Supports Questionable Bit No

Supports Multi-character PointSource No

Maximum Point Count About 500 for CIU01, 2500 for CIU02, 5000 for CIU03, 10000 for CIU04, and 10000 for ICI

* Uses PI SDK No

PINet String Support No

* Source of Timestamps PI Server computer

History Recovery No

UniInt-based* Disconnected Startup* SetDeviceStatus

NoNoNo

* Failover Yes

* Vendor Software Required on Interface Node / PINet Node

No

Vendor Software Required on Foreign Device

No

Vendor Hardware Required Yes

Additional PI Software Included with interface

No

Device Point Types Net90/Infi90 point types 1, 2, 3, 4, 5, 6, 7, 12, 13, 14, 15, 19, 21, and 22

Serial-Based interface Yes

* See paragraphs below for further explanation.

Uses PI SDKThe PI SDK and the PI API are bundled together and must be installed on each interface node. This interface does not specifically make PI SDK calls.

Exception ReportingThe Bailey Net90 or Infi90 control system performs exception reporting. This Interface receives exception values and sends them to the PI Server.

Source of TimestampsThe clock on the computer running the PI Server provides timestamps for the BaInfi90 interface. For input points, the Interface writes a timestamp that reflects the time at which it received the exception values from the CIU. For output points, the Interface writes a timestamp that reflects the time of the event that triggered the output.


Introduction

FailoverFailover is implemented by running two copies of the BaInfi90 Interface in a failover configuration. One copy is designated as the Primary and the other as the Secondary. The failover mechanism uses a watchdog signal on the Bailey control system to determine when the Secondary interface should assume data collection because of a failure in the Primary.

Vendor Hardware RequiredThe interface connects to either the CIU01 version or the enhanced versions (CIU02, CIU03, CIU04) of the Bailey Net90 computer interface module. The interface also connects to the serial version of the Infi90 ICI01.

Device Point TypesThe BaInfi90 interface supports the following Net90/Infi90 point types:

Point Type Description

1 Process Variable

2 Setpoint Read

3 Control Output Read

4 Ratio Index Read

5 Analog Read

6 Station Status

7 Digital Read

12 Analog Report

13 Digital Report

14 Module Status

15 RCM Read

19 RMSC Read

21 4-byte Analog Read (CIU04 only)

22 4-byte Analog Report (CIU04 only)

Serial-Based InterfaceThis interface uses a serial connection to the Bailey Infi90 network.

Recent Dell server class machines are using only 3 volt power supplies to drive the serial port – IEEE RS232 specification requires at least +/- 4.7 volts for a valid RS232 signal.

Some recent models of HP and Dell server class machines have been observed to have serial port circuitry which overheat and experience thermal shutdown after a few minutes or hours of operation over long cables or high speeds.

Self-powered serial port extenders should not be used for interfaces. Customers often attempt to extend serial port ranges using twisted pair wire devices or fiber optic cable devices. Devices with their own external power source (for example, a wall wart transformer) should be the only types used. Devices which leech power from the PC’s serial port will have difficulty at high data speeds (baud rates) or long cables. In some applications, a cable more than 20-50 feet long may be considered long. Higher speeds or longer cables translate to sharply increased power supply demand by the serial port hardware.

Server class machines often have inferior serial ports. Server class machines are not required for most interfaces and should not be used, especially not when serial port connections are required.

Diagram of Hardware Connection

Option 1


Introduction

Option 2

Chapter 2. Principles of Operation

When the BaInfi90 interface runs, it begins by searching the PI Server for points that it should service. In particular, it looks for points whose PointSource attribute matches the /ps startup command parameter. For these potential points, the interface then checks the Location codes attributes to determine point validity.

Next, the interface opens the COM port to establish connection to the CIU. The program sends the CIU restart command, and establishes and connects all the points. Informational messages are sent to the PIPC.LOG at successful restart and at the end of the point establishment phase. The point establishment phase may last from less than a minute to more than ten minutes, depending on the number of points that the interface is servicing. Normally, the interface can establish ten points in one second.

After all the points have been established and connected, the program begins the loop to read Net90/Infi90 exceptions and send outputs. The startup parameters /delay and /cnt determine the rate at which the interface polls the CIU. The interface uses the following algorithm:

Read exceptions until /cnt consecutive reads or the number of exceptions received in a read is less than half the read capacity.

Read miscellaneous status exceptions until /cnt reads or the number of exceptions received in a read is less half of the read capacity.

Check the PI Server for new snapshot values for the output source points. If there are, send those output values to the Net90/Infi90.

Delay for /delay seconds or check for PI point database updates.

If the timesync parameter /tsync is positive and thirty minutes have passed since the last time synchronization, then do time synchronization.

For CIU04s, the algorithm is the similar. The only difference is that reading exceptions and reading miscellaneous status exceptions are combined into a single command.

The interface program periodically checks for changes in the PI point database and automatically accounts for the modification, addition, and deletion of points. Thus, there is no need for a program restart if interface points are edited. Each time the interface processes a point change, it writes a message to the PIPC.LOG. Hence, the user can trace the progress on the point database change.

However, it may take some time for the program to pick up all the changes when a large number of tags are changed. Accordingly, if the user has changed a large number of points, it will be faster for the changes to take effect if the user restarts the interface.

If the interface program has ten consecutive I/O errors, it will try to restart the CIU. All communication errors are recorded in the PIPC.LOG file. Consecutive errors of the same type are redacted in the log file only once.

The CIU commands used by the BaInfi90 interface are:


Restart CIU

Establish point

Establish report

Disestablish point

Define nodes

Get system time

Set system time

Connect points

Read exceptions

Read miscellaneous status exceptions

Output value group

Output value (CIU02 only)

Reread

Read data exceptions (CIU04 only)

Output report (CIU04 only)

Failover

You can run two copies of the interface in a failover configuration whereby one copy fails over to another. These two copies are designated as the Primary and the Secondary. Initially, the Primary collects data while the Secondary runs in standby mode.

The Primary and Secondary communicate indirectly with each other through a watchdog signal on the Net90. Specifically, the Primary periodically writes watchdog messages. When the Secondary interface times out in receiving these watchdog messages, it takes over data collection. When the Primary interface comes back online and starts writing watchdog messages, the Secondary interface stops data collection and returns to waiting mode.

The failover scheme covers the cases of Windows computer failure, CIU communication failure, CIU failure, and interface program crashes. Note that there is a limitation on this failover scheme. The limitation applies to PI-to-Net90 points, that is, output points. The primary and the secondary CIU must to have different PCU addresses because it is possible that they are both online at the same time (when the primary Windows computer fails, the primary CIU is still online). Hence, the failover is only seamless for input to PI. However, when the Secondary interface is active, the outputs from PI have different N90 addresses. Accordingly, any PCU configuration reading from the CIU must be able to switch to the secondary CIU when the primary CIU watchdog stops updating. So, for output points, you need to modify the existing PCU configuration to take advantage of the failover.

There are three startup command parameters related to failover. The startup command parameter /failover indicates whether a copy of the interface is running in a failover configuration: a value of 0 indicates no failover; 1 indicates that the interface is running as the Primary; and 2 indicates that the interface is running as the Secondary.

When the command parameter /failover is 2, the parameter /PriCIU is required. This parameter indicates the Primary's CIU node/PCU number.


Finally, the /wdogidx indicates the CIU index for the watchdog output signal. This parameter is required when /failover is 1 or when /failover is 2.

The interface automatically creates the watchdog point on the Bailey control system. No additional configuration is necessary.


Chapter 3. Installation Checklist

If you are familiar with running PI data collection interface programs, this checklist helps you get the interface running. If you are not familiar with PI interfaces, return to this section after reading the rest of the manual in detail.

This checklist summarizes the steps for installing this interface. You need not perform a given task if you have already done so as part of the installation of another interface. For example, you only have to configure one instance of Buffering for every interface node regardless of how many interfaces run on that node.

The Data Collection Steps below are required. Interface Diagnostics and Advanced Interface Features are optional.

Data Collection Steps

1. Confirm that you can use PI SMT to configure the PI Server. You need not run PI SMT on the same computer on which you run this interface.

2. If you are running the interface on an interface node, edit the PI Server’s Trust Table to allow the interface to write data.

3. Run the installation kit for the PI Interface Configuration Utility (ICU) on the interface node if the ICU will be used to configure the interface. This kit runs the PI SDK installation kit, which installs both the PI API and the PI SDK.

4. Run the installation kit for this interface. This kit also runs the PI SDK installation kit which installs both the PI API and the PI SDK if necessary.

5. If you are running the interface on an interface node, check the computer’s time zone properties. An improper time zone configuration can cause the PI Server to reject the data that this interface writes.

6. Run the ICU and configure a new instance of this interface. Essential startup parameters for this interface are:

Point Source (/PS=x)Interface ID (/ID=#)PI Server (/Host=host:port) Port (/port=#)

7. Use the Bailey EWS (Engineering Workstation) to confirm the ability to use the serial cable to communicate to the CIU/ICI. Use this same serial cable to connect the interface computer to the CIU/ICI.

8. If you will use digital points, define the appropriate digital state sets.

9. If necessary, configure a digital state set that indicates the Bailey Station Status values (Manual, Auto, Cascade/Ratio, Dig Station Failure, Manual Lock, Bypassed, Auto Lock, Cascade Lock).


10. If necessary, configure a digital state set that indicates the Bailey module status values (Configure, Failed, Error, Execute).

11. Build input tags and, if needed, output tags for this interface. Important point attributes and their purposes are:

Location1 specifies the interface instance ID; it should match the /ciu# parameter..Location2 is the Bailey PCU (node) portion of the Bailey address.Location3 is the Bailey module portion of the Bailey address.Location4 is the Bailey block portion of the Bailey address.Location5 is the Bailey point type.ExDesc is not used.InstrumentTag is not used.

12. Start the interface interactively and confirm its successful connection to the PI Server without buffering.

13. Confirm that the interface collects data successfully.

14. Stop the interface and configure a buffering application (either Bufserv or PIBufss). When configuring buffering use the ICU menu item Tools Buffering… Buffering Settings to make a change to the default value (32678) for the Primary and Secondary Memory Buffer Size (Bytes) to 2000000. This will optimize the throughput for buffering and is recommended by OSIsoft.

15. Start the buffering application and the interface. Confirm that the interface works together with the buffering application by either physically removing the connection between the interface node and the PI Server Node or by stopping the PI Server.

16. Configure the interface to run as a Service. Confirm that the interface runs properly as a Service.

17. Restart the interface node and confirm that the interface and the buffering application restart.

Interface Diagnostics

1. Configure the I/O Rate point.

2. Install and configure the Interface Status Utility on the PI Server Node.

3. Configure the Interface Status point.


Chapter 4. Interface Installation

OSIsoft recommends that interfaces be installed on interface nodes instead of directly on the PI Server node. An interface node is any node other than the PI Server node where the PI Application Programming Interface (PI API) is 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.

After the interface has been installed and tested, Buffering should be enabled on the interface node. Buffering refers to either PI API Buffer Server (Bufserv) or the PI Buffer Subsystem (PIBufss). For more information about Buffering see the Buffering chapter of this manual.

In most cases, interfaces on interface 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 install the interface as an automatic service that depends on the PI Update Manager and PI Network Manager services. This typical scenario assumes that Buffering is not enabled on the PI Server node. Bufserv or PIBufss 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 the PI Server, but it is not standard practice to enable buffering on the PI Server node. The PI Buffer Subsystem can also be installed on the PI Server. See the UniInt Interface User Manual for special procedural information.

Naming Conventions and Requirements

In the installation procedure below, it is assumed that the name of the interface executable is i90.exe and that the startup command file is called i90.bat.

When Configuring the Interface ManuallyIt is customary for the user to rename the executable and the startup command file when multiple copies of the interface are run. For example, i901.exe and i901.bat would typically be used for instance 1, i902.exe and i902.bat for instance 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 parameters in a file that has the same root name.


Interface Directories

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.

For 32-bit operating systems, a typical pipc.ini file contains the following lines:[PIPC]PIHOME=C:\Program Files\PIPC

For 64-bit operating systems, a typical pipc.ini file contains the following lines:[PIPC]PIHOME=C:\Program Files (X86)\PIPC

The above lines define the root of the PIHOME directory on the C: drive. The PIHOME directory does not need to be on the C: drive. OSIsoft recommends using the paths shown above as the root PIHOME directory name.

Interface Installation Directory

The interface install kit will automatically install the interface to:PIHOME\Interfaces\i90\

PIHOME is defined in the pipc.ini file.

Interface Installation Procedure

The BaInfi90 interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000 and later operating systems. To install, run the appropriate installation kit.

BaInfi90_#.#.#.#_.exe

Installing Interface as a Windows Service

The BaInfi90 interface service can be created, preferably, with the PI Interface Configuration Utility, or can be created manually.


Installing Interface Service with PI Interface Configuration Utility

The PI Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service:

Service Configuration

Service nameThe Service name box shows the name of the current interface service. This service name is obtained from the interface executable.

IDThis is the service ID used to distinguish multiple instances of the same interface using the same executable.

Display nameThe 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 name to indicate that the service is part of the OSIsoft suite of products.


Interface Installation

Log on asThe 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.

PasswordIf 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 passwordIf a password is entered in the Password text box, then it must be confirmed in the Confirm password text box.

DependenciesThe Installed services list is a list of the services currently installed on this machine. Services upon which this interface is dependent should be moved into the Dependencies list using the

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. To remove a service from the list of

dependencies, use the button, and the service name will be removed from the Dependencies list.

When the 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, then the interface service will not run.

Note: Please see the PI Log and Windows Event Logger for messages that may indicate the cause for any service not running as expected.

- Add ButtonTo add a dependency from the list of Installed services, select the dependency name, and click the Add button.

- Remove ButtonTo remove a selected dependency, select 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.

Startup TypeThe Startup Type indicates whether the interface service will start automatically or needs 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.

CreateThe 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

The toolbar contains a Start button and a Stop button . 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.


Status of the ICU

Service installed or uninstalled

Status of the Interface Service

Interface Installation

Installing Interface Service Manually

Help for installing the interface as a service is available at any time with the command:i90.exe /help

Open a Windows command prompt window and change to the directory where the i901.exe executable is located. Then, consult the following table to determine the appropriate service installation command.

Note: In the following Windows Service Installtation Commands you may use either a slash (/) or dash (-) as the delimiter.

Windows Service Installation Commands on an Interface Node or a PI Server Node with Bufserv implemented

Manual service i90.exe /install /depend "tcpip bufserv"

Automatic service i90.exe /install /auto /depend "tcpip bufserv"

*Automatic service with service ID

i90.exe /serviceid X /install /auto /depend "tcpip bufserv"

Windows Service Installation Commands on an Interface Node or a PI Server Node without Bufserv implemented

Manual service i90.exe /install /depend tcpip

Automatic service i90.exe /install /auto /depend tcpip

*Automatic service with service ID

i90.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) parameter found in the interface .bat file.

Check the Microsoft Windows Services control panel to verify that the service was added successfully. The services control panel can be used at any time to change the interface from an automatic service to a manual service or vice versa.

Chapter 5. Digital States

For more information regarding Digital States, refer to the PI Server documentation.

Digital State SetsPI 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 Server manuals.

An interface point that contains discrete data can be stored in PI as a digital point. A digital point associates discrete data with a digital state set, as specified by the user.

The Bailey Station Status (Net90/Infi90 point type 6) has the following discrete values:

Value Station Mode

0 Manual

1 Auto

2 Cascade/Ratio

3 Dig Station Failure

4 Manual Lock

5 Bypassed

6 Auto Lock

7 Cascade Lock

If you want to store into a PI point the value of the Bailey Station Status, creation of a digital state set with the above states is required.

The Bailey module status (Net90/Infi90 point type 14) has the following discrete values:

Value Module Status

0 Configure

1 Failed

2 Error

3 Execute

If you want to store into a PI point the Bailey module status, creation of a digital state set with the above states is necessary.


System Digital State SetSimilar to digital state sets is the system digital state set. This set is used for all points, regardless of type, to indicate the state of a point at a particular time. For example, if the interface receives bad data from the data source, it writes the system digital state Bad Input to PI instead of a value. The system digital state set has many unused states that can be used by the interface and other PI clients. Digital States 193-320 are reserved for OSIsoft applications.


Chapter 6. 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 example, the letter R may be chosen to identify points that belong to the MyInt interface. To implement this, set the PointSource attribute to R for every PI point that is configured for the MyInt interface. Then, /ps=R 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 R. 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.

Case-sensitivity for PointSource AttributeThe PointSource character that is supplied with the /ps command-line parameter is not case sensitive. That is, /ps=P and /ps=p are equivalent.

Reserved Point SourcesSeveral subsystems and applications that ship with PI are associated with default PointSource characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem uses @ for Alarm Tags, G for Group Alarms and Q for SQC Alarm Tags, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Do not use these PointSource characters or change the default point source characters for these applications. Also, if a PointSource character is not explicitly defined when creating a PI point; the point is assigned a default PointSource character of Lab (PI 3). Therefore, it would be confusing to use Lab as the PointSource character for an interface.

Note: Do not use a point source character that is already associated with another interface program. However it is acceptable to use the same point source for multiple instances of an interface.


Chapter 7. PI Point Configuration

The PI point is the basic building block for controlling data flow to and from the PI Server. A single point is configured for each measurement value that needs to be archived.

Point Attributes

Use the point attributes below to define the PI point configuration for the interface, including specifically what data to transfer.

This document does not discuss the attributes that configure UniInt or PI Server processing for a PI point. Specifically, UniInt provides exception reporting and the PI Server provides data compression. Exception reporting and compression are very important aspects of data collection and archiving, which are not discussed in this document.

Note: See the UniInt Interface User Manual and PI Server documentation for information on other attributes that are significant to PI point data collection and archiving.

Tag

The Tag attribute (or tag name) is the name for a point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI documentation uses the terms “tag” and “point” interchangeably.

Follow these rules for naming PI points:

The name must be unique on the PI Server.

The first character must be alphanumeric, the underscore (_), or the percent sign (%).

Control characters such as linefeeds or tabs are illegal.

The following characters also are illegal: * ’ ? ; { } [ ] | \ ` ' "

LengthFor OSIsoft interfaces that are UniInt-based, the length of the Tag attribute field is limited by the version of the PI API and the version of the PI Server. However, the BaInfi90 interface is not UniInt-based. Therefore, this interface limits the length of tagnames to be 80 characters, independent of the version of the PI API or the version of the PI Server.

PI API PI Server Maximum Length1.6.0.2 or higher 3.4.370.x or higher 80

1.6.0.2 or higher Below 3.4.370.x 80

Below 1.6.0.2 3.4.370.x or higher 80


PI API PI Server Maximum LengthBelow 1.6.0.2 Below 3.4.370.x 80

PointSource

The PointSource attribute contains 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 parameter and the PointSource chapter.

PointType

The BaInfi90 interface supports the following PI Server point types:

Digital

Int16

Int32

Float16

Float32

Float64

However, the interface cannot store a negative number in an Int32 point type. So to store a negative value into a PI point, configure a Float-type point instead.

For more information about these point types, see the PI Server manuals.

Location1

Location1 is the CIU number or the interface ID number. This number does not correspond to any parameter on the Net90/Infi90 side, but it is often set equal to the node number of the CIU for easy identification.

This number must match the value of the /ciu# parameter specified in the command file.

Location2

Location2 is the Bailey PCU, that is, the node portion of the Bailey address for inputs.

For inputs with a CIU04, Location2 is 256 times the loop (i.e. ring) number plus the PCU number. For example, a loop number of 4 and PCU number of 29 indicates that a Location2 of 1053.

For output points, Location2 is the CIU index. Assign a unique CIU index for each output point. This index is used as the block number when configuring Bailey modules to read the output (the CIU module number would be 2 and PCU would be the CIU's node address).

For example, a PI tag named CR:T121 with index number 49 for the PI-connected CIU whose node address is 25 could be read from another node on Plant Loop with an analog input block (FC26) by:PCU-Module-Block = 25-2-49


Location3

For inputs, Location3 is the Bailey module portion of the Bailey address.

For outputs, Location3 should be 1.

Location4

For inputs, Location4 is the Bailey block portion of the Bailey address. For station blocks, use the block number of the station block for all parameters of that station. For example, the process variable, setpoint, mode, and control output would all have the same block number; however, they would have different Bailey point types (Location5).

For outputs, Location4 should be 1.

Location5

Location5 is the Bailey point type. Section Bailey Point Types describes these point types. For RCMs and device drivers, Location5 can be something other than the Bailey point type. See Bailey point type 15.

A Location5 value of 12, 13, or 22 (for CIU04) indicates that a PI point is an output point.

InstrumentTag

The BaInfi90 interface does not use the InstrumentTag attribute.

ExDesc

The BaInfi90 interface does not use the ExDesc (Extended Descriptor) attribute.

Scan

The BaInfi90 interface does not use the Scan attribute. You cannot remove a point from the interface by setting its Scan attribute to 0. This behavior is different from most OSIsoft interfaces.

Shutdown

The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of a power failure. For additional information on shutdown events, refer to PI Server manuals.

Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat=Shutdown command-line parameter is specified.


PI Point Configuration

SHUTDOWN events can be disabled from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, the default behavior of the PI Shutdown Subsystem can be changed to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Server manuals.

Bufserv and PIBufssIt is undesirable to write shutdown events when buffering is being used. Bufserv and PIBufss are utility programs that provide the capability to store and forward events to a PI Server, allowing continuous data collection when the PI Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when the PI Server is shutdown, Bufserv or PIBufss will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface. Disabling Shutdown is recommended when sending data to a Highly Available PI Server Collective. Refer to the Bufserv or PIBufss manuals for additional information.

Output Points

SourceTag

The source tag is the PI tag from which the output point gets the value to send to the Bailey Net90 / Infi90. For example, the source tag can be a performance equation calculation tag or a lab (manual input) tag.

When the source tag is not defined for an output point, the interface will get the output value from the output tag snapshot. In this case, the user is responsible for updating the value directly.

Bailey Point Types

Analog data from Bailey control system should be stored in the PI Server as a float type (e.g., Float16, Float32, or Float32) point. If the quality of the value is good, the floating point value from the CIU exception report is stored in the PI point. If the passed quality is bad, the digital code for BAD INPUT is stored for that tag.

If Bailey analog data is configured to be stored as a digital point in the PI Server, the CIU exception value is interpreted as the offset from the digital starting code of the point. Any value out of the range of the point's digital state set is stored as BAD INPUT.

The different types of Bailey points are further described below:

Process VariableN90 point type 1 This is the process variable of a control station block (function code 80, 21, 22 or 23). The block address should be that of the station block.

Setpoint ReadN90 point type 2 This is the setpoint of a control station block. See point type 1.

Control Output ReadN90 point type 3 This is the control output of a control station block. See point type 1.

Ratio Index ReadN90 point type 4 This is the ratio index of a ratio control station block. See point type 1.

Analog ReadN90 point type 5 This refers to an analog output block (function code 30) in the plant loop.

Station StatusN90 point type 6 Define a station status as a digital point in the PI Server. The status is returned as a 5 byte code from the CIU. The first byte is the process variable status and the last 3 bytes are zero. The second byte contains the station mode. This station mode is converted to a digital value of 0-5 for processing by the interface. The correlation between the mode byte and the PI digital value is:

if bit 7 is set then value = 5 (bypassed)else if bit 6 set then value = 4 (manual lock)else if bit 4 set then value = 3 (dig station failure)else if bit 1 set then value = 2 (cascade/ratio)else if bit 0 set then value = 1 (auto)else then value = 0 (manual)

In addition, there are two more modes for the station status: auto lock and cascade lock, corresponding to states 6 and 7. This addition is necessary for some sites because the lock bit and the auto bit are not mutually exclusive.

Set the PI digital point's digital state set to a digital state set that contains the following states:

Value Station Mode0 Manual

1 Auto

2 Cascade/Ratio

3 Dig Station Failure

4 Manual Lock

5 Bypassed

6 Auto Lock

7 Cascade Lock

Digital Read

N90 point type 7 These points should be defined as a digital point in the PI Server. The Bailey digital report is packed in a byte. After checking bit 7 for quality, the interface extracts bit 0 and puts it in the PI point. The first digital state of the PI point's digital state set determines what digital state string will show on the system.



Analog Report

N90 point type 12 This is one of the point types for writing from the PI Server to the Bailey Net90 / Infi90. Bailey analog values should be either Float or Int type points in the PI Server. Bailey real points are in the range -9.2E18 to 9.2E18.

If the PI point's value is a system digital state code (such as SHUTDOWN or OVER RANGE), the output is set to bad quality and the value 0 is sent to Bailey. If the PI point is defined as a digital point type, the interface sends the digital state offset as an analog value to Bailey.

Digital ReportN90 point type 13 This is another point type for writing from the PI System to Bailey. A digital output can be configured as Float, Int, or Digital point in the PI Server. A bad quality status is sent to Bailey when the snapshot value is a system digital state value. Also, for digital points, the interface sends a bad quality status if the snapshot value is out of the range of the point's digital state set.

For PI Float points, a status of 1 is sent to Bailey if the PI value is greater than 0. A status of 0 is sent for a value less than or equal to 0.

For PI Int points, the status byte is set equal to the integer value.

For PI Digital points, the status byte is set to the digital state offset.

Module StatusN90 point type 14 Define a module status as a digital point in the PI Server. Only the module mode (bits 7-6 of the first status byte) is saved by the interface. The four states of the Module status are:

ConfigureFailedErrorExecute

Set the PI digital point's digital state set to a digital state set that contains the following states:

Value Module Status0 Configure

1 Failed

2 Error

3 Execute

Set the block number (Location4) to 0 for this point type.

RCM ReadN90 point type 15 An RCM (function code 62), device driver (function code 123), or multi-state device driver block (function code 129) can be read in several ways. It is possible to save the output value, the alarm state, the set permissive bit, or an integer containing all of the bits in the first two status bytes of an RCM report. Use point type 15 to save all of the bits into a PI Server integer point. The first byte of the status is the high-order byte and the second byte is the low-order byte in the resulting integer value.

To read only the output value, set Location5 to 24. Define the PI point as type Digital or Int. The block output (bit 0 of status byte 1) is saved by the interface. The value is set to BAD INPUT if the quality is bad. When communicating with the CIU, the interface sets this point type to Bailey point type 15.

For the alarm state or the RCM set permissive bit, set Location5 to 25 or 26, respectively. These point types are also converted to point type 15 when the interface communicates with the CIU.

These pseudo-point types are used so that it is possible to have more than one PI tag for a single CIU index. The alarm state and set permissive bit points can be either PI Digital or Int.

The interface supports user-defined bitmap processing on RCM and device driver blocks. For the user bitmap points, the value of Location5 is 27XXXXX where XXXXX is the bitmap ranging from 1 to 32767. The interface masks the Net90/Infi90 status word with the user bitmap and puts the result into the PI point. See section User Defined Bit Mask for the meaning of the Bailey status word and example of the bit mask.

Note that the maximum value of the mask is 32767, which excludes the quality bit of the N90 status word, because with the quality bit set, the PI value is automatically set to BAD INPUT. Only one user bitmap PI point can be configured per RCM/DD block.

RMSC ReadN90 point type 19 The conversion is the same as for the other analog point types. RMSC is function code 68. Note that the CIU cannot be in monitor mode if the user wishes to read RMSC points. See section Troubleshooting for details.

4-byte Analog ReadN90 point type 21 This point type is supported by the CIU04 only. It is handled like other analog point types except that the precision is higher (about 7 significant digits) and the range is larger (-3.4E38 to 3.4E38).

4-byte Analog ReportN90 point type 22 This point type is supported by the CIU04 only. This is one of the point types for writing from the PI Server to the Bailey control system. Analog values should be either PI Float or Int points. The range is from -3.4E38 to 3.4E38. The output is set to bad quality if the PI value is a system digital state code (such as SHUTDOWN or OVER RANGE).

Bailey Database Conversion

The Bailey MCS and OIS Operator Console configuration contains much of the information needed for the PI Point database. The MCS or OIS can be configured from DBASE files on a personal computer. The same files can be used to create text files for use with PICONFIG or comma separated value (CSV) files for use with PI Tag Configurator.

Start by entering DBASE and creating a new database with several of the same fields as the MCSTAG.dbf or OISTAG.dbf file. The PI attributes listed below can be extracted.



Tag

The field name in the MCS or OIS database is TAGNAME. The MCS or OIS field is 14 characters long.

Descriptor

The field name in the MCS or OIS database is TAGDESC. The MCS or OIS field is 32 characters long.

EngUnits

The field name in the MCS or OIS database is EUDESC.

Zero

The field name in the MCS or OIS database is VAL0.

Span

The field name in the MCS or OIS database is SPAN.

Location2

For CIU04's, this is 256 times the MCS or OIS field LOOP (also known as ring) plus the MCS or OIS field PCU. For other CIU's, this is the field PCU.

Location3

This is the MCS or OIS field MOD.

Location4

This is the MCS or OIS field BLOCK.

Location5

The field name in the MCS or OIS database is TAGTYPE. The MCS or OIS field has string descriptions of the type (for example, ANALOG, RCM) rather than the number of the CIU point type. These can be converted with DBASE or a text editor.

Digital Points

The MCS or OIS database field ZEROSTATE refers to a string in the MCS or OIS state table. Before building a digital point, you need to create the appropriate digital state set that contains these strings.

Chapter 8. Startup Command File

Command-line parameters can begin with a / or with a -. For example, the /ps=M and -ps=M command-line parameters are equivalent.

For Windows, command file names have a .bat extension. The Windows continuation character (^) allows for the use of 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.

The PI Interface Configuration Utility (PI ICU) provides a tool for configuring the interface startup command file.

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 (i90.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 BaInfi90 interface.

From the PI ICU menu, select Interface, then NewWindows Interface Instance from EXE..., and then Browse to the i90.exe executable file. Then, enter values for Host PI System, Point Source, and Interface ID#. A window such as the following results:


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 Add.

The following message should appear:

Note that in this example the Host PI Server is Sydney. To configure the interface to communicate with a remote PI Server, select Connections…from the PI ICU Interface menu and select 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 bainfi90. If not, use the drop-down box to change the interface Type to be bainfi90.

Click on Apply to enable the PI ICU to manage this copy of the BaInfi90 interface.

The next step is to make selections in the interface-specific page (that is, “bainfi90”) that allows you to enter values for the startup parameters that are particular to the BaInfi90 interface.


To set up the interface as a Windows Service, use the Service page. This page allows configuration of the interface to run as a service as well as to starting and stopping of the interface service. The interface can also be run interactively from the PI ICU. To do that, select Start Interactive on the Interface menu.

For more detailed information on how to use the above-mentioned and other PI ICU pages and selections, please refer to the PI Interface Configuration Utility user guide. The next section describes the selections that are available from the bainfi90 page. 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.

bainfi90 Interface Page

Since the startup file of the BaInfi90 interface is maintained automatically by the PI ICU, use the bainfi90 page to configure the startup parameters and do 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.


Startup Command File

bainfi90 Page

The BaInfi90 interface ICU Control for PI ICU has one section. A yellow text box indicates that an invalid value has been entered or that a required value has not been entered.

Baud RateThe Baud Rate parameter specifies the data rate of the COM port. The only acceptable values are 1200, 2400, 4800, 9600, or 19200 bps. (/baudrate=#)

PortThe Port parameter specifies the COM port of the Windows computer for communications to the Bailey CIU. Use a value of 1 for COM1, a value of 2 for COM2, and so on. (/port=#)

CIU #The CIU# parameter is a user-specified positive number that corresponds to a point’s Location1 attribute. Each instance of the interface uses the Pointsource and CIU# parameters to identify uniquely its particular list of points to service. (/CIU#=#)

CIU Type #The CIUtype parameter specifies the CIU version number from 1 to 4, inclusive. (/CIUtype=#, Default: 3)

Debug LevelThe Debug Level parameter specifies the interface's debugging level, from 0 to 3, inclusive. When Debug Level is non-zero, the interface prints debugging messages. The higher the

debugging level, the more messages the interface prints. (/debuglevel=#, Default: 0, that is, no debugging)

# of exception calls before delayThis parameter specifies the number of exception calls before delay, from 1 to 100, inclusive. (/cnt=#, Default: 20)

Time to delay between callsThis parameter specifies the number of seconds to delay between calls, from 0.1 to 30, inclusive. (/delay=#, Default: 2)

Enable Output PointsSelect whether or not to enable Output Points. 1-Enable enables them, 0 – Disable disables them. (/outputflag=#, Default: 1)

Enable exception screeningCheck this box to enable CIU exception reporting screening. (/excepscreen=#, Default: 0, that is, disabled)

Synchronize Bailey time with interface node timeCheck this box to synchronize the Bailey time with the interface computer time. (/tsync=#, Default=0)

Failover

None, Primary, SecondarySelect whether or not the interface runs in a failover configuration: None (0), Primary interface (1) or Secondary interface (2). See section Principles of Operations chapter for more information. (/failover=#, Default=0)

Primary CIU Node/PCU NumberEnter the primary CIU node/PCU number. This parameter is required when the interface is running as the Secondary interface in a failover configuration. (/priCIU=#)

Watchdog CIU indexWhen two copies of the interface run in a failover configuration, they communicate with each other via a CIU index. This parameter specifies this watchdog CIU index. (/wdogidx=#, Default=1)

Additional ParametersThis section is provided for any additional parameters that the current ICU Control does not support.



Manual Maintenance of the Startup Command File

Note: The UniInt Interface User Manual includes details about other command-line parameters, which may be useful.

Manual Maintenance of the Startup Command File

OSIsoft strongly recommends that the user run the PI ICU to configure and maintain the interface's startup command file. However, it is possible to edit the command file that starts up the interface manually.

For proper operation, the interface requires various command-line parameters. These parameters begin with either the dash character (-) or the slash character (/). For example, the /ps=N and –ps=N command-line parameters are equivalent.

Put these parameters, along with the name of the interface executable file, into a start-up command file. For example,

i90.exe /ps=N /ciu#=1 /baudrate=9600 /ec=11 ...

Various file name extensions are associated with command files. For example, .bat and .cmd are both acceptable. However, only the .bat extension is valid for a command file used by the interface.

The name of the start-up command file must be the name of the interface executable file, with the .exe extension replaced with the .bat extension. Thus, the start-up command file for this interface is typically i90.bat. The installation program installs a sample command file named i90.bat_new. You can use this file as a template for the i90.bat that actually runs the interface.

The contents of an interface command file can contain the caret line continuation character (^). For example, an i90.bat file with these contents

i90.exe ^ /ps=N ^ /ciu#=1 ^ /baudrate=9600 ^ /ec=11

is equivalent to the above example.

The maximum length of each line in a command file is 1024 characters. The number of parameters is unlimited, and the maximum length of each parameter is 1024 characters.

Command-line Parameters

For a list of parameters that the interface uses, use the /h parameter. That is,C:> i90.exe /h

Parameter Description

/baudrate=#Required

Specifies the data rate of the COM port. The only acceptable values are 1200, 2400, 4800, 9600, or 19200 bps.

/CIU#=#Required

A positive number that corresponds to a point’s Location1 attribute. Each instance of the interface uses the /ps and /CIU# parameters to uniquely identify its particular list of points to service.

/CIUtype=#Optional

Specifies the CIU version number from 1 to 4, inclusive. The default value is 3.

/cnt=#Optional

Specifies the number of exception calls before delay, from 1 to 100, inclusive. The default value is 20.

/debuglevel=#Optional

Specifies the interface's debugging level, from 0 to 3, inclusive. When /debuglevel is non-zero, the interface prints debugging messages. The higher the debugging level, the more messages the interface prints. The default value is 0 (no debugging).

/delay=#Optional

Specifies the number of seconds to delay between calls, from 0.1 to 30, inclusive. The default value is 2.

/ec=#Optional

The first instance of the /ec parameter on the command-line is used to specify a counter number, #, for an I/O Rate point. If the # is not specified, then the default event counter is 1. If the /ec parameter is not specified, the interface uses a value equal to the /CIU# parameter.IIf there is an I/O Rate point that is associated with an event counter of 1, every interface that is running without /ec=# explicitly defined will write to the same I/O Rate point. Either explicitly define an event counter other than 1 for each instance of the interface or do 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 Point.

/excepscreen=#Optional

A value of 0 for this parameter disables CIU exception reporting screening. A value of 1 enables it. The default value is 0.

/failover=#Optional

Indicates whether the interface is running in a failover configuration: 0 – no failover; 1 – Primary interface; 2 – Secondary interface. See section Principles of Operations for more information. The default value is 0.

/host=host:portRequired

The /host parameter is used to specify the PI Home node. Host is the IP address of the PI Server node or the domain name of the PI Server node. Port is the port number for TCP/IP communication. The port is always 5450. 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.

Examples:

The interface is running on a interface node, the domain name of the PI 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

/outputflag=#Optional

A value of 0 for this parameter disables PI output points. A value of 1 enables it. The default value is 1.



Parameter Description

/port=#Required

Specifies the COM port of the Windows computer for communications to the Bailey CIU. Use a value of 1 for COM1, a value of 2 for COM2, and so on.

/priCIU=#Required when -failover=2

Indicates the primary CIU node/PCU number. This parameter is required when the interface is running as the Secondary interface in a failover configuration. If this parameter is 0, the /priCIU parameter has no effect.

/ps=xOptional

Indicates the point source character of the PI points that the interface services. Each instance of the interface uses the /ps and /CIU# parameters to uniquely identify its particular list of points to service. The default value is N.

/tsync=#Optional

A positive value for this parameter synchronizes the Bailey time with the interface computer time. A value of 0 indicates no time synchronization. The default value is 0.

/wdogidx=#Optional

When two copies of the interface run in a failover configuration, they communicate with each other through a CIU index. This parameter specifies this watchdog CIU index. The default value is 1. If this parameter is 0, it has no effect.

Sample i90.bat File

The following is an example file:REM==========================================================REMREM i90.batREMREM Sample startup file for the PI Interface for Bailey Infi90REMREM==========================================================REM REM OSIsoft strongly recommends using PI ICU to modify startup files.REMREM Sample command lineREM .\i90.exe -ps=N -ciu#=1 -host=XXXXXX:5450 -port=2 -baudrate=9600REMREM End of i90.bat File

The installation program installs a sample command file named i90.bat_new. You can use this file as a starting template to configure the i90.bat file.



Legacy Startup Command File

Versions 1.8 and earlier of the interface used a start-up command file that contains comma-separated parameters that are order dependent. See the following:rem Command file to start i90 interfaceremrem parameters to executable i90 are as follows:remrem debuglevel Set to 0 to suppress all interface messages rem to stdout. Set to either 1, 2, or 3 to see rem messages. The higher the number, the more rem information is output. In any case, severe rem messages are always written to the PI log rem file (wherever it is defined to be).remrem host The pi serverremrem CIU# The user-defined number indicating the CIU, rem also stored in location 1 of points in PI rem point database referring to the CIU that the rem interface is servicing.remrem Port Com port 1, 2, 3, or 4remrem Baudrate Either 1200, 2400, 4800, 9600, 19200remrem CIUType The version of the CIU, from 1 to 4, rem corresponding to CIU01, CIU02, CIU03, CIU04.rem Default is CIUSTARTVERSION (defined in rem ciuindex.h), currently 3.remrem Delay Number of seconds to delay between exceptionrem calls, from .1 to 30 seconds. Converted torem milliseconds in code. Default is 2 seconds.rem Cnt Maximum number of exception calls beforerem delay, from 1 to 100. Default is 20.remrem Tsync Time synchronization facility, either 0 or 1rem Default is 0 (no synchronization).remrem PS Point source in PI database for all pointsrem covered by the particular CIU#.rem Default is N.remrem EC Event Counter number (number you specify in rem the iorates.dat file)remrem The following parameters are supported in interfacerem version 1.6 and aboveremrem Outputflag Flag indicating whether to enable output:rem 0 to disable output; 1 to enable.rem Default is 1 (enable).remrem ExcepScreen CIU Exception Report screening: 1 to enable, rem 0 to disable. Default is 0 (disable).remrem Failover Failover Mode: 0 for no failover, 1 forrem primary interface, 2 for secondary interface.rem Default is 0 (no failover).

remrem PriCIU Primary CIU node/PCU number. Required for rem secondary interface.remrem Wdogidx CIU index for watchdog output signal inrem primary CIU. If the wdogidx is not supplied,rem index 1 is used.remrem The following line starts i90 with debug level 3,rem PIServer named cloudberry, CIU Index 1, com port 1,rem baudrate 19200, CIUType 4, pointsource I, eventrem counter number 2, secondary node, Primary CIU indexrem 20, watchdox index 1.rem All other parameter values are the default. This isrem indicated by a non-argument in the appropriate position ofrem of the parameter list. Use no spaces betweenrem parameters (except of course between name ofrem executable and the parameters list). Delimitrem parameters with commas. remrem Sample startup command line belowi90.exe 3,cloudberry,1,1,19200,4,,,,I,2,,,2,20,1

For backwards compatibility, the interface still supports the above start-up command syntax.


Chapter 9. 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 Automatically adjust clock for daylight saving changes box. For example,

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 Variables button under the Advanced tab, and remove TZ from the list of environment variables.


Chapter 10. Security

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 “Managing Security” of the PI 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 Server, it writes a -999 error. See the section Appendix A: Error and Info r mational Messages for additional information on error messaging.

PI Server v3.3 and Higher

Security configuration using piconfigFor 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,PIUsera_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 EditorThe 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.2For 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,proxyaccountpiapimachine,piadmin@quit

In place of piapimachine, put the name of the interface node as it is seen by the PI Server.


Chapter 11. Starting / Stopping the Interface

This section describes starting and stopping the interface once it has been installed as a service. See the UniInt Interface User Manual to run the interface interactively.

Starting Interface as a Service

If the interface was installed as service, it can be started from PI ICU, the Services control panel or with the command:i90.exe /start

To start the interface service with PI ICU, use the button on the PI ICU toolbar.

A message will inform the user of the status of the interface service. Even if the message indicates that the service has started successfully, double check through the Services control panel applet. Services may terminate immediately after startup for a variety of reasons, and one typical reason is that the service is not able to find the command-line parameters in the associated .bat file. Verify that the root name of the .bat file and the .exe file are the same, and that the .bat file and the .exe file are in the same directory. Further troubleshooting of services might require consulting the pipc.log file, Windows Event Viewer, or other sources of log messages. See the section Appendix A: Error and Informational Messages for additional information.

Stopping Interface Running as a Service

If the interface was installed as service, it can be stopped at any time from PI ICU, the Services control panel or with the command:i90.exe /stop

The service can be removed by:i90.exe /remove

To stop the interface service with PI ICU, use the button on the PI ICU toolbar.


Chapter 12. Buffering

Buffering refers to an interface node’s ability to temporarily store the data that interfaces collect and to forward these data to the appropriate PI Servers. OSIsoft strongly recommends that you enable buffering on your interface nodes. Otherwise, if the interface node stops communicating with the PI Server, you lose the data that your interfaces collect.

The PI SDK installation kit installs two buffering applications: the PI Buffer Subsystem (PIBufss) and the PI API Buffer Server (Bufserv). PIBufss and Bufserv are mutually exclusive; that is, on a particular computer, you can run only one of them at any given time.

If you have PI Servers that are part of a PI collective, PIBufss supports n-way buffering. N-way buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI collective. (Bufserv also supports n-way buffering, but OSIsoft recommends that you run PIBufss instead.)

Which Buffering Application to Use

You should use PIBufss whenever possible because it offers better throughput than Bufserv. In addition, if the interfaces on an interface node are sending data to a PI collective, PIBufss guarantees identical data in the archive records of all the PI Servers that are part of that collective.

You can use PIBufss only under the following conditions:

the PI Server version is at least 3.4.375.x; and

all of the interfaces running on the interface node send data to the same PI Server or to the same PI collective.

If any of the following scenarios apply, you must use Bufserv:

the PI Server version is earlier than 3.4.375.x; or

the interface node runs multiple interfaces, and these interfaces send data to multiple PI Servers that are not part of a single PI collective.

If an interface node runs multiple interfaces, and these interfaces send data to two or more PI collectives, then neither PIBufss nor Bufserv is appropriate. The reason is that PIBufss and Bufserv can buffer data only to a single collective. If you need to buffer to more than one PI collective, you need to use two or more interface nodes to run your interfaces.

It is technically possible to run Bufserv on the PI Server Node. However, OSIsoft does not recommend this configuration.


How Buffering Works

A complete technical description of PIBufss and Bufserv is beyond the scope of this document. However, the following paragraphs provide some insights on how buffering works.

When an interface node has buffering enabled, the buffering application (PIBufss or Bufserv) connects to the PI Server. It also creates shared memory storage.

When an interface program makes a PI API function call that writes data to the PI Server (for example, pisn_sendexceptionqx()), the PI API checks whether buffering is enabled. If it is, these data writing functions do not send the interface data to the PI Server. Instead, they write the data to the shared memory storage that the buffering application created.

The buffering application (either Bufserv or PIBufss) in turn

reads the data in shared memory, and

if a connection to the PI Server exists, sends the data to the PI Server; or

if there is no connection to the PI Server, continues to store the data in shared memory (if shared memory storage is available) or writes the data to disk (if shared memory storage is full).

When the buffering application re-establishes connection to the PI Server, it writes to the PI Server the interface data contained in both shared memory storage and disk.

(Before sending data to the PI Server, PIBufss performs further tasks such as data validation and data compression, but the description of these tasks is beyond the scope of this document.)

When PIBufss writes interface data to disk, it writes to multiple files. The names of these buffering files are PIBUFQ_*.DAT.

When Bufserv writes interface data to disk, it writes to a single file. The name of its buffering file is APIBUF.DAT.

As a previous paragraph indicates, PIBufss and Bufserv create shared memory storage at startup. These memory buffers must be large enough to accommodate the data that an interface collects during a single scan. Otherwise, the interface may fail to write all its collected data to the memory buffers, resulting in data loss. The buffering configuration section of this chapter provides guidelines for sizing these memory buffers.

When buffering is enabled, it affects the entire interface node. That is, you do not have a scenario whereby the buffering application buffers data for one interface running on an interface node but not for another interface running on the same interface node.

Buffering and PI Server Security

After you enable buffering, it is the buffering application – and not the interface program – that writes data to the PI Server. If the PI Server’s trust table contains a trust entry that allows all applications on an interface node to write data, then the buffering application is able write data to the PI Server.

However, if the PI Server contains an interface-specific PI Trust entry that allows a particular interface program to write data, you must have a PI Trust entry specific to buffering. The following are the appropriate entries for the Application Name field of a PI Trust entry:


Buffering Application Application Name field for PI TrustPI Buffer Subsystem PIBufss.exe

PI API Buffer Server APIBE (if the PI API is using 4 character process names)APIBUF (if the PI API is using 8 character process names)

To use a process name greater than 4 characters in length for a trust application name, use the LONGAPPNAME=1 in the PIClient.ini file.

Enabling Buffering on an Interface Node with the ICU

The ICU allows you to select either PIBufss or Bufserv as the buffering application for your interface node. Run the ICU and select Tools > Buffering.

Choose Buffer Type

To select PIBufss as the buffering application, choose Enable buffering with PI Buffer Subsystem.

To select Bufserv as the buffering application, choose Enable buffering with API Buffer Server.

If a warning message such as the following appears, click Yes.


Buffering

Buffering Settings

There are a number of settings that affect the operation of PIBufss and Bufserv. The Buffering Settings section allows you to set these parameters. If you do not enter values for these parameters, PIBufss and Bufserv use default values.

PIBufssFor PIBufss, the paragraphs below describe the settings that may require user intervention. Please contact OSIsoft Technical Support for assistance in further optimizing these and all remaining settings.

Primary and Secondary Memory Buffer Size (Bytes)This is a key parameter for buffering performance. The sum of these two memory buffer sizes must be large enough to accommodate the data that an interface collects during a single scan. A typical event with a Float32 point type requires about 25 bytes. If an interface writes data to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a result, the size of each memory buffer should be 62,500 bytes.

The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these two memory buffer sizes should be increased to the maximum of 2000000 for the best buffering performance.

Send rate (milliseconds)Send rate is the time in milliseconds that PIBufss waits between sending up to the Maximum transfer objects (described below) to the PI Server. The default value is 100. The valid range is 0 to 2,000,000.

Maximum transfer objectsMaximum transfer objects is the maximum number of events that PIBufss sends between each Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.

Event Queue File Size (Mbytes)This is the size of the event queue files. PIBufss stores the buffered data to these files. The default value is 32. The range is 8 to 131072 (8 to 128 Gbytes). Please see the section entitled "Queue File Sizing" in the PIBufss.chm file for details on how to appropriately size the event queue files.

Event Queue PathThis is the location of the event queue file. The default value is [PIHOME]\DAT.

For optimal performance and reliability, OSIsoft recommends that you place the PIBufss event queue files on a different drive/controller from the system drive and the drive with the Windows paging file. (By default, these two drives are the same.)

BufservFor Bufserv, the paragraphs below describe the settings that may require user intervention. Please contact OSIsoft Technical Support for assistance in further optimizing these and all remaining settings.

Maximum buffer file size (KB)This is the maximum size of the buffer file ([PIHOME]\DAT\APIBUF.DAT). When Bufserv cannot communicate with the PI Server, it writes and appends data to this file. When the buffer file reaches this maximum size, Bufserv discards data.

The default value is 2,000,000 KB, which is about 2 GB. The range is from 1 to 2,000,000.


Buffering

Primary and Secondary Memory Buffer Size (Bytes)This is a key parameter for buffering performance. The sum of these two memory buffer sizes must be large enough to accommodate the data that an interface collects during a single scan. A typical event with a Float32 point type requires about 25 bytes. If an interface writes data to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a result, the size of each memory buffer should be 62,500 bytes.

The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these two memory buffer sizes should be increased to the maximum of 2000000 for the best buffering performance.

Send rate (milliseconds)Send rate is the time in milliseconds that Bufserv waits between sending up to the Maximum transfer objects (described below) to the PI Server. The default value is 100. The valid range is 0 to 2,000,000.

Maximum transfer objectsMax transfer objects is the maximum number of events that Bufserv sends between each Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.

Buffered Servers

The Buffered Servers section allows you to define the PI Servers or PI collective that the buffering application writes data.

PIBufssPIBufss buffers data only to a single PI Server or a PI collective. Select the PI Server or the PI collective from the Buffering to collective/server drop down list box.

The following screen shows that PIBufss is configured to write data to a standalone PI Server named starlight. Notice that the Replicate data to all collective member nodes check box is disabled because this PI Server is not part of a collective. (PIBufss automatically detects whether a PI Server is part of a collective.)

The following screen shows that PIBufss is configured to write data to a PI collective named admiral. By default, PIBufss replicates data to all collective members. That is, it provides n-way buffering.

You can override this option by not checking the Replicate data to all collective member nodes check box. Then, uncheck (or check) the PI Server collective members as desired.


Buffering

BufservBufserv buffers data to a standalone PI Server, or to multiple standalone PI Servers. (If you want to buffer to multiple PI Servers that are part of a PI collective, you should use PIBufss.)

If the PI Server to which you want Bufserv to buffer data is not in the Server list, enter its name in the Add a server box and click the Add Server button. This PI Server name must be identical to the API Hostname entry:

The following screen shows that Bufserv is configured to write to a standalone PI Server named etamp390. You use this configuration when all the interfaces on the interface node write data to etamp390.

The following screen shows that Bufserv is configured to write to two standalone PI Servers, one named etamp390 and the other one named starlight. You use this configuration when some of the interfaces on the interface node write data to etamp390 and some write to starlight.

Installing Buffering as a Service

Both the PIBufss and Bufserv applications run as a Service.

PI Buffer Subsystem ServiceUse the PI Buffer Subsystem Service page to configure PIBufss as a Service. This page also allows you to start and stop the PIBufss service.

PIBufss does not require the logon rights of the local administrator account. It is sufficient to use the LocalSystem account instead. Although the screen below shows asterisks for the LocalSystem password, this account does not have a password.


Buffering

API Buffer Server ServiceUse the API Buffer Server Service page to configure Bufserv as a Service. This page also allows you to start and stop the Bufserv Service

Bufserv version 1.6 and later does not require the logon rights of the local administrator account. It is sufficient to use the LocalSystem account instead. Although the screen below shows asterisks for the LocalSystem password, this account does not have a password.

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.

Configure buffering through entries in the piclient.ini file. The file is found in the dat subdirectory of the PIHOME directory (typically c:\program files\pipc\dat). This file follows the conventions of Microsoft Windows initialization files with sections, keywords within sections, and values for keywords. Enter all buffering settings in a section called [APIBUFFER]. To modify settings, edit the piclient.ini file in a text editor, such as Notepad.

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)


Buffering

Keywords Values Default DescriptionRETRYRATE 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, you can use the [PISERVER] to define the default PI server and an optional time offset change that may occur between the client and server.

Keywords Values Default Description

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

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”.

A piclient.ini file might look like:[APIBUFFER]BUFFERING=1MAXFILESIZE=100000; The PI API connection routines have a 1 minute default timeout.RETRYRATE=600

Chapter 13. Interface Diagnostics Configuration

The PI Point Configuration chapter provides information on building PI points for collecting data from the device. This chapter describes the configuration of points related to interface diagnostics.

Note: The procedure for configuring interface diagnostics is not specific to this interface. Thus, for simplicity, the instructions and screenshots that follow refer to an interface named ModbusE.

Some of the points that follow refer to a “performance summary interval”. This interval is 8 hours by default. You can change this parameter via the Scan performance summary box in the UniInt – Debug parameter category page:

Scan Class Performance Points

This interface does not support Performance Points.


I/O Rate Point

An I/O Rate point measures the rate at which the interface writes data to its input tags. 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.

When the interface starts, it writes 0 to the I/O Rate point. After running for ten minutes, the interface writes the I/O Rate value. The interface continues to write a value every 10 minutes. When the interface stops, it writes 0.

The ICU allows you to create one I/O Rate point for each copy of this interface. Select this interface from the Interface drop-down list, click IO Rate in the parameter category pane, and check Enable IORates for this interface.

As the preceding picture shows, the ICU suggests an Event Counter number and a Tagname for the I/O Rate Point. Click the Save button to save the settings and create the I/O Rate point. Click the Apply button to apply the changes to this copy of the interface.

You need to restart the interface in order for it to write a value to the newly created I/O Rate point. Restart the interface by clicking the Restart button:

(The reason you need to restart the interface is that the PointSource attribute of an I/O Rate point is Lab.)

To confirm that the interface recognizes the I/O Rate Point, look in the pipc.log for a message such as:PI-ModBus 1> IORATE: tag sy.io.etamp390.ModbusE1 configured.

To see the I/O Rate point’s current value (snapshot), click the Refresh snapshot button:


Enable IORates for this InterfaceThe Enable IORates for this interface check box enables or disables I/O Rates for the current interface. To disable I/O Rates for the selected interface, uncheck this box. To enable I/O Rates for the selected interface, check this box.

Event CounterThe 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.

TagnameThe tag name listed in the Tagname box is the name of the I/O Rate tag.

Tag StatusThe Tag Status box indicates whether the I/O Rate 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 PI ICU is not able to access the PI Server

In FileThe In File box indicates whether the I/O Rate 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

SnapshotThe Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists in PI. The Snapshot box is updated when the IORate page is selected, and when the interface is first loaded.


Interface Diagnostics Configuration

Create/SaveCreate the suggested I/O Rate tag with the tag name indicated in the Tagname box. Or Save any changes for the tag name indicated in the Tagname box.

DeleteDelete the I/O Rate tag listed in the Tagname box.

RenameAllow the user to specify a new name for the I/O Rate tag listed in the Tagname box.

Add to FileAdd the tag to the IORates.dat file with the event counter listed in the Event Counter box.

SearchAllow the user to search the PI Server for a previously defined I/O Rate tag.

Interface Status Point

The PI Interface Status Utility (ISU) alerts you when an interface is not currently writing data to the PI Server. This situation commonly occurs if

the monitored interface is running on an interface node, but the interface node cannot communicate with the PI Server; or

the monitored interface is not running, but it failed to write at shutdown a system state such as Intf Shut.

The ISU works by periodically looking at the timestamp of a Watchdog Tag. The Watchdog Tag is a tag whose value a monitored interface (such as this interface) frequently updates. The Watchdog Tag has its ExcDev, ExcMin, and ExcMax point attributes set to 0. So, a non-changing timestamp for the Watchdog Tag indicates that the monitored interface is not writing data.

Please see the Interface Status Utility Interface for complete information on using the ISU. PI Interface Status Utility Interface runs only on a PI Server Node.

If you have used the ICU to configure the PI Interface Status Utility Interface on the PI Server Node, the ICU allows you to create the appropriate ISU point. Select this interface from the Interface drop-down list and click Interface Status in the parameter category pane. Right-click on the ISU tag definition window to open the shortcut menu:

Click Create to create the ISU tag.

Use the Tag Search button to select a Watchdog Tag. (Recall that the Watchdog Tag is one of the points for which this interface collects data.)

Select a Scan frequency from the drop-down list box. This Scan frequency is the interval at which the ISU monitors the Watchdog Tag. For optimal performance, choose a Scan frequency that is less frequent than the majority of the scan rates for this interface’s points. For example, if this interface scans most of its points every 30 seconds, choose a Scan frequency of 60 seconds. If this interface scans most of its points every second, choose a Scan frequency of 10 seconds.

If the Tag Status indicates that the ISU tag is Incorrect, right-click to open the shortcut menu and select Correct.

Note: The PI Interface Status Utility Interface – and not this interface – is responsible for updating the ISU tag. So, make sure that the PI Interface Status Utility Interface is running correctly.

Monitoring I/O Rates on the Interface Node

Because an I/O Rate point is a PI point, you can run standard PI client applications to monitor its value. For example, you can use PI ProcessBook to build and view a trend that displays the most recent 8-hour values for an I/O Rate point.


Appendix A. Error and Informational Messages

A string CIU #ID> is pre-pended to error messages written to the message log. Name is a non-configurable identifier that is no longer than 9 characters. ID is a configurable identifier that is no longer than 9 characters and is specified using 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 Interface User Manual 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 loads points, messages are sent to the log if there are any problems with the configuration of the points.

System Errors and PI Errors

System errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers.

Descriptions of system and PI errors can be obtained with the pidiag utility:\PI\adm\pidiag /e error_number


Appendix B. PI SDK Options

To access the PI SDK settings for this interface, select this interface from the Interface drop-down list and click UniInt – PI SDK in the parameter category pane.

Disable PI SDKSelect Disable PI SDK to tell the interface not to use the PI SDK. If you want to run the interface in disconnected startup mode, you must choose this option.

The command line equivalent for this option is /pisdk=0.

Use the Interface’s default settingThis selection has no effect on whether the interface uses the PI SDK. However, you must not choose this option if you want to run the interface in disconnected startup mode.

Enable PI SDKSelect Enable PI SDK to tell the interface to use the PI SDK. Choose this option if the PI Server version is earlier than 3.4.370.x or the PI API is earlier than 1.6.0.2, and you want to use extended lengths for the Tag, Descriptor, ExDesc, InstrumentTag, or PointSource point attributes. The maximum lengths for these attributes are:

Attribute Enable the Interface to use the PI SDK

PI Server earlier than 3.4.370.x or PI API earlier than 1.6.0.2, without the use of the PI SDK

Tag 1023 255

Descriptor 1023 26

ExDesc 1023 80

InstrumentTag 1023 32

PointSource 1023 1

However, if you want to run the interface in disconnected startup mode, you must not choose this option.

The command line equivalent for this option is /pisdk=1.


Appendix C. Troubleshooting

The interface normally starts as Windows service. It writes informational and error messages to the PIPC.LOG file. So, it is important to look at this file to troubleshoot the interface.

Hardware Configuration

When you install the CIU/ICI module, you need to cut the dipshunt in a specific manner in the termination unit of the CIU. In addition, set the dipswitch of U72 and U73 on the CIU module. The dipswitch setting determines the many options on running the CIU. Refer to the hardware manual of the CIU for information about how to set the dipswitch and the dipshunt.

The Bailey Engineering WorkStation (EWS) hardware manual provides a recommended dipshunt/dipswitch configuration for the CIU module. OSIsoft suggests that the BaInfi90 interface use this same configuration.

The serial cable connecting the interface computer and the CIU/ICI is wired straight through on pins 1- 8 and 20. The best way to test the termination hardware, CIU/ICI module setup, and cable configuration of the CIU is to try using the EWS to substitute for the interface computer. If all hardware settings appear correct and connection problems still exist, try switching pins 2 and 3 in the cable by using a null modem connector.

Communication Problems

Most of the BaInfi90 interface start-up problems are related to the communication between the interface computer and the CIU module. The start-up problem is normally indicated by the error message “Restart err: timeout” in the log file. The best way to test the termination hardware, module setup, and cable configuration of the CIU is to try using the EWS to substitute for the interface computer.

After the interface restarts the CIU, the hardware configuration is proven to be correct. However, the interface may still encounter another type of communication error. Occasionally, the log file may indicate the following error messages:

checksum error,

0 byte read,

framing error,

These errors are typically caused by noise in the serial line or by an improperly grounded termination unit.

If there is a terminal server between the CIU and the interface machine, disable the XON/XOFF flow control in the terminal server port. Disabling the XON/XOFF is necessary because the CIU protocol is binary and the data may contain binary code 19 (which is the ASCII code for XOFF), locking up the terminal server port. Also set the port data rate to match the CIU module data rate and the data rate specified in the command file


The interface sometimes functions properly during the point establishment phase but fails to read exceptions. This type of problem normally occurs in a heavily loaded terminal server. Since the read exception call can return up to 1600 bytes of data, the CIU can overrun the terminal server buffer, causing a read error for the interface. You may need to increase the type ahead of the buffer or use hardware flow control on the interface port on the terminal server. The best solution for a particular system depends on the type of terminal server used.

Bailey Loop Problems

For early versions of the CIU04, when the interface tries to disestablish the CIU index of a station block, the CIU module will be hung up (stay in error state with red light in front of the module). The interface then cannot communicate to the CIU module and reports timeout error messages to the log file. The PI points will stop getting new snapshot values. This problem would only occur if more than one PI point are configured to read attributes from a station point, that is, one reading PV and one reading the mode, and one of these PI points is modified. This is a CIU problem that only occurs for CIU04 with firmware version earlier than E0. Thus, if the CIU04 module firmware version is earlier than E0, contact ABB / Bailey to obtain an upgrade.

Another commonly reported problem is that PI points have a Bad Input status and are not getting updated, that is, the snapshot timestamp does not change. This problem may be caused by one of the following scenarios:

If the PI point is newly created and the interface has no problem establishing the point on the CIU module, then most likely the point has the wrong Bailey address. The CIU module does not verify that there is an actual exception source of the same point type during point establishment, and therefore, the point could be established on the CIU but will receive no exception report in the future. Ensure that each PI point has the correct Bailey address.

If the PI point has been collecting data but suddenly gets Bad Input and then no more events, the problem is most likely caused by an upset in the Bailey loop communication. For older versions of the Bailey loop communication module, the module does not re-establish the exception report routes after an upset, especially for routes across a network bridge. The CIU module has to re-establish the point in order for the PCU to resume sending exception report. You can force the CIU to re-establish the point either by restarting the interface or by changing one of the non-essential attributes, that is, typical value, on the problematic PI point.

PI Configuration Problems

If a PI point for the BaInfi90 interface is not configured correctly, the CIU module will not establish the point and the interface will write the reason for the failure to the log file. The PI point's snapshot value will remain at the same value and time stamp as before the interface startup. Typical errors are:

“Block already established as another point”: The system is trying to read the same attribute for the same Bailey block with more than one PI point. The easiest way to find the other PI points reading the same Bailey block is through the PICONFIG utility. Set up a PICONFIG file to look for all tags with the same Location1, Location2, Location 3, Location4, and PointSource attributes.


“Number out of range”: Most likely, one of the address parameters is out of legal range. For example, the module number cannot be less than 2 for all point type except the module status points.

“Monitor mode conflict”: This is primarily for point type 19, RMSC block. The CIU cannot be in Monitor Mode when you want to read RMSC block. The CIU monitor mode can be turned off only with the Talk90 utility through the diagnostic port of the CIU.

“Unsupported N90 point type”: The specified point type (location 5) is not supported by the interface.

Occasionally, a configuration error may prevent a point from being established on the CIU. For example, if an input block is configured in a Bailey PCU to read from the CIU at an index number, this index number is then reserved for output in the CIU. The interface cannot establish any input point on that index. Accordingly, the interface reports this index when the CIU replies "index already established by another PCU". Furthermore, the interface marks this index number as unusable so that future addition of a point will not have the same problem. You can search all Bailey PCUs for an input block reading that CIU index number. The appropriate output point should then be created on the PI Server to send an output to the PCU.


Appendix D. User-defined Bit Mask for MSDD, DD and RCM Points

For the MSDD (multiple state device driver block, FC 129), DD (device driver block, FC 123) and the RCM (Remote Control Memory, FC 62) blocks, exception reports consist of a two-byte status word. The information contained in these status words are shown in the following tables:

Multi-state Device Driver Exception

Name Description Bit Decimal Value

Q Quality 15 32768

ALM Alarm 14 16384

SO Status Override 13 8192

CO Control Override 11 2048

M Auto/Manual Mode 10 1024

TAG Block is Tagged 9 512

V Control Output 8 256

F1 Feedback State 1 7 128




GS Good State (two bits) 2&3 12 (4+8)

RS Requested State (two bits) 0&1 3 (1+2)

Device Driver Exception


Q Quality 15 32768

ALM Alarm 14 16384


V Control Output 8 256



FS Feedback status quality 3 8

SO Override 2 4

Mode Auto/Manual Mode (two bits) 0&1 3 (1+2)


Remote Switch (RCM) Exception


Q Quality 15 32768

ALM Alarm 14 16384


OV Output Value 8 256

SI Logic Set 6 64

SP Set Permissive 5 32

RI Logic Reset 4 16

OR Override 3 8

FB Feedback 2 4

SC Set Command 1 2

RC Reset Command 0 1

Example MSDD to PI Tag State Translation

To get the entire status word for the Bailey block, define the PI tag with Location5 set to 15.

To get selected bits of the status word, use the bit mask option by setting Location5 to 27XXXXX where XXXXX is the sum of the decimal value corresponding to all the bits of interest.

For example, Location5 is 2700176 for a PI point to store feedback state 1, 3 and 4 of a MSDD, i.e. bit mask 176 = 128 + 32 + 16. The result of this tag is an eight state variable. The meaning of the states is given in the following table.

State Meaning

0 All three FB states are 0

1 F4 on, F3 and F1 off


3 F3 and F4 on, F1 off




7 All three FB states are on.

Note that the interface compresses the bits selected by the bit mask to produce the final PI value. The compacting is done in the order of the bit position. In this example, bit 4 (FB4) get shifted to bit 0 of the final value; bit 5 (FB3) is shifted to bit 1; bit 7 (FB1) is shifted to bit 2 of the final value.

If the PI point to hold the above values is to be a Digital point, you need to create a digital state set with 8 states. Then, specify this digital state set as the state set for the digital point.


Appendix E. Terminology

To understand this interface manual, you should be familiar with the terminology used in this document.

BufferingBuffering refers to an interface node’s ability to store temporarily the data that interfaces collect and to forward these data to the appropriate PI Servers.

N-Way BufferingIf you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering. N-way buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI Collective. (Bufserv also supports n-way buffering to multiple PI Servers however it does not guarantee identical archive records since point compressions attributes could be different between PI Servers. With this in mind, OSIsoft recommends that you run PIBufss instead.)

ICUICU refers to the PI Interface Configuration Utility. The ICU is the primary application that you use to configure PI interface programs. You must install the ICU on the same computer on which an interface runs. A single copy of the ICU manages all of the interfaces on a particular computer.

You can configure an interface by editing a startup command file. However, OSIsoft discourages this approach. Instead, OSIsoft strongly recommends that you use the ICU for interface management tasks.

ICU ControlAn ICU Control is a plug-in to the ICU. Whereas the ICU handles functionality common to all interfaces, an ICU Control implements interface-specific behavior. Most PI interfaces have an associated ICU Control.

Interface NodeAn interface node is a computer on which

the PI API and/or PI SDK are installed, and

PI Server programs are not installed.

PI APIThe PI API is a library of functions that allow applications to communicate and exchange data with the PI Server. All PI interfaces use the PI API.


PI CollectiveA PI Collective is two or more replicated PI Servers that collect data concurrently. Collectives are part of the High Availability environment. When the primary PI Server in a collective becomes unavailable, a secondary collective member node seamlessly continues to collect and provide data access to your PI clients.

PIHOMEPIHOME refers to the directory that is the common location for PI 32-bit client applications.

A typical PIHOME on a 32-bit operating system is C:\Program Files\PIPC.

A typical PIHOME on a 64-bit operating system is C:\Program Files (x86)\PIPC.

PI 32-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME.

For example, files for the 32-bit Modbus Ethernet Interface are in

[PIHOME]\PIPC\Interfaces\ModbusE.

This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory path. For example, ICU files in [PIHOME]\ICU.

PIHOME64PIHOME64 is found only on a 64-bit operating system and refers to the directory that is the common location for PI 64-bit client applications.

A typical PIHOME64 is C:\Program Files\PIPC.

PI 64-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME64.

For example, files for a 64-bit Modbus Ethernet Interface would be found in

C:\Program Files\PIPC\Interfaces\ModbusE.

This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory path. For example, ICU files in [PIHOME]\ICU.

PI Message LogThe PI message log is the file to which OSIsoft interfaces based on UniInt 4.5.0.x and later write informational, debug and error messages. When a PI interface runs, it writes to the local PI message log. This message file can only be viewed using the PIGetMsg utility. See the UniInt Interface Message Logging.docx file for more information on how to access these messages.

PI SDKThe PI SDK is a library of functions that allow applications to communicate and exchange data with the PI Server. Some PI interfaces, in addition to using the PI API, require the use of the PI SDK.

PI Server NodeA PI Server Node is a computer on which PI Server programs are installed. The PI Server runs on the PI Server Node.


PI SMTPI SMT refers to PI System Management Tools. PI SMT is the program that you use for configuring PI Servers. A single copy of PI SMT manages multiple PI Servers. PI SMT runs on either a PI Server Node or a interface node.

Pipc.logThe pipc.log file is the file to which OSIsoft applications write informational and error messages. When a PI interface runs, it writes to the pipc.log file. The ICU allows easy access to the pipc.log.

PointThe PI point is the basic building block for controlling data flow to and from the PI Server. For a given timestamp, a PI point holds a single value.

A PI point does not necessarily correspond to a “point” on the foreign device. For example, a single “point” on the foreign device can consist of a set point, a process value, an alarm limit, and a discrete value. These four pieces of information require four separate PI points.

ServiceA Service is a Windows program that runs without user interaction. A Service continues to run after you have logged off from Windows. It has the ability to start up when the computer itself starts up.

The ICU allows you to configure a PI interface to run as a Service.

Tag (Input Tag and Output Tag)The tag attribute of a PI point is the name of the PI point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI System documentation uses the terms “tag” and “point” interchangeably.

Interfaces read values from a device and write these values to an Input Tag. Interfaces use an Output Tag to write a value to the device.


Appendix F. Technical Support and Resources

You can read complete information about technical support options, and access all of the following resources at the OSIsoft Technical Support Web site:

http://techsupport.osisoft.com (http://techsupport.osisoft.com)

Before You Call or Write for Help

When you contact OSIsoft Technical Support, please provide:

Product name, version, and/or build numbers

Computer platform (CPU type, operating system, and version number)

The time that the difficulty started

The log file(s) at that time

Help Desk and Telephone Support

You can contact OSIsoft Technical Support 24 hours a day. Use the numbers in the table below to find the most appropriate number for your area. Dialing any of these numbers will route your call into our global support queue to be answered by engineers stationed around the world.

Office Location Access Number Local Language OptionsSan Leandro, CA, USA 1 510 297 5828 English

Philadelphia, PA, USA 1 215 606 0705 English

Johnson City, TN, USA 1 423 610 3800 English

Montreal, QC, Canada 1 514 493 0663 English, French

Sao Paulo, Brazil 55 11 3053 5040 English, Portuguese

Frankfurt, Germany 49 6047 989 333 English, German

Manama, Bahrain 973 1758 4429 English, Arabic

Singapore 65 6391 181186 021 2327 8686

English, MandarinMandarin

Perth, WA, Australia 61 8 9282 9220 English


http://techsupport.osisoft.com/

Support may be provided in languages other than English in certain centers (listed above) based on availability of attendants. If you select a local language option, we will make best efforts to connect you with an available Technical Support Engineer (TSE) with that language skill. If no local language TSE is available to assist you, you will be routed to the first available attendant.

If all available TSEs are busy assisting other customers when you call, you will be prompted to remain on the line to wait for the next available TSE or else leave a voicemail message. If you choose to leave a message, you will not lose your place in the queue. Your voicemail will be treated as a regular phone call and will be directed to the first TSE who becomes available.

If you are calling about an ongoing case, be sure to reference your case number when you call so we can connect you to the engineer currently assigned to your case. If that engineer is not available, another engineer will attempt to assist you.

Search Support

From the OSIsoft Technical Support Web site, click Search Support.

Quickly and easily search the OSIsoft Technical Support Web site’s Support Solutions, Documentation, and Support Bulletins using the advanced MS SharePoint search engine.

Email-based Technical Support

[email protected]

When contacting OSIsoft Technical Support by email, it is helpful to send the following information:

Description of issue: Short description of issue, symptoms, informational or error messages, history of issue

Log files: See the product documentation for information on obtaining logs pertinent to the situation.

Online Technical Support

From the OSIsoft Technical Support Web site, click Contact us > My Support > My Calls.

Using OSIsoft’s Online Technical Support, you can:

Enter a new call directly into OSIsoft’s database (monitored 24 hours a day)

View or edit existing OSIsoft calls that you entered

View any of the calls entered by your organization or site, if enabled

See your licensed software and dates of your Service Reliance Program agreements


mailto:[email protected]

Remote Access

From the OSIsoft Technical Support Web site, click Contact Us > Remote Support Options.

OSIsoft Support Engineers may remotely access your server in order to provide hands-on troubleshooting and assistance. See the Remote Access page for details on the various methods you can use.

On-site Service

From the OSIsoft Technical Support Web site, click Contact Us > On-site Field Service Visit.

OSIsoft provides on-site service for a fee. Visit our On-site Field Service Visit page for more information.

Knowledge Center

From the OSIsoft Technical Support Web site, click Knowledge Center.

The Knowledge Center provides a searchable library of documentation and technical data, as well as a special collection of resources for system managers. For these options, click Knowledge Center on the Technical Support Web site.

The Search feature allows you to search Support Solutions, Bulletins, Support Pages, Known Issues, Enhancements, and Documentation (including user manuals, release notes, and white papers).

System Manager Resources include tools and instructions that help you manage: Archive sizing, backup scripts, daily health checks, daylight savings time configuration, PI Server security, PI System sizing and configuration, PI trusts for interface nodes, and more.

Upgrades

From the OSIsoft Technical Support Web site, click Contact Us > Obtaining Upgrades.

You are eligible to download or order any available version of a product for which you have an active Service Reliance Program (SRP), formerly known as Tech Support Agreement (TSA). To verify or change your SRP status, contact your Sales Representative or Technical Support (http://techsupport.osisoft.com / ) for assistance.


http://techsupport.osisoft.com/

Technical Support and Resources

OSIsoft Virtual Campus (vCampus)

The OSIsoft Virtual Campus (vCampus) Web site offers a community-oriented program that focuses on PI System development and integration. The Web site's annual online subscriptions provide customers with software downloads, resources that include a personal development PI System, online library, technical webinars, online training, and community-oriented features such as blogs and discussion forums.

OSIsoft vCampus is intended to facilitate and encourage communication around PI programming and integration between OSIsoft partners, customers and employees. See the OSIsoft vCampus Web site, http://vCampus.osisoft.com (http://vCampus.osisoft.com) or contact the OSIsoft vCampus team at [email protected] for more information.

http://vCampus.osisoft.com/

Appendix G. Revision History

Date Author Comments

07-Aug-1996 PKIM Revision of original VAX-based documentation

23-Sep-1996 JFZ Included more installation information

13-Dec-1996 MMG Add NT service information

01-Oct-1998 LFM Remove figures in hardware configuration. Refer to Bailey document instead.

14-Dec-1998 LFM Remove hardware configuration figure from TOC. Minor modification in parameter description.

25-Feb-1999 JK Added in parameter description for event counters for NT

22-Jun-1999 JK Fixed typo in Station Status section: should be PI2 not PI3

10-Sep-1999 JK More info on how to configure digital states for Module Status tags (point type 14)

20-Nov-2000 AKF Updated formatting, introduction section and minor edits

30-Oct-2002 CG Clarified the meaning of NT to include W2K & XP; fixed headers & footers & TOC.

19-Sep-2006 Janelle NT and UNIX version 1.6 to 1.8; VMS version 2.1.2 Rev A: Updated Supported Features table to include APS Connector; fixed headers and footers; updated How to Contact Us page

27-Nov-2006 PRowe Version 1.8, Rev B; Updated manual to Skeleton v2.5.3, applied template and spell checked document. Requires much additional work.

09-Mar-2007 E Tam Version 1.8.2.0 (updated from Version 1.8 Rev B)

04-Jan-2008 Janelle Version 1.8.2.0, Revision A: updated hardware diagram, fixed headers, added serial information to supported features table, added ICU screen shots and description in Startup Command File section; made final

09-Jan-2008 E Tam Version 1.8.2.0, Revision B: minor corrections

13-Aug-2009 S Horwitz Revision C. Convert to new Interface Skeleton

11-Sep-2009 MMoore Version 1.8.3.0, Revision A: Update to latest interface Skeleton version 3.0.16

11-Oct-2012 SBranscomb Version 1.8.3.0; Revision B; Updated to Skeleton Version 3.0.35

03-May-2013 BAndersen Version 1.8.3.x; Revision C; Updated supported operating systems table to add Windows 8 and Windows 2012

14-May-2013 BAndersen Version 1.8.3.x; Revision D; Updated copyright information; Changed references to interface to conform with naming conventions


Date Author Comments

23-May-2013 BAndersen Version 1.8.4.x; Revision A


PI Interface for Bailey Infi90 - OSIsoftcdn.osisoft.com/interfaces/3296/PI_BaInfi90_1.8.4.9.docx · Web viewABB/Bailey. Computer Interface ... a wall wart transformer) ... The interface

Documents