PI Interface for Bailey Infi90
Version 1.8.4.x
Revision A
iii
OSIsoft, LLC
777 Davis St., Suite 250
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://www.osisoft.com
OSIsoft Australia • Perth, Australia
OSIsoft Europe GmbH • Frankfurt, Germany
OSIsoft Asia Pte Ltd. • Singapore
OSIsoft Canada ULC • Montreal & Calgary, Canada
OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China
OSIsoft Japan KK • Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil
PI Interface for Bailey Infi90
Copyright: © 1997-2017 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 RIGHTS
Use, 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: 07/2017
Table of Contents
Chapter 1. Introduction ................................................................................................ 1
Reference Manuals ............................................................................................. 2
Supported Operating Systems ............................................................................ 2
Supported Features............................................................................................. 2
Diagram of Hardware Connection ....................................................................... 5
Chapter 2. Principles of Operation .............................................................................. 7
Failover ................................................................................................................ 8
Chapter 3. Installation Checklist ................................................................................ 11
Data Collection Steps ........................................................................................11
Interface Diagnostics .........................................................................................12
Chapter 4. Interface Installation................................................................................. 13
Naming Conventions and Requirements ..........................................................13
Interface Directories ..........................................................................................14
PIHOME Directory Tree ..........................................................................14
Interface Installation Directory ................................................................14
Interface Installation Procedure ........................................................................14
Installing Interface as a Windows Service.........................................................14
Installing Interface Service with PI Interface Configuration Utility .....................15
Service Configuration .............................................................................15
Installing Interface Service Manually.................................................................18
Chapter 5. Digital States............................................................................................. 19
Chapter 6. PointSource .............................................................................................. 21
Chapter 7. PI Point Configuration .............................................................................. 23
Point Attributes ..................................................................................................23
Tag ..........................................................................................................23
PointSource ............................................................................................24
PointType ................................................................................................24
Location1 ................................................................................................24
Location2 ................................................................................................24
Location3 ................................................................................................25
Location4 ................................................................................................25
Location5 ................................................................................................25
InstrumentTag .........................................................................................25
ExDesc ....................................................................................................25
Scan ........................................................................................................25
Shutdown ................................................................................................25
Output Points .....................................................................................................26
SourceTag ..............................................................................................26
PI Interface for Bailey Infi90
iii
Table of Contents
Bailey Point Types ..................................................................................26
Digital Read ............................................................................................27
Analog Report .........................................................................................28
Bailey Database Conversion .............................................................................29
Tag ..........................................................................................................30
Descriptor ................................................................................................30
EngUnits .................................................................................................30
Zero .........................................................................................................30
Span ........................................................................................................30
Location2 ................................................................................................30
Location3 ................................................................................................30
Location4 ................................................................................................30
Location5 ................................................................................................30
Digital Points ...........................................................................................30
Chapter 8. Startup Command File ............................................................................. 31
Configuring the Interface with PI ICU ................................................................31
bainfi90 Interface Page ...........................................................................33
Manual Maintenance of the Startup Command File ...............................36
Manual Maintenance of the Startup Command File ..........................................36
Command-line Parameters ...............................................................................37
Sample i90.bat File............................................................................................39
Legacy Startup Command File ..........................................................................40
Chapter 9. Interface Node Clock ................................................................................ 43
Chapter 10. Security ................................................................................................. 45
Chapter 11. Starting / Stopping the Interface ......................................................... 47
Starting Interface as a Service ..........................................................................47
Stopping Interface Running as a Service ..........................................................47
Chapter 12. Buffering ............................................................................................... 49
Which Buffering Application to Use ...................................................................49
How Buffering Works.........................................................................................50
Buffering and PI Server Security .......................................................................50
Enabling Buffering on an Interface Node with the ICU .....................................51
Choose Buffer Type ................................................................................51
Buffering Settings....................................................................................52
Buffered Servers .....................................................................................54
Installing Buffering as a Service .............................................................57
Configuring Buffering Manually .........................................................................59
Example piclient.ini File ..........................................................................60
Chapter 13. Interface Diagnostics Configuration ................................................... 61
Scan Class Performance Points .......................................................................61
I/O Rate Point ....................................................................................................62
Interface Status Point ........................................................................................64
Monitoring I/O Rates on the Interface Node .....................................................65
Appendix A.
iv
Error and Informational Messages..................................................... 67
Message Logs ...................................................................................................67
System Errors and PI Errors .............................................................................67
Appendix B. PI SDK Options.................................................................................... 69
Appendix C. Troubleshooting .................................................................................. 71
Hardware Configuration ....................................................................................71
Communication Problems .................................................................................71
Bailey Loop Problems .......................................................................................72
PI Configuration Problems ................................................................................73
Appendix D. User-defined Bit Mask for MSDD, DD and RCM Points .................... 75
Multi-state Device Driver Exception ..................................................................75
Device Driver Exception ....................................................................................75
Remote Switch (RCM) Exception ......................................................................76
Example MSDD to PI Tag State Translation .....................................................76
Appendix E. Terminology......................................................................................... 77
Appendix F. Technical Support and Resources ..................................................... 81
Before You Call or Write for Help ...........................................................81
Help Desk and Telephone Support.........................................................81
Search Support .......................................................................................82
Email-based Technical Support ..............................................................82
Online Technical Support .......................................................................82
Remote Access .......................................................................................83
On-site Service .......................................................................................83
Knowledge Center ..................................................................................83
Upgrades ................................................................................................83
OSIsoft Virtual Campus (vCampus)........................................................84
Appendix G. Revision History.................................................................................. 85
PI Interface for Bailey Infi90
v
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.
PI Interface for Bailey Infi90
1
Introduction
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
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
Windows 2008
32-bit OS
Yes
No
Windows 2008 R2
64-bit OS
Yes (Emulation Mode)
No
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
64-bit OS
Yes (Emulation Mode)
No
Windows XP
Windows 2003 Server
Windows Vista
Windows 7
Windows 8
Windows 2012
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
2
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
No
No
No
* 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 SDK
The 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 Reporting
The Bailey Net90 or Infi90 control system performs exception reporting. This Interface
receives exception values and sends them to the PI Server.
Source of Timestamps
The 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.
PI Interface for Bailey Infi90
3
Introduction
Failover
Failover 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 Required
The 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 Types
The 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 Interface
This 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.
4
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
PI Interface for Bailey Infi90
5
Introduction
Option 2
6
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.
PI Interface for Bailey Infi90
7
Principles of Operation
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.
8
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.
PI Interface for Bailey Infi90
9
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.
PI Interface for Bailey Infi90
11
Installation Checklist
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.
12
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 Manually
It 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.
PI Interface for Bailey Infi90
13
Interface Installation
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.
14
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 name
The Service name box shows the name of the current interface service. This service name is
obtained from the interface executable.
ID
This is the service ID used to distinguish multiple instances of the same interface using the
same executable.
Display name
The Display name text box shows the current Display Name of the interface service. If there
is currently no service for the selected interface, the default Display Name is the service name
with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the
prefix “PI-” be appended to the beginning of the interface name to indicate that the service is
part of the OSIsoft suite of products.
PI Interface for Bailey Infi90
15
Interface Installation
Log on as
The Log on as text box shows the current “Log on as” Windows User Account of the
interface service. If the service is configured to use the Local System account, the Log on as
text box will show “LocalSystem.” Users may specify a different Windows User account for
the service to use.
Password
If a Windows User account is entered in the Log on as text box, then a password must be
provided in the Password text box, unless the account requires no password.
Confirm password
If a password is entered in the Password text box, then it must be confirmed in the Confirm
password text box.
Dependencies
The 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
Dependencies list.
button, and the service name will be removed from the
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 Button
To add a dependency from the list of Installed services, select the dependency name, and
click the Add button.
- Remove Button
To 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 Type
The Startup Type indicates whether the interface service will start automatically or needs to
be started manually on reboot.
16

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.
Create
The Create button adds the displayed service with the specified Dependencies and with the
specified Startup Type.
Remove
The Remove button removes the displayed service. If the service is not currently installed, or
if the service is currently running, this button will be grayed out.
Start or Stop Service
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
PI Interface for Bailey Infi90
Status of the
Interface
Service
Service
installed or
uninstalled
17
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.
18
Chapter 5.
Digital States
For more information regarding Digital States, refer to the PI Server documentation.
Digital State Sets
PI digital states are discrete values represented by strings. These strings are organized in PI as
digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n
to represent different values of discrete data. For more information about PI digital tags and
editing digital state sets, see the PI 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.
PI Interface for Bailey Infi90
19
Digital States
System Digital State Set
Similar 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.
20
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 Attribute
The 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 Sources
Several 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.
PI Interface for Bailey Infi90
21
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: * ’ ? ; { } [ ] | \ ` ' "
Length
For 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 Interface for Bailey Infi90
23
PI Point Configuration
PI API
PI Server
Maximum Length
1.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
Below 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).
24
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.
PI Interface for Bailey Infi90
25
PI Point Configuration
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.
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 PIBufss
It 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 Variable
N90 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.
26
Setpoint Read
N90 point type 2 This is the setpoint of a control station block. See point type 1.
Control Output Read
N90 point type 3 This is the control output of a control station block. See point type 1.
Ratio Index Read
N90 point type 4 This is the ratio index of a ratio control station block. See point type 1.
Analog Read
N90 point type 5 This refers to an analog output block (function code 30) in the plant loop.
Station Status
N90 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 Mode
0
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.
PI Interface for Bailey Infi90
27
PI Point Configuration
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 Report
N90 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 Status
N90 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:
Configure
Failed
Error
Execute
Set the PI digital point's digital state set to a digital state set that contains the following states:
Value
Module Status
0
Configure
1
Failed
2
Error
3
Execute
Set the block number (Location4) to 0 for this point type.
RCM Read
N90 point type 15 An RCM (function code 62), device driver (function code 123), or multistate 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.
28
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 Read
N90 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 Read
N90 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 Report
N90 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.
PI Interface for Bailey Infi90
29
PI Point Configuration
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.
30
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:
PI Interface for Bailey Infi90
31
Startup Command File
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.
32
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.
PI Interface for Bailey Infi90
33
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 Rate
The Baud Rate parameter specifies the data rate of the COM port. The only acceptable
values are 1200, 2400, 4800, 9600, or 19200 bps. (/baudrate=#)
Port
The 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)
34
Debug Level
The 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 delay
This parameter specifies the number of exception calls before delay, from 1 to 100, inclusive.
(/cnt=#, Default: 20)
Time to delay between calls
This parameter specifies the number of seconds to delay between calls, from 0.1 to 30,
inclusive. (/delay=#, Default: 2)
Enable Output Points
Select whether or not to enable Output Points. 1-Enable enables them, 0 – Disable disables
them. (/outputflag=#, Default: 1)
Enable exception screening
Check this box to enable CIU exception reporting screening. (/excepscreen=#, Default: 0,
that is, disabled)
Synchronize Bailey time with interface node time
Check this box to synchronize the Bailey time with the interface computer time. (/tsync=#,
Default=0)
Failover
None, Primary, Secondary
Select 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 Number
Enter 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 index
When 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)
PI Interface for Bailey Infi90
35
Startup Command File
Additional Parameters
This 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.
36
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=#
Specifies the data rate of the COM port. The only acceptable
values are 1200, 2400, 4800, 9600, or 19200 bps.
Required
/CIU#=#
Required
/CIUtype=#
Optional
/cnt=#
Optional
/debuglevel=#
Optional
/delay=#
Optional
/ec=#
Optional
/excepscreen=#
Optional
/failover=#
Optional
PI Interface for Bailey Infi90
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.
Specifies the CIU version number from 1 to 4, inclusive. The
default value is 3.
Specifies the number of exception calls before delay, from 1 to
100, inclusive. The default value is 20.
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).
Specifies the number of seconds to delay between calls, from 0.1
to 30, inclusive. The default value is 2.
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.
A value of 0 for this parameter disables CIU exception reporting
screening. A value of 1 enables it. The default value is 0.
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.
37
Startup Command File
Parameter
Description
/host=host:port
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.
Required
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
/port=#
Required
/priCIU=#
Required when -failover=2
/ps=x
Optional
/tsync=#
Optional
/wdogidx=#
Optional
38
A value of 0 for this parameter disables PI output points. A value
of 1 enables it. The default value is 1.
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.
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.
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.
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.
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==========================================================
REM
REM i90.bat
REM
REM Sample startup file for the PI Interface for Bailey Infi90
REM
REM==========================================================
REM
REM OSIsoft strongly recommends using PI ICU to modify startup files.
REM
REM Sample command line
REM
.\i90.exe -ps=N -ciu#=1 -host=XXXXXX:5450 -port=2 -baudrate=9600
REM
REM 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.
PI Interface for Bailey Infi90
39
Startup Command File
Legacy Startup Command File
Versions 1.8 and earlier of the interface used a start-up command file that contains commaseparated parameters that are order dependent. See the following:
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
rem
40
Command file to start i90 interface
parameters to executable i90 are as follows:
debuglevel
Set to 0 to suppress all interface messages
to stdout. Set to either 1, 2, or 3 to see
messages. The higher the number, the more
information is output. In any case, severe
messages are always written to the PI log
file (wherever it is defined to be).
host
The pi server
CIU#
The user-defined number indicating the CIU,
also stored in location 1 of points in PI
point database referring to the CIU that the
interface is servicing.
Port
Com port 1, 2, 3, or 4
Baudrate
Either 1200, 2400, 4800, 9600, 19200
CIUType
The version of the CIU, from 1 to 4,
corresponding to CIU01, CIU02, CIU03, CIU04.
Default is CIUSTARTVERSION (defined in
ciuindex.h), currently 3.
Delay
Number of seconds to delay between exception
calls, from .1 to 30 seconds. Converted to
milliseconds in code. Default is 2 seconds.
Maximum number of exception calls before
delay, from 1 to 100. Default is 20.
Cnt
Tsync
Time synchronization facility, either 0 or 1
Default is 0 (no synchronization).
PS
Point source in PI database for all points
covered by the particular CIU#.
Default is N.
EC
Event Counter number (number you specify in
the iorates.dat file)
The following parameters are supported in interface
version 1.6 and above
Outputflag
Flag indicating whether to enable output:
0 to disable output; 1 to enable.
Default is 1 (enable).
ExcepScreen CIU Exception Report screening: 1 to enable,
0 to disable. Default is 0 (disable).
Failover
Failover Mode: 0 for no failover, 1 for
primary interface, 2 for secondary interface.
Default is 0 (no failover).
rem PriCIU
Primary CIU node/PCU number. Required for
rem
secondary interface.
rem
rem Wdogidx
CIU index for watchdog output signal in
rem
primary CIU. If the wdogidx is not supplied,
rem
index 1 is used.
rem
rem
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, event
rem
counter number 2, secondary node, Primary CIU index
rem
20, watchdox index 1.
rem
All other parameter values are the default. This is
rem
indicated by a non-argument in the appropriate position of
rem
of the parameter list. Use no spaces between
rem
parameters (except of course between name of
rem
executable and the parameters list). Delimit
rem
parameters with commas.
rem
rem Sample startup command line below
i90.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.
PI Interface for Bailey Infi90
41
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.
PI Interface for Bailey Infi90
43
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 Informational Messages
for additional information on error messaging.
PI Server v3.3 and Higher
Security configuration using piconfig
For PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust
table:
C:\PI\adm> piconfig
@table pitrust
@mode create
@istr Trust,IPAddr,NetMask,PIUser
a_trust_name,192.168.100.11,255.255.255.255,piadmin
@quit
For the above,
Trust: An arbitrary name for the trust table entry; in the above example,
a_trust_name
IPAddr: the IP Address of the computer running the interface; in the above example,
192.168.100.11
NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr
PIUser: the PI user the interface to be entrusted as; piadmin is usually an appropriate user
Security Configuring using Trust Editor
The Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI
Trust table.
PI Interface for Bailey Infi90
45
Security
See the PI System Management chapter in the PI Server manual for more details on security
configuration.
PI Server v3.2
For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:
C:\PI\adm> piconfig
@table pi_gen,piproxy
@mode create
@istr host,proxyaccount
piapimachine,piadmin
@quit
In place of piapimachine, put the name of the interface node as it is seen by the PI Server.
46
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
PI Interface for Bailey Infi90
button on the PI ICU toolbar.
47
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. Nway 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.
PI Interface for Bailey Infi90
49
Buffering
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:
50
Buffering Application
Application Name field for PI Trust
PI 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.
PI Interface for Bailey Infi90
51
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.
PIBufss
For 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.
52
Maximum transfer objects
Maximum 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 Path
This 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.)
Bufserv
For 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.
PI Interface for Bailey Infi90
53
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 objects
Max 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.
PIBufss
PIBufss 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.)
54
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 nway 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.
PI Interface for Bailey Infi90
55
Buffering
Bufserv
Bufserv 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.
56
Installing Buffering as a Service
Both the PIBufss and Bufserv applications run as a Service.
PI Buffer Subsystem Service
Use 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.
PI Interface for Bailey Infi90
57
Buffering
API Buffer Server Service
Use 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.
58
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)
PI Interface for Bailey Infi90
59
Buffering
Keywords
Values
Default
Description
RETRYRATE
0 – 2,000,000
120
When the buffering process discovers
the home node is unavailable it will wait
this long before attempting to reconnect
(seconds)
MAXFILESIZE
1 – 2,000,000
100,000
Maximum buffer file size before
buffering fails and discards events.
(Kbytes)
MAXTRANSFEROBJS
1 – 2,000,000
500
Maximum number of events to send
between each SENDRATE pause.
BUF1SIZE
64 – 2,000,000
32768
Primary memory buffer size. (bytes)
BUF2SIZE
64 – 2,000,000
32768
Secondary memory buffer size. (bytes)
SENDRATE
0 – 2,000,000
100
The time to wait between sending up to
MAXTRANSFEROBJS to the server
(milliseconds)
In addition to the [APIBUFFER] section, 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=1
MAXFILESIZE=100000
; The PI API connection routines have a 1 minute default timeout.
RETRYRATE=600
60
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.
PI Interface for Bailey Infi90
61
Interface Diagnostics Configuration
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:
62
Enable IORates for this Interface
The 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 Counter
The Event Counter correlates a tag specified in the iorates.dat file with this copy of the
interface. The command-line equivalent is /ec=x, where x is the same number that is
assigned to a tag name in the iorates.dat file.
Tagname
The tag name listed in the Tagname box is the name of the I/O Rate tag.
Tag Status
The 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 File
The 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
Snapshot
The 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.
PI Interface for Bailey Infi90
63
Interface Diagnostics Configuration
Create/Save
Create 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.
Delete
Delete the I/O Rate tag listed in the Tagname box.
Rename
Allow the user to specify a new name for the I/O Rate tag listed in the Tagname box.
Add to File
Add the tag to the IORates.dat file with the event counter listed in the Event Counter box.
Search
Allow 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 nonchanging 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:
64
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.
PI Interface for Bailey Infi90
65
Error and Informational Messages
Appendix A.
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
PI Interface for Bailey Infi90
67
Appendix B.
PI SDK Options
To access the PI SDK settings for this interface, select this interface from the Interface dropdown list and click UniInt – PI SDK in the parameter category pane.
Disable PI SDK
Select 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 setting
This 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 SDK
Select 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.
PI Interface for Bailey Infi90
69
Troubleshooting
Appendix C.
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.
PI Interface for Bailey Infi90
71
Troubleshooting
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:
72

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 reestablish the point either by restarting the interface or by changing one of the nonessential 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.
PI Interface for Bailey Infi90
73
User-defined Bit Mask for MSDD, DD
and RCM Points
Appendix D.
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
F2
Feedback State 2
6
64
F3
Feedback State 3
5
32
F4
Feedback State 4
4
16
GS
Good State (two bits)
2&3
12 (4+8)
RS
Requested State (two bits)
0&1
3 (1+2)
Device Driver Exception
Name
Description
Bit
Decimal Value
Q
Quality
15
32768
ALM
Alarm
14
16384
TAG
Block is Tagged
9
512
V
Control Output
8
256
F2
Feedback State 2
5
32
F1
Feedback State 1
4
16
FS
Feedback status quality
3
8
SO
Override
2
4
Mode
Auto/Manual Mode (two bits)
0&1
3 (1+2)
PI Interface for Bailey Infi90
75
User-defined Bit Mask for MSDD, DD and RCM Points
Remote Switch (RCM) Exception
Name
Description
Bit
Decimal Value
Q
Quality
15
32768
ALM
Alarm
14
16384
TAG
Block is Tagged
9
512
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
2
F3 on, F4 and F1 off
3
F3 and F4 on, F1 off
4
F1 on, F3 and F4 off
5
F1 and F4 on, F3 off
6
F1 and F3 on, F4 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.
76
Terminology
Appendix E.
To understand this interface manual, you should be familiar with the terminology used in this
document.
Buffering
Buffering 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 Buffering
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 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.)
ICU
ICU 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 Control
An 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 Node
An interface node is a computer on which

the PI API and/or PI SDK are installed, and

PI Server programs are not installed.
PI API
The 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 Interface for Bailey Infi90
77
Terminology
PI Collective
A 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.
PIHOME
PIHOME 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.
PIHOME64
PIHOME64 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 Log
The 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 SDK
The 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 Node
A PI Server Node is a computer on which PI Server programs are installed. The PI Server
runs on the PI Server Node.
78
PI SMT
PI 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.log
The 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.
Point
The 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.
Service
A 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.
PI Interface for Bailey Infi90
79
Technical Support and Resources
Appendix F.
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 Options
San 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 1811
86 021 2327 8686
English, Mandarin
Mandarin
Perth, WA, Australia
61 8 9282 9220
English
PI Interface for Bailey Infi90
81
Technical Support and Resources
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:
82

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
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.
PI Interface for Bailey Infi90
83
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 communityoriented 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.
84
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
PI Interface for Bailey Infi90
85
Revision History
86
Date
Author
Comments
14-May-2013
BAndersen
Version 1.8.3.x; Revision D; Updated copyright
information; Changed references to interface to
conform with naming conventions
23-May-2013
BAndersen
Version 1.8.4.x; Revision A