novatech d/3® interface to the pi system...

NovaTech D/3®

Interface to the PI System

Version 4.30.0.12Rev E

How to Contact UsOSIsoft, Inc. 777 Davis St., Suite 250San Leandro, CA 94577 USA

Telephone(01) 510-297-5800 (main phone)(01) 510-357-8136 (fax) (01) 510-297-5828 (support phone)

[email protected]

Houston, TX Johnson City, TN Mayfield Heights, OHPhoenix, AZ Savannah, GASeattle, WAYardley, PA

Worldwide Offices

OSIsoft AustraliaPerth, AustraliaAuckland, New Zealand

OSI Software GmbH Altenstadt, Germany

OSI Software Asia Pte Ltd.Singapore

OSIsoft Canada ULCMontreal, Canada

OSIsoft, Inc. Representative OfficeShanghai, People’s Republic of China

OSIsoft Japan KKTokyo, Japan

OSIsoft Mexico S. De R.L. De C.V.Mexico City, Mexico

Sales Outlets and Distributors Brazil Middle East/North Africa Republic of South Africa Russia/Central Asia

South America/Caribbean Southeast Asia South Korea Taiwan

WWW.OSISOFT.COM

OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI ProcessBook, Sequencia, Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the property of its owner and use herein in no way indicates an endorsement, recommendation, or warranty of such party’s products or any affiliation with such party of any kind.

RESTRICTED RIGHTS LEGENDUse, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013

Unpublished – rights reserved under the copyright laws of the United States.D/3 is a registered trademark of NovaTech Process Solutions, LLC.

© 2002-2006 OSIsoft, Inc . PI_GSETID3.doc

http://WWW.OSISOFT.COM/

mailto:[email protected]

Table of Contents

Introduction......................................................................................................................1Reference Manuals........................................................................................................1

Supported Features........................................................................................................2

Diagram of Hardware Connection..................................................................................8

Principles of Operation...................................................................................................9Installation Checklist.....................................................................................................11Interface Installation on Windows................................................................................15

Naming Conventions and Requirements......................................................................15

Interface Directories.....................................................................................................16

The PIHOME Directory Tree.....................................................................................16

Interface Installation Directory..................................................................................16

Interface Installation Procedure....................................................................................16

Installing the Interface as a Windows Service..............................................................16

Installing the Interface Service with PI ICU..............................................................17

Installing the Interface Service Manually..................................................................19

Interface Installation on OpenVMS...............................................................................21Naming Conventions and Requirements......................................................................21

Interface Installation Procedure....................................................................................21

Linking the Interface on OpenVMS..............................................................................22

Object Files...............................................................................................................22

TID3.opt....................................................................................................................22

TID3Link.com............................................................................................................23

PIBuild and PISysExe...............................................................................................24

Digital States..................................................................................................................25PointSource....................................................................................................................27D/3 Point Configuration.................................................................................................29

D/3 Versions 5.0 to 9.0-1..............................................................................................29

D/3 Version 9.0-2 and Higher.......................................................................................29

D/3 Point Lists................................................................................................................31D/3 Hardware Shutdown................................................................................................33

NovaTech D/3 Interface to the PI System iii

PI Point Configuration...................................................................................................35Point Attributes.............................................................................................................35

Tag............................................................................................................................35

PointSource..............................................................................................................35

PointType..................................................................................................................35

Location1..................................................................................................................36

Location2..................................................................................................................36

Location3..................................................................................................................37

Location4..................................................................................................................37

Location5..................................................................................................................38

InstrumentTag...........................................................................................................38

ExDesc.....................................................................................................................39

Scan..........................................................................................................................40

Shutdown..................................................................................................................41

Output Points................................................................................................................41

Trigger Method 1 (Recommended)..........................................................................42

Trigger Method 2......................................................................................................42

Performance Point Configuration................................................................................43Configuring Performance Points with PI ICU (Windows).............................................43

Configuring Performance Points Manually...................................................................44

I/O Rate Tag Configuration...........................................................................................47Monitoring I/O Rates on the Interface Node.................................................................47

Configuring I/O Rate Tags with PI ICU (Windows).......................................................47

Configuring I/O Rate Tags Manually............................................................................49

Configuring the PI Point on the PI Server.................................................................49

Configuration on the Interface Node.........................................................................49

Startup Command File...................................................................................................51Configuring the Interface with PI ICU...........................................................................51

General Parameters.................................................................................................53

General Tab..............................................................................................................54

Other UniInt Parameters...........................................................................................55

Command-Line Parameters.........................................................................................56

Sample TID3.bat File....................................................................................................61

UniInt Failover Configuration.......................................................................................63Introduction...................................................................................................................63

NovaTech D/3 Interface to the PI System iv

Failover Installation Checklist.......................................................................................63

Startup Command File Configuration...........................................................................66

Sample Interface Startup Files.................................................................................67

PI ICU Configuration.....................................................................................................67

Data Source Failover Control Point Configuration.......................................................69

Active ID...................................................................................................................70

Heartbeat..................................................................................................................70

Control Point Data Flow............................................................................................71

PI Failover Control Tag Configuration..........................................................................72

Active ID...................................................................................................................72

Heartbeat..................................................................................................................73

Interface State Tag.......................................................................................................74

Interface State Tag Configuration.............................................................................74

Digital State Configuration........................................................................................74

Importing Failover Digital Set to PI via PI SMT 3.....................................................75

Messages.....................................................................................................................77

Informational.............................................................................................................77

Errors........................................................................................................................78

Interface Node Clock.....................................................................................................81Windows.......................................................................................................................81

OpenVMS.....................................................................................................................81

Security...........................................................................................................................83Windows.......................................................................................................................83

OpenVMS.....................................................................................................................84

Starting / Stopping the Interface on Windows............................................................85Starting Interface as a Service.....................................................................................85

Stopping Interface Running as a Service.....................................................................85

Starting / Stopping the Interface on OpenVMS...........................................................87Starting a Detached Process........................................................................................87

Stopping.......................................................................................................................88

Buffering.........................................................................................................................89Configuring Buffering with PI ICU (Windows)...............................................................89

Configuring Buffering Manually....................................................................................92

Example piclient.ini File................................................................................................93

Appendix A: Error and Informational Messages.........................................................95

NovaTech D/3 Interface to the PI System

v

Message Logs..............................................................................................................95

System Errors and PI Errors........................................................................................95

Appendix B: PINet to PI 3 String Tag Support............................................................97Method of Operation.....................................................................................................97

Setup Instructions.........................................................................................................98

The Automatic FTP Script............................................................................................99

Configuring the Script...............................................................................................99

Starting and Stopping the FTP Script.....................................................................103

Informational and Error Messages from the FTP Script.........................................104

Appendix C: “Watchdog”............................................................................................107Restart.com................................................................................................................107

RestartDetach.com.....................................................................................................107

Using the “Watchdog”.................................................................................................108

Startup........................................................................................................................108

Shutdown....................................................................................................................108

Revision History.............................................................................................................111

vi

IntroductionThe NovaTech D/3 Interface to the PI System, also known as the PI GSETID3 Interface provides two-way communication with a NovaTech D/3 distributed control system. The interface program reads the PI point database to determine which points to read from and write to the NovaTech Configurator/Display Control Modules (CDCM/DCM).

The interface runs on a DEC VAX or Alpha computer with the D/3 Database Access software from NovaTech. The D/3 Software must be version 5.0 or later. The interface also runs on Windows NT/2000/XP with DBA D/3 Software version 10.0, 10.1, 10.2, 11.2, or 12.1.

Note: Please contact OSIsoft if you need to run with a version of D/3 software other than one of those listed above.

The interface can run on the various versions of Windows, but is limited to the versions on which the DBA D/3 software runs.

The PI System can run on the same computer as the D/3 software. The PI system can also run on another computer with the D/3 computer as a PI Interface node. In this way, it is possible to have several D/3 systems on different computers communicating with a PI System.

Reference ManualsOSIsoft

UniInt End User Document

PI Data Archive Manual

PI API Installation Instructions

VendorConsult the following NovaTech documentation for more information on D/3 software:

D/3 Database Access User’s Guide (UG1.0007.V6.2C)

D/3 PCM Database Fields Reference Manual, (RM1.0008.V6.2C)

NovaTech D/3 Interface to the PI System 1

Supported FeaturesFeature Support

Part Number PI-IN-GSE-D3-AXPPI-IN-GSE-D3-VAXPI-IN-GSE-D3DB-NTI

* Platforms VMS / Alpha VMS / NTI (4.0 / 2000 / XP)

APS Connector No

PointBuilder Utility No

ICU Control Yes

PI Point Types Real / digital / integer / float 32 / float 16 / string

Sub-second Timestamps No

Sub-second Scan Classes No

Automatically Incorporates PI Point Attribute Changes

Yes

Exception Reporting Yes

Outputs from PI Yes

Inputs to PI: Scan-based / Unsolicited / Event Tags

Scan-based

Supports Questionable Bit No

Supports Multi-character PointSource No

Maximum Point Count Unlimited

Uses PI SDK No

PINet to PI 3 String Support Yes

* Source of Timestamps PI Server

History Recovery No

* Failover UniInt Failover (phase 1)

Server-Level Failover No

* UniInt-based Yes

* Vendor Software Required on PI API / PINet Node

Yes

Vendor Software Required on Foreign Device

No

Vendor Hardware Required No

* Additional PI Software Included with Interface

Yes (on OpenVMS)

* Device Point Types See below

* See paragraphs below for further explanation.


PlatformsThe Interface is designed to run on Windows XP, Windows 2000, and Windows NT 4.0 SP6a operating systems. Because it is dependent on vendor software, newer platforms may not yet be supported.

Source of TimestampsAll input data uses the PI server as its source of timestamp.

UniInt-basedUniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by our developers, and is integrated into many interfaces, such as the PI GSETID3 interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.

The UniInt End User Document is a supplement to this manual.

UniInt Failover SupportUniInt provides support for a hot failover configuration which results in a no data loss solution for bi-directional data transfer between the PI Server and the Data Source given a single point of failure in the system architecture. This failover solution requires that two copies of the interface be installed on different interface nodes collecting data simultaneously from a single data source. Failover operation is automatic and operates with no user interaction. Each interface participating in failover has the ability to monitor and determine liveliness and failover status. To assist in administering system operations, the ability to manually trigger failover to a desired interface is also supported by the failover scheme.

The failover scheme is described in detail in the UniInt End User Document, which is a supplement to this manual. Details for configuring this Interface to use failover are described in the UniInt Failover Configuration section of this manual.

Vendor Software RequiredD/3 Database Access (DBA) software from NovaTech is required on the interface node. On OpenVMS the D/3 Software must be version 5.0 or later. The interface runs on Windows NT/2000/XP with DBA version 10.0, 10.1, 10.2, 11.2, or 12.1.

Additional PI SoftwareThe PI GSETID3 interface supports input of strings on all platforms when sending data to PI 3. The BatchFile interface is required to input strings from interfaces running on a VAX. The BatchFile interface must run on Windows or UNIX.


3

Introduction

Device Point Types

AI CAL CB DED DEV

AI_ALMCT CAL_VAHI CB_AFLG DED_DIVL DEV_ALMCT

AI_CRIT CAL_VALO CB_FLG DED_DIVS DEV_CMD

AI_CURAL CAL_VAVL CB_FLG1 DED_VEVL DEV_DFLG

AI_DEAD CAL_VAVS CB_FLG2 DEV_FLG

AI_DEV CAL_VBVL CB_INVL DEV_MODE

AI_DVLIM CAL_VBVS CB_INVS DEV_STAT

AI_FLG CAL_VCVL CB_LOUT DEV_TMP0

AI_HHLIM CAL_VCVS CB_OTHI DEV_TMP1

AI_HLIM CAL_VDVL CB_OTLO

AI_INVL CAL_VDVS CB_OTRT

AI_INVS CAL_VEVL CB_OTVL

AI_LLIM CAL_VEVS CB_OTVS

AI_LLLIM CAL_VFVL

AI_MEAS CAL_VFVS

AI_RLIM

DGR DIN DOT FAN INT

DGR_ALMCT DIN_ALMCT DOT_ALMCT FAN_OVL1 INT_ETIM

DGR_FLG DIN_FLG DOT_FLG FAN_OVS1 INT_K

DGR_VAL DIN_VAL DOT_VAL FAN_LO1 INT_TOT

FAN_OVL2

FAN_OVS2

FAN_LO2

4

IOS LIM LLG MF PID

IOS_I0VL LIM_HIVL LLG_KVL MF_FCHI PID_GNVL

IOS_I0VS LIM_HIVS LLG_KVS MF_FCLO PID_GNVS

IOS_I1VL LIM_LOVL LLG_LDVL MF_FCORR PID_GPAC

IOS_I1VS LIM_LOVS LLG_LDVS MF_FLVL PID_INISP

IOS_TGVL LIM_OHVL LLG_LGVL MF_FLVS PID_LERR

IOS_TGVS LIM_OHVS LLG_LGVS MF_K1VL PID_LLDR

IOS_TG LIM_OLVL LLG_LI MF_K1VS PID_LMEA

LIM_OLVS MF_K2VL PID_MESP

MF_K2VS PID_MEVL

MF_PRVL PID_MEVS

MF_PRVS PID_MEZE

MF_PTVL PID_RAVL

MF_PTVS PID_RAVS

MF_TCVL PID_REVL

MF_TCVS PID_REVS

MF_TMVL PID_SPHI

MF_TMVS PID_SPINT

PID_SPLO

PID_SPRT

PID_SPVL

PID_SPVS


5

Introduction

PRF RMP RB SAV SEL

PRF_FDSP RMP_ICVL RB_IBHI SAV_I0HI SEL_I0HI

PRF_FDVL RMP_ICVS RB_IBLO SAV_I0LO SEL_I0LO

PRF_FDVS RB_IBVL SAV_I0VL SEL_I0VL

PRF_FDZE RB_IBVS SAV_I0VS SEL_I0VS

PRF_GNVL RB_INTRT SAV_I1VL SEL_I1VL

PRF_GNVS RB_OBHI SAV_I1VS SEL_I1VS

PRF_GPAC RB_OBLO SAV_I2VL SEL_I2VL

PRF_INISP RB_OBVL SAV_I2VS SEL_I2VS

PRF_LBIAS RB_OBVS SAV_I3VL

PRF_LERR RB_RAMP SAV_I3VS

PRF_LFDBK RB_RSAF SAV_I4VL

PRF_LMEA RB_RTHI SAV_I4VS

PRF_MESP RB_RTLO SAV_I5VL

PRF_MEVL RB_RTVL SAV_I5VS

PRF_MEVS RB_RTVS SAV_NAVG

PRF_MEZE SAV_NCOL

PRF_OTSP

PRF_OTZE

PRF_RAVL

PRF_RAVS

PRF_REVL

PRF_REVS

PRF_SPHI

PRF_SPINT

PRF_SPLO

PRF_SPRT

PRF_SPVL

PRF_SPVS

PRF_FDSP

PRF_FDVL

6

XBR

XBR_CPVL

XBR_HISPEC

XBR_LCPKV

XBR_LCPVL

XBR_LOSPEC

XBR_LRNGV

XBR_LXBRV

XBR_RLCL

XBR_RMAX

XBR_RMIN

XBR_RNGV

XBR_RTARG

XBR_RUCL

XBR_STDDEV

XBR_XBALM

XBR_XBRV

XBR_XLCL

XBR_XTARG

XBR_XUCL


7

Introduction

Diagram of Hardware Connection

8

Principles of OperationAt startup the interface loads all the PI points with the designated point source and interface number. As each point is loaded a call is made to the D/3 system to verify the existence of the point in the DBA. GLF calls are used for continuous points and get_vseq is used for sequence points.

The startup command line controls whether the Sequence Database is accessible or exists. If the interface should not attempt to read the Sequence Database and Sequence Database PI points should be rejected, the command line should include /noseq.

Once the PI points are loaded, the interface periodically reads data from the D/3 or outputs data on event. The interface can request or send up to 255 points of the same D/3 database block type at the same time for collection of continuous data. There is a dilemma with this grouping, though: it is more efficient to group the requests, but the D/3 does not return error information point-by-point. This means that if the request fails all the tags would be considered BAD INPUT. The interface allows for two options when such an error occurs:

1. The interface can go on to individually requesting data for each of the points and eventually determine the point or points in error. These points are then added to a list to revisit at a later time, about thirty minutes later. This waiting period allows the user to change points in the D/3 without having to cycle the interface. If on the second pass the GLF call still returns an error for the D/3 point, the PI point is removed from the interface. The interface attempts to add the PI point again when the interface is restarted or if a non-essential PI point attribute is changed.

2. The user may want the interface to handle the GLF errors by stopping the interface automatically. In this case, use /KS or /KS=0 as a command-line parameter.

UniInt FailoverThis interface supports UniInt failover. Refer to the “UniInt Failover Configuration” section of this document for configuring the interface for failover.


Installation ChecklistFor those users who are familiar with running PI data collection interface programs, this checklist helps get the PI GSETID3 interface running. If unfamiliar with PI interfaces, return to this section after reading the rest of the manual in detail.

Windows1. Install the PI Interface Configuration Utility (which installs the PI SDK and PI API)

2. Verify that the PI API has been installed.

3. Install the interface.

4. Define digital states.

5. Choose a point source. If installing on a PI 2 home node, create the point source.

6. Configure PI points.

7. Configure performance points.

8. Configure I/O Rate tag.

9. Use the PI ICU to configure the startup command file, TID3.bat.

10. Set interface node clock.

11. Set up security.

12. Start the interface without buffering.

13. Verify data.

14. Stop interface, start buffering, start interface.

15. Configure UniInt Failover. Refer to the UniInt Failover Configuration section of this manual for details relating to configuring the interface for failover.


Installation Checklist

OpenVMS1. Check the hardware.2. Install NovaTech D/3 Software.3. Make sure that the D/3 logical D3$INCLUDE is defined.4. Make sure that the D/3 logical D3EXE is defined.5. Rename one of the object files to tid3.obj.6. Edit TID3.opt.7. Link the interface by executing tid3link.com.8. Define the necessary digital states.9. Choose a point source. If PI 2 home node, create the point source.

10. Configure the PI tags.11. Configure performance points.

12. Configure I/O Rate tag.

13. Edit startup command file, TID3.com and TID3detach.com.

14. Set up security.

15. Test the FTP mechanism for PINet to PI 3 string support. See Appendix B for more information.

16. Edit the D3SET:SiteStartUp.com file. Add a new line for the interface as follows: @PISysExe:RestartDetach tid3

17. Edit the SiteStop.com file. Add 2 new lines for the interface as follows:@PISysExe:Stop TID3_r@PISysExe:Stop TID3

or@PISysExe:TID3Stop

18. Start the interface.

19. Verify data.

20. Edit the D3SET:SiteStartUp.com file. Add a new line for the interface as follows: @PISysExe:RestartDetach tid3

21. Edit the SiteStop.com file. Add 2 new lines for the interface as follows:@PISysExe:Stop TID3_r@PISysExe:Stop TID3

or@PISysExe:TID3Stop


Interface Installation on WindowsOSIsoft recommends that interfaces be installed on PI API nodes instead of directly on the PI Server node. A PI API node is any node other than the PI Server node where the PI Application Programming Interface (PI API) has been installed (see the PI API Installation Instructions 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, Bufserv should be enabled on the PI API node (once again, see the PI API Installation Instructions manual). Bufserv is distributed with the PI API. It is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when communication to the PI Server is lost. Communication will be lost when there are network problems or when the PI Server is shut down for maintenance, upgrades, backups, or unexpected failures.

In most cases, interfaces on PI API nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.

The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and interfaces as manual services that are launched by site-specific command files when the PI Server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI Server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI Server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI Server node. See the UniInt End User Document for special procedural information.

Naming Conventions and RequirementsIn the installation procedure below, it is assumed that the name of the interface executable is TID3.exe and that the startup command file is called tid3.bat.

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, one would typically use tid31.exe and tid31.bat for interface number 1, tid32.exe and tid32.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line parameters in a file that has the same root name.


Interface Installation on Windows

Interface Directories

The PIHOME Directory TreeThe PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the %windir% directory. A typical pipc.ini file contains the following lines:[PIPC]PIHOME=c:\pipc

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

Interface Installation DirectoryPlace all copies of the interface into a single directory. The suggested directory is:PIHOME\Interfaces\TID3\

Replace PIHOME with the corresponding entry in the pipc.ini file.

Interface Installation ProcedureThe PI GSETID3 Interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000 and greater operating systems. When running on Windows NT 4.0 systems, the PI GSETID3 setup program will install the Windows Installer itself if necessary. To install, run the GSETID3_x.x.x.x.exe installation kit.

In the installation procedure below, assume that interface number 1 is being installed and that all copies of the interface will be installed in the same directory.

1. Use the PI ICU program to configure the interface’s .bat file based on the discussions found in this manual.

2. Try to start the interface interactively with the command:TID3.bat

If the interface cannot be started interactively, one will not be able to run the interface as a service. It is easier to debug interactively started processes because error messages are echoed directly to the screen. Once the interface is successfully running interactively, one can try to run it as a service by following the instructions below.

Note: When installing the interface from the installation kit, it is important to choose the correct D/3 version because only the corresponding TID3.exe will be installed.

Installing the Interface as a Windows ServiceThe PI GSETID3 interface service can be created with the PI Interface Configuration Utility, or can be created manually.

16

Installing the Interface Service with PI ICUThe PI Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service:

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

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

Display nameThe Display Name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of the OSIsoft suite of products.

Log on asThe Log on as text box shows the current “Log on as” Windows User Account of the interface service. If the service is configured to use the Local System account, the Log on as text box will show “LocalSystem”. Users may specify a different Windows User account for the service to use.

PasswordIf the user has specified a Windows User account in the Log on as text box that has a password, the password must be provided in the Password text box.


17


Confirm PasswordIf a password is specified in the Password text box, then repeat the password in the Confirm Password text box to confirm it.

Startup TypeThe Startup Type indicates whether the interface service will start automatically or needs to be started manually on reboot.

If the Auto option is selected, the service will be installed to start automatically when the machine reboots.

If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.

If the Disabled option is selected, the service will not start at all.

Generally, interface services are set to start automatically.

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

list using the button. For example, if PI API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left. To remove a

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

When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.

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

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

- Remove ButtonTo remove a selected dependency, highlight the service name in the Dependencies list, and click the Remove button.

The full name of the service selected in the Installed services list is displayed below the Installed services list box.

CreateThe Create button adds the displayed service with the specified Dependencies and with the specified Startup Type.

Remove The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out.

18

Create or Remove Interface ServiceCreateThe 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 ServiceTo Start or Stop an interface service, use the Start button and a Stop button on the ICU toolbar. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.

The status of the Interface service is indicated in the lower portion of the PI ICU dialog.

Installing the Interface Service ManuallyOne can get help for installing the interface as a service at any time with the command:TID3.exe –help

Change to the directory where the TID3.exe executable is located. Then, consult the following table to determine the appropriate service installation command.

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

Manual service TID3.exe –install –depend “tcpip bufserv”

Automatic service TID3.exe –install –auto –depend “tcpip bufserv”

*Automatic service with service id

TID3.exe –serviceid X –install –auto –depend “tcpip bufserv”

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

Manual service TID3.exe –install –depend tcpip

Automatic service TID3.exe –install –auto –depend tcpip

*Automatic service with service id

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


19

Status of the ICU

Status of the Interface Service

Service installed or uninstalled


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

20

Interface Installation on OpenVMSOne of the first issues that must be resolved is where the interface should be installed. Should the interface be installed on the PI Server node or on a remote PINet node? OSIsoft recommends that the interface be installed on a PINet node. The primary function of the server node is to archive data and to service clients that request data. The PI Server should not need to compete with interfaces for the machine’s resources. If the interface is installed on a PINet node, then PINet must be installed on that node before the interface is installed. Refer to the PI 2.1.x Installation and Upgrade Handbook for installation instructions.

If the interface runs on a PINet node, interfaces can communicate to either a PI 2 Server or a PI 3 Server. If the interface runs on a PI 2 Server, the interface can only communicate to the PI 2 Server.

On a PINet node, PISysExe, PISysMgr, and PISysDat are all aliases for the PINet directory, and PIBuild is an alias for the PINetBuild directory.

Naming Conventions and RequirementsIn the installation procedure below, it is assumed that the interface executable is called TID3.exe, the startup command file for interactive processes is called tid3.com, and the startup command file for detached processes is called tid3detach.com.

Install the interface executable and command files in the PISysExe directory. If multiple instances of the interface must be run as interactive or detached processes, create multiply copies of the tid3.com file. For this purpose, it is customary to copy the tid3.com file to tid31.com for instance 1, to tid32.com for instance 2, and so on. The individual command files then need to be edited separately as appropriate.

Regardless of how many instances of the interface are running as interactive or detached processes, only one TID3.exe file and one tid3detach.com file are needed.

When the interface is run as a detached process, interface-specific log files are created in the PISysExe directory. The interface log files are .out, .log, or .txt. The log files typically have names similar to tid31.out, tid32.out, and so on.

Note: The interface will always write error and information messages to the PISysMgr:PIMessLog.txt file.

Interface Installation ProcedureInterface files are installed and linked automatically as part of PI or PINet installations. If the interface has been automatically installed, skip to the “Starting and Stopping the Interface” section, p. 87. Sometimes, however, an interface needs to be installed or upgraded separately from the PI or PINet installation. This procedure is frequently done when the available version of the interface is newer than that which is included with the PI or PINet distribution.

Interface files for OpenVMS-based interfaces are now distributed on CD-ROM readable by Windows machines. The appropriate files must be transferred over the network to the OpenVMS node. The following files are distributed.


Distribution Files

PI_GSETID3.DOCInterface manual (Microsoft Word Document). The interface-specific installation procedure is in this manual.

TID3_platform_version.BCK Saveset containing the interface files.

TID3_version.TXT Release notes.

Linking the Interface on OpenVMSThe interface requires the NovaTech D/3 software to be installed on the VAX in order to link. Each site must also choose the correct object file and modify tid3.opt based on the version of NovaTech D/3 software they are running.

Object FilesCustomers must choose which object file is correct for their site and rename the file to tid3.obj before linking. This means that linking of this interface still cannot be part of the standard PI Install procedure.

There are five object files delivered to each site. The site specific version of NovaTech D/3 software will determine which file to use. The files will have been copied to PIBuild along with all the other files needed to link the interface or manually copy them as described in the table below.

1. If NovaTech D/3 9.0 or higher is running, rename tid3090hardchangevax.obj or tid3090hardchangeaxp.obj to tid3.obj.

2. If NovaTech D/3 8.1-2 is running and the NovaTech D/3 software includes get_d3_lock, rename tid3281hardvax.obj or tid3281hardaxp.obj to tid3.obj.

3. If NovaTech D/3 8.1-2 is running and the NovaTech D/3 software does NOT include get_d3_lock, rename tid3281vax.obj or tid3281axp.obj to tid3.obj.

The only way to tell whether the site-specific system has get_d3_lock may be to try using the file compiled with the /HARDWARE switch and have the link declare that it cannot find get_d3_lock.

4. If NovaTech D/3 8.0-3 is running and the NovaTech D/3 software includes get_d3_lock, rename tid3380hardvax.obj or tid3380hardaxp.obj to tid3.obj.

5. If NovaTech D/3 8.0-3 is running and the NovaTech D/3 software does NOT include get_d3_lock, rename tid3380hardvax.obj or tid3380hardaxp.obj to tid3.obj.

The only way to tell whether the site-specific system has get_d3_lock may be to try using the file compiled with the /HARDWARE switch and have the link declare that it cannot find get_d3_lock.

TID3.optThis file is system dependent. This file must be changed to reflect the local system configuration before linking.! THIS FILE IS SITE SPECIFIC!!! This file must be changed to reflect the location of the necessary! shareables. You will need to locate the files on your system.


!! Define d3exe to point to the directory with these files.! It also uses different shareables depending on which version of D/3 software! is being used.!! Choose one of the sets below.!! For D/3 version 6 and above use this option.

D3exe:d3libshr/shareabled3exe:d3oslibshr/shareable

!! For D/3 version 5 and below use this option.! d3exe:d3libshr/shareable! d3exe:emclibshr/shareable!!-----------------------------------------------------------------------------!! 2-Jul-97 CG> Created! 9-Sep-98 CG> changed pibuild to d3exe

TID3Link.comLinking the interface is setup to be run from the PIBuild directory. The command file for compiling should have copied the necessary files to this directory. Many warnings will be generated due to the inclusion of timsub – ignore them.

To execute type:@tid3link

$! TID3Link.com$! This file is used to link the TID3 interface file.$! 950718 LLG release$! V 1.0$!==============================================================================$!$ Set NoOn$!$ define lnk$library sys$library:vaxcrtl$! The timsub include is there because of a conflict with the D3 libraries$! The link error declaring multiply defined labels for TIMSUB may be $! Disregarded$ If F$Search(“Pilink:tid3.opt”) .eqs. “” $ then $ copy tid3.opt pilink:$ endif$!$ Link/exe=pisysexe:TID3.exe tid3,uniint,pilink:pisubshr.olb/lib/inc=timsub, -

pilink:pitklib/opt,pilink:tid3/opt$!$! Copy the startup/shutdown command procedures to PISysExe:$ If (F$Search(“PISysExe:tid3.com”) .eqs. “”) then copy tid3.com PISysExe:


23

Interface Installation on OpenVMS

$ If (F$Search(“PISysExe:tid3detach.com”) .eqs. “”) $ then $ copy tid3detach.com PISysExe:$ endif$ If (F$Search(“PISysExe:tid3stop.com”) .eqs. “”) then copy tid3stop.com PISysExe:$!$ Exit

PIBuild and PISysExeAll the files listed below must be in the PIBuild directory before linking the interface. The link command procedure will copy the necessary files to PISysExe.

PIBuild DirectoryTID3.OBJ Object file for the interface.TID3.OPT Options file for the interface.UNIINT.OBJ Object file for the interfaceTID3LINK.COM Command procedure for re-linking the executable.

PISysExe directoryTID3.EXE Interface executable.TID3.COM Startup command file for interactive processes.

TID3DETACH.COMStartup command file for detached processes (the command-line parameters are still defined in the TID3.COM file).

TID3stop.com Command file for stopping the interface.

24

Digital StatesFor more information regarding Digital States, refer to the Data Archive Manuals.

PI 2 Home NodeDigital states are defined by running the Digtl Stat display from the PI menu. The states must be contiguous for each status type and may be anywhere within the Digital State Table outside of the range 193 - 320, which is reserved for OSIsoft. The digital states need to be defined prior to point configuration. The digital state sets described in the PI 3 sections below should be entered into the PI 2 Digital State Table.

For more information, see the DA manual.

PI 3 Home NodeDigital State SetsPI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI digital tags and editing digital state sets, see the PI Data Archive Manual for Windows NT and Unix manual.

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

System Digital State SetSimilar to digital state sets is the system digital state set. This set is used for all tags, regardless of type to indicate the state of a tag at a particular time. For example, if the interface receives bad data from an interface point, 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.

PointSourcePI 3 Server Nodes

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, one may choose the letter D to identify points that belong to the PI GSETID3 interface. To implement this, one would set the PointSource attribute to D for every PI Point that is configured for the PI GSETID3 interface. Then, if one uses /ps=D on the startup-command line of the PI GSETID3 interface, the interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of D. 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 AttributeIf the interface is running on a PINet node, use a capital letter (or a case-insensitive character such as a number, a question mark, etc.) for the PointSource attribute when defining points. For all other scenarios, the case of the PointSource is insignificant.

In all cases, 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. It is only necessary to be careful with the case of the PointSource during point definition and only if the Interface will be running on a PINet node communicating to a PI Server.

Reserved Point SourcesNo point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character

Several subsystems and applications that ship with PI are associated with default PointSource characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem uses G and @, 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 L (PI 2) or Lab (PI 3). Therefore, it would be confusing to use L or Lab as the PointSource character for an interface.

PI 2 Server NodesThe following point source characters are reserved on PI 2 systems and cannot be used as the point source character for an interface: C, ?, @, Q, T. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.

Before a PI point with a given point source can be created, the point source character must be added to the PI 2 point source table. For example, if point source D is not defined in the PI 2 point source table, a point with a point source of D cannot be created. This prevents the user from accidentally creating a point with an incorrect point source character.

Defining a Point Source Character in the PI 2 Point Source Table1. Enter PI by typing the following command from a OpenVMS command prompt:

@pisysexe:pi2. Select the PointSrc option from the menu.3. Select New from the menu.4. Assign a point source next to the Code: field. Also, assign minimum and maximum

values for the Location1 to Location5 attributes. Location1 Location2 Location3 Location4 Location5

Minimum 1 -1 0 1 -1

Maximum 50 256 2 20 1616

5. Select “Save” from the menu.

D/3 Point ConfigurationD/3 Versions 5.0 to 9.0-1

Changes to the D/3 database cause the shared memory regions that keep track of the Ethernet addresses and the display databases to be modified, but they are not updated in the interface. Subsequent calls to the D/3 continuous database will return –69 errors. The interface will rebuild any list that returns a –69 error, deleting the tag with the offending IPN from the list. The PI tag will be set to BAD INPUT and internally set to scan off. Every 10 minutes for up to 40 minutes the interface will attempt to add the tag back into an appropriate GLF list. If it cannot be added back in, the tag will be deleted from the interface. If the D/3 point is added back into the database later, the PI point will need to be modified in order for the interface to add the tag again.

Note: It is paramount that all changes to the D/3 database be made from a single file to prevent cycling within the interface for every point change.

D/3 Version 9.0-2 and HigherChanges to the D/3 database cause the shared memory regions that keep track of the Ethernet addresses and the display databases to be modified, but they are not updated in the interface. Starting with version 9.0-2, NovaTech provides a mechanism to programmatically recognize that the D/3 database has changed. The interface will rebuild any list that returns a –69 error, deleting the tag with the offending IPN from the list. The PI tag will be set to BAD INPUT and internally set to scan off. Every 10 minutes for up to 40 minutes the interface will attempt to add the tag back into an appropriate GLF list. If it cannot be added back in, the tag will be deleted from the interface. If the D/3 point is added back into the database later, the PI point will need to be modified in order for the interface to add the tag again.

OpenVMS Interface NodeTo activate this feature choose an object file with “change” in the filename and use the /CH command line parameter.

Windows Interface NodeTo activate this feature, use the /CH command-line parameter.

Note: It is paramount that all changes to the D/3 database be made from a single file to prevent cycling within the interface for every point change.

D/3 Point ListsThe interface can request or send up to 255 points of the same D/3 database block type at the same time for collection of continuous data. Several different field types can be included in a single request. This means that when PI points are grouped, it is important to be aware of the distribution of fields associated with the set of points within the group. If there are several PI points getting data from the same unit, block type, and the same set of fields, this will result in very efficient data access from the D/3 because all of the required data will be retrieved in one transaction. However, if a large group of PI tags accesses a large number of different blocks, but some points access many data fields and most access only a few fields, some inefficiency will result because the transaction that results will include all requested fields for all requested blocks.

To change the allocation of points to lists, edit the point attributes by using the POINT BLD display or by using the PIDIFF utility in PI 2 or PIConfig in PI 3. If massive changes are made to the PI point database, it is advisable to stop and restart the D/3 interface in order to expedite the changes taking effect.

Note: The most efficient list building is done by the interface and this is the recommended method of operation. Location2 should be set to 0 for the interface to build the lists.

D/3 Hardware ShutdownWhen the D/3 hardware or software is shut down, the interface must be shutdown. If the interface is allowed to run when the D/3 System is down, problems can arise in the D/3 System and in the interface. Some steps can be taken to minimize the potential problems with #1 being the best approach.

1. Add the /hw switch to the startup command line in the D3Set:sitestop.com (OpenVMS) or RunBeforeD3Stop.bat (Windows) file which will automatically shutdown the interface when the D/3 System is shutdown gracefully. If /stopstat=<digstate> is used on the command line, the digital state will be written to each input tag when the interface exits.

2. If the D/3 System is down, but the interface is still running, manually shut down the interface by typing:@pisysexe:stop tid3

If /stopstat=<digstate> is used on the command line, the digital state will be written to each input tag when the interface exits.

3. If the version of D/3 software in use has the routine get_d3_lock, then compiling the interface with /HARDWARE defined and using the /hw command line parameter when the interface is started will allow the interface to be notified by the D/3 system when a shutdown is in process so the interface can exit gracefully. If /stopstat=<digstate> is used on the command line, the digital state will NOT be written to each input tag when the interface exits. To be able to use the get_d3_lock routine, use one of the object files with “hard” in the filename.

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

Point AttributesUse the point attributes below to define the PI Point configuration for the Interface, including specifically what data to transfer.

TagA tag is a label or name for a point. Any tag name can be used in accordance to the normal PI point naming conventions.

LengthThe length of the Tag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.

PI API PI Server Maximum Length

1.6 or higher 3.4.370.x or higher 1023

1.6 or higher Below 3.4.370.x 255

Below 1.6 3.4.370.x or higher 255

Below 1.6 Below 3.4.370.x 255

PointSourceThe PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line parameter and the “Point Source” section.

PointTypeTypically, device point types do not need to correspond to PI point types. For example, integer values from a device can be sent to floating point or digital PI tags. Similarly, a floating-point value from the device can be sent to integer or digital PI tags, although the values will be truncated.

PI 2 Server NodesScaled real, full-precision real, integer, and digital point types are supported on PI 2 Servers. For more information on the individual point types, refer to the Data Archive (DA) section of PI System Manual I.

PI 3 Server NodesFloat16, float32, int16, int32, digital, and string point types are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for NT and UNIX.

Numerical & DiscreteTypically the PI point type will match the D/3 field data type. It is possible to use a PI point type that does not match the D/3 point type since the interface determines the D/3 point type when retrieving the D/3 internal IDs. Note that D/3 integer values can range between -32767 and 32767 so OSIsoft recommends configuring a type floating-point PI point if negative integer values are expected.

StringsThis interface supports reading of strings from the NovaTech D/3 when the PI home node is PI 3. Configure the point the same as any other point. String input to PI 3 is supported from an interface running on either OpenVMS or Windows. String output to the NovaTech D/3 is only supported from Windows.

OpenVMS Interface NodeDue to the lack of an extended PI API for the OpenVMS platform, string support has been added through the use of an FTP mechanism on the DEC computer and the Batch File interface running on the PI 3 home node. A string value is put into the Batch File interface compatible file in the following format:

pt_id,timestamp,stringThe default field separator is a comma, but this may be changed to match the default of the Batch File interface at the site by using the /FS=<field separator character> command line option.

Note: At this time, the Batch File interface must be used on the PI 3 home node to send string data to PI. See the section below on how to FTP the file to the PI 3 home node. Please contact OSI to obtain a copy of the Batch File interface if string data is to be collected. There is no additional charge for this interface when used to put D/3 string data into PI.

Windows Interface NodeThe interface uses extended PI API calls to send strings from the interface to a PI 3 home node. The Batch File interface is not required when the interface runs on Windows.

Location1Location 1 contains the interface number. The interface number must match that specified in PISysExe:TID3.com (OpenVMS) orTID3.bat(Windows) by the parameter /ID=n. This allows multiple instances of the interface to run using a single point source.

Location2This is the list number for continuous data and is also used to specify whether a point is input or output. Since Sequence variables and outputs do not use list numbers, Location2 should be zero for Sequence variables that are inputs and a negative value should be used for variables that are outputs.

Outputs = negative number as described below

Sequence variables = 0

When collecting continuous data, the interface sends and receives values for a list of D/3 fields in each message.

Note: The most efficient list building is done by the interface and this is the recommended method of operation. Location2 should be set to 0 for the interface to build the lists.

Continuous data – interface builds lists = 0

However, the user can control the grouping of fields into lists by specifying the list number in Location2. List numbers start at 1 and may be repeated for each scan class (Location 4), D/3 Unit, and D/3 Block Type combination. In general, the most efficient grouping will occur when points are grouped requesting the same field together into a given list.

Continuous data – user specifies list = 1 – X

When using a PI2 server, the user may edit the PI Point Source Table to prohibit outputs by limiting Location 2 to positive values.

OutputsThe user has the option of controlling what data gets sent, or not, to the DCS in the event that the PI value is a digital state. In this case, digital state means any digital state for a float or integer tag or a digital state not in the normal range for a digital state tag.

-1: Enter –1 to have the current value of the tag sent to the DCS, even if it is a digital state. (This is the action taken in interface version 3.19 and earlier.)

-2: Enter –2 to have no value sent to PI when the PI value is a digital state.

-3: Enter –3 to replace a digital state PI value with the value entered with the /val command-line parameter.

Location3Location 3 is used to specify the type and extent of data quality checking on Continuous Database items to be performed by the interface. A value of 1 in this Location indicates that the scan status of the D/3 scan block is to be checked. If the block is not being scanned, a No Data digital state will be sent to PI. If this Location contains a value of 2, the preceding check is performed and the status of the ALMCT field is checked for indications of D/3 hardware problems. If any problem is detected, a Bad Input state is generated. A value of 0 in this location indicates that neither of these checks is to be performed.

Do not perform any data quality checking = 0

Check if D/3 scan block is being scanned = 1

Check if D/3 scan block is being scanned and check ALMCT field = 2

Note: Only Continuous Database blocks AI, DEV, DIN, DOT, and DGR allow quality checking.

Location4Scan-based InputsFor interfaces that support scan-based collection of data, Location4 defines the scan class for the PI point. The scan class determines the frequency at which input points are

PI Point Configuration

scanned for new values. For more information, see the description of the /f parameter in the section called “The Startup Command File”.

Trigger-based Inputs, Unsolicited-Inputs, and Output PointsLocation 4 should be set to zero for these points.

Location5 This location is used to specify bit-masking operations for D/3 continuous database elements, short int data types only. The least significant bit is labeled bit 1 and the most significant bit is bit 16.

A four-digit code is used to specify a group of contiguous bits within an integer value to be masked and shifted. The low bit number is provided in the lower two digits and the high bit number is provided in the upper two digits. The lesser of the 2 numbers is used for shifting. For example, a value in location 5 of 1205 or 0512 would mask out bits 5 through 12 and shift the result four places (bits) to the right. For example if bits 5 and 12 are set, the value returned is 129.

A value of 0707 would mask bit 7 and shift 6 bits to the right.

Note: The above examples may seem confusing, but the interface does a conversion to count the least significant bit as zero.

Zero in this location means that no bit masking is to be used.

A value of –1 in this location indicates that the number of the first bit that is set is to be returned. The D/3 value is checked starting from the least significant bit. If no bits are set, a value of zero is returned. For example, if the D/3 value is 4, a value of 3 is returned because the binary representation is 0100. If the D/3 value is 24 a value of 4 is returned because the binary representation is 011000.

InstrumentTagLengthThe length of the InstrumentTag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.





Below 1.6 Below 3.4.370.x 32

This contains the specification of the D/3 data element to be accessed.

For continuous data, this consists of the D/3 External Point Name, block number, and field type each separated by a colon, ”:”. An example of a continuous database specification is: T1001:0:AI_MEAS

Note that the D3-specified Control Block can be selected by using CB as the block number. This will cause the block specified in the AI block as the D/3 control block to be accessed. As such, TI1001:0:AI_MEAS and TI1001:CB:AI_MEAS are equivalent.

For sequence data, the specification consists of Unit Name and variable name separated by a colon “:”. An example of a sequence database item specification is: UNITX:variable1

Note: The colon delimiter may be replaced by specifying a different character in the /itdelim=char parameter. For example, the EPN T1:003 cannot be read if the delimiter is a colon. If the delimiter is changed with /itdelim=|, then the InstrumentTag could be T1:003|0|AI_MEAS. The new delimiter will need to be used in every InstrumentTag when /itdelim=char is used.

ExDescLengthThe length of the Extended Descriptor field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.





Below 1.6 Below 3.4.370.x 80

The extended descriptor has multiple uses.

Continuous Database PointFor Continuous Database items the extended descriptor must contain: D3C

Sequence Database PointFor Sequence Database items the extended descriptor must contain: D3S

String TagIf the interface runs on an OpenVMS node, string tags must include the string “FTPSTRINGTAG” in the extended descriptor. This is because the interface will be running on a PI 2 PINet node, and the PI API on PI 2 cannot distinguish between PI points of type integer and PI points of type string. Unless "FTPSTRINGTAG" is found in the extended descriptor of a PI Point of type string, the PI Point will be assumed to be of type integer by the interface.

Performance PointsFor UniInt-based interfaces, the extended descriptor is checked for the string “PERFORMANCE_POINT”. If this character string is found, UniInt treats this point as a performance point. See the section called “Performance Points.”


Trigger-based InputsFor trigger-based input points, a separate trigger point must be configured. An input point is associated with a trigger point by entering a case-insensitive string in the extended descriptor (ExDesc) PI point attribute of the input point of the form:keyword=trigger_tag_name

where keyword is replaced by “event” or “trig” and trigger_tag_name is replaced by the name of the trigger point. There should be no spaces in the string. UniInt automatically assumes that an input point is trigger-based instead of scan-based when the keyword=trigger_tag_name string is found in the extended descriptor attribute.

An input is triggered when a new value is sent to the Snapshot of the trigger point. The new value does not need to be different than the previous Snapshot value to trigger an input, but the timestamp of the new value must be greater than (more recent than) or equal to the timestamp of the previous value. This is different than the trigger mechanism for output points. For output points, the timestamp of the trigger value must be greater than (not greater than or equal to) the timestamp of the previous value.

Conditions can be placed on trigger events. Event conditions are specified in the extended descriptor as follows:Event=‘trigger_tag_name’ event_condition

The trigger tag name must be in single quotes. For example,Event=‘Sinuoid’ Anychange

will trigger on any event to the PI Tag sinusoid as long as the next event is different than the last event. The initial event is read from the snapshot.

The keywords in the following table can be used to specify trigger conditions.

Event Condition

Description

Anychange Trigger on any change as long as the value of the current event is different than the value of the previous event. System digital states also trigger events. For example, an event will be triggered on a value change from 0 to “Bad Input,” and an event will be triggered on a value change from “Bad Input” to 0.

Increment Trigger on any increase in value. System digital states do not trigger events. For example, an event will be triggered on a value change from 0 to 1, but an event will not be triggered on a value change from “Pt Created” to 0. Likewise, an event will not be triggered on a value change from 0 to “Bad Input.”

Decrement Trigger on any decrease in value. System digital states do not trigger events. For example, an event will be triggered on a value change from 1 to 0, but an event will not be triggered on a value change from “Pt Created” to 0. Likewise, an event will not be triggered on a value change from 0 to “Bad Input.”

Nonzero Trigger on any non-zero value. Events are not triggered when a system digital state is written to the trigger tag. For example, an event is triggered on a value change from “Pt Created” to 1, but an event is not triggered on a value change from 1 to “Bad Input.”

Scan By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when

the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.

There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.

ShutdownPI 2 Server Nodes

The Shutdown attribute is not used if the server node is a PI 2 system. For information on configuring shutdown events for PI 2, see Data Archive (DA) section 4.2.3 of PI System Manual I.

PI 3 Server NodesThe shutdown attribute is used only if the server node is a PI 3 system.

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 Data Archive for NT and UNIX.

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.

One can disable SHUTDOWN events from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem 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 Data Archive for NT and UNIX.

BufservIt is undesirable to write shutdown events when Bufserv is being used. Bufserv is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when the Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when PI is shut down, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.

Output PointsOutput points control the flow of data from the PI Data Archive to any destination that is external to the PI Data Archive, such as a PLC or a third-party database. For example, to write a value to a register in a PLC, one would use an output point. Each interface has its own rules for determining whether a given point is an input point or an output point.


There is no de facto PI point attribute that distinguishes a point as an input point or an output point.

Outputs are triggered for UniInt-based interfaces. That is, outputs are not scheduled to occur on a periodic basis. There are two mechanisms for triggering an output.

Event conditions can be placed on triggered outputs. The conditions are specified using the same event condition keywords in the extended descriptor as described under “Trigger-Based Inputs.” The only difference is that the trigger tag is specified with the SourceTag attribute instead of with the “event” or “trig” keywords; otherwise, the behavior of event conditions described under ‘Trigger-based Inputs” are identical for output points. For output points, event conditions are specified in the extended descriptor as follows:event_condition

Trigger Method 1 (Recommended)For trigger method 1, a separate trigger point must be configured. The output point must have the same point source as the interface. The trigger point can be associated with any point source, including the point source of the interface. Also, the point type of the trigger point does not need to be the same as the point type of the output point.

The output point is associated with the trigger point by setting the SourceTag attribute of the output point equal to the tag name of the trigger point. An output is triggered when a new value is sent to the Snapshot of the trigger point. The new value does not need to be different than the previous value that was sent to the Snapshot to trigger an output, but the timestamp of the new value must be more recent than the previous value. If no error is indicated, then the value that was sent to the trigger point is also written to the output point. If the output is unsuccessful, then an appropriate digital state that is indicative of the failure is usually written to the output point. If an error is not indicated, the output still may not have succeeded because the interface may not be able to tell with certainty that an output has failed.

Trigger Method 2For trigger method 2, a separate trigger point is not configured. To trigger an output, write a new value to the Snapshot of the output point itself. The new value does not need to be different than the previous value to trigger an output, but the timestamp of the new value must be more recent than the previous value.

Trigger method 2 may be easier to configure than trigger method 1, but trigger method 2 has a significant disadvantage. If the output is unsuccessful, there is no tag to receive a digital state that is indicative of the failure, which is very important for troubleshooting.

Performance Point ConfigurationOne can configure performance points to monitor the amount of time in seconds that an interface takes to complete a scan for a particular scan class. The closer the scan completion time is to 0 seconds, the better the performance. The scan completion time is recorded to millisecond resolution

Configuring Performance Points with PI ICU (Windows)The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing Performance Points.

CreateTo create a Performance Point, right-click the line belonging to the tag to be created, and select Create.

DeleteTo delete a Performance Point, right-click the line belonging to the tag to be deleted, and select Delete.

CorrectIf the “Status” of a point is marked “Incorrect”, the point configuration can be automatically corrected by ICU by right-clicking on the line belonging to the tag to be corrected, and selecting Correct. The Performance Points are created with the following PI attribute values. If ICU detects that a Performance Point is not defined with the following, it will be marked Incorrect:

The Performance Points are created with the following PI attribute values:

Attribute Details

Tag Tag name that appears in the list box

Point Source Point Source for tags for this interface, as specified on the first tab

Compressing Off

Excmax 0

Descriptor Interface name + " Scan Class # Performance Point"

RenameRight-click the line belonging to the tag and select “Rename” in order to rename the Performance Point.

StatusThe Status column in the Performance Points table indicates whether the Performance Point exists for the scan class in column 2.

Created – Indicates that the Performance Point does exist

Not Created – Indicates that the Performance Point does not exist

Deleted – Indicates that a Performance Point existed, but was just deleted by the user

Scan ClassThe Scan Class column indicates which scan class the Performance Point in the Tagname column belongs to. There will be one scan class in the Scan Class column for each scan class listed in the Scan Classes combo box on the UniInt Parameters tab.

TagnameThe Tagname column holds the Performance Point tag name.

SnapshotThe Snapshot column holds the snapshot value of each Performance Point that exists in PI. The Snapshot column is updated when the Performance Points/Counters tab is clicked, and when the interface is first loaded.

Configuring Performance Points ManuallyPerformance point configuration is the same on all operating system platforms. Performance points are configured as follows.

1. Set the extended descriptor to:PERFORMANCE_POINTor to:PERFORMANCE_POINT=interface_idwhere interface_id corresponds to the identifier that is specified with the /id parameter on the startup command line of the interface. The character string PERFORMANCE_POINT is case insenstive. The interface_id does not need to be specified if there is only one copy of an interface that is associated with a particular point source.

2. Set Location4 to correspond to the scan class whose performance is to be monitored. For example, to monitor scan class 2, set Location4 to 2. See the /f parameter for a description of scan classes.

3. Set the PointSource attribute to correspond to the /ps parameter on the startup command line of the interface.

4. Set the PointType attribute to float32.

I/O Rate Tag ConfigurationAn I/O Rate point can be configured to receive 10-minute averages of the total number of exceptions per minute that are sent to PI by the interface. An exception is a value that has passed the exception specifications for a given PI point. Since 10-minute averages are taken, the first average is not written to PI until 10 minutes after the interface has started. One I/O Rate tag can be configured for each copy of the interface that is in use.

Monitoring I/O Rates on the Interface NodeFor Windows and UNIX nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook. For Open VMS nodes, the rate (events/minute) can be monitored with the PISysExe:IOMonitor.exe program or with another client program such as Process Book. The IOMonitor program is discussed on page DA-71 of PI System Manual I.

Configuring I/O Rate Tags with PI ICU (Windows)The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing I/O Rate Tags.

PI ICU currently allows for one I/O Rate tag to be configured for each copy of the interface that is in use. Some interfaces allow for multiple I/O Rate tags.

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

Tag StatusThe Tag Status column indicates whether the I/O Rate tag exists in PI. The possible states are:

Created – This status indicates that the tag exist in PI

Not Created – This status indicates that the tag does not yet exist in PI

Deleted – This status indicates that the tag has just been deleted

Unknown – This status indicates that the PI ICU is not able to access the PI Server

In FileThe In File column 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

Event CounterThe Event Counter correlates a tag specified in the iorates.dat file with this copy of the interface. The command line equivalent is /ec=x, where x is the same number that is assigned to a tag name in the iorates.dat file.

TagnameThe tag name listed under the Tagname column is the name of the I/O Rate tag.

SnapshotThe Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists in PI. The Snapshot column is updated when the IORates/Status Tags tab is clicked, and when the Interface is first loaded.

Right Mouse Button Menu OptionsCreateCreate the suggested I/O Rate tag with the tag name indicated in the Tagname column.

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

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

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

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

Configuring I/O Rate Tags ManuallyThere are two configuration steps.

1. Configuring the PI Point on the PI Server

2. Configuration on the Interface Node

Configuring the PI Point on the PI ServerPI 2 Server Nodes

A listing of the I/O Rate Tags that are currently being monitored can be obtained with the command:@PISysDat:IOMonitor.com

Create an I/O Rate Tag using one of the existing I/O Rate Tags as a template.

PI 3 Server NodesCreate an I/O Rate Tag with the following point attribute values.

Attribute Value

PointSource L

PointType float32

Compressing 0

ExcDev 0

Configuration on the Interface NodeFor the following examples, assume that the name of the PI tag is tid3001, and that the name of the I/O Rate on the home node is tid3001.

Windows Nodes1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The

PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the %windir% directory. If both are specified, the PIPCSHARE entry takes precedence.

Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.

Add a line in the iorates.dat file of the form:tid3001, x

where tid3001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x parameter in the startup command file. x can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.

2. Set the /ec=x parameter on the startup command file of the interface to match the event counter in the iorates.dat file.

I/O Rate Tag Configuration

The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.

Open VMS NodesI/O Rates are discussed on page DA-59 of PI System Manual I.

To implement an I/O Rate tag, perform the following steps:

1. Add a line to the PISysDat:IORates.dat file of the form:tid3001, xwhere tid3 is an abbreviation for the interface and x corresponds to the event counter specified by the first instance of the /ec=x parameter in the startup command file of the interface. x can be any number between 1 and 34 or between 51 and 200, inclusive. However, it is best to use an event counter, x, that is not equal to 1 because 1 is the default event counter for UniInt-based interfaces. The event counter, /ec=x, should be unique for each copy of the interface.

Note: The PISysDat:IORates.dat file must be edited on the node where the interface is running. That is, if the interface is running on a PINet node, then the PISysDat:IORates.dat file on the PINet node must be edited, not the PISysDat:IORates.dat file on the home node.

2. Set the /ec=x parameter on the startup command file of the interface to match the event counter in the PISysDat:IORates.dat file.

3. Stop and start the I/O Rates process with the following commands so that the changes take effect:@PISysExe:stop iorates@PISysExe:iorates.com

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

Notes for WindowsFor 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 ICUNote: PI ICU requires PI 3.3 or greater.

The NovaTech D/3 ICU Control for PI ICU has 2 sections. A yellow text box indicates that an invalid value has been entered, or that a required value has not been entered.

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 (tid3.bat) will be maintained by the PI ICU and all configuration changes will be kept in that file. The procedure below describes the necessary steps for using PI ICU to configure the PI GSETID3 Interface.

From the PI ICU menu, select Interface, NewWindow Interface Instance form EXE…, and then Browse to the TID3.exe executable file. Then, enter values for Point Source and Interface ID#. A window such as the following results:

“Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name and it will be the display name in the services menu.

Click on Add.

The following display should appear:

Note that in this example the Host PI System is localhost, which means that the interface will be configured to communicate with the local PI Server. However, to configure the interface to communicate with a remote PI Server, select the ‘Connections…’ item from PI ICU menu and make it the default server. If the remote node is not in the list of servers, add that in.

Once the interface is added to PI ICU, near the top of the main PI ICU screen, the Interface Type should be gsetid3. If not, use the drop-down box to change the Interface Type to be gsetid3.

Click on Apply to enable the PI ICU to manage this copy of the PI GSETID3 Interface.

General ParametersThe following interface-specific parameters can be configured on the GSETID3 tab shown above.

Specify delimiter other than colon (:) in InstrumentTagThis optional parameter is the character used as the delimiter in the InstrumentTag point attribute. By default, a colon (:) is used as the InstrumentTag delimiter. This is useful when the EPN on the D/3 uses embedded colons. Note that lower-case characters and the following list of characters are not allowed for /ITDELIM values:

% ^ & “ | < >

The command-line parameter equivalent is (/ITDELIM=x).

Treat GLF errors for continuous points differentlyThis optional parameter indicates that the interface should treat GLF errors for continuous points differently. By default, GLF errors will cause the interface to rebuild the internal lists and recovery takes place. If this option is selected in the ICU Control, the user can specify the number of minutes to delay after a GLF error occurs before making another GLF call. (/KS=#).

Note: The /KS option is provided for only specific instances where it has been needed. In General, this option should NOT be used.

Startup Command File

Send the value to the DCS if the PI tag has a digital stateThis optional parameter allows the user to specify a value that will be sent to PI if the PI tag has a digital state. This value is used in conjunction with a value of -3 in the PI tag’s Location2 attribute. (/VAL=#)

Check for D/3 database updatesThis optional parameter notifies the interface to programmatically check for D/3 database updates. If this option is NOT specified, the interface will only detect changes when a -69 error is returned from a GLF call. This option should always be used on Windows. (/CH).

D/3 will notify interface of hardware shutdownThis optional parameter indicates that the D/3 can notify the interface that there is a hardware shutdown. The interface will shutdown after writing shutdown messages to each input tag. The interface should then be restarted from the D/3 sitestartup.com (OpenVMS) or RunAfterD3Start.bat (Windows). This option should always be used on Windows. (/HW)

Store Null strings as blank strings in PIThis optional parameter will cause NULL strings to be stored in PI as blank strings. The default is to leave the string NULL. (/BL)

Do not use sequential databaseThis optional parameter tells the interface not to use the sequential database or that the sequential database is unavailable. (/NOSEQ)

Debug ParametersFor debugging purposes the user can set the interface to send extra interface specific messages to the pipc.log file. There are six different types of debugging messages. These will be sent to the log depending on which check box was selected in the Debug Parameters section of the GSETID3 tab. For details of the available options see the Debugging section. (/DB=#, where # is 1, 2, 4, 8, 16, 32 or a combination of any or all values, maximum=63)

Additional ParametersThis text box is included so that any additional parameters not currently support by the ICU Control can be added to the interface. Parameters should be entered into the additional parameters textbox in command-line format with each parameter starting with a “/”character.

General TabThe following parameters can be configured on the General PI ICU tab shown above:

Point sourceThe point source is used to identify points for this interface and is a required parameter. The point source that is assigned with this parameter corresponds to the pointsource attribute of individual PI points. The interface will attempt to load only those PI points with the appropriate point source. The point source is generally a single character but if the PI SDK is enabled can be more than one character. The point source is case insensitive. (/PS=E)

Host This is the PI server node. Select the PI server from the drop down list. If the server is not listed in the drop down list, use the triple dot button to browse to the Connections Dialog and add the server. The added server will then be available in the drop down list. (/HOST=hostname[:port])

Interface ID #This required parameter is an integer that is used to identify a particular copy of an interface. The ID should match the value in Location 1 of points for this copy of the interface. This identifier is also added to the header that is used to identify error messages as belonging to a particular interface. (/ID=#)


Other UniInt ParametersOther optional parameters that can be configured on the UniInt tab include:

Enable PI SDKBy default, the PI SDK is disabled. If the PI SDK is enabled, the ExDesc tag attribute can be 1024 characters long instead of 80 characters long. In addition, the excmin and excmax tag attributes will be full 32-bit values, and the point source can have more than one character. To enable the PI SDK select the Enable radio button in the PI SDK section of the UniInt tab. (/PISDK=x)

Queue DataExceptions can be queued before they are sent to the PI Server node. Queuing exceptions causes the interface to be more efficient, if the interface is on a separate computer from the PI Server. However, it will slightly delay the update of the snapshot value if the data rate is low. The maximum queue size is close to 4000 bytes. The queue is flushed between scans if it is not filled. To use this option check “Queue data” in the Data Handling section of the UniInt tab. (/Q)

Write Digital State to Tags on ShutdownThe interface can be configured to write a digital state to each PI point serviced by the interface when the interface shuts down. To use this option check “Write status to tags on shutdown” in the Data Handling section of the UniInt tab and select the required digital state from the dropdown list. If this option is not checked nothing will be written to the interface points when the interface shuts down. (/shutdown=digstate)

Note: The UniInt End User Document includes details about other command line parameters, which may be useful.

Notes for OpenVMSFor OpenVMS, command file names have a .com extension. The OpenVMS continuation character (-) allows one to use multiple lines in the command file. However, the maximum number of characters in a single or multi-line command is 256 characters. That is, adding continuation characters may make the command file easier to read, but they do not extend the 256-character limitation. The 256-character limitation can be overcome by putting the parameters in a separate argument file. See the /arg file command-line parameter in The UniInt End User Document for details.

Note: The UniInt End User Document includes details about other command line parameters, which may be useful.

Command-Line ParametersParameter Description

/blOptional

This will cause NULL strings to be stored in PI as blank strings. The default is to leave the string NULL.

/chOptional

This parameter notifies the interface to programmatically check for D/3 database updates. If this option is NOT specified, the interface will only detect changes when a –69 error is returned from a GLF call.One should always use this option on Windows.

/db=#/dbOptional

This is an optional command line switch that will turn on additional interface debugging messages.(#=message level.) Supported debug levels: /db=1 D/3 tag information /db=2 D/3 source tag information /db=4 D/3 sequence data status /db=8 D/3 read/write status /db=16 Digital output values /db=32 Internal testing use onlyNote: Debug levels may also be combined. For example, to print all messages from levels 1 and 2, set the debug level to 3 (/db=3).

/ec=xOptional

The first instance of the /ec parameter on the command line is used to specify a counter number, x, for an I/O Rate point. If x is not specified, then the default event counter is 1. Also, if the /ec parameter is not specified at all, there is still a default event counter of 1 associated with the interface. If there is an I/O Rate point that is associated with an event counter of 1, each copy of the interface that is running without /ec=x explicitly defined will write to the same I/O Rate point. This means that one should either explicitly define an event counter other than 1 for each copy of the interface or one should not associate any I/O Rate points with event counter 1. Configuration of I/O Rate points is discussed in the section called “I/O Rate Tag Configuration,” p. 45.For interfaces that run on Windows nodes, subsequent instances of the /ec parameter may be used by specific interfaces to keep track of various input or output operations. One must consult the interface-specific documentation to see whether subsequent instances of the /ec parameter have any effect. Subsequent instances of the /ec parameter can be of the form /ec*, where * is any ASCII character sequence. For example, /ecinput=10, /ecoutput=11, and /ec=12 are legitimate choices for the second, third, and fourth event counter strings.

/f=SSor/f=SS,SSor /f=HH:MM:SSor/f=HH:MM:SS,hh:mm:ss

Required for reading

The /f parameter defines the time period between scans in terms of hours (HH), minutes (MM), and seconds (SS). The scans can be scheduled to occur at discrete moments in time with an optional time offset specified in terms of hours (hh), minutes (mm), and seconds (ss). If HH and MM are omitted, then the time period that is specified is assumed to be in seconds. Each instance of the /f parameter on the command line defines a scan class for the interface. There is no limit to the number of scan classes that can be defined. The first occurrence of the /f parameter on the command line defines the first scan class of the interface, the second


Parameter Description

scan-based inputs occurrence defines the second scan class, and so on. PI Points are associated with a particular scan class via the Location4 PI Point attribute. For example, all PI Points that have Location4 set to 1 will receive input values at the frequency defined by the first scan class. Similarly, all points that have Location4 set to 2 will receive input values at the frequency specified by the second scan class, and so on. Two scan classes are defined in the following example:/f=00:01:00,00:00:05 /f=00:00:07or, equivalently:/f=60,5 /f=7The first scan class has a scanning frequency of 1 minute with an offset of 5 seconds, and the second scan class has a scanning frequency of 7 seconds. When an offset is specified, the scans occur at discrete moments in time according to the formula:scan times = (reference time) + n(frequency) + offsetwhere n is an integer and the reference time is midnight on the day that the interface was started. In the above example, frequency is 60 seconds and offset is 5 seconds for the first scan class. This means that if the interface was started at 05:06:06, the first scan would be at 05:06:10, the second scan would be at 05:07:10, and so on. Since no offset is specified for the second scan class, the absolute scan times are undefined.The definition of a scan class does not guarantee that the associated points will be scanned at the given frequency. If the interface is under a large load, then some scans may occur late or be skipped entirely. See the section called “Performance Point Configuration” for more information on skipped or missed scans.

/fs=xOptional, PI 2 PINet only,default: /fs=,

The /fs parameter is used to set the field separator in the files that are used for UniInt's automatic ftp mechanism for sending string tags from a PI2 PINET node to a PI 3 Server node.The default field separator is a comma (,).

/host=host:portRequired for WindowsNot implemented for OpenVMS interface nodes

The /host parameter is used to specify the PI Home node. host is the IP address of the PI Sever node or the domain name of the PI Server node. port is the port number for TCP/IP communication. The port is always 5450 for a PI 3 Server and 545 for a PI 2 Server. It is recommended to explicitly define the host and port on the command line with the /host parameter. Nevertheless, if either the host or port is not specified, the interface will attempt to use defaults. Defaults:The default port name and server name is specified in the pilogin.ini or piclient.ini file. The piclient.ini file is ignored if a pilogin.ini file is found. Refer to the PI API Installation Instructions manual for more information on the piclient.ini and pilogin.ini files.Examples:The interface is running on a PI API node, the domain name of the PI 3 home node is Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host parameters would be:/host=marvin /host=marvin:5450


/host=206.79.198.30/host=206.79.198.30:5450

/hwOptional

This parameter indicates that the D/3 can notify the interface that there is a hardware shutdown. The interface will shutdown after writing shutdown messages to each input tag. The interface should then be restarted from the D/3 sitestartup.com (OpenVMS) or RunAfterD3Start.bat (Windows). This option should always be used on Windows.

/id=xHighly Recommended

The /id parameter is used to specify the interface identifier. The interface identifier is a string that is no longer than 9 characters in length. UniInt concatenates this string to the header that is used to identify error messages as belonging to a particular interface. See the section called “Error and Informational Messages” for more information, page 95.UniInt always uses the /id parameter in the fashion described above. This interface also uses the /id parameter to identify a particular interface copy number that corresponds to an integer value that is assigned to Location1. For this interface, one should use only numeric characters in the identifier. For example,/id=1

/itdelim=xDefault:/itdelim=:

Specify a delimiter other than a colon for use in the InstrumentTag point attribute. This is useful when the EPN on the D/3 uses embedded colons. Note: The following characters are not allowed for the /itdelim value: % ^ & “ | < >Please note that lower-case characters are also not supported in the /itdelim field.

/ks=#Optional

This parameter indicates that the interface should treat GLF errors for continuous points differently. Normal operation is that GLF errors cause the interface to rebuild the internal lists and recovery takes place.If the parameter is /KS or /KS=0, the interface will exit immediately upon ANY error from the GLF call.If the parameter is /KS=# where # is a positive number, the interface will delay # number of minutes before making another GLF call. This allows time for maintenance of connection to the D/3.Note: We have only had one customer who has needed this option. It is suggested that the interface be run without it unless errors abound.

/maxstoptime=stoptime(Windows only)Optional

When a Windows service is stopped, the service control manager spawns a new thread for the exit handler. The exit handler sets the “keep going” parameter for the interface to false and then waits a maximum of stoptime seconds for the main thread to reach a safe exit point before the exit handler continues with its cleanup operations. By default, stoptime is 120 seconds. If stoptime seconds are exceeded, the exit handler will continue with its cleanup operations and then force the interface to exit.

/noseqOptional

Do not use the sequential database or it is unavailable.



/ps=xRequired

The /ps parameter specifies the point source for the interface. x is not case sensitive and can be any single character. For example, /ps=P and /ps=p are equivalent. The point source that is assigned with the /ps parameter corresponds to the PointSource attribute of individual PI Points. The interface will attempt to load only those PI points with the appropriate point source.

/qOptional for Windows Not implemented for interfaces on OpenVMS nodes

When the /q parameter is present, Snapshots and exceptions are queued before they are sent to the PI Server node. The maximum queue size is 255 bytes for a PI 3 Server and 36 bytes for a PI 2 Server. For example, if the interface is running on a UNIX node and is communicating to a PI 2 Server, then the maximum queue size is 36. The queue is flushed between scans if it is not filled.When the /q parameter is specified in non-extended API mode, the PI API sends integer values as 16-bit integers instead of 32-bit integers. Therefore, integer points will be limited to values between 0 and 32767. Values higher than 32767 need to be sent to floating-point PI tags.

/sioOptional

The /sio parameter stands for “suppress initial outputs.” The parameter applies only for interfaces that support outputs. If the /sio parameter is not specified, the interface will behave in the following manner.When the interface is started, the interface determines the current Snapshot value of each output tag. Next, the interface writes this value to each output tag. In addition, whenever an individual output tag is edited while the interface is running, the interface will write the current Snapshot value to the edited output tag.This behavior is suppressed if the /sio parameter is specified on the command line. That is, outputs will not be written when the interface starts or when an output tag is edited. In other words, when the /sio parameter is specified, outputs will only be written when they are explicitly triggered.

Parameter Description/stopstator/stopatat=digstate

Default:/stopstat=”Intf Shut”

Optional

If the /stopstat parameter is present on the startup command line, then the digital state Intf Shut will be written to each PI Point when the interface is stopped.

If /stopstat=digstate is present on the command line, then the digital state, digstate, will be written to each PI Point when the interface is stopped. For a PI 3 Server, digstate must be in the system digital state table. For a PI 2 Server, where there is only one digital state table available, digstate must simply be somewhere in the table. UniInt uses the first occurrence in the table.

If neither /stopstat nor /stopstat=digstate is specified on the command line, then no digital states will be written when the interface is shut down.

Note: The /stopstat parameter is disabled If the interface is running in a Uniint failover configuration as defined in the “Error: Reference source not found” section of this manual. Therefore, the digital state, digstate, will not be written to each PI Point when the interface is stopped. This prevents the digital state being written to PI Points while a redundant system is also writing data to the same PI Points. The /stopstat parameter is disabled even if there is only one interface active in the failover configuration.

Examples:/stopstat=shutdown/stopstat=”Intf Shut”

The entire digstate value should be enclosed within double quotes when there is a space in digstate.

/val=#Optional

Use this optional parameter in conjunction with –3 in location 2 to send the number # to the DCS when the tag has a digital state PI value.


Sample TID3.bat FileThe following is an example file:REM=======================================================================REM TID3.batREM ==============================================================REMREM Sample startup file for the Novatech D/3 Interface to the PI SystemREMREM=======================================================================REM REM OSIsoft strongly recommends using PI ICU to modify startup files.REMREM Sample command lineREM TID3.exe ^ /id=1 ^ /ps=4 ^ /hw ^ /ch ^ /host=host:5450 ^ /f=00:00:10 ^ /f=5 ^ /f=1 ^ /sioREMREM End of TID3.bat File

UniInt Failover ConfigurationIntroduction

UniInt provides support for a hot failover configuration. When properly configured, the interface will provide a no data loss solution for bi-directional data transfer between the PI Server and the Data Source given a single point of failure in the system architecture. This failover solution requires that two copies of the interface be installed on different PI Interface nodes collecting data simultaneously from a single data source. Each copy of the interface participating in failover has the ability to monitor and determine liveliness and failover status. Moreover, the failover operation is automatic and operates with no user interaction. To assist in administering system operations, the ability to manually trigger failover to a desired copy of the interface is also supported by this failover scheme. Implementing the UniInt failover solution requires configuration of the startup command file, Data Source failover control points, and PI failover control tags as described below.

Each copy of the interface participating in the failover solution will queue two intervals worth of data to prevent any data loss. When a failover occurs, there may be a period of overlapping data for up to 2 intervals. The exact amount of overlap is determined by the timing and the cause of the failover and may be different every time. Using the default update interval of 1 second will result in overlapping data between 0 and 2 seconds. The no data loss claim is based on a single point of failure. If both copies of the interface have trouble collecting data for the same period of time, data will be lost during that time.

The failover scheme is described in detail in the UniInt End User Document, which is a supplement to this manual.

Failover Installation ChecklistThe checklist below may be used to configure this Interface for failover. The failover configuration requires the two copies of the interface participating in failover be installed on different nodes. Users should verify non-failover interface operation as discussed in the “Installation Checklist” section of this manual prior to configuring the interface for failover operations. If not familiar with UniInt failover configuration, return to this section after reading the rest of the “UniInt Failover Configuration” section in detail. If a failure occurs at any step below, correct the error and start again at the beginning of the checklist. For the discussion below, the first copy of the interface configured and tested will be considered the primary interface and the second copy of the interface configured will be the backup interface.

1. Verify non-failover interface operation as described in the “Installation Checklist” section of this manual.

2. Use the PI ICU to modify the startup command file to include the proper UniInt failover startup command-line parameters: /UFO_ID and /UFO_OtherID. See the “PI ICU Configuration” section below.

3. Create and initialize the required failover Active ID and Heartbeat control tags on the Data Source. See the “Data Source Failover Control Point Configuration” section below.

4. Create and initialize the six required failover PI Point on the PI Server for the Active ID and Heartbeat control tags. See the section Data Source Failover Control Point Configuration below for instructions. Pay particular attention to the PointSource, Location1, and ExDesc attributes.

5. If using PI APS to synchronize the Data Source and PI points, special attention must be paid to the failover control points and tags. Check that the failover control points and tags are not included in the PI APS synchronization scheme. Synchronizing the control points will cause the failover tags to be edited by PI APS and may result in possible interface shutdown.

6. Start the primary interface interactively without buffering.

7. Verify a successful interface start by reviewing the pipc.log file. The log file will contain messages that indicate the failover state of the interface. A successful start with only a single interface copy running will be indicated by an informational message stating “UniInt failover: Interface in the "Primary" state and actively sending data to PI. Backup interface not available.” If the interface has failed to start, an error message will appear in the log file. For details relating to informational and error messages, refer to the “Messages” section below.

8. Verify data on the D/3 Server.

The Active ID control point on the D/3 Server must be set to the value of the running copy of the interface as defined by the /UFO_ID startup command-line parameter.

9. Verify data on the PI Server using available PI tools.

The Active ID control tag on the PI Server must be set to the value of the running copy of the interface as defined by the /UFO_ID startup command-line parameter.

10. Stop the primary interface.

11. Start the backup interface interactively without buffering. Notice that this copy will become the primary because the other copy is stopped.

12. Repeat steps 7, 8, and 9.

13. Stop the backup interface.

14. Start buffering.

15. Start the primary interface interactively.

16. Once the primary interface has successfully started and is collecting data, start the backup interface interactively.

17. Verify that both copies of the interface are running in a failover configuration.

Review the pipc.log file for the copy of the interface that was started first. The log file will contain messages that indicate the failover state of the interface. The state of this interface must have changed as indicated with an informational message stating “UniInt failover: Interface in the “Primary" state and actively sending data to PI. Backup interface available.” If the interface has not changed to this state, browse the log file for error messages. For details relating to informational and error messages, refer to the “Messages” section below.

Review the pipc.log file for the copy of the interface that was started last. The log file will contain messages that indicate the failover state of the interface. A successful start of the interface will be indicated by an informational message stating “UniInt failover: Interface in the “Backup” state.” If the interface has failed to start, an error message will appear in the log file. For details relating to informational and error messages, refer to the “Messages” section below.

18. Verify data on the D/3 Server.

The Active ID control point on the D/3 Server must be set to the value of the running copy of the interface that was started first as defined by the /UFO_ID startup command-line parameter.

19. Verify data on the PI Server using available PI tools.

The Active ID control tag on the PI Server must be set to the value of the running copy of the interface that was started first as defined by the /UFO_ID startup command-line parameter.

20. Test Failover by stopping the primary interface.

21. Verify the backup interface has assumed the role of primary by searching the pipc.log file for a message indicating the backup interface has changed to the “UniInt failover: Interface in the "Primary" state and actively sending data to PI. Backup interface not available.” The backup interface is now considered primary and the previous primary interface is now backup.

22. Verify no loss of data in PI. There may be an overlap of data due to the queuing of data. However, there must be no data loss.

23. Start the backup interface. Once the primary interface detects a backup interface, the primary interface will now change state indicating “UniInt failover: Interface in the "Primary" state and actively sending data to PI. Backup interface available.” in the pipc.log file.

24. Verify the backup interface starts and assumes the role of backup. A successful start of the backup interface will be indicated by an informational message stating “UniInt failover: Interface in "Backup” state.” Since this is the initial state of the interface, the informational message will be near the beginning of the start sequence of the pipc.log file.

25. Test failover with different failure scenarios (e.g. loss of PI connection for a single interface copy). UniInt failover guarantees no data loss with a single point of failure. Verify no data loss by checking the data in PI and on the data source.

26. Stop both copies of the interface, start buffering, start each interface as a service.

27. Verify data as stated above.

28. To designate a specific interface as primary, set the Active ID point on the Data Source Server of the desired primary interface as defined by the /UFO_ID startup command-line parameter.

Startup Command File ConfigurationNote: The /stopstat parameter is disabled If the interface is running in a UniInt failover configuration as defined by this section. Therefore, the digital state, digstate, will not be written to each PI Point when the interface is stopped. This prevents the digital state

UniInt Failover Configuration

being written to PI Points while a redundant system is also writing data to the same PI Points. The /stopstat parameter is disabled even if there is only one interface active in the failover configuration.

There are three interface startup parameters that control UniInt failover: /UFO_ID and /UFO_OtherID. UFO stands for UniInt Failover. The /UFO_ID and /UFO_OtherID parameters are required for the interface to operate in a failover configuration. All parameters specified must be configured correctly at interface startup. If they are not, the interface will not start and an error message will be printed to the interface log file. All existing UniInt startup parameters (e.g., /ps, /id, /q, /sn, etc.) will continue to function as documented and must be identical in both copies of the interface. Each of the failover startup parameters is described below.


/UFO_ID=nRequired

The required /UFO_ID startup parameter specifies the failover ID for the current copy of the interface. Each copy of the interface requires a failover ID specified by the /UFO_ID=n. The value, n, represents the identification number for this copy of the interface. Each copy of the interface must also know the failover ID for the redundant instance of the interface specified by the /UFO_OtherID=m. The integer number, n, used for /UFO_ID must be different than the number, m, used for /UFO_OtherID. The failover ID for both copies of the interface must be a positive integer.

The failover ID is written to the Active ID point when the interface attempts to become the primary interface. The failover ID is also used to identify the Heartbeat tag for this copy of the interface. For more information on Heartbeat tag configuration, see the “Heartbeat” section below.

/UFO_OtherID=mRequired

The required /UFO_OtherID startup parameter specifies the failover ID for the redundant copy of the interface. Each copy of the interface requires a redundant failover ID specified by the /UFO_OtherID=m. The value, m, represents the identification number for the redundant interface instance. Moreover, m must be a positive integer and must differ from the value, n, provided by the /UFO_ID=n parameter.

The other failover ID is used in conjunction with the Active ID point to determine when the redundant interface is primary. The other failover ID is also used to identify the Heartbeat tag for the redundant interface copy. For more information on Heartbeat tag configuration, see the section below.

Sample Interface Startup FilesThe following is an example of the TID3 interface configured for UniInt failover. In this example, the interface name is TID3 and the interface executable is TID3.exe. The two interface copies are installed on different PI Interface nodes. The interface nodes are referred to as IFNode1 and IFNode2. Any additional command-line parameters needed

for the interface would be identically defined in both startup command-line files. The startup command file for the interface on IFNode1 would be defined as follows:

The startup command file for the interface on IFNode1 would be defined as follows:

TID3.exe /PS=D /ID=1 /UFO_ID=1 /UFO_OtherID=2

The startup command file for the interface on IFNode2 would be defined as follows:

TID3.exe /PS=D /ID=1 /UFO_ID=2 /UFO_OtherID=1

CAUTION: The only differences in the startup parameters for the two interface copies are the /UFO_ID and /UFO_OtherID startup parameters. These parameters must be the reverse of one another. A configuration error in these parameters could result in no data being collected from either copy of the interface.

PI ICU ConfigurationThe use of the PI ICU is the recommended and safest method for configuring the Interface for UniInt failover. With the exception of the notes described in this section, the Interface shall be configured with the PI ICU as described in the “Configuring the Interface with the PI ICU” section of this manual.

Note: With the exception of the /UFO_ID and /UFO_OtherID startup command-line parameters, the UniInt failover scheme requires that both copies of the interface have identical startup command files. This requirement causes the PI ICU to produce a message when creating the second copy of the interface stating that the “PS/ID combo already in use by the interface” as shown in Figure 1 below. Ignore this message and click the Add button.

Figure 1: PI ICU configuration screen displaying a message that the “PS/ID combo already in use by the interface.” The user must ignore the yellow boxes, which indicate errors, and click the Add button to configure the interface for failover.


There are three interface startup parameters that control UniInt failover: /UFO_ID and /UFO_OtherID. The UFO stands for UniInt Failover. The /UFO_ID and /UFO_OtherID parameters are required for the interface to operate in a failover configuration. Each of these parameters is described in detail in Startup Command File Configuration section above. These parameters must be entered into the Additional Parameters text field located under the interface ICU Control tab in the PI ICU utility.

Figure 2: PI ICU configuration screen showing the UniInt failover startup parameters entered in the Additional Parameters text field. This copy of the interface defines /UFO_ID=1 and /UFO_OtherID=2. The other failover interface copy must define /UFO_ID=2 and /UFO_OtherID=1 in its Additional Parameters field.

Data Source Failover Control Point ConfigurationIn order to synchronize the two copies of the interface, there must be three interface Control Points defined on the Data Source. There must be one Active ID control point and each copy of the interface will have one Heartbeat control point. These control points must be initialized to a valid value that when read by the interface would not produce an error that would write a system digital state value to PI. An example SABL

program; PI.MDL.txt, is provided that shows the configuration of the Control Points. To download these programs please see the D3Edit section of the D/3 documentation set.

Note: Data Source control points that cannot be initialized may produce a bad result when read by UniInt failover and cause the interface to fail. If the points on the Data Source cannot be initialized and return a bad result to the interface, bypass failover operations by removing the failover startup command-line parameters and run the interface in a non-failover configuration. Force an output value from PI to each of the failover control points; Active ID and Heartbeat points. To output a value for the interface specific Heartbeat point, each interface participating in failover will need to be run separately. Once the values on the Data Source are valid, insert the proper failover startup command-line parameters and restart the interface.

Active IDThe Active ID point is used to identify which copy of the interface will act as the primary interface sending data to PI. The UniInt failover scheme will determine which copy of the interface will act as the primary copy and which will act as the backup copy of the interface. The primary copy of the interface will set the Active ID control point on the Data Source to the value of its ID as defined by the /UFO_ID=n startup command-line for the primary interface copy. The status of an interface as primary or backup can be changed by simply changing the value of the Active ID control point on the Data Source to the ID of the desired primary copy of the interface.

During a normal interface shutdown sequence, the interface will write a value of zero to the Active ID control point if the interface is in a primary role as indicated by the Active ID control point. Setting the Active ID control point to zero allows the backup copy of the interface to quickly transition to the primary role.

D/3 Control Tag Configuration for Active ID Point

EPN BlockACTIVEID AI

HeartbeatThe two Heartbeat control points are used to monitor the liveliness of the failover configuration. Each copy of the interface is assigned one Heartbeat control point on the Data Source to write (output) values. Each copy of the interface also reads (input) the value of the Heartbeat control point of the other interface in the failover configuration. Simply put, the concept of operation for the Heartbeat control point is for each copy of the interface to output a Heartbeat value to its Heartbeat control point and read the Heartbeat value of the other copy of the interface.

During a normal interface shutdown sequence, the interface will write a value of zero to its Heartbeat control point. Setting the Heartbeat control point to zero allows the backup copy of the interface to quickly transition to the primary role.

D/3 Control Tag Configuration for Heartbeat Points

EPN BlockIF1HRTBEAT AI IF2HRTBEAT AI


Control Point Data FlowThe figure below shows the data flow to and from the Heartbeat and Active ID control points for a typical failover configuration.

PI Failover Control Tag Configuration

CAUTION: Users must not delete the failover control tags once the interface has started. Deleting any of the failover control tags after interface startup will cause the interfaces in the failover scheme to shutdown and log an error message to the pipc.log file.

For details on proper configuration of failover control tags, refer to the sections below. It is highly recommended that the PI System Administrator be consulted before any changes to failover tags are made.

Synchronization of the two failover interface copies requires the configuration of six PI tags that are used to send and received data for each of the Data Source failover control points. All six PI tags must be configured correctly at interface startup or the interface will not start and an error message will be logged to the interface log file. The six PI tags are used exclusively for configuring the interface control points. Values written to a Data Source failover control point are also written to the corresponding PI tag as a historical record.

The only PI tag attribute used specifically for Data Source failover control point configuration is the ExDesc attribute. All other PI tag attributes are configured according to the interface documentation. For example, the PointSource attribute must match the /ps interface startup parameter or the interface will not load the PI tag.

The interface installation kit includes the sample file, UniInt_Failover_Sample_PI_Tags.xls that can be used with the Tag Configurator add-in for Excel to create UniInt failover control tags. Simply modify the point attributes as described in the sections below and use the Configurator to create the tags on the PI server.

Note: The PointSource and Location1 attributes must be identical for all the failover control tags in the failover scheme and must match the PointSource and Location1 attributes for PI tags loaded by the interface. Failure to comply with this rule will result in the interface failing to start.

Active IDThe Active ID tag is used to identify which copy of the interface will act as the primary interface sending data to PI. For a redundant interface installation, one interface Active ID input tag and one Active ID output tag must be configured. The Active ID input tag must be configured to read from the Active ID control point on the Data Source. Whereas the Active ID output tag must be configured to write to the Active ID control point on the Data Source. The Active ID tags must be successfully loaded or the interface will log a message to the interface log and fail to start.

To configure the interface Active ID tag, the string [UFO_ActiveID] must be found in the ExDesc attribute of the PI tag. The UFO_ActiveID keyword is not case sensitive. The square brackets must be included. The Interface Active ID Tag should be configured as an integer tag.


During a normal interface shutdown sequence, the interface will write a value of zero to its Active ID control point and PI tag. Setting the Active ID control point to zero allows the backup copy of the interface to quickly transition to the primary role.

Active ID Tag ConfigurationAttributes ActiveID IN AcitveID OUTTag <Intf>_Active_IN <Intf>_Active_OUTExDesc [UFO_ActiveID] [UFO_ActiveID]Location1 Match # in /id=# Match # in /id=#Point Source Match x in /ps=x Match x in /ps=xPoint Type Int32 Int32Shutdown 0 0Step 1 1

HeartbeatThe Heartbeat tags are used to configure and monitor the liveliness of the failover configuration. For interface failover to operate properly, each copy of the interface must have an input Heartbeat PI tag, and an output Heartbeat PI tag. Therefore, a total of four Heartbeat tags are required.

The input and output tag for each interface copy must have the string [UFO_Heartbeat:n] in the ExDesc attribute of the PI tag. The value of n must match the failover ID for the interface as defined by the /UFO_ID or /UFO_OtherID startup parameter (see example below). The UFO_HeartBeat keyword is not case sensitive. The square brackets must be included. All four of the Heartbeat tags must be successfully loaded or the interface will log a message to the pipc.log and fail to start.

For example: An interface copy participating in failover has /UFO_ID=5 and /UFO_OtherID=6 on the startup command line indicating that its interface ID is 5 and the other copy of the interface has an ID of 6. The ExDesc attribute for the input and output Heartbeat tags for the interface with an ID of 5 must have [UFO_Heartbeat:5] defined. Likewise, the ExDesc attribute for the input and output Heartbeat tags for the interface with an ID of 6 must have [UFO_Heartbeat:6] defined.

During a normal interface shutdown sequence, the interface will write a value of zero to its Heartbeat control point. Setting the Heartbeat control point to zero allows the backup copy of the interface to quickly transition to the primary role.

Heartbeat Tag Configuration

Attribute Heartbeat 1 IN Heartbeat 1 OUT Heartbeat 2 IN Heartbeat 2 OUT

Tag <HB1>_IN <HB1>_OUT <HB2>_IN <HB2>_OUT

ExDesc [UFO_Heartbeat:#]

Match # in /UFO_ID=#

[UFO_Heartbeat:#]

Match # in /UFO_ID=#

[UFO_Heartbeat:#]

Match # in /UFO_OtherID=#

[UFO_Heartbeat:#]

Match # in /UFO_Other=#

Location1 Match # in /id=# Match # in /id=# Match # in /id=# Match # in /id=#

Point Source Match x in /ps=x Match x in /ps=x Match x in /ps=x Match x in /ps=x

Point Type int32 int32 int32 int32

Shutdown 0 0 0 0

Attribute Heartbeat 1 IN Heartbeat 1 OUT Heartbeat 2 IN Heartbeat 2 OUT

Step 1 1 1 1

Interface State TagUniInt failover provides the ability to monitor the operational state of the interface using a PI tag. Each copy of the interface participating in failover can have an interface state tag defined to monitor the individual interface. To configure the interface readiness tag, the string [UFO_State:n] must be found in the ExDesc attribute of the PI tag. The value of n must match the failover ID for the interface as defined by the /UFO_ID startup parameter. The UFO_State keyword is not case sensitive. The square brackets must be included. The Interface state should be configured as a digital tag.

Note: UniInt limits the number of interface state tags to one per interface copy. If more than one tag is created for a particular copy of the interface, only the last tag sent to the interface during the startup process will be configured to monitor the interface state. All other interface state tags for this copy of the interface will be ignored and will not receive data.

Interface State Tag Configuration

Point Attribute Primary Backup

Tag <Tagname1> <Tagname2>

DigitalSet UFO_State UFO_State

ExDesc [UFO_State:#]

(Match /UFO_ID=# on primary node)

[UFO_State:#]

(Match /UFO_ID=# on backup node)

Location1 Match # in /id=# Same as for Primary node

PointSource Match x in /ps=x Same as for Primary node

PointType digital digital

Shutdown 0 0

Step 1 1

Digital State ConfigurationOSIsoft recommends configuring digital state set when using interface state tags to monitor the operational state of the failover configuration. UniInt is capable of providing six different states (values) that indicate the operational condition of interfaces participating in failover.

State Number State Name Description

0 Off The interface is not started.

1 Backup_No_DataSource

The interface is connected to the PI Server, but not to the Data Source. No data is being collected by the interface.


State Number State Name Description

2 Backup_No_PI The interface is connected to the Data Source, but not to the PI Server. The interface is actively collecting and queuing data. If the primary interface fails, this copy of the interface will continue to collect data and if a connection to PI becomes available, the queued data will be sent to the PI Server. The primary copy of the interface has the ability to monitor the backup interface and is able to set the state of the backup interface on the PI Server accordingly.

3 Backup The interface is connected to PI and the Data Source. Data is being collected and queued by the interface. If the primary interface fails, this copy of the interface will transition to primary and send its queued data to PI and continue in the primary role.

4 Transition The interface is changing roles from Backup to Primary. The interface remains in this state for two update intervals.

5 Primary The interface is connected to both the PI Server and the Data Source. Data is actively being sent to the PI Server.

Importing Failover Digital Set to PI via PI SMT 3The interface installation kit includes the digital set file, UniInt_Failover_DigitalSet_UFO_State.csv, that can be imported using the PI System Management Tools (SMT) (version 3.0.0.7 or above) application. The procedure below outlines the steps necessary to create a digital set on a PI Sever using the “Import from File” function found in the SMT application. The procedure assumes the user has a basic understanding of the SMT application.

1. Open the SMT application.

2. Select the appropriate PI Server from the PI Servers window. If the desired server is not listed, add it using the PI Connection Manager. A view of the SMT application is shown in Figure 3 below.

3. From the System Management Plug-Ins window, select Points then Digital States. A list of available digital state sets will be displayed in the main window for the selected PI Server. Refer to Figure 3 below.

4. In the main window, right click on the desired server and select the “Import from File” option. Refer to Figure 3 below.

Figure 3: PI SMT application configured to import a digital state set file. The PI Servers window shows the “localhost” PI Server selected along with the System Management Plug-Ins window showing the Digital States Plug-In as being selected. The digital state set file can now be imported by selecting the Import from File option for the localhost.

5. Navigate to and select the UniInt_Failover_DigitalSet_UFO_State.csv file for import using the Browse icon on the display. Select the desired Overwrite Options. Click on the OK button. Refer to Figure 4 below.

Figure 4: PI SMT application Import Digital Set(s) window. This view shows the UniInt_Failover_DigitalSet_UFO_State.csv file as


being selected for import. Select the desired Overwrite Options by choosing the appropriate radio button.

6. Navigate to and select the UniInt_Failover_DigitalSet_UFO_State.csv file for import using the Browse icon on the display. Select the desired Overwrite Options. Click on the OK button. Refer to Figure 4 above.

7. The UFO_State digital set is created as shown in Figure 5 below.

Figure 5: The PI SMT application showing the UFO_State digital set created on the “localhost” PI Server.

MessagesThe following are examples of typical error and informational messages that can be found in the pipc.log file.

Informational16-May-06 10:38:00TID3 1> UniInt failover: Interface in the "Backup" state.

Meaning: Upon system startup, the initial transition is made to this state. While in this state the interface monitors the status of the other interface participating in failover. Data received from the data source is queued and not sent to the PI Server while in this state. The amount of data queued while in this state is determined by the failover update interval.

In any case, there will be typically no more than two update intervals of data in the queue at any given time. Some transition chains may cause the queue to hold up to five failover update intervals worth of data

16-May-06 10:38:05TID3 1> UniInt failover: Interface in the “Primary” state and actively

sending data to PI. Backup interface not available.

Meaning: While in this state, the interface is in its primary role and sends data to the PI Server as it is received. This message also states that there is not a backup interface participating in failover.

16-May-06 16:37:21TID3 1> UniInt failover: Interface in the “Primary” state and actively

sending data to PI. Backup interface available.

Meaning: While in this state, the interface sends data to the PI Server as it is received

Errors16-May-06 17:29:06TID3 1> Loading Failover Synchronization tag failed

Error Number = 0: Description = [FailOver] or [HeartBeat:n] was found in the exdesc for Tag Active_INbut the tag was not loaded by the interface.Failover will not be initialized unless another Active ID tag issuccessfully loaded by the interface.

Cause: The Active ID or Heartbeat tag is not configured properly.

Resolution: Check validity of point attributes. For example, make sure Location1 attribute is valid for the interface. All failover tags must have the same PointSource and Location1 attributes. Modify point attributes as necessary and restart the interface.

16-May-06 17:29:06TID3 1> One of the required Failover Synchronization points was not

loaded.Error = 0: The Active ID synchronization point was not loaded.The input PI tag was not loaded

Cause: The Active ID tag is not configured properly.



16-May-06 17:38:06TID3 1> One of the required Failover Synchronization points was not

loaded.Error = 0: The Heartbeat point for this copy of the interface was not loaded.The input PI tag was not loaded

Cause: The Heartbeat tag is not configured properly.


17-May-06 09:05:39TID3 1> Error reading Active ID point from Data source

Active_IN (Point 29600) status = -255

Cause: The Active ID point value on the data source produced an error when read by the interface. The value read from the data source must be valid. Upon receiving this error, the interface will enter the “Backup in Error state.”

Resolution: Check validity of the value of the Active ID point on the data source.

17-May-06 09:06:03TID3 1> Error reading the value for the other copy's Heartbeat point from

Data sourceHB2_IN (Point 29604) status = -255

Cause: The Heartbeat point value on the data source produced an error when read by the interface. The value read from the data source must be valid. Upon receiving this error, the interface will enter the “Backup in Error state.”

Resolution: Check validity of the value of the Heartbeat point on the data source.

17-May-06 09:06:03TID3 1> UniInt failover: Interface in an "Error" state. Could not

read failover control points."

Cause: The failover control points on the data source are returning a value to the interface that is in error. This error can be caused by creating a non-initialized control point on the data source.”

Resolution: Check validity of the value of the control points on the data source.

17-May-06 09:06:03TID3 1> The Uniint FailOver ID (/UFO_ID) must be a positive integer

Cause: The UFO_ID parameter has not been assigned a positive integer value.

Resolution: Change and verify the parameter to a positive integer and restart the interface.

17-May-06 09:06:03TID3 1> The Failover ID parameter (/UFO_ID) was found but the ID for

the redundant copy was not found

Cause: The UFO_OtherID parameter is not defined or has not been assigned a positive integer value.

Resolution: Change and verify the UFO_OtherID parameter to a positive integer and restart the interface.

Interface Node ClockWindows

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 Savings Time, check the box marked “Automatically adjust clock for daylight savings changes”. 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 tab. Remove TZ from the list of environment variables.

OpenVMSBy default, the system time of a PINet node is synchronized with the system time on the PI Server node once every hour by the PINETSYNC program. The behavior of the PINETSYNC program can be altered by editing the PINet:PINetSync1.com file. The synchronization interval can be changed, a time offset between the PINet node and the server node can be applied, and/or time synchronization can be disabled. The command-line parameters for implementing these changes are described in the PINet:PINetSync1.com file itself.

SecurityWindows

If the home node is a PI 3 Server, the PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Data Archive. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Data Archive Manual.

If the home node is a PI 2 Server, the read/write permissions should be set appropriately in the pisysdat:piserver.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the pibuild:piserver.txt file on the PI 2 home node.

If the interface cannot write data to a PI 3 Server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Serve, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.

PI Server v3.3 and HigherUse of piconfigFor PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust table:C:\PI\adm> piconfig@table pitrust@mode create@istr Trust,IPAddr,NetMask,PIUsera_trust_name,192.168.100.11,255.255.255.255,piadmin@quit

For the above,

Trust: An arbitrary name for the trust table entry; in the above example,

a_trust_name

IPAddr: the IP Address of the computer running the Interface; in the above example,

192.168.100.11

NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr

PIUser: the PI user the Interface to be entrusted as; piadmin is usually an appropriate user

Trust EditorThe Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI Trust table.

See the PI System Management chapter in the PI Server manual for more details on security configuration.

PI Server v3.2For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:C:\PI\adm> piconfig@table pi_gen,piproxy@mode create@istr host,proxyaccountpiapimachine,piadmin@quitIn place of piapimachine, put the name of the PI Interface node as it is seen by PI Server.

OpenVMS If the interface runs on a PINet node and communicates to a PI 3 Server, make sure that the PI Firewall Database and the PI Proxy Database are configured so that the PINet node is allowed to write data to the Archive. For more information, see “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Data Archive manual.

If the interface runs on a PINet node and communicates to a PI 2 Server, make sure that the PINet node has read/write permission to the PI 2 Archive by checking the configuration in the PISysDat:PIServer.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the PIBuild.PIServer.txt file on the PI 2 Server.

If the interface cannot write data to a PI 2 or PI3 Server owing to permission problems, error –10401 will be written to the PISysMgr:PIMesslog.txt file.

Starting / Stopping the Interface on Windows This section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.

Starting Interface as a ServiceIf the interface was installed a service, it can be started from the services control panel or with the command:TID3.exe –start

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

A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. One is that the service may not be able to find the command-line parameters in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See the section “Appendix A: Error and Informational Messages,” for additional information.

Stopping Interface Running as a ServiceIf the interface was installed a service, it can be stopped at any time from the services control panel or with the command:TID3.exe –stopThe service can be removed by:TID3.exe –remove

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

Starting / Stopping the Interface on OpenVMS This section describes starting and stopping the interface as a detached process. See the UniInt End User Document to run the interface interactively.

Starting a Detached ProcessThe interface is started as a detached process with the tid3detach.com command file. Typically, the tid3detach.com file does not need to be edited, because the command-line parameters are edited in the associated tid3#.com file. However, in some cases it may be necessary to edit the tid3detach.com file to increase quotas such as the page file size. Detached processes continue running after the user who started the process logs off.

The following is an example of a tid3detach.com file.

Assuming that the example command file is used to start the interface, the following command will start instance 1 of the interface as a detached process:@PISysExe: tid3detachThe name of the process will be PI TID3 as defined by the /proc parameter to the run command in the above command file

The example tid3detach.com command file performs the following tasks in the order listed.

$! TID3Detach.com

$! This file is used to start the TID3 interface as a detached

$! process. This file can be used in PiSysMgr:SiteStart.com$!

================================================================

$!$ If (F$Search("PISysExe:tid3.out").nes."") then - Purge/Keep=3 PISysExe:tid3.out$!$ run/detach/uic=[system]/process="PI TID3"/priority=8 - /input=pisysexe:tid3.com/output=pisysexe:tid3.out - /working_set=512/maximum_work=1024/extent=5000 - /pagefile=100000/buffer=32768 sys$system:loginout$ exit$!

================================================================

Starting / Stopping the Interface on OpenVMS

1. tid3detach.com searches for the existence of the PISysExe:tid3.out interface-specific log file. If the file exits, the command file executes the purge command to eliminate all but the last three versions of this file.

2. The PI TID3process is started with the run command. Several actions are performed by the run command:

The name of the process is set to PI TID3 by the /proc parameter.

The UIC of the process is set to the system account by the /uic parameter.

The priority of the process is set to 4 by the /priority parameter.

The input command file for the process is set to PISysExe:tid3.com by the /input parameter.

The standard output from the interface is redirected to the PISysExe:tid3.out file by the /output parameter.

The remaining parameters, /working_set, /maximum_work, /extent, /pagefile, and /buffer, are used to adjust the resources that are available to the interface.

StoppingTo stop the interface, issue the following command:@PISysExe:stop PI TID3-1Where 1 is the instance number of the process or @PISysExe:tid3stop

88

BufferingFor complete information on buffering, please refer to the NovaTech D/3® Interface to the PI System Documentation.

PI Interface Node buffering consists of a buffering process which runs continuously on the local node, a PI API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.

Note: Change the Local Security Policy on Windows XP. 1. Open “Administrative Tools” from the control panel. 2. Open “Local Security Policy” from administrative tools. 3. Browse to “Security Options” under “Local Policies.” 4. Double click on “System Objects: Default owner for objects created by members of the Administrators group.” 5. Change the dropdown from “Object Creator” to “Administrators group.”The behavior of Bufserv should now be the same on Windows XP as it was for Windows NT 4 and 2000.

Configuring Buffering with PI ICU (Windows)Buffering is enabled through the PI Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI API will not buffer data, sending data directly to the home node.

The API Buffering… dialog allows the user to view and configure the parameters associated with the API Buffering (bufserv) process. The user can start and stop the API Buffering process from the Service tab:

Buffering

Service TabThe Service tab allows for some PI API Buffering service configuration. For further configuration changes, use the Services applet.

Service NameThe Service name displays the name of the PI API Buffering Service.

Display NameThe Display name displays the full name associated with the PI API Buffering service.

Log On AsLog on as indicates the Windows user account under which the PI API Buffering service is setup to start automatically on reboot, or manually.

PasswordPassword is the name of the password for the Windows user account entered in the Log on as:above.

Confirm passwordReenter the password to verify it has been typed correctly both times.

DependenciesThe Dependencies lists the Windows services on which the PI API Buffering service is dependent.

Dependent ServicesThe Dependent services area lists the Windows services that depend on bufserv to function correctly.

Start / Stop ServiceThe Start / Stop buttons allow for the PI API Buffering service to be started and stopped. If the service is not created, this box will show Not Installed.

After a change is made to any of the settings on the Settings tab, the OK button must be clicked to save these settings, and then the service must be stopped and restarted for the changes to be picked up by bufserv.

Service Startup TypeThe Startup Type indicates whether the PI API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.

If the Auto option is selected, the service will be installed to start automatically when the machine reboots.

If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.

If the Disabled option is selected, the service will not start at all.

Generally, the PI API Buffering service is set to start automatically.

Create/Remove ServiceThe Create / Remove buttons allow for the creation or removal of the PI API Buffering service. Clicking the Create button will cause the service to be created using the Log on

90

as and passwords given. Once the service is created the Start / Stop buttons will be activated.

Settings TabThe Settings tab allows for configuration of the 7 configurable settings used by PI API Buffering. Default values are used if no other value is provided.

Enable BufferingEnable the PI API Buffering feature.

Maximum File SizeMaximum buffer file size in kilobytes before buffering fails and discards events. Default value is 100,000. Range is 1 to 2,000,000.

The Use Default button places the default value into the text box. To keep this value, click the Apply button.

Send RateSend rate is the time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds). Default value is 100. Range is 0 to 2,000,000.


Primary Memory Buffer SizePrimary memory buffer size is the size in bytes of the Primary memory buffer. Default value is 32768. Range is 64 to 2,000,000.


GSE Systems D/3 Interface to the PI System 91

Buffering

Secondary Memory Buffer SizeSecondary memory buffer size is the size in bytes of the Secondary memory buffer. Default value is 32768. Range is 64 to 2,000,000.


Max Transfer ObjectsMax transfer objects is the maximum number of events to send between each SENDRATE pause. Default value is 500. Range is 1 to 2,000,000.


Pause RateWhen buffers are empty the buffering process will wait for this number of seconds before attempting to send more data to the home node. Default value is 2. Range is 0 to 2,000,000.


Retry RateWhen the buffering process discovers the home node is unavailable it will wait this number of seconds before attempting to reconnect. Default value is 120. Range is 0 to 2,000,000.


Max Theoretical Send RateThis is the theoretical max send rate which is calculated like this:max = MAXTRANSFEROBJS / SENDRATE * 1000Default value is 5000. This value is automatically calculated for the user and can not be changed.

There are no additional steps needed to install buffering after installing the PI API. The delivered PI API library supports both buffered and un-buffered calls.

Configuring Buffering ManuallyBuffering is enabled through the use of a configuration file, piclient.ini. Unless this file is modified to explicitly enable buffering, the PI API will not buffer data, sending data directly to the home node.

There are no additional steps needed to install buffering after installing the PI API. The delivered PI API library supports both buffered and un-buffered calls.

Note: When buffering is configured to be on, the bufserv process must be started before other programs using the PI API, so that these programs can access the shared buffering resources. Any program that makes a connection to a PI Server has this requirement even if it does not write to PI.

Configuration of buffering is achieved through entries in the piclient.ini file. The file is found in the dat subdirectory of the PIHOME directory (typically c:\pipc\dat) under Windows. This file follows the conventions of Microsoft Windows initialization

92

files with sections, keywords within sections, and values for keywords. All buffering settings are entered in a section called [APIBUFFER]. To modify settings, simply edit the piclient.ini file in a text editor (Notepad on Windows) to the desired values.

The following settings are available for buffering configuration:

Keywords Values Default Description

BUFFERING 0,1 0 Turn off/on buffering. OFF = 0, ON = 1,

PAUSERATE 0 - 2,000,000 2 When buffers are empty the buffering process will wait for this long before attempting to send more data to the home node (seconds)

RETRYRATE 0 - 2,000,000 120 When the buffering process discovers the home node is unavailable it will wait this long before attempting to reconnect (seconds)

MAXFILESIZE 1 - 2,000,000 100,000 Maximum buffer file size before buffering fails and discards events. (Kbytes)

MAXTRANSFEROBJS 1 - 2,000,000 500 Maximum number of events to send between each SENDRATE pause.

BUF1SIZE 64 - 2,000,000 32768 Primary memory buffer size. (bytes)

BUF2SIZE 64 - 2,000,000 32768 Secondary memory buffer size. (bytes)

SENDRATE 0 - 2,000,000 100 The time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds)

In addition to the [APIBUFFER] section, the [PISERVER] section may be used to define the default PI server and an optional time offset change that may occur between the client and server.

Keywords Values Default Description

PIHOMENODE string none Windows default server is in pilogin.ini

DSTMISMATCH 0 - 2,000,000 0 The time that the server and client local time offset is allowed to jump. Typically, 3600 if the nodes are in time zones whose DST rules differ (seconds)

Example piclient.ini FileWindows

On Windows, the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds meaning wait 10 minutes after losing a connection before retrying.

On Windows a piclient.ini file might look like:


Buffering

[APIBUFFER]BUFFERING=1MAXFILESIZE=100000; The PI API connection routines have a 1 minute default timeout.RETRYRATE=600

94

Appendix A:Error and Informational Messages

A string NameID 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 LogsWindowsMessages are written to PIHOME\dat\pipc.log at the following times.

When the interface starts many informational messages are written to the log. These include the version of the interface, the version of UniInt, the command-line parameters used, and the number of points.

As the interface retrieves points, messages are sent to the log if there are any problems with the configuration of the points.

If the /db is used on the command line, then various informational messages are written to the log file.

OpenVMSError and informational messages are written to the PISysMgr:PIMessLog.txt log file and to an interface-specific log file. The interface-specific log file and the interface executable are both typically in the PISysExe directory. Since redirecting the standard output to a file typically creates an interface-specific log file, one can determine the name of this file by examining the startup command file of the interface.

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

Error Descriptions on WindowsOn Windows, descriptions of system and PI errors can be obtained with the pidiag utility:\PI\adm\pidiag –e error_number

Error Descriptions on OpenVMSOn OpenVMS, descriptions of system errors can be obtained with the exit command:

exit positive_error_number

Appendix B:PINet to PI 3 String Tag Support

String tags are supported on OpenVMS PINet nodes when the home node is PI 3. The interface cannot perform the data transfer directly, but uses an FTP mechanism instead. The string data is written to a file which is transferred to the PI 3 Server node by an automated FTP script that runs as a detached process. On the PI 3 Server node, the file is processed by the Batch File interface. (The BatchFile Interface is required as additional OSIsoft software.) The details of this process and the configuration that is necessary to set it up are discussed below.

Method of OperationThe name that UniInt uses for the data file is of the form “NameID.new.” 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. NameID is the same character string that identifies messages in the pipc.log file as belonging to a particular interface, except that UniInt removes any spaces and periods that may have appeared in the character string.

The file NameID.new is written to the currently active FTP buffer directory, which is determined by the definition of the system logical piftpdir. One can determine currently active directory with the command:$ sho logical PIFTPDIR

"PIFTPDIR" = "PIFTPBUF1" (LNM$SYSTEM_TABLE) 1 "PIFTPBUF1" = "PI$DISK:[FTP.BUF1]" (LNM$SYSTEM_TABLE)

The current active FTP directory can be either PI$DISK:[FTP.BUF1] or PI$DISK:[FTP.BUF2]. If piftpdir is not defined, then the current FTP directory will be set to PI$DISK:[FTP.BUF1] when the PI-FTP process starts.

Every minute the PI-FTP process checks to see if there are any files ending in ".new" in piftpdir. If there are, it renames the files so that the files end in ".old" and then copies all of the .old files to Strtags.srt. The files with the ".old" extension are then deleted. Renaming the files to the .old extension ensures that the data in Strtags.srt are in time order. Strtags.srt is then FTP'd to the PI Server node. On the PI Server node the file is given a name of the form PIFTPYYYYMMDDHHMM.DAT, where YYYY is the year, MM is the month, DD is the day, HH is the hour, and MM is the minute. After the files are processed by the Batch File interface, the files are renamed to PIFTPYYYYMMDDHHMM.999. The .999 files are deleted by the Batch File interface after a user-configurable amount of time has expired.

After the data files are copied to Strtags.srt, the FTP script changes piftpdir from PI$DISK:[FTP.BUF1] to PI$DISK:[FTP.BUF2] or vice versa. If the FTP transfer is successful, the PI-FTP process will delete the Strtag.srt file. If the FTP transfer is unsuccessful, the Strtag.srt file will not be deleted. The PI-FTP process will continue trying to send the Strtag.srt file until it is successful. Meanwhile, the interface can continue to write NameID.new files to the current FTP directory.

After every successful or unsuccessful FTP transaction, the PI-FTP process sleeps 1 minute before it attempts to send new or old data again. It is recommended that the wait time be at least 10 times the elapsed time for an FTP transaction.

The data in NameID.new is ASCII text of the form:point_identifier, pitime, value, status

The field separator can be changed from a comma to any character with the /fs command-line parameter. The point_identifier on the PINet Node corresponds to the point_number on the PI 3 Server node. The point_identifier is obtained by the interface with the pipt_pointid PI API call. The pitime is PI 2 time for OPEN OpenVMS. In other words, pitime is the number of seconds since January 1, 1970 in the local time zone. The value is the string that is to be written to the PI Point, and status is the current status of the point (0 is a good status).

Setup Instructions1. Obtain the files for the automatic FTP mechanism from OSIsoft. These files are:

piftp.compiftpdetach.compiftpstop.com

Copy these files to the PINet directory.

2. Create the following directories:create /directory pi$disk:[ftp]create /directory pi$disk:[ftp.buf1]create /directory pi$disk:[ftp.buf2]

3. Set the HomeNode, UserName, and PassWord for the automatic FTP mechanism by editing the file piftp.com. This is described in more detail later on in this procedure.

4. Add the following line to PINet:SITESTART.COM:$@pisysexe:piftpdetach

5. Add the following line to PINet:SITESTOP.COM:@piftpstop.com

6. Modify the startup command line of the interface if necessary. The /fs parameter is the only command-line parameter that is associated with the automatic FTP file transfer mechanism.

7. Set up an FTP daemon on the PI 3 Server node. FTP daemons normally come as a part of a UNIX system. If the PI 3 Server is on a Windows node, an FTP daemon will probably need to be installed. FTP daemons on Windows do not use Windows security. A user name and password will need to be configured for the FTP daemon and a default login directory must be setup. These user names and passwords are in no way related to Windows user names and passwords. They are configured via the FTP software, not the Windows administrator.

8. Set up the Batch File interface on the PI 3 Server node. The /pa parameter of the BatchFile interface should point to the directory where the ftp files are written. The BatchFile interface should be configured to read files ending in .dat. See the interface manual for the BatchFile interface for details. The /fs command-line

parameter for the BatchFile interface and the UniInt-based interface should be set to the same field separator.

9. Configure PI Points of point type string on the PI 3 Server node. FTPSTRINGTAG must appear in the extended descriptor (ExDesc) of each PI Point of type string. This is because the interface will be running on a PI 2 PINET node, and the PI API on PI 2 cannot distinguish between PI points of type integer and PI points of type string. The PI Point will be assumed to be of type integer by the interface unless FTPSTRINGTAG is found in the extended descriptor of a PI Point of type string.

The Automatic FTP Script

Configuring the ScriptThe HomeNode, UserName, and PassWord variables must be set by editing the PINet:piftp.com file. The HomeNode is the domain name or IP address of the PI 3 Server node. If the PI 3 Server is on a UNIX machine, then the UserName/PassWord correspond to an actual username/password on the UNIX box. If the PI 3 Server is an Windows machine, the UserName/PassWord correspond to a username/password that is configured from within the FTP software on the Windows box. These user names and passwords are in no way related to Windows user names and passwords.

The piftp.com script is given below.

$! PIFTP TO BATCHFL DRIVER FOR OpenVMS$! OSIsoft, INC$!$! REVISION HISTORY$! 18-NOV-97 BSO V1.0 CREATED$! 24-Dec-98 HAO Modified for CHIPtoPI Interface$! 30-Jul-99 GWM Added TCPWare and Multinet support$! 06-Sep-99 GWM Merged with changed made by SDS$!$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$!MODIFY THE FOLLOWING PARAMETERS$! $!$HomeNode := piserver$UserName := username$PassWord := password$!$!$!DO NOT MODIFY ANYTHING BELOW THIS LINE$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!$SET NOON$SET NOVERIFY$!$! LOG STARTUP EVENT$PIMSG:==$pinet:writemesslog$PIMSG "PI FTP SCRIPT STARTING"$!$if (f$trnlnm("PI$DISK") .nes. "") THEN GOTO CHECKTCPWARE $PIMSG "PI$DISK LOGICAL NOT DEFINED...PERHAPS PINET IS NOT RUNNING...ABORT"$EXIT


Appendix B: PINet to PI3 String Tag Support

$!$!$CHECKTCPWARE:$ if (f$trnlnm("tcpware") .nes. "") $ then $ @TCPWARE:TCPWARE_COMMANDS.COM$ PIMSG "RUNNING TCPWARE:TCPWARE_COMMANDS.COM"$ endif$!$! CHANGE PIFTPCMD <> RUN FOR CLEAN EXIT$DEFINE/System/Nolog PIFTPCMD RUN$!$! BUF1 & BUF2 MUST BE ON PI$DISK TO SUPPORT FILE RENAME$DEFINE/System/Nolog PIFTPBUF1 PI$DISK:[FTP.BUF1]$DEFINE/System/Nolog PIFTPBUF2 PI$DISK:[FTP.BUF2]$!$IF (F$TRNLNM("PIFTPDIR") .NES. "") THEN GOTO SKIPINIT$DEFINE/System/Nolog PIFTPDIR PIFTPBUF1$!$SKIPINIT:$FTPPREV = %X00000001 ! init FTP previous status$!$!$START:$!$!Find Active/InActive Directory$BUFNEW=F$TRNLNM("PIFTPDIR")$IF ( BUFNEW .EQS. "PIFTPBUF1" ) THEN BUFOLD="PIFTPBUF2"$IF ( BUFNEW .EQS. "PIFTPBUF2" ) THEN BUFOLD="PIFTPBUF1"$!$!$!Check for data in old buffer$IF (F$SEARCH("''BUFOLD':*.SRT").EQS. "") THEN GOTO CHECKNEW$RESET = F$SEARCH("''BUFOLD':*.SRT;*") ! reset search context$! Change directory focus$ SET Default 'BUFOLD$ GOTO MAKEFTP$!$CHECKNEW:$!Check for data in new buffer$IF (F$SEARCH("''BUFNEW':*.NEW").EQS. "") THEN GOTO SLEEP$!Change directory focus$ SET Default 'BUFNEW$! Switch Buffers$ DEFINE/System/Nolog PIFTPDIR 'BUFOLD$ WAIT 00:00:01 ! in case file being created$!$! concatenate new files into a single sorted file$!$REORDER:$ IF (F$SEARCH("*.NEW;*") .NES. "")$ THEN RENAME *.NEW *.OLD ! order versions to sort by date$ GOTO REORDER

100

$ ENDIF$ COPY/Nolog *.OLD;* STRTAGS.SRT$ DELETE/Nolog/Noconfirm *.OLD;*$!$MAKEFTP:$!$!Rename after FTP to prevent file open collisions$!$!012345678901234567890123$!yyyy-mm-dd hh:mm:ss.cc$tstr= f$cvtime(f$time())$!$!$yyyy = f$extract(0,4,tstr)$mm = f$extract(5,2,tstr)$dd = f$extract(8,2,tstr)$hh = f$extract(11,2,tstr)$mi = f$extract(14,2,tstr)$!$fname= "PIFTP"+yyyy+mm+dd+hh+mi+".DAT"$GOTO CREATESCRIPT$!$!$TRYFTP:[email protected] $FTPSTAT = $STATUS$IF (FTPSTAT) $THEN $ DELETE/Nolog/Noconf *.SRT.*$ PURGE/Nolog/Noconf PIFTPSCRIPT.COM$ PURGE/keep=3/Nolog/Noconf PISYSEXE:PIFTP.TRANSCRIPT$ IF (FTPSTAT .NE. FTPPREV) THEN PIMSG "PIFTP SUCCESS, STATUS = ''FTPSTAT'"$ELSE$ PURGE/Nolog/Noconf PIFTPSCRIPT.COM$ PURGE/keep=3/Nolog/Noconf PISYSEXE:PIFTP.TRANSCRIPT$ IF (FTPSTAT .NE. FTPPREV) THEN PIMSG "PIFTP FAILURE, STATUS = ''FTPSTAT'" $ENDIF$FTPPREV = FTPSTAT$!$!$SLEEP: $WAIT 00:01:00$IF (F$TRNLNM("PIFTPCMD") .EQS. "RUN") THEN GOTO START$PIMSG "PI FTP SCRIPT EXITING - PIFTPCMD <> RUN"$!$EXIT$!$! CREATE PIFTPSCRIPT FILE$CREATESCRIPT:$OPEN/WRITE/ERROR=OPEN_ERROR FTPC piftpscript.com$!$! DETERMINE THE FTP IMPLEMENTATION$ FTPTYPE = ""


mailto:[email protected]


$!$ if (f$trnlnm("ucx$service") .nes. "") .or. - (f$trnlnm("tcpip$service") .nes. "") $ then $ WRITE FTPC "$ DEFINE SYS$OUTPUT PISYSEXE:PIFTP.TRANSCRIPT"$ WRITE FTPC "$ FTPCMD = ""$SYS$SYSTEM:UCX$FTP"""$ WRITE FTPC "$ FTPCMD" $ WRITE FTPC "open ''HomeNode'" $ WRITE FTPC "user ''UserName'" $ WRITE FTPC "''PassWord'" $ WRITE FTPC "asc" $ WRITE FTPC "put STRTAGS.SRT ''fname'" $ WRITE FTPC "quit" $ WRITE FTPC "$ EXIT $status"$ CLOSE FTPC$!$ FTPTYPE = "UCX"$ endif$!$! TGV MultiNet.$ if (f$trnlnm("multinet") .nes. "") $ then$ WRITE FTPC "$ DEFINE SYS$OUTPUT PISYSEXE:PIFTP.TRANSCRIPT"$ WRITE FTPC "$ FTPCMD = ""MULTINET FTP"""$ WRITE FTPC "$ FTPCMD 'HomeNode' /user='UserName' /pass='PassWord'" $ WRITE FTPC "exit-on-error on" $ WRITE FTPC "TYPE ASCII" $ WRITE FTPC "put STRTAGS.SRT ''fname'" $ WRITE FTPC "quit" $ WRITE FTPC "$ EXIT $status"$ CLOSE FTPC$!$ FTPTYPE = "MULITNET"$ endif $!$! Process Software TCPWare$ if (f$trnlnm("tcpware") .nes. "") $ then $ WRITE FTPC "$ DEFINE SYS$OUTPUT PISYSEXE:PIFTP.TRANSCRIPT"$ WRITE FTPC "$SET NOON" $ WRITE FTPC "$FTP" $ WRITE FTPC "open ''HomeNode' ''Username' ''Password'" $ WRITE FTPC "ERROR_EXIT %X10000010"$ WRITE FTPC "TYPE ASCII" $ WRITE FTPC "ERROR_EXIT %X10000020"$ WRITE FTPC "put STRTAGS.SRT ''fname'" $ WRITE FTPC "ERROR_EXIT %X10000030"$ WRITE FTPC "exit" $ WRITE FTPC "$ EXIT $status"$ CLOSE FTPC$! $ FTPTYPE = "TCPWARE"$ endif$!

102

$ IF (FTPTYPE .nes. "") THEN GOTO TRYFTP$ PIMSG "ERROR, PI FTP SCRIPT COULD NOT RESOLVE THE TCP/IP IMPLEMENATION TYPE"$ GOTO SLEEP$!$!$OPEN_ERROR:$PIMSG "ERROR OPENING PI$DISK:PIFTPSCRIPT.COM FILE"$GOTO SLEEP$!

$

The piftpdetach.com script is given below.

$! PIFTPDETACH.COM$! This file is used to start the PI FTP SERVER as a detached process.$! This file can be used in PiSysMgr:SiteStart.com$!=======================================================$!$ If (F$Search("PISysExe:piftp.out").nes."") then -

Purge/Keep=3 PISysExe:piftp.out$!$ run/detach/uic=[system]/process="PI-FTP"/priority=4 -

/input=pisysexe:piftp.com/output=pisysexe:piftp.out -

/working_set=512/maximum_work=1024/extent=5000 -

/pagefile=100000/buffer=32768 sys$system:loginout$ exit

Starting and Stopping the FTP ScriptThe automatic FTP script is called PINet:piftp.com. The ftp script is started by:@pinet:piftpdetach.comOnce the detached process is started, the process "PI-FTP" should appear when the command Sho Sys is issued from a DCL prompt. The PI-FTP process can be launched before or after the interface.

The script is stopped by:@pinet:piftpstop.comThe command procedure piftpstop.com does not directly stop the PI-FTP process. Instead, the command procedure changes the definition of the system process logical name piftpcmd from run to exit. The PI-FTP process checks the definition piftpcmd once every minute to determine whether it should keep running or exit. Hence, the PI-FTP process could take up to 1 minute to exit.



Informational and Error Messages from the FTP ScriptThe PI-FTP process writes messages to the PINet:piftp.out file and the PINet:PIMessLog.txt file. The messages that are written to the piftp.out file are usually not very useful.

The following are examples of messages that may appear in the PIMessLog.txt file.

6-SEP-1999 10:09:39.76PI FTP STARTING

6-SEP-1999 14:01:26.28PIFTP FAILURE, STATUS = %X1000028C

6-SEP-1999 14:21:22.30PIFTP SUCCESS, STATUS = %X00000001

6-SEP-1999 15:10:44.16PI FTP EXITING – PIFTPCMD <> RUN

The above messages indicate that the PI FTP process started at 10:09:39.76 and that it ran correctly until 14:01:26.28. The process recovered at 14:21:22.30 and exited at 15:10:44. To determine the nature of the problem that occurred, one can look at the PINet:piftp.transcript file. The last 3 transcripts that occurred are kept. The following is an example of an FTP transcript indicating successful FTP transfer.

Vlc620.osisoft.com MultiNet FTP user process V4.0(118)Connection opened (Assuming 8-bit connections)< Jgaa’s Fan Club FTP Service WAR-FTPD 1.65 Ready<Please enter your user name.[Attempting to log in as piftpserver]<User logged in, proceed.FTP>[Will exit when an error occurs]FTP>Type: Ascii (Non-Print), Structure: File, Mode: StreamFTP><Ready to receive “/PIFTP199909061458.CSV”. Mode STREAM Type ASCII NO-PRINT.<Transfer finished successfully. Closing data connection.FTP><Goodbye. Control connection closed.

The following transcript indicates that the FTP script was told to log into an unknown node called PISERVER.

Vlc620.osisoft.com MultiNet FTP user process V4.0(118)? Unknown host “PISERVER”FTP>[Will exit when an error occurs]FTP>? Unknown host “TYPE”%DCL-W-SKPDAT, image data (records not beginning with “$”)

104

ignored

The message: %DCL-W-SKPDAT, image data (records not beginning with “$”)

ignored”is meaningless. It appears at the end of every unsuccessful ftp transcript. The following transcript indicates that the FTP daemon is not running on the PI Server node. The connection was refused because there was no FTP daemon to accept a connection.

Vlc620.osisoft.com MultiNet FTP user process V4.0(118)208.243.230.116: %MULTINET-F-ECONNREFUSED, Connection refusedFTP>[Will exit when an error occurs]FTP>? Unknown host “TYPE”%DCL-W-SKPDAT, image data (records not beginning with “$”) ignored


Appendix C:“Watchdog”

Some sites have found the watchdog program useful for an interface which cycles periodically.

The “watchdog” command file performs the restart. It checks periodically whether the interface process exists. The frequency of checking is configurable in the file Restart.com. If the process exists, the “watchdog” goes back to sleep. If the interface has stopped, the “watchdog” will restart it. The “watchdog” is actually comprised of two files; the “watchdog” command file itself and another command file to run it as a detached process.

Starting with version 3.00 of the interface we do not expect the watchdog program to be necessary. The information is kept here for backward compatibility.

Restart.comThe “watchdog” command file is restart.com as described below.$!RESTART.COM$ set noverify$ on error then continue$ ProcName = f$process()$ ProcName = procname-“_R”$START:$ ContextSymbol = “”$ Temp = F$Context(“PROCESS”, ContextSymbol, “PRCNAM”, ProcName, “EQL”)$ PID = F$PID (ContextSymbol)$ If (PID .eqs. “” ) then @pisysexe:’procname’_R.com$ wait 00:00:15$ on error then continue$ goto START$ exit

RestartDetach.comThe command file to start the “watchdog” as a detached process is restartdetach.com as described below.

$! RESTARTDETACH.COM$! This starts a process with the name ‘P1’_R.$! If the process ‘P1’ is not found, the file pisysexe:’P1’_R.com$! Is executed. The time between checks is configurable.$ on err then goto ERRHANDLER$ proc = p1$ASK:$ if proc .nes. “” then goto DOIT$ write sys$output “”

$ inquire proc “Please enter process name for restart “$ goto ASK$DOIT:$ write sys$output “”$ write sys$output “’’proc’_R starting… please wait”$ run/detach/process=”’’proc’_R”/priority=3-/output=pisysexe:’proc’_r.out/input=PISysExe:restart.com- sys$system:loginout$ wait 00:00:30 !insure file creation$ set protection=(s:wred,o:rwed,g:rwed,w:rwed) pisysexe:’proc’_r.out$ exit$ERRHANDLER:$ write sys$output “Error starting ‘’proc’_R”$ exit

Using the “Watchdog”These are the requirements to use the “watchdog”:

1. Edit d3set:sitestartup.com and add the line:$@pisysexe:restartdetach tid3

2. Edit pisysmgr:sitestop.com and d3set:sitestop.com and add the lines:$@pisysexe:stop TID3_r$@pisysexe:stop tid3

3. Copy the file tid3detach.com to pisysexe:TID3_r.com4. Start the program:

$@pisysexe:restartdetach tid3After configuration of the hardware and software, the PI GSETID3 Interface may be started. The interface may be run from the DCL prompt, but it should be configured to start automatically whenever the NovaTech D/3 and PI Systems are started.

StartupThe DCL command for starting the NovaTech D/3 interface is:@PISysExe:RestartDetach tid3To ensure that the interface restarts when the D/3 System is started, add the previous line to D3SET:SiteStartUp.com.

If the PI System is not yet running the interface will not start, but the “watchdog” will make multiple attempts until it is successful.

ShutdownThe “watchdog” program can be stopped from the DCL prompt by typing the command:@PISysExe:stop TID3_rThe NovaTech D/3 Interface can be stopped from the DCL prompt by typing the command: @PISysExe:stop tid3 or@PISysExe:TID3Stop

This stops the process PI TID3. The procedure will also send the digital state from the /stopstat command line parameter to all of the input tags with the given point source.

To ensure that the interface is stopped when the PI System is stopped, add the previous two DCL command lines to PISysMgr:SiteStop.com.

To ensure that the interface is stopped when the D/3 System is stopped, add the previous two DCL command lines to D3SET:SiteStop.com.


Revision HistoryDate Author Comments

2-Jul-97 CGoodell Added more information for compiling and linking.

8-Sep-98 CGoodell Elaborate on location 5, update command files

14-Sep-98 CGoodell Added FTP section; D/3 point configuration

15-Sep-98 CGoodell Added /CHANGE and /HARDWARE for compile

2-Oct-98 CGoodell Version 3.0; changed info about recovery instead of exit

13-Nov-98 CGoodell Version 3.18; if D3 AST routine called for shutdown, no digital state written to input tags; updated piftp.com; added revision significant changes

26-Mar-99 CGoodell Version 3.19; OSI now provides object files

8-Apr-99 CGoodell Added control of digital states to ouputs

16-Jul-99 HOrlett Modified PIFTP to use consistent directories.

29-Sep-99 CGoodell Version 4.0 runs on Windows; use UniInt 3.x for string support

1-Oct-99 CGoodell Added /KS switch information.

17-Apr-00 CGoodell Fixed an error in which file to rename

17-Jan-01 CGoodell Removed /file and /temp

10-Oct-01 CGoodell Updated list of install files

11-Dec-01 CGoodell Formatting changes; updated version number; fixed headers and footers

04-Jun-02 CGoodell Skeleton 1.11; ICU, output strings, version 4.27

03-Jun-03 CGoodell Added TID3_10_1.exe and TID3_11_2.exe; increased version to 4.29.0.0.

28-Oct-04 CGoodell Version 4.29.0.2 Rev A: Added /itdelim

15-Mar-06 MMoore Updated to use Skeleton 2.0

17-Apr-06 BPayne Added Failover section

26-Apr-06 MMoore Update debug levels and command-line parameters

15-May-06 MMoore Added Failover Appendix; Updated to v 4.30.0.12

05-Jun-06 MMoore Updated to use Skeleton 2.5

19-Jun-06 MMoore Updated to use Skeleton 2.5.1

21-Jun-06 BPayne v4.30.0.12 -Updated DCS control point section with information about creating DCS EPNs and downloading.

27-Jun-06 BPayne Rev B.- Added updates from Interface Manual


Date Author Comments

Skeleton v2.5.2.

6-Jul-06 Janelle Version 4.30.0.12 Revision C: updated headers and footers, added missing information for field length for ExDesc and InstrumentTag; removed first person references; fixed broken links; updated hardware diagram; assigned correct template to document; fixed file properties.

11-Jul-06 BPayne Version 4.30.0.12 Revision D: Included the name of the sample SABL program name; PI.MDL.txt, that is provided for assisting in configuring D/3 failover control EPNs.

18-Jul-06 BPayne Version 4.30.0.12 Revision E: Removed all references to UFO_Interval as it is not used with scan based only interfaces such as the Novatech D/3.

novatech d/3® interface to the pi system...

Documents