fisher-rosemount chip on nt/vms/hp-uxcdn.osisoft.com/interfaces/861/pi_chiptopi_hp_2.8.0.3.doc ·...

Fisher-Rosemount CHIP on NT/VMS/HP-UX

Fisher-Rosemount CHIP on NT/VMS/HP-UX Interface to the PI System

Version 2.8.0.3 and greaterDocument Revision C

How to Contact Us

Phone

(510) 297-5800 (main number)(510) 297-5828 (technical support)

Fax

(510) 357-8136

E-mail

[email protected]

World Wide Web

http://www.osisoft.com

Mail

OSIsoftP.O. Box 727San Leandro, CA 94577-0427USA

OSI Software GmbH Hauptstra(e 30 D-63674 Altenstadt 1Deutschland

OSI Software, LtdP. O. Box 8256Level One, 6-8 Nugent StreetAuckland 3, New Zealand

OSI Software, Asia Pte Ltd152 Beach Road#09-06 Gateway EastSingapore, 189721

Unpublished -- rights reserved under the copyright laws of the United States.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

Trademark statement—PI is a registered trademark of OSI Software, Inc. Microsoft Windows, Microsoft Windows for Workgroups, and Microsoft NT are registered trademarks of Microsoft Corporation. Solaris is a registered trademark of Sun Microsystems. HP‑UX is a registered trademark of Hewlett Packard Corp. IBM AIX RS/6000 is a registered trademark of the IBM Corporation. DUX, DEC VAX and DEC Alpha are registered trademarks of the Digital Equipment Corporation.FCHIPNT.DOC

( 2001 OSI Software, Inc. All rights reserved777 Davis Street, Suite 250, San Leandro, CA 94577

Table of Contents

1Introduction

1Reference Manuals

2Supported Features

5Diagram of Hardware Connection:

7Principles of Operation

9Installation Checklist

11Interface Installation on NT

11Naming Conventions and Requirements

12Microsoft DLLs

12Interface Directories

13Interface Installation Procedure

13Installing the Interface as an NT Service

15Interface Installation on UNIX


16Interface Directories


19Interface Installation on VMS



23Connection Tool - Viewing the Local CHIP Database

23CHIP_UTIL

26CHIPDIA

29DigitalSet and Digital States

31PointSource

33PI Point Configuration

33Point Attributes

36Input-specific PI Point Parameters

40Output-specific PI Point Parameters

42Alarm Processing

438 - Bit Status Processing


45Controller Mode Processing

45PIDIFF and CHIP GENER

49Performance Point Configuration

51I/O Rate Tag Configuration

55Startup Command File

57Command-line Parameters

65Interface Node Clock

65NT

65UNIX

65VMS

67Security

67NT and UNIX

67VMS

69Starting / Stopping the Interface on NT

69CHIPtoPI as an NT Service

70CHIPtoPI Interactively, not as a Service

71Starting / Stopping the Interface on UNIX

71Command-Line Syntax for Background Processes

72Terminating Background Processes

72Anomalous Background Job Termination

73Starting / Stopping the Interface on VMS

73Starting a Detached Process

75Stopping

77Failover

77General Failover Overview

78General Failover Information

80OpenVMS Failover

82Windows NT/Windows 2000 Failover

93Picking up CHIP Point Database Changes

95Appendix A: Error and Informational Messages

97Appendix B: PI 2 PINET to PI 3 String Tag Support

106Setting up PI Batch File Interface on the PI 3 Home Node

109Appendix C: Linking/Re-linking CHIPtoPI on VMS

111Appendix D: Installation of CHIPtoPI on VMS from a Separate Tape

113Appendix E: Migrating from the PI-CHIP Interface to the CHIPtoPI Interface

113The CHIPPTCONVERT Utility

117Appendix F: Interface Distributions as Self‑Extracting Executables

117NT Installation

117UNIX Installation

117VMS Installation

117Documentation Updates

119Appendix G: File Conversion Utility for VMS Save Sets

119Reblock

120VMS Set File Command

121Appendix H: GNR2PI -- CHIPtoPI Point Creation Utility

122GNR2PI on Windows NT

123Revision History

Introduction

The Fisher-CHIP to PI interface moves data from the DH6200 series CHIP software to the PI System. The interface program reads the PI point database to determine which points to read from CHIP. It then scans the CHIP database and sends exception reports to the PI system. The interface can also send values from PI to the CHIP database.

This interface runs on Microsoft NT operating system, OpenVMS, and HP-UX 10.20. Also, the interface needs to reside on the same computer as the CHIP on NT, CHIP on VMS, or the CHIP on HP-UX software from Fisher. The CHIP software communicates with the PROVOX instrumentation from Fisher. The Fisher CHIP Programming Library option of CHIP is required on VMS platforms only (the VMS CHIP with the Programming Library is sometimes referred to as SuperCHIP). If the interface is to be run on Windows NT or HPUX, the programming library option is not necessary. See the CHIP User Guide from Fisher for more information about this software. The Fisher-Rosemount CHIP software should be version P0.3 or later. The Fisher-Rosemount CHIP software on HP-UX software should be version P4.3 or later.

Note1: If you are running Fisher-Rosemount CHIP software version P4.3 or earlier, you will need to install and use the version of the Chiptopi interface specifically built for P4.3 or earlier. If you are running P5.0 or later, should run the version of the Chiptopi interface built for P5.0 and later. If you are running a version of the Chiptopi interface older than v1.2.0, and you wish to upgrade P4.3 or lower to P5.0 or greater, you will have to place a copy of chip_lib50.lib in the \winnt\system32 directory, and rename it to chip_lib.lib. You will also have to place a license_size50.dll in the \winnt\system32 directory, and rename it to license_size.dll. This makes it safe to upgrade to P5.0 with all builds of the Chiptopi interface.

Note2: The old VMS-based CHIP Interface is no longer the primary CHIP Interface. We are shipping chiptopi to all new chip customers. Currently, chiptopi provides failover on VMS. Version 1.2 of the old VMS based PI‑CHIP interface is included on this tape in the backup saveset CHIP_VMS.bck or those customers who are not prepared to migrate to CHIPtoPI.

Reference ManualsOSIsoft

1. UniInt End User Document

2. PI Data Archive Manual

3. PI-API Installation Instructions

Supported Features

Feature

Support

Part number

PI-IN-FI-CHIP-NT

Platforms

VMS / Alpha VMS / NTI / HPUX 10.20

PI Point Types

PI2: Integer, Real, Digital

PI3: int16, int32, float16, float32, float64, digital, 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

Maximum Point Count

Limited by resources

Uses PI-SDK

No

PINet to PI 3 String Support

Yes

* Source of Timestamps

PI Server

* History Recovery

No

* Failover

Yes

* UniInt-Based

Yes

* Vendor Software Required on PI-API / PINet Node

Yes

* Vendor Software Required on Foreign Device

Yes / No

* Vendor Hardware Required

No

* Additional PI Software Included with Interface

Yes

*Device Point Types

See below

* See paragraphs below for further explanation.

Source of Timestamps

The CHIPtoPI interface uses PI server timestamps.

On VMS Pinet nodes, you can configure the interface to use the local time.

History Recovery

History Recovery is not supported.

Failover

Failover is supported on VAX VMS, Alpha VMS, Windows NT and Windows 2000. This interface supports outputs to the PROVOX highway and supports automatic data‑collection failover on VMS and WindowsNT/2000. Failover for Windows NT and Windows 2000 requires Microsoft Cluster Server. This interface does not support failover on HP-UX.

UniInt-Based

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

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

Vendor Software Required

The interface needs to reside on the same computer as the CHIP on NT, CHIP on VMS, or the CHIP on HP-UX software from Fisher. The CHIP software communicates with the PROVOX instrumentation from Fisher. The Fisher CHIP Programming Library option of CHIP is required on VMS platforms only (the VMS CHIP with the Programming Library is sometimes referred to as SuperCHIP). If the interface is to be run on Windows NT or HPUX, the programming library option is not necessary. See the CHIP User Guide from Fisher for more information about this software. The Fisher-Rosemount CHIP software on VMS and NT should be version P0.3 or later. The Fisher-Rosemount CHIP software on HP-UX software should be version P4.3 or later.

Vendor Hardware Required

No special vendor hardware is required beyond what is required by Fisher-Rosemount CHIP.

Additional PI Software

The PI-API for interfaces is required to run the CHIPtoPI interface in Windows NT/2000 or HPUX. If the interface is to run on a VMS PINet node talking to a PI3 home node scanning string tags, then the Batch File interface will be required on either the NT/2000 or UNIX platform.

Device Point Types

The CHIPtoPI interface can scan data from the following Fisher Point Types:

Local Inputs

Remote Inputs

Local Outputs

Remote Outputs

Type 1

Remote DDPs

Type 1

PVs

Type 2

Type 4

Discrete

Type 4

Type 5

Parallel Discrete

Type 5

Type 7

Mode

Type 7

Type 8

SP (Type 1 only)

Type 8

Type 10

IVP

Type 9

Type 12

SP (Spervisory)

Type 10

Type 18

Bias

Type 11

Type 19

Ratio

Type 12

Type 31

CV float

Type 13

DDP

Type 14

Type 18

Type 19

Type 21

Type 31

For details on which attributes belonging to each of these types can be read from or written to, see the table in section “PI Point Configuration”.

Diagram of Hardware Connection:

Principles of Operation

The PI System can run on the same computer as CHIP. The PI System can also run on another computer with the CHIP computer as a PIAPI node. In this way, it is possible to have several CHIP systems on different computers sending data to a PI System. Also, running on a PIAPI node, the interface can put data into either a version 2.X PI server or a 3.X PI server.

When reading values from CHIP, questionable status (a status code of 8 from CHIP routine Access_Point) is treated the same as good status. Questionable status occurs during conditions such as loss of controller redundancy that do not affect the values. PROVOX module failures are recorded in CHIP as communication failures. Tags with communication failures are recorded in PI with a status of "Bad Input".

Users migrating from the PI-CHIP Interface on VMS to the CHIPtoPI Interface see Appendix E: Migrating from the PI-CHIP Interface to the CHIPtoPI Interface for detailed information on the CHIPPTCONVERT Utility.

Installation Checklist

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

1. Verify the PI-API has been installed

2. Install the interface.

3. Define digital states (for details see the section entitled “DigitalSet and Digital States”).

4. Choose a point source. If PI 2 home node, create the point source.

5. Configure PI points. Location1 is the DBI number (or the CHIP Tagname can be placed in the exdesc or instrumenttag field).Location2 CHIP Point type taken from the section titled “Input-specific PI Point Parameters”. Location3 CHIP occurrence number taken from the section titled “Input-specific PI Point Parameters”.Location4 is the scan class.Location5 is the interface instance.exdesc is the CHIP Tagname, or the DBI can be specified in Location1.instrumenttag is the CHIP Tagname, or the DBI can be specified in Location1.

6. Edit startup command file (for details, see the section titled “Startup Command File”).

7. Configure performance points (for details see the section titled “Performance Point Configuration”).

8. Configure I/O Rate Tag (for details see the section titled “I/O Rate Tag Configuration”)

9. Set interface node clock. (Note that this step should be ignored if you are running on VMS.)

10. Set up security.

11. If CHIPtoPI is running on VMS, and sending data to a PI3 home node, test the FTP mechanism for PINet to PI 3 string support. See Appendix B for more information.

12. Start the interface.

13. Verify data.

14. Stop interface, start buffering, start interface. (This does not apply if the interface is running on VMS.)

Interface Installation on NT

Prior to the installation of the CHIPtoPI interface, you need to install the CHIP NT software on the computer. OSIsoft 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.

The CHIPtoPI interface setup program for interface version 2.8.0.0 and later uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000. When running on Windows NT 4.0 systems, the CHIPtoPI setup program will install the Windows Installer itself if necessary. To install, run the CHIPtoPI_x.x.x.x.exe installation kit.

Naming Conventions and Requirements

In the installation procedure below, it is assumed that the name of the interface executable is chiptopi.exe and that the startup command file is called chiptopi.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 chiptopi1.exe and chiptpoi1.bat for interface number 1, chiptopi2exe and chiptopi2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in a file that has the same root name.

Microsoft DLLs

The following Microsoft DLLs are distributed on the installation CD-ROM. Copy these files to the winnt\system32 directory only if the files in the winnt\system32 directory are older than the files on the CD-ROM.

MSVCIRT.DLL

MSVCRT.DLL

MSVCRT40.DLL

MSVCP50.DLL

MSVCP60.DLL

The following additional Microsoft DLLs are also distributed on the CD-ROM. These DLLs are only used by a debug version of the interface. Copy these files to the Winnt\system32 directory only if the files in the winnt\system32 directory are older than the files on the CD-ROM.

MSVCIRTD.DLL

MSVCRTD.DLL

MSVCP50D.DLL

MSVCP60D.DLL

Interface Directories

The following files are installed:

PI HOME DIRECTORY\

INTERFACES\

CHIPTOPI\

CHIPTOPI.EXE

CHIPTOPI.BAT.NEW

APIONLINE.BAT

APIONLINE.EXE

chiptopi_P4.3.dbg

chiptopi_P4.3.exe

chiptopi_readme.txt

Clusapi.dll

MSClus.zip

Resutils.dll

chiptopi.doc

WINNT \

Symbols\

EXE\

chiptopi.dbg

The PIHOME Directory Tree

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

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

Interface Installation Directory

The interface is installed to:

PIHOME\interfaces\chiptopi\

Where PIHOME is the corresponding entry in the pipc.ini file.

Interface Installation Procedure

To install, run the CHIPtoPI_x.x.x.x.exe installation kit.

Run PI-ICU to configure the interface, or alter the command-line arguments in the .bat file as discussed in this manual.

Try to start the interface interactively with PI-ICU, or manually with the command:chiptopi.bat

If the interface cannot be started interactively, it will not be able to run 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.

Installing the Interface as an NT Service

Run PI-ICU to configure and manage the interface service, or manually configure and manage the interface service as described below. One can get help for installing the interface as a service at any time with the command:chiptopi.exe –help

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

NT Service Installation Commands on a PI-API node or a PI Server node

with Bufserv implemented

Manual service

chiptopi.exe –install –depend “tcpip bufserv”

Automatic service

chiptopi.exe –install –auto –depend “tcpip bufserv”

NT Service Installation Commands on a PI-API node or a PI Server node

without Bufserv implemented

Manual service

chiptopi.exe –install –depend tcpip

Automatic service

chiptopi.exe –install –auto –depend tcpip

When the interface is installed as a service on the PI Server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will repeatedly attempt to connect to the PI Server until it is successful.

Note: Interfaces are typically not installed as automatic services when the interface is installed on the PI Server node.

Check the Microsoft Windows NT 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.

Interface Installation on UNIX

Prior to the installation of the CHIPtoPI interface, install the CHIP HP‑UX software on the computer. One 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 PI-API node? OSIsoft recommends that the interface be installed on a remote PI-API node. The primary function of the server node is to archive data and to service the clients that request that data. The PI Server should not need to compete with interfaces for the machine’s resources. If the interface is installed on a remote PI‑API node, then the PI-API must be installed on that node before the interface is installed. Refer to the PI‑API Installation Instructions manual.

When the interface is installed on a PI-API node, it is also a good idea to install and run Bufserv on the PI-API node. 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. It is not critical to install Bufserv before the initial installation of the interface. In fact, it is recommended that Bufserv be installed after the interface has been shown to work to ease troubleshooting. Refer to the PI-API Installation Instructions manual for installation instructions and additional information on Bufserv.

If the interface is installed on the PI Server node, the advantage of using Bufserv is diminished because it is no longer needed to protect against network failures. Bufserv would still allow data to be collected when the PI Server is brought down for routine maintenance, but one must weigh this advantage against the additional load that Bufserv incurs on the server. Typically, users do not choose to run Bufserv on the PI Server node. If Bufserv is used on the server node, one must make sure that Bufserv is started before any interfaces by the startup script for PI.

If the interface is installed on a server node, the interface should be configured to start and stop in conjunction with the PI Server. If the interface is installed on a PI‑API node, then the interface should be configured to start and stop with the PI-API. Site‑specific scripts can be edited for this purpose, as described in the installation procedure below. The PI Server and the PI-API, in turn, can be configured to start and stop automatically when the system is shut down or rebooted. Procedures for automatic startup and shutdown of PI or the PI-API are platform specific. The automation procedures are discussed in the PI System Management chapter of the PI Data Archive manual.


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

Note: UNIX does not enforce file-naming conventions, and it is possible that the file name extensions for the actual interface executable and command files are different than .exe and .sh, or it is possible that the file extensions are eliminated entirely.

In order to run multiple copies of the interface from the same directory, it is necessary to rename the executable and the command file. It is customary to use chiptopi1 and chiptopi1.sh for interface number 1, chiptopi2 and chiptopi2.sh for interface number 2, and so on.

Interface Directories

Example interface directory structure

The following files should be installed:

PI HOME DIRECTORY\

INTERFACES\

CHIPTOPI\

CHIPTOPI

CHIPTOPI.sh

The PIHOME Directory

PIHOME is an environment variable that points to the base directory where the PI-API is installed. The setting of environment variables is discussed in the PI-API Installation Instructions manual.

Interface Installation Directory

There are two conventions for the installation directory. The first convention is to place all copies of the interface into a single directory. If this convention is followed, it is recommended to place chiptopi1, chiptopi2, chiptopi3, etc., in the directory:

$PIHOME\interfaces\chiptopi\

The second convention is to create a separate interface directory for each copy of the interface. If this convention is followed, it is recommended to place chiptopi1, chiptopi2, chiptopi3, etc., in the directories:

$PIHOME\interfaces\chiptopi1\



and so on.

Create the installation directories as necessary.


In the installation procedure below, it is assumed that interface number 1 is being installed and that all copies of the interface will be installed in the same directory. To install another copy of the interface, repeat the following procedure with chiptopi# used in place of chiptopi1, where # is the interface number between 1 and 99.

Copy the interface files to $PIHOME\interfaces\chiptopi\. Create the directory if necessary.

If necessary, rename the executable and command files to chiptopi1 and chiptopi1.sh. The executable and command file should have the same root name.

Alter the command-line arguments in the chiptopi1.sh file as discussed in the section “Startup Command File.”

Try to start the interface as a foreground process. Follow the instructions in the next two sections to configure the command file and start the interface. It is advantageous to begin with foreground processes because the procedure for starting and stopping foreground processes is easier than for background processes. Once the interface is successfully running as a foreground process, one can try to run the interface in the background by following the appropriate instructions in the section “Starting and Stopping the Interface.”

If the Fisher-Rosemount CHIP library (libchip.so) is not in the SHLIB_PATH, its location needs to be added to this path before the interface can successfully run. To check to see if the directory is in the path, users can use this command:echo $SHLIB_PATHTo append a path to the end of SHLIB_PATH in the c shell, users can use this command:SHLIB_PATH=/usr/somepathname:$SHLIB_PATHwhere /usr/somepathname is the directory in which the CHIP library is installed.

Interface Installation on VMS

The CHIPtoPI Interface is supported on the OpenVMS VAX or Alpha platform. The Interface runs with a Fisher CHIP Database. The CHIPtoPI program interface is linked with the CHIPtoPI Programming Toolkit library and with PI toolkit library on site, which is why the Fisher-Rosemount CHIP Programming License is required.

One 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 PI2 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.


In the installation procedure below, it is assumed that the interface executable is called chiptopi.exe, the startup command file for is called chiptopi.com, and the startup command file for detached processes is called chiptopidetach.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 chiptopi.com file. For this purpose, it is customary to copy the chiptopi.com file to chiptopi1.com for instance 1, to chiptopi2.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 chiptopi.exe file and one chiptopidetach.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 file is chiptopi.out.

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


Interface 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 below. Sometimes, however, an interface needs to be installed or upgraded separately from the PI or PINet installation. This frequently needs to be done when a newer version of the interface is available than is distributed with the PI or PINet distribution.

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

Distribution files

CHIPtoPI.DOC

Interface manual (Microsoft Word Document). The interface‑specific installation procedure is in this manual.

CHIPtoPILink.COM

Installation command file for the Interface.

CHIPtoPI.BCK

Saveset containing the interface files.

RELEASENOTES.TXT

Release notes.

REBLOCK.README

Readme file for REBLOCK.EXE.

REBLOCK.EXE

The interface backup saveset must be reblocked before the saveset can be unpacked. See the REBLOCK.README.

The following procedure is typical.

1. Transfer CHIPTOPI.BCK and REBLOCK.EXE to the VMS node by some sort of binary file transfer mechanism. For example, one could use binary ftp. Copy the files to a safe directory, one that will not be overwritten during an upgrade of PI or PINet.

2. Transfer CHIPTOPILink.COM to the VMS node by some sort of ASCII file transfer mechanism. Copy the file to the safe directory.

3. Run REBLOCK.EXE on the CHIPTOPI.BCK file. Reblock corrects the block size of the CHIPTOPI.BCK file, which is altered during the binary file transfer. Binary file transfer does not affect the block size of the reblock executable itself. An example reblock session is given below.

$ run reblock

REBLOCK: Convert file to blocksize 32256

Filename ("\" to exit): CHIPTOPI.bck

Filename ("\" to exit): \

4. Unpack the CHIPTOPI.BCK saveset to the PIBuild directory by:backup/verify/log chiptopi.bck/sav *.*

5. Install the interface files with the command:@ CHIPTOPILink.comThe command file copies the files to the appropriate directories, and links the interface executable. Files similar to the following are typically installed.

PIBuild directory

CHIPTOPI.OBJ

Object file for the interface.

UNIINT.OBJ

Object file for the interface

CHIPTOPILINK.COM

Command procedure for re-linking the executable.

PISysExe directory

CHIPTOPI.EXE

Interface executable.

CHIPTOPI.COM

Startup command file for interactive processes.

CHIPTOPI DETACH.COM

Startup command file for detached processes (the command-line arguments are still defined in the CHIPTOPI.COM file).

Connection Tool - Viewing the Local CHIP Database

There is a utility that allows users to view the current value for a CHIP tag in the local CHIP database on a node where the CHIPtoPI interface runs. On Windows NT/2000, use the chip_util.exe utility in the CHIP directory to view the local CHIP database. On VMS use the CHIPDIA logical to run the CHIP utility_menu.com.

CHIP_UTIL

To run chip_util, go to the Start menu, select Programs, select the CHIP folder, and select the CHIP_UTIL utility. This opens a command window with the following options:

Enter 1 to view the CHIP Local Utilities Menu:

Enter 3 to View and Operate on CHIP Database Points:

The first point displayed will be the point with the lowest DBI in the local CHIP database. To display a different tag or DBI, type in N for (N)ew TAG/DBI:

Enter either a CHIP tagname (found in either the PI tag’s exdesc (Extended Descriptor) field or the InstrumentTag field), or enter the CHIP DBI (found in the PI tag’s location1 field).

This will display the selected DBI or CHIP Tag:

There are many different types of CHIP tags. The PI Tag’s Location2 parameter must match the “Type” of the CHIP tag. In the above example, the tag is a Type 5, so the PI tag that is scanning this point must have Location2 = 5. The PI Tag’s Location3 parameter determines which value the PI tag is scanning. For example, in the Type 5 tag above, if Location3 is set to 1, then the PI tag will be scanning the “%Process Variable”. If the Location3 value is 4, then the PI tag will be scanning the “Mode”.

To exit the chip_util utility, press the “enter” key until the windows closes.

CHIPDIA

On VMS, the CHIP diagnostic utility has a logical called “CHIPDIA” pointing to the .com file:

"CHIPDIA" = "CHIP_MENU:UTILITY_MENU.COM"

To launch CHIPDIA:

$@chipdia

If you receive this error:

%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

You may first need to set your UIC to CHIP:

$set uic chip

The CHIP Utilities menu will be displayed after running @chipdia:

CHIP Utilities Menu

1 - CHIP_DB_UTIL - CHIP Local Utilities Menu

2 - CHIP_SYS_UTIL - PROVOX System Utilities Menu

3 - PROVUE_UTIL - PROVUE Specific Utilities

4 - REDIRECT OUTPUT - Define a File to Receive Output

5 - INSTRUCTIONS - Turn instruction prompting on

6 - QUIT - or Press Return to QUIT

Enter choice number [quit]: : 1

Enter 1 for CHIP Local Utilities Menu

CHIP Local Utilities Menu

1 - FSLOG - CHIP Error Logging Program

2 - SMRY - CHIP Database Summary

3 - POINT_UTIL - View and operate on CHIP database points

4 - HIFSTATS - View HIU Statistics

5 - WATCH_DOG - Monitor Status of CHIP Programs

6 - OUR_ADDR - Address of this CHIP

7 - REV_LEVEL - Revision, DB Info & Address of this CHIP

8 - CLEAR_DB - Clear ERR flag on CHIP Points


Enter choice number [quit]: 3

Enter 3 for View and operate on CHIP database points

Do you want instructions? (Y,N,S: [NO]): n

If you wish to view instructions, type Y, otherwise, type N.

The first point displayed will be the point with the lowest DBI in the local CHIP database:

Mode ................ MAN

Output Tracking …… 0 A Alarm ... 0 Percent IVP Low ... 0

Integral Tracking ... 0 B Alarm ... 0 Percent IVP Hi .... 0

Setpoint Tracking ... 0 C Alarm ... 0 SP Low ............ 0

Questionable Data ... 1 D Alarm ... 0 SP Hi ............. 0

%Process Variable ... 0.0000

Local/Remote ... LOCAL Slot Param ... n/a Object ID ... 1

Tag .. L1-1 Type .. 1 EU High .. 100.00 EU Low .. 0.00

Source @8-20 DBI 1 status = 8 (0/8) Questionable Data

(A)ttr/Mnem list (C)hange oper param (N)ew TAG/DBI

(P)oint list (D)isplay DDPs (T)ime int (Q)uit

To display a different tag or DBI, type in N for (N)ew TAG/DBI:

Enter TAG, DBI or : 5

Enter either a CHIP tagname (found in either the PI tag’s exdesc (Extended Descriptor) field or the InstrumentTag field), or enter the CHIP DBI (found in the PI tag’s location1 field). This will display the selected DBI or CHIP Tag:

Mode ................ MAN

Output Tracking ..... 0 A Alarm ... 0 Percent IVP Low ... 0

Integral Tracking ... 0 B Alarm ... 0 Percent IVP Hi .... 0

Setpoint Tracking ... 0 C Alarm ... 0 SP Low ............ 0

Questionable Data ... 1 D Alarm ... 0 SP Hi ............. 0

%Process Variable ... 0.0000

%Set Point .......... 0.0000

%IVP ................ 0.0000

Local/Remote ... LOCAL Slot Param ... n/a Object ID ... 5

Tag .. L5-5 Type .. 5 EU High .. 100.00 EU Low .. 0.00

Source @8-20 DBI 5 status = 8 (0/8) Questionable Data

(A)ttr/Mnem list (C)hange oper param (N)ew TAG/DBI

(P)oint list (D)isplay DDPs (T)ime int (Q)uit

There are many different types of CHIP tags. The PI Tag’s Location2 parameter must match the “Type” of the CHIP tag. In the above example, the tag is a Type 5, so the PI tag that is scanning this point must have Location2 = 5. The PI Tag’s Location3 parameter determines which value the PI tag is scanning. For example, in the Type 5 tag above, if Location3 is set to 1, then the PI tag will be scanning the “%Process Variable”. If the Location3 value is 4, then the PI tag will be scanning the “Mode”.

To exit the CHIPDIA utility, press the “enter” key until VMS DCL prompt is displayed.

DigitalSet and Digital States

PI 2 Sample Digital State Table

A sample Digital State Table for the CHIP alarm states is shown below. The entries at 130-4 are for alarm tags with Location3 equal to 5. According to this example, these tags should have a DigStartCode of 130 and a DigNumber of 4. The entries at 150‑165 are for alarm tags with Location3 equal to 6. Entries 136-7 are for alarm tags with Location3 equal to 7. Entries 138-9 are for Location3 equal to 8. Entries 140-1 are for Location3 equal to 9. Entries 142-3 are for Location3 equal to 10.

Entries 170-177 are for controller mode tags. Note that state 0 (170) is not used. The Digital Start Code for mode tags should still be 170 for this example.

Printed out for: CET - 26-Jun-89 09:54:48

PI System Digital States Definition Page 3 26-Jun-89 09:54:48

Digital States Table

-----------------------------------------------------------

129 145 161 D,B,C Alarms 177 HManual

130 No Alarm 146 162 D,A Alarms 178

131 C Alarm 147 163 D,A,C Alarms 179

132 B Alarm 148 164 D,A,B Alarms 180

133 A Alarm 149 165 D,A,B,C Alrm 181

134 D Alarm 150 No Alarm 166 182

135 151 C Alarm 167 183

136 No Alarm 152 B Alarm 168 184

137 A Alarm 153 B,C Alarms 169 185

138 No Alarm 154 A Alarm 170 < Blank > 186

139 B Alarm 155 A,C Alarms 171 Manual 187

140 No Alarm 156 A,B Alarms 172 Auto 188

141 C Alarm 157 A,B,C Alarms 173 RSP 189

142 No Alarm 158 D Alarm 174 Sup 190

143 D Alarm 159 D,C Alarms 175 DDC 191

144 160 D,B Alarms 176 Com 192

PI 3 Sample Digital State Table

For a PI 3.X system, you may need to define the following digital state sets for the controller mode and the alarm status:

@table PIDS

@mode create

@istru set,state,...

Onoff,Off,On

CHIPMODE,Zero,Manual,Auto,RSP,SUP,DDC,COM,HMAN

CHIPALARM,no alarm,C alarm,B alarm,A alarm,D alarm

CHIPALMCOMB,noalarm,C,B,CB,A,CA,BA,CBA,D,CD,BD,CBD,AD,CAD,BAD,CBAD

@ends

These digital state sets need to be defined before the PI 3 tags digital tags are defined.

PointSource

The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For example, one may choose the letter F to identify points that belong to the CHIPtoPI interface. To implement this, one would set the PointSource attribute to F for every PI Point that is configured for the CHIPtoPI interface. Then, if one uses /ps=F on the startup-command line of the CHIPtoPI interface, the CHIPtoPI interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of F. 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 argument.

Case-sensitivity for PointSource Attributes

If the interface is running on a PINet node and the Server node is a PI 3 system, 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, one does not need to be careful with the case of the PointSource.

In all cases, the point source character that is supplied with the /ps command-line argument is not case sensitive. That is, /ps=F and /ps=f are equivalent. One only needs 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 3 Server.

PI 2 Server Nodes

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

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

Defining a Point Source Character in the PI 2 Point Source Table

1. Enter PI by typing the following command from a VMS command prompt: @pisysexe:pi

2. Select the PointSrc option from the menu.

3. Select New from the menu.

4. Assign a point source next to the Code: field. Also, assign minimum and maximum values for the Location1 to Location5 attributes.

Location1

Location2

Location3

Location4

Location5

Minimum

0

-19

1

0

0

Maximum

10240

300

385

32

99

5. Select “Save” from the menu.

PI 3 Server Nodes

No point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character. Several subsystems and applications that ship with PI 3 are associated with default point source characters The Totalizer Subsystem uses the point source character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Either do not use these point source characters or change the default point source characters for these applications. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.

PI Point Configuration

A PI point or tag is a single parameter from a CHIP point. For example, a process variable and a set point are part of the same point in the Fisher system. In the PI System, these parameters are stored as two separate tags. The following PI point attributes determine how values are interpreted as they are moved from CHIP to PI or PI to CHIP.

Point Attributes

Tag

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

Point Source

The point source is any one-character value, for example F. The point source must be defined in the point source library before interface operation on version 2.X of the PI system. Also, the point source used in the PI tag definition should match the point source used in the interface startup file. For additional information, see the /ps command-line argument and the “Point Source” section.

Point Type

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

When the interface is running on Windows or UNIX, and writing data to a PI3 home node, negative integer values can be scanned now, whereas they previously were not. If the interface runs on PINet or a PI2 home node, this feature is not available. (2.7.0.3).

PI 2 Server Nodes

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

PI 3 Server Nodes

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

Location1

This is the CHIP DBI (database index). If Location1 is 0, the CHIP tag name should be in the beginning of the Extended Descriptor or in the Instrument Tag. Note that the interface will convert the CHIP tag name to its corresponding DBI upon startup. If, at any time, the DBI for any tag changes, the affected PI tag will need to be re-added to the interface, or the interface will have to be stopped and restarted. To cause the tag to be re-added to the interface, modify a benign tag attribute field, such as the descriptor. The interface will pick up the change, and re-add the tag to the interface, and re-obtain the DBI. This behavior will be modified in a future release of the interface.

Location2

This is the CHIP point type for inputs and local outputs (see Table B-6 of the CHIP User Manual, UM4.10:DH6215). The sign of this parameter determines the direction of data transfer from CHIP to PI. If this value is positive, the value is transferred from CHIP to PI. If this is the negative of the CHIP point type, values are sent from PI to CHIP. The exception to this is when sending data to the CHIP Highway points, where the sign is positive.

Location3

This determines which CHIP parameter is associated with this PI tag for local inputs and outputs. Location2 determines how this parameter is interpreted (see table below).

Location4

This parameter determines the scan class of the tag. The number of scan classes and the scan frequencies are specified in the interface startup command file. A value of 1 in Location4 assigns this tag to the first scan class specified in the startup file; a value of 3 assigns the tag to the third scan class.

Location5

This is the CHIP System Number or the interface ID number. It is used when there is more than one interface running on different computers. In that case, this parameter differentiates between points with the same DBI on different CHIP systems. If the interface ID number is specified in the interface startup command file, only points with Location5 matching the ID number are loaded. If the startup command file does not specify an interface ID number or it specifies -1, all the tags with matching point source are loaded, i.e. Location 5 are ignored.

Instrument Tag

If Location1 is 0, the Instrument tag field should contain the CHIP tag name. For compatibility with previous versions of PI-CHIP, this field or the Extended Descriptor field can contain the CHIP tag name.

Extended Descriptor

The Extended Descriptor can be used to specify a number of attributes for the CHIP interface tag. If Location1 is 0 and the CHIP tag name is not defined in the Instrument tag field, the first 16 characters of the Extended Descriptor should contain the CHIP tag name.

Also, the interface supports event-based inputs. The syntax for defining an event‑based point is to add the following in the Extent Descriptor of the input point:

EVENT=PI tag name, where the PI tag name is the name of the event trigger tag.

Every time the interface receives a new event for the event tag, the interface will read the CHIP for all of the event inputs associated with this event tag. A new event is defined as a snapshot event with time stamp greater than the existing snapshot time. The event-based input tags are useful for batch analysis.

You can also use the Extended Descriptor to specify the bit to extract in the LCP Status Word, or the EDCD statuses. Use the syntax:

PI2 Server: BIT=X,where X is the bit number from 1 to 16.

PI3 Server: BIT=X,where X is the bit number from 1 to 32.

If the BIT option is not specified for a LCP Status Word tag or if the BIT option is set to 0, the whole status word is stored into PI.

You can also use the Extended Descriptor to specify the Occurrence number for point type 100 DDP Highway Outputs. Use the syntax:

DDP=X, where x is the occurrence number

Source Tag

For outputs, the tag you are creating is only a pointer tag. The name of the tag, containing the values to be sent to CHIP, must be entered here. If this field remains empty, the pointer tag itself contains the values to be sent.

UserInt1

This parameter determines whether a conversion factor is to be applied to CHIP Point Type 31 CV5 to CV8 input values. The default behavior is to apply no conversion to the CV5 to CV8 input values. If UserInt1 = 1, and the PI tag is a floating point tag, then the CV value will be converted from percent to floating point value (effectively dividing the value by 256). This feature requires that the PI-API be version 1.3.x or greater. (2.1.8)

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.

Point Attributes that Also Affect the Interface Program

For further information regarding these attributes, see the UniInt End User Document.

· Exception Deviation

· Exception Minimum Time

· Exception Maximum Time

Note: Since this interface does exception reporting, the Compression Minimum Time should be less than the scan time for the interface in most situations. The exception reporting algorithm sends values from consecutive scans. If the Compression Minimum Time is too large, the second of these two values will never be recorded. Use the Exception Minimum Time only if it is necessary to throttle data from especially noisy points. The Scan attribute can be used to stop data collection.

Point Attributes that Do not Apply to CHIP Points

· Square Root

· Convers

· TotalCode

Input-specific PI Point Parameters

The interface program recognizes the CHIP point types and parameters listed in this table. The first PI PointType listed is most like the Fisher CHIP database point type. If there are two listed, and they are separated by a comma, both pointtypes are recommended. If the second value is in parentheses, it is second choice for matching the Fisher CHIP database point type.

Local Inputs

CHIP Point Type (Location2)

CHIP Parameter

Location3

Recommended PI PointType

PI 3 PI 2

1

PV

1

Float16 (Int16)

R (I)

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (int16)

D (I)

2

Count

1

Int16

I

Alarm

5-10

Digital (int16)

D (I)

4

PV1

1

Float16

R

PV2

2

Float16

R

5

PV

1

Float16

R

SP

2

Float16

R

IVP

3

Float16

R

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (int16)

D (I)

Output Tracking

35

Float32, Digital

R, D

Integral Tracking

36

Float32, Digital

R, D

Setpoint Tracking

37

Float32, Digital

R, D

7

PV

1

Float16

R

SP

2

Float16

R

IVP

3

Float16

R

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (int16)

D (I)

Bias or Ratio

11

Float16

R

8

PV

1

Float16

R

SP

2

Float16

R

IVP

3

Float16

R

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (int16)

D (I)

Bias

11

Float16

R

Ratio

12

Float16

R

9

Value

bit number, 1-4

Digital (Int16)

D (I)

Mode

5

Digital (Int16)

D (I)

10

Mode

4

Digital (Int16)

D (I)

Number UV's

13

Int16

I

Operation Number

14

Int16

I

Step Number

15

Int16

I

Phase Number

16

Int16

I

Unit State

17

Int16

I

Hold Phase Number

18

Int16

I

Operation Complete

19

Int16

I

Unit Status

20

Int16

I

Operation Timer

21

Int16

I

State Timer

22

Int16

I

Step Timer

23

Int16

I

Iteration

24

Int16

I

Fail Index

25

Int16

I

OAR

26

Int16

I

OAR Sequence No.

27

Int16

I

Message Number

28

Int16

I

Message Param 1

29

Float16

R

Message Param 2

30

Float16

R

Activity Point DBI

31

Int16

I

Highway Address of Console

32

Int16

I

Unit Variable #n

100 + n (note 1)

Float (note 1)

11

Mode

4

Digital (Int16)

D (I)

In/out of Service

13

Digital, Int16

D (I)

Off Scan

14

Int16

I

SP Number

15

Int16

I

PV Number

16

Int16

I

Group Status

17

Digital (Int16)

D (I)

Fail Index

18

Int16

I

12,13

Mode

4

Digital (Int16)

D (I)

In/out of Service

13

Digital, Int16

D, I

Off Scan

14

Digital, Int16

D, I

Discrete Value

15

Int16

I

14

Mode

4

Digital (Int16)

D (I)

In/out of Service

13

Digital, Int16

D, I

Off Scan

14

Digital, Int16

D, I

SP Number

15

Int16

I

PV Number

16

Int16

I

DCD Status

17

Digital (Int16)

D (I)

Input Channel Status

18 (note 4)

Digital, Int32

D, I

Output Channel Stat

20 (note 4)

Digital, Int16

D, I

Interlocks Configured

21 (note 4)

Digital, Int16

D, I

Condition – Status

22 (note 4)

Digital, Int16

D, I

Condition – Last Fail

23 (note 4)

Digital, Int16

D, I

Condition – Override

24 (note 4)

Digital, Int16

D, I

Miscellaneous Flags

25 (note 4)

Digital, Int16

D, I

Setpoint Disables

26 (note 4)

Digital, Int32

D, I

18

PV

1

Float32 (Int32)

R (I)

Local DDP

171-186

Float32 (Int32)

R (I)

19

Real Value

1

Float32 (Int32)

R (I)

ASCIIMSG

34 (note 5)

String

N/A

21

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (Int16)

D (I)

Activity State

13

Digital (Int16)

D (I)

Activity Status

14

Int16

I

Iteration Count

17

Int16

I

Procedure Index

24

Int16

I

Process Index

25

Int16

I

Hold Process Index

26

Int16

I

Grade Index

27

Int16

I

Point Set Number

28

Int16

I

Activity Index

29

Int16

I

Statement Index

31

Int16

I

Fail Value

32

Int16

I

State Timer

33

Int16

I

Batch ID

34 (note 5)

String

N/A

Point Status Mask (MVPSTMSK 1-16) (2.8.0.3)

38 (note 4)

Digital (Int16)

D (I)

31

Mode

4

Digital (Int16)

D (I)

Alarm

5-10

Digital (int16)

D (I)

In/out of Service

13

Digital, Int16

D, I

Off Scan

14

Digital, Int16

D, I

Fail Index

17

Int16

I

State

18

Int16

I

Status Word

19 (note 2)

Int16

I

User-Defined integer (2.5.9.0)

20 (note 2)

Int16

I

Point Status Mask (MVPSTMSK 1-16) (2.8.0.3)

38 (note 4)

Digital (Int16)

D (I)

CV #n

100 + n (note 3)

Float32 (Int32)

R (I)

Note 1: n is between 1 and 32 for Unit Variables. Uvs 1-8 use Float64, Uvs 9-32 use float16.

Note 2: for LCP Status Words and User-defined integers, you can extract a single bit from the Status Word with the BIT keyword in the Extended Descriptor. The PI tag in this case can be an Integer, Digital, or Real Point Type. If you don’t use the BIT processing option, the entire Status word being returned. Since the value can exceed the maximum integer value of 32767, it is recommended that the PI2 tag be defined as Point Type Real and High Precision, and the PI3 tag be defined as an int32 tag.

Note 3: n is between 1 and 12 for the CVs.

Note 4: 16-bit statuses with Extended Descriptor field = 0 or 17 (record the whole status) must be Full Precision Real tags on PI 2 or int32 (float32), otherwise the value could result in an Over/Under Range value. To specify just one bit, specify the bit # in the Extended Descriptor field, in the form BIT=x. To read the first bit set to ON from the 8-bit statuses, specify BIT=10 in the Extended Descriptor field. (2.5.4.0)

Note 5: To scan ASCIIMSG and BATCHID string tags on a VMS PINet and send them to a PI3 server, run the PIFTP process and install the BatchFile interface on the PI3 server or on a PI-API node. This is documented below in a section titled “Appendix B: PI 2 PINET to PI 3 String Tag Support”.

Output-specific PI Point Parameters

Local outputs are transferred from the PI System to the CHIP shareable image. Local CHIP points can be read by consoles on the PROVOX highway. You can use local outputs to display the results of calculations in the VAX to operators.

An output is sent whether the PI snapshot value, status, or time has changed for the source tag. All outputs are sent on the first scan after restarting the interface if the /sio option is not specified in the interface startup file. If the output tag is not the same as the source tag, each output value is written to the output tag on PI so that the user has a record of when an output event has occurred. PI exception report specifications are not used for outputs to CHIP but are used when writing the output value to the output tag on PI.

For highway outputs, a point must be defined in the CHIP database.

The interface program uses the CHIP database's point attributes to determine the highway address for the output as well as the scaling factor and limits for the highway output value. The CHIP point output can also be defined as an input to PI.

For outputs to the PROVOX highway, the remote device may reject the value if the point is not in the correct mode. The correct mode for accepting an output depends on the point type. Appendix C of the CHIP User Manual lists which parameters may be changed for each point type. The interface program writes a message to PISysExe:CHIPtoPI.out and the PI Message Log when a highway output is not successful.

Local Outputs

Recommended PI Pointtype

CHIP Point Type(Location2)

CHIP Parameter

Location3

-1

PV

1

Int16

I

-4

PV1

1

Int16

I

PV2

2

Int16

I

-5, -7, -8

PV

1

Int16

I

SP

2

Int16

I

-10

Activity Point DBI (ATAG)

31

Int16

I

-12

Discrete Value

15

Int16

I

-18

PV

1

Int16

I

-19

PV

1

Int16

I

ASCIIMSG

34

String, Float32, Int32, Digital

I, R, or D

-31

CV #n

100 + n (note 1)

Float32 or Int32

R or I

Note 1: n is between 1 and 12 for the CVs.

Highway Outputs

Location2

CHIP Parameter

Location3

Extended Descriptor

41

PV

45

Discrete

47 (note 2)

Parallel Discrete

48

Mode

Not

Used

50

SP (only CHIP Type 1)

51

IVP

52

SP (Supervisory)

53

Bias

54 (note 2)

Ratio

84 (note 2)

CV float

CV number

100

DDP

mnemonic #

Occurrence # optional, 1-x (note 1)

Note 1: DDP=x, where x is the optional occurrence number, can be placed in the extended descriptor. Note 2: Highway outputs for Parallel Discrete (47), Ratio (54), and CV float (84) are not yet supported.

Highway Inputs

Location2

CHIP Parameter

Location3

Extended Descriptor

200

Remote DDPs (note 1)

mnemonic #

Occurrence # optional, 1-x (note 2)

Note 1: Highway reads take longer than local database reads. It is recommended that a separate copy of the interface be run to collect DDPs. Local database reads/writes, and Highway outputs can all be collected/written by the same copy of the interface. Supported Remote DDP reads include DDP mnemonic#s 1-385, and mnemonic#s 769-1023.

Note 2: DDP=x, where x is the optional occurrence number, can be placed in the extended descriptor.

Alarm Processing

The interface gives three options for interpreting alarm values from CHIP:

· A five-state result shows which alarm bit is set. Only one alarm at a time can be recorded.

· A 15-state result shows any possible combinations of the alarm bits.

· A single alarm bit can be assigned to a tag.

If the Location3 parameter is 5, the alarm states are:

0 = no alarm

1 = C alarm

2 = B alarm

3 = A alarm

4 = D alarm

If two alarm bits are set, the first one in the above list is reported. For example, if both B and D alarm bits are set, the PI value will be the B alarm state.

If Location3 is 6, the combination of the 4 alarms for a point is recorded. The value returned will have a range of 0-15, where:

1 = C alarm

2 = B alarm

4 = A alarm

8 = D alarm

These values are summed for alarm bits that are set to represent the combined alarm state.

Use a Location3 in the range 7-10 to record a single alarm bit. State 0 means no alarm. State 1 means the specified bit is set.

7 = A alarm

8 = B alarm

9 = C alarm

10 = D alarm

For alarms, the PI point type can be real, integer or digital. Note that the meaning of the alarm state may be site specific. The defaults are:

A alarm - deviation alarm

B alarm - Low alarm

C alarm - High alarm

D alarm - user defined

A sample Digital State table that shows these states is at the end of this chapter.


The interface gives two options for interpreting 8-bit statuses from CHIP.

· A nine-state result shows the first bit set to ON. Only one alarm at a time can be recorded.

· The Integer value of the entire 8-bit status may be assigned to a tag and recorded.

· A single alarm bit may be assigned to a Digital or Integer tag and recorded.

To read one bit of an 8-bit status, one of the following Instrument Tag field settings must be used:

0 = all bits are to be read (this is optional, if the instrument tag field is blank, the whole status is read)

1 = 1st status bit is to be read

2 = 2nd status bit is to be read

3 = 3rd status bit is to be read

4 = 4th status bit is to be read





For statuses, the PI point type can be real, integer or digital. The default status states are:

0 = Off

1 = On

If the Location3 parameter is 5, the alarm states are:

0 = no alarm

1 = C alarm

2 = B alarm

3 = A alarm

4 = D alarm

If two alarm bits are set, the first one in the above list is reported. For example, if both B and D alarm bits are set, the PI value will be the B alarm state.

A sample Digital State table that shows the status On/Off states is at the end of this chapter.


The interface gives two options for interpreting statuses from CHIP:

· The Integer value of the entire 16-bit status may be assigned to a tag and recorded.

· A single alarm bit may be assigned to a Digital or Integer tag and recorded.

To read one bit of a 16-bit status, one of the following Instrument Tag field settings must be used:

0 = all bits are to be read (this is optional, if the instrument tag field is blank, the whole status is read)

1 = 1st status bit is to be read

2 = 2nd status bit is to be read

3 = 3rd status bit is to be read














For bit statuses, the PI point type can be real, integer or digital. The default status states are:

0 = Off

1 = On

For the entire 16-bit status, the PI point type needs to be a Real, Full Precision tag with a Span of 65534.

A sample Digital State table that shows the status On/Off states is at the end of this chapter.

Controller Mode Processing

The controller modes are shown below. A sample Digital State table that shows these states is at the end of this chapter.

1 - MAN

2 - AUTO

3 - RSP

4 - SUP

5 - DDC

6 - COM

7 - HMAN

PIDIFF and CHIP GENER

The CHIP points in the PI database are usually created after defining the CHIP database. The CHIP database is compiled from an ASCII file with a Fisher‑supplied utility called GENER. The input file is based upon keywords that GENER recognizes as prompts that precede the CHIP database parameters. You can often use this same ASCII file, with some editing, to create points in PI. The file is used as a data file for the PI tag database creation/maintenance utility, PIDIFF.

When using the GENER input file as the data file for PIDIFF, consider the following fields:

GENER Keyword

PIDIFF Keyword

POINT

Tag

DESC

Descriptor

DBI

Location1

POINT TYPE

Location2

EU

EngUnits

LOLIMIT

Zero

HILIMIT

Span + Zero

The exception specifications in CHIP could be used for PI's exception deviation and exception minimum time.

Since the interface is using the CHIP routines Access_Point and Change_Point, the CHIP database must have valid HI and LO limit specifications. The HI and LO limits are used by CHIP to convert the PROVOX highway values to engineering units. If these limits are not set, all analog values from CHIP will be zero.

Following is a sample file for the CHIP GENER utility. Below the database fragment is a PIDIFF structure file for using this file to create new PI points in 2.X PI system and a PICONFIG file to create tags in 3.X PI system.

RECORD 1, LENGTH = 240

DBI = 1 LOCAL = FALSE

POINT TYPE = 1 UNSOLICITED = TRUE

DEVICE ADDRESS = 0- 6 SLOT PARAMETERS --

POINT NUMBER = 35-156 DEADZONE ENABLED

DEADZONE VALUE = 0.0625

SAMPLE INTERVAL = 60

TAG = 510X9116

DESCRIPTOR = BREAK #1 P. M.

UNITS =

EU HIGH = 1.00

EU LOW = 0.00

RECORD 2, LENGTH = 240

DBI = 2 LOCAL = FALSE

POINT TYPE = 1 UNSOLICITED = TRUE

DEVICE ADDRESS = 0- 6 SLOT PARAMETERS --

POINT NUMBER = 35-184 DEADZONE ENABLED

DEADZONE VALUE = 0.0625

SAMPLE INTERVAL = 60

TAG = 520X9144

DESCRIPTOR = BREAK #2 P. M.

UNITS =

EU HIGH = 1.00

EU LOW = 0.00

PIdiff structure file for 2.X PI system:

* Structure1.pdf

* Oil Systems, Inc.

*

* Structure file for creating PI Points from the CHIP

* file shown above.

*

* Directives

errormax,0

errorfile,PISysMgr:Errorfile.pdf

*

* Defaulted Items

pointtype,DEFAULT,R

pointsource,DEFAULT,F

location3,DEFAULT,1

location5,DEFAULT,1

excmax,DEFAULT,600

res,DEFAULT,2

*

* Tag Attributes

tag,8,16,10

descriptor,9,16,16

engunits,10,16,10

typicalvalue,11,16,10

zero,12,16,10

span,11,16,10

location1,2,22,5

location2,3,24,3

excdev,6,21,6

excmin,7,24,3

*

* End of file

The corresponding PIConfig structure definition section for creating tags in PI 3.X system is:

* chipconfig.pdf

* Oil Systems, Inc.

*

* Structure file for creating PI3.X Points from the CHIP

* file shown above.

*

* Point Database Directives

@ptclas classic

@tabl pipoint

@mode create

@stype fixed

*

* Defaulted Items

@modi ptclass=classic

@modi pointtype=R

@modi pointsource=F

@modi location3=1

@modi location5=1

@modi excmax=600

*

* Tag Attributes

@istr tag,8,16,10

@istr descriptor,9,16,16

@istr engunits,10,16,10

@istr typicalvalue,11,16,10

@istr zero,12,16,10

@istr span,11,16,10

@istr location1,2,22,5

@istr location2,3,24,3

@istr excdev,6,21,6

@istr excmin,7,24,3

*

* End of structure definition section

Performance Point Configuration

One can configure performance points to monitor the amount of time in seconds that it takes an interface 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 time is recorded to millisecond resolution.

Configuring Performance Points with PI-Interface Configuration Utility

Configuring Performance Points Manually

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

1. Set the extended descriptor to:PERFORMANCE_POINTor toPERFORMANCE_POINT=interface_idwhere interface_id corresponds to the identifier that is specified with the /id flag 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 flag for a description of scan classes.

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

4. Set the PointType attribute float32.

I/O Rate Tag Configuration

An IO 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 IO Rate tag can be configured for each copy of the interface that is in use.

Configuring IORates Tags with PI-Interface Configuration Utility

Configuring IORates Tags Manually

There are two configuration steps.

Configuring the PI Point on the PI Server

PI 2 Server Nodes

A listing of the IO Rate Tags that are currently being monitored can be obtained with the command:

@PISysDat:IOMonitor.com

Create an IO Rate Tag using one of the existing IO Rate Tags as a template. The IOMonitor program is discussed on page DA-71 of PI System Manual I.

PI 3 Server Nodes

Create an IO Rate Tag with the following point attribute values.

Attribute

Value

PointSource

L

PointType

float32

Compressing

0

ExcDev

0

The default settings can be used for the remaining PI Point attributes. When Compressing is set to Zero the IO Rate Tag acts like a heartbeat tag for the interface, which can be examined easily in ProcessBook with markers turned on. If a value is not written to the IO Rate Tag every 10 minutes, then there is problem with the interface communication.

Configuring on the Interface Node

For the following examples, assume that the name of the PI tag is chiptopi001, and that the IO Rate point on the home node is chiptopi001.

NT Nodes

1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the \WinNT 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:chiptopi001, xwhere chiptopi001 is the name of the IO Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. 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. To specify additional rate counters for additional copies of the interface, create additional IO 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 flag on the startup command file of the interface to match the event counter in the iorates.dat file.

3. The interface must be stopped and restarted in order for the IO Rate tag to take effect. IORates will not be written to the tag until 10 minutes after the interface is started.

The 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.

UNIX Nodes

1. Edit/Create a file called iorates.dat in the $PIHOME\dat directory. PIHOME is an environment variable that is set equal to the PI home directory name as discussed in the PI-API Installation Instructions manual. Add a line in the iorates.dat file of the form:chiptopi001, xwhere chiptopi001 is the name of the IO Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. 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. To specify additional rate counters for additional copies of the interface, create additional IO 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 flag on the startup command file of the interface to match the event counter in the iorates.dat file.

3. The I/O rates shared memory server and the I/O rates monitor program must be stopped and started for the changes to take effect. The easiest way to do this is to run the pistop and pistart command scripts with the following commands.

sh $PIHOME/bin/pistop

nohup sh $PIHOME/bin/pistart

One can determine that the shared memory server and the I/O rates monitor are running with the commands:ps –ef | grep ioshmsrv

ps –ef | grep iorates

The 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.

Open VMS Nodes

IORates are discussed on page DA-59 of PI System Manual I.

To implement an IO Rate tag, perform the following steps:

1. Add a line to the PISysDat:IORates.dat file of the form:CHIPTOPI001, xwhere chiptopi001 is the name of an iorates tag for this copy of the interface and x corresponds to the event counter specified by the first instance of the /ec=x flag 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 that 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 flag on the startup command file of the interface to match the event counter in the PISysDat:IORates.dat file.

3. Stop and start the IORates process with the following commands so that the changes take effect.

@PISysExe:stop iorates

@PISysExe:iorates.com

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.

Startup Command File

The CHIPtoPI interface on Windows has an ICU Control that will aid in configuring the CHIPtoPI interface startup command file:

The CHIPtoPI control for PI-ICU has four sections. A yellow text box indicates that an invalid value has been entered, or that a required value has not been entered.

General

Pause before connecting to CHIP

This tells the interface to pause x milliseconds before loading the CHIP DB points to allow for the CHIP DB to startup fully. The default is not to pause on startup. The command line equivalent is /sp=x, where x is the number of milliseconds to pause before loading CHIP points.

Allow highway outputs

Allow highway outputs enables Highway Outputs. The command line equivalent is /hiway.

Update DBIs

The Update DBIs every x hours. X can be any integer from 1 to 24. The default is to update DBIs once every 24 hours. The command line equivalent is /udbi=x, where x is how often in hours to update the DBIs.

Debug Levels

The Debug Levels flag is used to set a debug level for debug messaging. Check all types of debug messages that you would like to see logged. Any combination of debug levels can be applied. The command line equivalent is /db=x, where x indicates the level of debug messaging.

Failover

A detailed discussion of failover can be found later in this manual in a section titled “Failover”.

Enable failover

If checked, failover is to be enabled. Interface platform must then be selected. The command line equivalent for VMS is /fo. The command line equivalent for NT/2000 is /fo=x, where x is the number associated with the APIOnline process discussed in the Failover section of the CHIPtoPI interface manual

This is the Primary node

One node must be marked primary. If this is the primary interface, check the This is the Primary Node check box. The name of the primary interface node may optionally be entered. The command line equivalent is /primary=x.

Secondary CHIP address

This is required only on the Primary interface node, and is the CHIP address of the secondary node. The first text box is the highway number. The second text box is the device number. The CHIP address can be retrieved by running CHIP_UTIL on the secondary interface node, and selecting option 1:

CHIP Utilities Menu

1 - CHIP_DB_UTIL - CHIP Local Utilities Menu

2 - CHIP_SYS_UTIL - PROVOX System Utilities Menu


Enter number of your choice:

Then run select option 6:

CHIP Local Utilities Menu

1 - FSLOG - CHIP Error Logging Program

2 - SMRY - CHIP Database Summary

3 - POINT_UTIL - View and Operate on CHIP Database Points

4 - HIFSTATS - View Highway Interface Statistics

5 - CHIPTASKS - Monitor Status of CHIP Programs

6 - OUR_ADDR - Address of this CHIP

7 - REV_LVL - Revision and DB Info of this CHIP

8 - CLEAR_DB - Clear ERR flag on CHIP Points


Enter number of your choice:

And the CHIP address will be displayed:

The Address of This CHIP Device is: @1- 0

The command line equivalents are /fosh=x and /fosd=x, respectively.

Other failover node

The Other failover Node parameter is required on both failover nodes. This is the computer name of the other node in the failover pair. The command line equivalent is /secn=x, where x is the computer name of the other node.

Failover tag

The Failover Tag is required on both failover nodes. The failover tag must be digital, and needs to have at least two states – one state to identify each of the two failover nodes. The ‘…’ button invokes the tag search dialog so that a failover tag can be selected, if one already exists. The command line equivalent is /ft=x, where x is the name of the digital failover tag.

Digital state

The failover tag’s Digital State is required on both nodes in a failover setup. It is the digital state from the failover tag’s digital state set that is assigned to this node as a flag that indicates which interface is collecting data. The command line equivalent is /fds=x, where x is the digital state.

Failover Number

The Failover Number only applies to failover on Windows NT/2000. The failover number is the number assigned to apionline. The command line equivalent is /fo=x, where x is the failover number.

Error threshold

The Error threshold is the number of error 9s – Fisher CHIP communication errors – that can be received in one scan loop before the interface assumes that the communication errors indicate that this node’s connection to the Data Highway is down This feature allows the interface to exit in the middle of a scan loop to check the connection to the Data Highway, and then failover if necessary. The command line equivalent is /fo9=x, where x is the number of error 9s.

Additional Arguments

The Additional Arguments section is provided for any flags that may have been required in the future.

Command-line Parameters

There are several option parameters in ChiptoPI.bat (WinNT), ChiptoPI.sh (UNIX), and CHIPtoPI.com (VMS) that control the operation of the interface program. Some of the parameters are optional. The parameters are described in the table below:

Command-line Parameters

/hiway

Enables Highway Outputs.

/ver

Indicates what revision of Fisher CHIP software is running. The interface attempts to determine the revision, but if it cannot, it will require the /ver startup parameter. e.g., /ver=4.3

/file=fn

This parameter is required if string data will be sent to PI 3 string tags from an interface running on VMS. It defines the file that will be FTP’ed to the PI 3 home node for use by the Batch File Interface. You will need to specify the logical and file name: /file=PIFTPDIR:STRTAGS.NEW. This needs to match up with the settings in the piftp.com file.

/sp=x(1.1.9.2)

Where x is in milliseconds. This tells the interface to pause x milliseconds before loading the CHIP DB points into the interface to allow for CHIP DB to startup fully. The default is not to pause on startup.

/udb

fisher-rosemount chip on nt/vms/hp-uxcdn.osisoft.com/interfaces/861/pi_chiptopi_hp_2.8.0.3.doc ·...

Documents