fisher-rosemount chip on nt/vms/hp-uxcdn.osisoft.com/interfaces/844/pi_chiptopi_axp_2.5.4.doc ·...

Fisher-Rosemount CHIP onNT/VMS/HP-UX

Interface to the PI System

Version 2.5.4.0 and greaterDocument Revision A

How to Contact UsPhone (510) 297-5800 (main number)

(510) 297-5828 (technical support)

Fax (510) 357-8136

Internet [email protected]

World Wide Web

http://www.osisoft.com

Bulletin Board

(510) 895-9423Telebit WorldBlazer modem (Hayes, MNP, or PEP compatible)8 data bits, 1 stop bit, no parity, up to 14400 bps downloadprotocols: Xmodem, Ymodem, Zmodem, Kermit

Mail OSI Software, Inc.P.O. Box 727San Leandro, CA 94577-0427USA

OSI Software GmbH Hauptstrae 30 D-63674 Altenstadt 1Deutschland

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

Unpublished -- rights reserved under the copyright laws of the United States.RESTRICTED RIGHTS LEGEND

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

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.

document.doc

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

4/25/2000 01:46:00 AM ii

Table of ContentsIntroduction...............................................................................................................................1

PI Point Definition......................................................................................................................3

Input-specific PI Point Parameters........................................................................................5

Output-specific PI Point Parameters.....................................................................................9

Alarm Processing................................................................................................................10

8 - Bit Status Processing....................................................................................................11

16 - Bit Status Processing..................................................................................................12

Controller Mode Processing................................................................................................13

PIDIFF and CHIP GENER...................................................................................................13

Installing CHIPtoPI..................................................................................................................16

Installing CHIPtoPI on NT....................................................................................................16

Installing CHIPtoPI on HP-UX.............................................................................................17

Installing CHIPtoPI on VMS.................................................................................................18

Software Requirements...................................................................................................18

Software Installation........................................................................................................18

PI 2 PINET to PI 3 String Tag Support...................................................................................20

Method of Operation........................................................................................................20

Setup Instructructions......................................................................................................21

The Automatic FTP Script................................................................................................22

Setting up PI Batch File Interface on the PI 3 Home node..................................................27

Setting up the Interface...........................................................................................................29

Running the Interface..............................................................................................................32

Running the Interface on NT...............................................................................................32

CHIPtoPI as an NT Service.............................................................................................32

CHIPtoPI Interactively, not as a Service..........................................................................33

Running the Program on HP-UX.........................................................................................34

Running the Program on VMS.............................................................................................35

05/20/2311:38 AM iii

Picking up CHIP Point Database Changes.............................................................................36

Sample Digital State Table......................................................................................................37

PI 2 Sample Digital State Table...........................................................................................37

PI 3 Sample Digital State Table...........................................................................................37

Appendix A: Linking/Re-linking CHIPtoPI on VMS.................................................................39

Appendix B: Installation of CHIPtoPI on VMS from a Separate Tape....................................40

Appendix C: Migrating from the PI-CHIP Interface to the CHIPtoPI Interface.......................41

The CHIPPTCONVERT Utility.............................................................................................41

Appendix D: Interface Distributions as Self-Extracting Executables.......................................44

NT Installation......................................................................................................................44

UNIX Installation..................................................................................................................44

VMS Installation...................................................................................................................44

Documentation Updates......................................................................................................44

Appendix E: File conversion utility for VMS save sets............................................................45

Reblock................................................................................................................................45

Installing REBLOCK........................................................................................................45

Useing REBLOCK...........................................................................................................45

Sample Session on VMS node........................................................................................46

VMS Set File Command......................................................................................................46

VMS BCK Save Set File..................................................................................................46

VMS Save Set .A or .B File..............................................................................................46

Appendix F: GNR2PI -- CHIPtoPI Point Creation Utility.........................................................47

GNR2PI on OpenVMS.........................................................................................................48

GNR2PI on Windows NT.....................................................................................................48

Using the PIConfig File........................................................................................................48

Using the PIDiff File.............................................................................................................48

Appendix G: Failover...............................................................................................................49

General Failover Overview..................................................................................................49

Windows NT Failover Overview.......................................................................................49

OpenVMS Failover Overview..........................................................................................49

General Failover Information...............................................................................................50

Enabling Failover on All Platforms...................................................................................50

05/20/2311:38 AM iv

Failover Tag on All Platforms...........................................................................................50

OpenVMS Failover..............................................................................................................51

General Requirements.....................................................................................................51

Hardware Requirements..................................................................................................51


Software Setup................................................................................................................52

Windows NT Failover..........................................................................................................52

General Requirements.....................................................................................................52

Hardware Requirements..................................................................................................52


General Failover Strategy................................................................................................53

Typical Configuration.......................................................................................................54

Scenarios Covered..........................................................................................................54

Multiple Interfaces on API node.......................................................................................55

Primary/Secondary Interface Failover.............................................................................55

CHIPtoPI Interface Software Setup for Failover..............................................................55

Appendix G: Troubleshooting..................................................................................................56

communication failure for tag>x.......................................................................................56

Fail to initialize Chip, err: 9469, 36/253...........................................................................56

CHIP internal operational status error: 44, Shared memory error...................................56

chip_util is unable to execute due to one of the above errors.........................................56

Error Access Denied PID xx could not access the PID yy found in CH_Security.log......56

05/20/2311:38 AM v

IntroductionThe 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. 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 software should be version P0.3 or later. The Fisher-Rosemount CHIP software on HP-UX software should be version P4.3 or later.

***NOTE, 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.

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.

This interface supports outputs to the PROVOX highway and supports automatic data-collection failover on VMS and Windows NT (using Microsoft Cluster Server) only. This interface does not support highway outputs or failover on HP-UX.

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

Supported Features

Sign up for updates Yes

Exception reporting Yes

PINet/PI API Yes

Outputs Yes

Vendor software required Yes

05/20/2311:38 AM 1

Failover No

Maximum points limit by resource

Uniint based Yes

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

***** NOTE: THE OLD VMS BASED CHIP INTERFACE WILL NO LONGER BE THE PRIMARY CHIP INTERFACE. We will be shipping chiptopi to all new chip

customers. Currently, chiptopi does not provide failover, but it will be added shortly. Version 1.1I of the old VMS based CHIP interface is included on this tape in the backup saveset CHIP_VMS11I.bck for those customers to use which require failover.

05/20/2311:38 AM 2

PI Point DefinitionA 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 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.

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.

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.

Point Type

This is usually R for analog points, I or D for digital points, modes, alarms, and pulse counts. However, any PI point type can be used for any CHIP point. For instance, an analog CHIP point may be stored in a PI point with a type of I. The value is rounded off in the PI System in this case.

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 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:BIT=X, where X is the bit number from 1 to 16.

05/20/2311:38 AM 3

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

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

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.

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)

These point attributes also affect the interface program

Point Type

Scan

05/20/2311:38 AM 4

Exception Deviation

Exception Minimum Time

Exception Maximum Time

Digital Start Code and Digital Number (PI 2.X)

Digital State Set (PI 3.X)

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.

The following point attributes do not apply to CHIP points.

Square Root

Convers

TotalCode

Input-specific PI Point ParametersThe 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 PointtypePI 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


4 PV1 1 Float16 R

PV2 2 Float16 R

5 PV 1 Float16 R

SP 2 Float16 R

IVP 3 Float16 R



Output Tracking 35 Float32, Digital R, D

Integral Tracking 36 Float32, Digital R, D

Setpoint Tracking 37 Float32, Digital R, D

05/20/2311:38 AM 5

Local Inputs

CHIP Point Type (Location2) CHIP Parameter Location3 Recommended PI Pointtype

PI 3 PI 2

7 PV 1 Float16 R

SP 2 Float16 R

IVP 3 Float16 R



Bias or Ratio 11 Float16 R

8 PV 1 Float16 R

SP 2 Float16 R

IVP 3 Float16 R



Bias 11 Float16 R

Ratio 12 Float16 R

9 Value bit number, 1-4 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

05/20/2311:38 AM 6

Local Inputs


PI 3 PI 2

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)

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)


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




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


05/20/2311:38 AM 7

Local Inputs


PI 3 PI 2

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






State 18 Int16 I

Status Word 19 (note 2) Int16 I

CV #n 100 + n (note 3) Float32 (Int32) R (I)

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

Note 2 : for LCP Status Words, 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 a 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 PI tag be defined as Point Type Real and High Precision.

Note 3: n is between 1 to 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, you must 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, you need to run the PIFTP process and install the BatchFile interface on the PI3

05/20/2311:38 AM 8

server or on an API node. This is documented below in a section titled “FTP String Files to PI 3 Home Node”.

Output-specific PI Point ParametersLocal 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 /do 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 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 data base'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 value may be rejected by the remote device 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:CHIP.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

-12 Discrete Value 15 Int16 I

-18, -19 PV 1 Int16 I

-31 CV #n 100 + n (note 1) Float32 or Int32 R or I

Note 1: n is between 1 to 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

05/20/2311:38 AM 9

Highway Outputs


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


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 ProcessingThe 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

05/20/2311:38 AM 10

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

8 - Bit Status ProcessingThe 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 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




05/20/2311:38 AM 11


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.

16 - Bit Status ProcessingThe 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 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











05/20/2311:38 AM 12




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 ProcessingThe 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 GENERThe 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.

05/20/2311:38 AM 13

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 = 240DBI = 1 LOCAL = FALSEPOINT TYPE = 1 UNSOLICITED = TRUEDEVICE ADDRESS = 0- 6 SLOT PARAMETERS --POINT NUMBER = 35-156 DEADZONE ENABLEDDEADZONE VALUE = 0.0625SAMPLE INTERVAL = 60TAG = 510X9116DESCRIPTOR = BREAK #1 P. M.UNITS =EU HIGH = 1.00EU LOW = 0.00

RECORD 2, LENGTH = 240DBI = 2 LOCAL = FALSEPOINT TYPE = 1 UNSOLICITED = TRUEDEVICE ADDRESS = 0- 6 SLOT PARAMETERS --POINT NUMBER = 35-184 DEADZONE ENABLEDDEADZONE VALUE = 0.0625SAMPLE INTERVAL = 60TAG = 520X9144DESCRIPTOR = BREAK #2 P. M.UNITS =EU HIGH = 1.00EU 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.** Directiveserrormax,0errorfile,PISysMgr:Errorfile.pdf** Defaulted Itemspointtype,DEFAULT,R

05/20/2311:38 AM 14

pointsource,DEFAULT,Flocation3,DEFAULT,1location5,DEFAULT,1excmax,DEFAULT,600res,DEFAULT,2** Tag Attributestag,8,16,10descriptor,9,16,16engunits,10,16,10typicalvalue,11,16,10zero,12,16,10span,11,16,10location1,2,22,5location2,3,24,3excdev,6,21,6excmin,7,24,3** End of file

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

05/20/2311:38 AM 15

@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

05/20/2311:38 AM 16

Installing CHIPtoPI Installing CHIPtoPI on NT

Prior to the installation of the CHIPtoPI interface, you need to install the CHIP NT software on the computer. Also, if the PI Server is not running on the same computer, you need to install the PI-API or PINet before you can run the interface.

Then, create the directory in which to put the interface program. If the PI Server is running on the same computer, the convention is to put the interface in a sub-directory under the interface directory, e.g. \pi\interfaces\chiptopi. If the interface is running on an API Node, put the interface in a sub-directory under the pipc directory, e.g. \pipc\interfaces\chiptopi. Copy the interface files from the distribution CD (see example directory structure below). The file CHIPtoPI.bat contains startup parameters described in the next section. You should modify that file to suit your system’s need.

The distribution CD also contains the file chipstart.bat that is an example for starting up the CHIP software and the interface. For more information, see the section "Running the " below.

The CHIPtoPI Interface installation CD contains the following files:CHIPTOPI.EXE : CHIPtoPI Interface executable fileCHIPTOPI.BAT : Startup command fileCHIPTOPI.DBG : Debug Symbols

The debug symbols file needs to be copied to the \winnt\symbols\exe directory. If this directory does not exist, it needs to be created.

Example interface directory structureThe following files should be installed:PI HOME DIRECTORY\

INTERFACES\CHIPTOPI\

CHIPTOPI.EXECHIPTOPI.BAT

T

05/20/2311:38 AM 17

Installing CHIPtoPI on HP-UXPrior to the installation of the CHIPtoPI interface, you need to install the CHIP HP-UX software on the computer. Also, if the PI Server is not running on the same computer, you need to install the PI-API or PINet before you can run the interface.

Then, create the directory in which to put the interface program. If the PI Server is running on the same computer, the convention is to put the interface in a sub-directory under the interface directory, e.g. /opt/pi/interfaces/chiptopi. If the interface is running on an API Node, put the interface in a sub-directory under the piapi directory, e.g. /piapi/interfaces/chiptopi. Copy the interface files from the distribution CD (see example directory structure below). The file CHIPtoPI.sh contains startup parameters described in the next section. You should modify that file to suit your system’s need.

The distribution CD also contains the file chipstart.sh that is an example for starting up the CHIP software and the interface. For more information, see the section "Running the " below.

The CHIPtoPI Interface installation CD contains the following files:CHIPTOPI : CHIPtoPI Interface executable fileCHIPTOPI.SH : Startup command file

Example interface directory structureThe following files should be installed:PI HOME DIRECTORY\

INTERFACES\CHIPTOPI\

CHIPTOPI.EXECHIPTOPI.BAT

05/20/2311:38 AM 18

Installing CHIPtoPI on VMS

Software RequirementsThe 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.

The CHIPtoPI Interface can run either on the PI 2.x server node or on a PINet node.

The CHIPtoPI Interface is delivered on a CD and contains the following files:CHIPtoPI.DOC : Interface DocumentationCHIPtoPI_xxx.txt : Release NotesCHIPtoPI.BCK : CHIPtoPI Interface Files

CHIPtoPI.OBJ : CHIPtoPI Interface object fileCHIPtoPI.COM: CHIPtoPI Interface Startup command fileCHIPtoPILINK.COM: Build the CHIPtoPI Interface.CHIPtoPIDETACH.COM: Detach the CHIPtoPI Interface Program.CHIPtoPIReadMe.xxx: Readme file about the current releaseUNIINT.OBJ : Universal Interface object filePIFTP.COM : Command file that automates FTPs to PI 3PIFTPDETACH.COM : Detaches above file

CHIPPTConvert.BCK : PI-CHIP to CHIPtoPI point conversion utility

CHIPPTCONVERT.COM CHIPPTCONVERT.DATCHIPPTCONVERT.OBJCHIPPTCONVERT.STRCHIPPTCONVERTREADME.TXTCHIPPTCONVERTCLEANUP.COMCHIPPTCONVERT_INSTALL.COM

chip_vms11i.exe (Now obsolete VMS-based distribution of CHIP)

And CHIPTOPI Interface support files:REBLOCK.EXE : Reblock utility for VAX VMSREBLOCK_ALPHAVMS.EXE : Reblock utility for Alpha VMSREBLOCK.README : Instructions on using Reblock utility

Software Installation

The Fisher CHIPtoPI Interface is now being shipped on CD. The enclosed CD contains the backup save set CHIPTOPI.BCK, which contains the PI-Fisher CHIP Interface, and its support files.

1. FTP the CHIPTOPI.BCK file and the REBLOCK files from your PC to your VMS machine.

2. Run Reblock on the save set, or on VMS nodes running VMS 6.0 or greater, use the VMS Set File command to reformat the file internally to the correct VMS save set standard block size of 32356. For more information on Reblock and the VMS Set File command, see Appendix E.

3. Unpack the saveset to a “safe” directory by:backup/verify/log chiptopi.bck/sav *.*

05/20/2311:38 AM 19

2. Copy the files contained in CHIPTOPI.BCK to PIBuild: and go to that directory.

3. Link the interface by executing @chiptopilink. The executable chiptopi.exe will then get copied to pisysexe.

05/20/2311:38 AM 20

PI 2 PINET to PI 3 String Tag SupportSince the extended PI-API is not supported on VMS, string tags are supported on PINET via an FTP mechanism. That is, the interface writes data to a file. The file 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 details of this process and the configuration that is necessary to set this up are discussed below.

Method of OperationThe name that the interface 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 flag 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 FTPd 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 formpoint_identifier, pitime, value, status

05/20/2311:38 AM 21

The field separator can be changed from a comma to any character with the /fs command-line argument. 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 VMS. 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 Instructructions1. Obtain the files for the automatic FTP mechanism from OSI. These files are

piftp.compiftpdetach.compiftpstop.comCopy 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:[email protected]

6. Modify the startup command line of the interface if necessary. The /fs flag is the only command-line argument 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 sysstem. If the PI 3 server is on an NT node, then an FTP daemon will probably need to be installed. FTP daemons on NT do not use NT security. A user name and password will need to be configured for the FTP daemon and a default login directory will need to be setup. These user names and passwords are in no way related to NT user names and passwords. They are configured via the FTP software, not the NT administrator.

8. Set up the Batch File interface on the PI 3 server node. The Batch File interface (BatchFL) is not shipped with the CHIPtoPI interface, so users wanting to scan string tags on a PINet and send them to a PI3 home node will need to contact OSI Tech Support for information on downloading the Batch File interface for. This interface can either be run on the PI3 home node, or it can be run on an API node.

When you setup the FTP transfer, you will need to choose a directory to receive these files from the PINet node’s FTP. This directory will be where the Batch File interface is configured to read the files, and is specified on the Batch File interface commmand line with the /pa command line option. Data files transferred from the PINet node to the PI 3 home node are named .dat. This is the mask you will need to use in setting up the Batch File interface. An example of a /pa definition is:/pa=d:\pipc\interfaces\batchfl\datafiles\*.dat.

Also, please note that the /fs command-line argument for the Batch File interface and the Uniint-based interface should be set to the same field separator.

For more details on setting up the Batch File interface, please see the Batch File

05/20/2311:38 AM 22

documentation, which is available on our Interfaces web site:http://interfaces.osisoft.comand is distributed with the Batch File interface.

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

The Automatic FTP Script

Configuring the Script

The 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 NT machine, then the UserName/PassWord correspond to a username/password that is configured from within the FTP software on the NT box. These user names and passwords are in no way related to NT user names and passwords.

The piftp.com script is given below.

$! PIFTP TO BATCHFL DRIVER FOR VMS$! OSI SOFTWARE, 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

05/20/2311:38 AM 23

http://interfaces.osisoft.com/

$!$!$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$ ENDIF

05/20/2311:38 AM 24

$ 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 = ""$!

05/20/2311:38 AM 25

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$!$ IF (FTPTYPE .nes. "") THEN GOTO TRYFTP$ PIMSG "ERROR, PI FTP SCRIPT COULD NOT RESOLVE THE TCP/IP

05/20/2311:38 AM 26

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 Script

The automatic FTP script is called PINet:piftp.com. The ftp script is started by@pinet:piftpdetach.com

Once 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.com

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

Information and Error Messages from the FTP Script

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

05/20/2311:38 AM 27

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 fine 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 "$") ignored

The message

%DCL-W-SKPDAT, image data (records not beginning with "$") ignored"

05/20/2311:38 AM 28

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

Setting up PI Batch File Interface on the PI 3 Home node The Batch File interface (BatchFL) is not shipped with the CHIPtoPI interface, so users wanting to scan string tags on a PINet and send them to a PI3 home node will need to contact OSI Tech Support for information on downloading the Batch File interface for. This interface can either be run on the PI3 home node, or it can be run on an API node.

You will need to setup an FTP client on the PI 3 home node to receive the data files from the PINet node. OSI does not have a suggestion regarding which FTP client to use.

When you setup the FTP transfer, you will need to choose a directory to receive these files from the PINet node’s FTP. This directory will be where the Batch File interface is configured to read the files, and is specified on the Batch File interface commmand line with the /pa command line option. Data files transferred from the PINet node to the PI 3 home node are named .csv. This is the mask you will need to use in setting up the Batch File interface. An example of a /pa definition is:/pa=d:\pipc\interfaces\batchfl\datafiles\.csv

For details on setting up the Batch File interface, please see the Batch File documentation, which is available on our Interfaces web site:http://interfaces.osisoft.comand is distributed with the Batch File interface.

05/20/2311:38 AM 29

http://interfaces.osisoft.com/

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

Parameter Description

/ps= Specifies the point source

/host= Specifies the name of the PI Server Node. If not supplied, the default Server in pilogin.ini will be used.

/id= Specifies the interface ID number. Valid values are between 0 and 7. See discussion in Location5.

/f= Specifies the scan period and phase. The period is the amount of time between scan. The phase is the time to start the first scan specified as offset from midnight.

The period and phase are supplied in the format of hh:mm:ss. A comma should separate the period and the phase. If the phase is not defined, the interface will start the scan cycle for this class as soon as possible.

You can define as many scan class as need.

/ec= Specifies the event counter number, which corresponds to the number assigned to the Event Rate tag in the IORates.dat file (found in \pipc\dat on NT nodes, pisysdat: on VMS nodes, and $PIHOME/dat on UNIX nodes)

/sn Tells the interface to ignore the exception specifications of the tag and put all the input events into the PI snapshot. By default, the SN flag is not used to reduce data traffic.

/db Tells the interface to write debug messages to the log file.

/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

/stopstat= If the /stopstat command line parameter is specified, the interface writes I/O timeout to all INPUT points (not OUTPUT), zeros the event counters, and disconnects from the PI server. If /stopstat=system_digital_state then the interface writes the system digital state instead to input points instead. The suggested system digital state is shutdown.

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

/q Tells the interface to queue up events before putting the data into the PI system. The q version is 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 buffer size of the event queue for the interface is 128 events.

/sp=x 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 t o startup fully. The

05/20/2311:38 AM 30

Parameter Description

default is not to pause on startup. (1.1.9.2)

/fo /fo=x

VMS: /fo enables failover. NT: /fo=x is required, where x is the number assigned to apionline. See Appendix F, Failover, for more information on what number to user for x.

/primary Required on primary node in failover setup; this should not be specified on the secondary node. Tells the interface that this node is the primary node in a failover setup. User can optionally specify the name of this node like this: /primary=wolverine

/secn=x Required on both nodes in a failover setup. Name of secondary node in a failover setup: /secn=dragon

/ft=x Required on both nodes in a failover setup. Name of the digital state failover tag on the PI Home node that will record which node is currently collecting: /ft=chipfailtag

/fds=x Required on both nodes in a failover setup. Name of the digital state from the failover tag’s digital state set that is assigned to current node as a flag for who is collecting. See Appendix F, Failover, on setting up the failover tag and the digital state set for this tag: /fds=wolverine

/udbi=x Update DBIs every x hours. X can be any number from 1 to 24. The default is to update DBIs once every 24 hours. (2.0.8)

The following is a sample interface startup command file.chiptopi ! don’t startup as NT service/ps=F ! point source = F/id=1 ! interface ID number/host=localhost:5450 ! PI Server node name/f=00:00:10,21:00:05 ! First scan class period and phase/f=00:00:12,00:00:00 ! Second scan class period and phase

Home Node is a PI 2.x Server

For an interface talking to a PI 2.X Server, you need to configure the Server by adding event counter tags and the point source as described below.

Define each tag added to IORates.dat using PIDIFF or the Point Def display on the PI System node. You may use SY:SNP001 as a template tag in the Point Def display.

Add the point source character chosen for the CHIP interface to the PI System using the Point Src display. This lets PI access and maintenance functions recognize the new interface and allow creation of its tags. The location maximum and minimum values are shown below.

Location number 1 2 3 4 5

Minimum 0 -19 1 1 0

Maximum 10240 100 385 32 7

You don’t need to define the point source character separately from the PI tags in a PI 3.X Server.

05/20/2311:38 AM 31

Running the InterfaceRunning the Interface on NT

CHIPtoPI as an NT Service

The CHIPSERVICE

The CHIPtoPI interface can only be started after the CHIP software has been started. The current version of CHIP on NT software (version 4.3) does support NT services. Hence the startup can be automated as soon as the machine is turned on. The CHIP software has to be configured as a service. You use the CHIP chipserve utility to configure the CHIP software to run as a service:

D:\CHIP\chipserv -install Account_string Password_string

where D:\CHIP\ is the path to the CHIP product directory. Account_string is the desired account for CHIP to execute in. Password_string is the password for the above account.

Account_string should be in the form of "DomainName\Username." If the account belongs to the built-in domain, ".\Username" can be specified.

For more information on configure the CHIP service, see the readme_nt.txt file that comes with the CHIP software Installation, Section on INSTALLING, STARTING AND STOPPING CHIP AS A NT SERVICE.

The CHIPtoPI Service

To register the chiptopi service to execute from the executable's directory:

c:\pi\interfaces\chiptopi\chiptopi –install –depend “chipservice tcpip”

or

c:\pi\interfaces\chiptopi\chiptopi –install –auto –depend “chipservice tcpip”

to register the chiptopi service to start automatically at NT startup.

The CHIPtoPI interface Service is now dependent on the CHIPService. If the CHIPService is stopped, the CHIPtoPI interface service will be stopped first. If the CHIPtoPI Interface Service is started, and the CHIPService is not started, the CHIPtoPI Interface Service will not start successfully, but the CHIPService will be started. You will have to start the CHIPtoPI Interface Service again. You can set the CHIPService and the CHIPtoPI services to automatic. This way, the services will always be started in the correct order.

Starting, Stopping, Querying, and Removing the CHIPtoPI Service

Other command line parameters are listed as:

05/20/2311:38 AM 32

-remove Remove the CHIPtoPI Service

-start Start the CHIPtoPI Service

-stop Gracefully stop the CHIPtoPI Service

-query Query the CHIPtoPI Service

-help Print usage statement

The -depend option is only valid with the -install action

CHIPtoPI Interactively, not as a ServiceIf you do not configure the software to run as a service, you can:

Build a startup batch command file and

Add the batch file to the startup group of program manager to start up the chip software and the interface as soon as a user logs on the NT system.

The command batch file chipstart.bat that is on the distribution CD provides an example for

Starting the CHIP software,

Loading CHIP database and

Starting the CHIPTOPI interface.

You may need to change the path name of the interface startup batch file and the database CNF file to suit your system. The program WAIT.exe used in chipstart.bat is also on the distribution CD. Copy it to the Windows or WINNT35 directory or on your system path.

Alternatively, you can startup the system manually. You can start the interface by typing:chiptopi.bat

on the command prompt. If you are not currently in the same directory where the interface program resides, you need to specify the full path name of the command file. Also, you may want to specify the full path name for the interface program in the command file.

05/20/2311:38 AM 33

Running the Program on HP-UX Build/Edit the startup batch command file and

The command batch file chipstart.sh that is on the distribution CD provides an example for

Start the CHIP software

Load CHIP database and

Starting the CHIPtoPI interface.

You may need to change the path name of the interface startup batch file and the database CNF file to suit your system.

To have the CHIPtoPI Interface startup with the PI-API node or the PI Home node, add the startup to the sitestart.sh file.

To startup the system manually. You can start the interface by typing:chiptopi.sh

at the command prompt. If you are not currently in the same directory where the interface program resides, you need to specify the full path name of the command file. Also, you may want to specify the full path name for the interface program in the command file.

05/20/2311:38 AM 34

Running the Program on VMS There are two files needed to run the CHIPtoPI interface on a VMS PI Home or PINet node:

CHIPtoPI.com: this is the file that needs to be edited to match each user’s system

(see section entitled Setting Up The Interface).

CHIPtoPIDetach.com: this is the detach file that is run to start the CHIPtoPI Interfaces as

a detached processes.

To automate Interface startup, add the following lines to the PISysMgr:SiteStart:$! Start CHIPtoPI Interface$@PISysExe:CHIPtoPIDetach

The Fisher CHIP software needs to be started before the CHIPtoPI interface.

To Stop the CHIPtoPI Interface, type:

$@PISysExe:STOP CHIPtoPI

05/20/2311:38 AM 35

Picking up CHIP Point Database Changes

The interface program automatically:

Picks up points that are added to the PI database and

Changes in points that are edited in the PI database.

It will process twenty-five point database changes every two minutes. Time-stamped error messages are written to the PI message log. Messages describing the number of points to scan are also written whenever the interface is restarted.

Note: When using the CHIP tagname instead of the DBI number, you must stop and restart the interface when the DBI numbers change in the CHIP Database.

05/20/2311:38 AM 36

Sample Digital State TablePI 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:48PI System Digital States Definition Page 3 26-Jun-89

09:54:48 Digital States Table-----------------------------------------------------------129 145 161 D,B,C Alarms 177

HManual130 No Alarm 146 162 D,A Alarms 178131 C Alarm 147 163 D,A,C Alarms 179132 B Alarm 148 164 D,A,B Alarms 180133 A Alarm 149 165 D,A,B,C Alrm 181134 D Alarm 150 No Alarm 166 182135 151 C Alarm 167 183136 No Alarm 152 B Alarm 168 184137 A Alarm 153 B,C Alarms 169 185138 No Alarm 154 A Alarm 170 < Blank > 186139 B Alarm 155 A,C Alarms 171 Manual 187140 No Alarm 156 A,B Alarms 172 Auto 188141 C Alarm 157 A,B,C Alarms 173 RSP 189142 No Alarm 158 D Alarm 174 Sup 190143 D Alarm 159 D,C Alarms 175 DDC 191144 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

05/20/2311:38 AM 37

CHIPMODE,Zero,Manual,Auto,RSP,SUP,DDC,COM,HMANCHIPALARM,no alarm,C alarm,B alarm,A alarm,D alarmCHIPALMCOMB,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.

05/20/2311:38 AM 38

Appendix A: Linking/Re-linking CHIPtoPI on VMS

The interface program is linked during any PI System install or upgrade. You may have to relink the CHIP interface after installing a new release of the CHIP software. You may also have to relink if the CHIP logical names were not defined during the install or upgrade. To relink just the CHIP interface, execute CHIPtoPILink.com with PIBuild as your default directory. If you have a version of CHIP older than version 3.0, a version of the interface which does not support all the features in the manual is linked. The PI install/upgrade procedure checks for CHIP:Link1.com to see if the CHIP version is 3.0 or later.

05/20/2311:38 AM 39

Appendix B: Installation of CHIPtoPI on VMS from a Separate Tape

The Fisher CHIPtoPI Interface is now being shipped on CD. The enclosed CD contains the backup save set CHIPTOPI.BCK, which contains the PI-Fisher CHIP Interface, and its support files.

4. FTP the CHIPTOPI.BCK file and the REBLOCK files from your PC to your VMS machine.

5. Run Reblock on the save set, or on VMS nodes running VMS 6.0 or greater, use the VMS Set File command to reformat the file internally to the correct VMS save set standard block size of 32356. For more information on Reblock and the VMS Set File command, see Appendix E.

6. Unpack the saveset to a “safe” directory by:backup/verify/log chiptopi.bck/sav *.*

4. Copy the files contained in CHIPTOPI.BCK to PIBuild: and go to that directory.

5. Link the interface by executing @chiptopilink. The executable chiptopi.exe will then get copied to pisysexe.

05/20/2311:38 AM 40

Appendix C: Migrating from the PI-CHIP Interface to the CHIPtoPI InterfaceThe CHIPPTCONVERT Utility

OSI provides the CHIPPTCONVERT utility to convert old VMS based PI-CHIP tags to run under the CHIPtoPI interface. All tags need to have a scan class specified in location 4 (see discussion below on CHIPtoPI Scan Classes), and two Fisher CHIP point types require further conversion (see discussion below on CHIP Point type 31 and 100). CHIPPTCONVERT handles all these conversions. On the occasion that a CHIP tag cannot be converted programmatically, a message will be printed to the PISYSMGR:CHIPPTCONVERT.OUT file.

The CHIPPTCONVERT.BCK file that is provided with the CHIPtoPI interface is unpacked to the PISYSMGR directory with the CHIPPTCOVERT_INSTALL.COM file that is provided on the same tape. The following instructions on using the utility are also included in the save set in the CHIPPTCONVERTREADME.TXT file:

************************************************************************This is the PI CHIP point conversion readme file.The conversion utility changes points in the PI point database from the point format used by the old VMS CHIP interface to the point format used by the new uniint-based CHIP interface.

Warning - DO NOT EXECUTE THE POINT CONVERSION UTILITY TWICE!

************************************************************************

************************************************************************File list************************************************************************

The CHIPPTCONVERT_INTALL script should have created the following files in the PISYSMGR directory:

CHIPPTCONVERT.COMCHIPPTCONVERT.STRCHIPPTCONVERT.DATCHIPPTCONVERT.OBJCHIPPTCONVERT.EXECHIPPTCONVERTREADME.TXTCHIPPTCONVERTCLEANUP.COM

*************************************************************************Instructions for using the conversion utility*************************************************************************

05/20/2311:38 AM 41

1. Edit the PISYSMGR:CHIPPTCONVERT.DAT file and change the "-" character to the appropriate point source character for the CHIP interface. If you want to convert CHIP tags for one copy of the CHIP interface at a time, you can also change the Location5 = * to be Location5 = #, where # is 0 to 7, matching up with the interface number specified in the CHIP.COM interface startup file.

2. Start the point conversion utility with the command:

@PISYSMGR:CHIPPTCONVERT.COM

The conversion utility reads in all CHIP tags, and moves Location4 to the Extended Descriptor to fit the format needed by CHIPTOPI.

Ignore the warning message:

%NONAME-W-NOMSG, Message number 00000000

3. After verifying that the points have been converted correctly, execute CHIPPTCONVERTCLEANUP.COM script to delete the files from the PISYSMGR directory to avoid accidental re-execution of the conversion utility. You can still re-install the conversion utility at a later date if you want to run the utility again.

*************************************************************************What the conversion utility does*************************************************************************

The conversion utility reads in all CHIP tags, searching for tags with Location4 defined for DDP tags or with Location4 defining a bit. It then constructs the Extended Descriptor for those tags to contain DDP= or BIT= followed by the DDP number or BIT number that was stored in Location4. It will then assign Location4=1, indicating the uniint scan class for all CHIP tags.

If the Extended Descriptor is not blank, and the Instrument Tag is blank, the Extended Descriptor will be moved to the Instrument Tag field before the Extended Descriptor is overwritten. If both the Extended Descriptor and the Instrument Tag field are not empty, the tag will be rejected, and not added to the new PIDIFF file. These tags will then need to be manually modified. A list of the tags that are not converted is written the out file for the utility: PISYSMGR:CHIPPTCONVERT.OUT.

All converted tags are put into scan class 1, as defined in the startup command line for the new interface:

/f=00:01:00 /f=00:00:10 /f=00:00:30

It is up to the user to modify Location4 to move tags into different scan classes.

*************************************************************************Files created by the PISYSMGR:CHIPPTCONVERT.COM script*************************************************************************

PISYSMGR:CHIPPTCONVERTOLD.DAT

This pidiff dat file can be used with the structure file PISYSMGR:CHIPPTCONVERT.STR to convert the point database back to the old VMS CHIP interface point format.

PISYSMGR:CHIPPTCONVERTNEW.DAT

05/20/2311:38 AM 42

This pidiff dat file is used with the structure file PISYSMGR:CHIPPTCONVERT.STR to convert the point database from the old VMS CHIP point format to the point format for the new uniint-based CHIPTOPI interface. The user does not need to explicitly run pidiff to perform the conversion because pidiff is executed by the @PISYSMGR:CHIPPTCONVERT.COM

script.

PISYSMGR:CHIPPTCONVERT.OUT

This contains a list of the points that were not edited in the PI point database.

CHIPtoPI Scan Classes

The CHIPtoPI Interface supports multiple scan classes, which are assigned to each point in the location 4 parameter. The scan classes are defined in the CHIPtoPI startup file (CHIPtoPI.COM on VMS, CHIPtoPI.BAT on NT, chiptopi.sh on HP-UX) in the following manner:/f=00:00:10,21:00:05 ! First scan class period and phase/f=00:00:12,00:00:00 ! Second scan class period and phase

The first scan class listed in the startup file is scan class 1, the second is scan class2, etc. In this example, to have a tag scan every 12 seconds, you need to define that tag’s location 4 to be 2.

CHIP Point type 31 and 100

LCP Status Words

The PI-CHIP Interface currently uses location 4 for LCP Status Word reads, to specify a single bit from the Status Word. To convert these tags for the CHIPtoPI interface, the status word bit needs to be moved from location 4 to the Extended Descriptor with the following syntax:BIT=x, where x is the LCP status word bit to be extracted

DDP Highway Outputs

The PI-CHIP Interface currently uses location 4 for point type 100 DDP Highway Outputs. To convert these tags for the CHIPtoPI interface, the DDP occurrence number needs to be moved from location 4 to the Extended Descriptor with the following syntax:DDP=x, where x is the occurrence number

05/20/2311:38 AM 43

Appendix D: Interface Distributions as Self-Extracting Executables

PI Interfaces are now being shipped on CD, or are available for download via the OSI FTP server. Either method provides a Windows NT/9x self-extracting executable zip file that contains zipped files for the platform on which your interface is intended to run.

1. Copy or move the distribution .exe file from CD or the OSI FTP server to your PC (running Windows NT or Windows 9x).

2. Unpack the .exe file by clicking on it from Windows Explorer, or from running the executable from the command prompt. You will be prompted for where to unzip the files. Be sure to unzip to a safe directory, so as not to over-write any existing configuration files.

NT Installation3. Move the distribution files to the correct directory, and follow the setup instructions in the corresponding interface manual.

UNIX Installation3. Ftp the distribution files from your PC to your UNIX node, and follow the setup instructions in the corresponding interface manual.

VMS Installation3. FTP the interface .BCK save set file and the REBLOCK files from your PC to your VMS machine.

4. Run Reblock on the save set, or on VMS nodes running VMS 6.0 or greater, use the VMS Set File command to reformat the file internally to the correct VMS save set standard block size of 32356. For more information on Reblock and the VMS Set File command, see the section below on File Conversion Utilities for VMS Save Sets.

5. Unpack the save set to a “safe” directory by:backup/verify/log savesetname.bck/sav *.*6. Follow the installation instructions on linking in the corresponding interface manual.7. Follow the setup instructions in the corresponding interface manual.

Documentation UpdatesInterface manuals should now be, or will soon be included in the interface distribution. For interface manual updates, you can view or download the latest documentation from our Support Web:

http://support.osisoft.com

After registering the first time, go to the PI Interfaces link and then view the spreadsheet from the Documentation link

05/20/2311:38 AM 44

http://support.osisoft.com/

Appendix E: File conversion utility for VMS save sets

There are two options for internally reformatting the interface VMS save sets bck files to the correct VMS save set standard block size of 32356. The internal block size gets restructured when ftp’ing files from non-VMS computers.

ReblockThis utility allows you to convert VMS save sets back to their original internal format after downloading them in binary mode from the FTP server to your VAX or Alpha.

In binary file transfer mode, FTP imposes a maximum record size of 512 bytes. Since the standard record length of a VMS save set is 32256 bytes, FTP breaks the records apart during the upload. When you download the file, the record size is still 512 bytes.

REBLOCK reorganizes the file so that the standard VMS save set record format is restored. You can download executable versions of REBLOCK for both VAX/VMS and Alpha/VMS. A VMS executable has a record size of 512 bytes, so it is ready to use as soon as it is downloaded.

This utility is also available in the 'pub/reblock' directory of the FTP server at OSI Software, Inc. It is offered without warranty.

Installing REBLOCK1. Switch to binary mode using the command 'bin'.

2. Move the correct executable to your VMS node via FTP:

VAX/VMS : get reblock.exe reblock.exe

Alpha/VMS: get reblock_alphavms.exe reblock.exe

REBLOCK is ready to use.

Useing REBLOCK1. Type RUN REBLOCK at the "$" prompt. You are prompted for a filename.

Enter the name of the save set downloaded from the FTP server and hit return.

2. When REBLOCK has processed the file, the filename prompt reappears again.

REBLOCK does NOT create a new file version; it reorganizes the existing file.

05/20/2311:38 AM 45

3. You may process other files, or type "\" to exit.

Sample Session on VMS node$ run reblock

REBLOCK: Convert file to blocksize 32256

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

Filename ("\" to exit): \

VMS Set File Command

VMS BCK Save Set FileThere is a VMS command available with VMS 6.0 and later.$ Set File/attribute=(lrl:32256) savesetname.bck

Set File does the same thing as the REBLOCK program does, but from the operating system level.

VMS Save Set .A or .B FileIf you have downloaded a VMSInstal save set with a “.A” or a “.B” file extension that was not wrapped in a .bck file, and you have VMS 6.0 or later, you can recover the “.A” and “.B” VMSInstal save sets with the following command:$ Set File/attribute=(lrl:9216) savesetname.A

$ Set File/attribute=(lrl:9216) savesetname.B

This will re-order the VMSInstal save set to the non-standard block size required by VMSInstall.com

05/20/2311:38 AM 46

Appendix F: GNR2PI -- CHIPtoPI Point Creation Utility

The gnr2pi utility can run on Windows NT-Intel, VAX OpenVMS, or Alpha Open VMS. It can generate either a PIConfig file or a PIDiff file, on any of these platforms, that can be transferred to the PI Home node, and be used to create CHIPtoPI Tags.

PIConfig usage

PI[C]onfig gnr_file piconfig_I/R_file piconfig_D_file pointsource interface_id# [D]BI/[T]agname

PIDiff usage

PI[D]iff gnr_file pidiff_I/R_dat_file pidiff_I/R_str_file pidiff_D_dat_file pidiff_D_str_file pointsource interface_id# [D]BI/[T]agname

Help usage-h

Parameter List option explanations

PI[D]iff/PI[C]onfig [D] creates a PIDiff file; [C] creates a PIConfig file

gnr_file CHIP gnr file name, found in the CHIP directory

piconfig_I/F_file PIConfig file with Integer and Float tags that this utility generates

piconfig_D_file PIConfig file with Digital tags that this utility generates

pidiff_I/R_str_file PIDiff Structure file for I and R tags that this utility generates

pidiff_I/R_dat_file PIDiff Data file with I and R tags that this utility generates

05/20/2311:38 AM 47

pidiff_D_dat_file PIDiff Data file with D tags that this utility generates

pidiff_D_str_file PIDiff Structure file for D tags that this utility generates

pointsource PI Point Source character for these tags

interface_id# Number assigned to Interface (/id=) and Location5

[D]BI/[T]agname [D] means DBI will be placed in Loc1; [T] means CHIP tagname will be used in instrumenttag field

Optioanl [D]ebug [D] writes out extra debug flags. Ignored if not present

GNR2PI on OpenVMSTo run the GNR2PI utility on an OpenVMS PINet or PI Home node, the user needs to modify the GNR2PI.COM file in the PISysExe directory to point to the correct Fisher-Rosemount Gener file, and to optionally modify the names of the data files that are to be created. The parameters are different for creating a PIConfig file and a PIDiff file.

Creating a PIConfig File

The following is an example GNR2PI.COM file command line to create a PIConfig file on a PINet node that is to be transferred to a PI 3 home node an run to create CHIPtoPI Points:

gnr2pi C d:\chip\config.gnr chip_ir.dat chip_d.dat F 1 T

These tags are created from the config.gnr file found in the d:\chip directory. The chip_ir.dat file will contain the CHIPtoPI Integer and Real tags. The chip_d.dat file will contain the CHIPtoPI Digital tags. These tags will be created with pointsource F. Their id number, found in location5, will be 1, and they will use the CHIP tagname, instead of the CHIP DBI number, to reference the tags in the CHIP database.

Creating a PIDiff File

gnr2pi D d:\chip\config.gnr chip_ir.dat chip_ir.str chip_d.dat chip_d.str F 1 T

GNR2PI on Windows NT

Using the PIConfig FileOnce the GNR2PI utility has generated the PIConfig files, transfer them to the PI 3 Home node, and place them in the \pi\adm directory. Then, to create these new CHIPtoPI Points with PIConfig, use the following command, replacing the example file names with the names of the files you generated with the GNR2PI Utility:

Using the PIDiff FileOnce the GNR2PI utility has generated the PIConfig files, transfer them to the PI 3 Home node, and place them in the \pi\adm directory. Then, to create these new CHIPtoPI Points with PIConfig, use the following command, replacing the example file names with the names of the files you generated with the GNR2PI Utility:

05/20/2311:38 AM 48

Appendix G: FailoverGeneral Failover Overview

The failover configuration permits greater reliability through increased up-time. Failover requires identical CHIP databases on the redundant nodes (except for the CHIP exception reporting parameters). Every CHIP point that is a PI input or output must be in both CHIP databases with the same database indexes (DBI's) or CHIP tag names.

Failover is handled differently on OpenVMS nodes and Windows NT nodes. The following discussions address each of the two Failover schemes.

Windows NT Failover OverviewCHIPtoPI failover on Windows NT uses Microsoft Cluster Server.

OpenVMS Failover OverviewThe failover logic uses two communication paths to the redundant node. The first path is a link between the two interfaces programs which uses DECnet task-to-task communication. The second path uses the ECHO command via the PROVOX highway to determine the health of the other CHIP device. In normal operation, the primary node is SCANNING and the secondary node is in STANDBY. When either link to the primary node fails, the secondary node switches to SCANNING. The primary node switches to STANDBY in the case where the DECnet link is good but the ECHO command failed. When the failure condition ends, the secondary node switches back to STANDBY and the primary node switches to SCANNING.

When the interface on either node changes from SCANNING to STANDBY, the command procedure PISysExe:CHIPOffScan.com is executed as a detached process. This command procedure can be used to load a CHIP database with modified exception reporting parameters. It can also be used to stop or notify user applications which depend on CHIP data. When the interface changes from STANDBY to SCANNING, command procedure PISysExe:CHIPOnScan.com is executed. The output files for the detached processes have the same name as the command file but the extension is .out. The detached processes run at priority 4 with the UIC of the interface process and a process name of PI-CHIPOffScan or PI-CHIPOnScan.

Local CHIP outputs (Location2 < 0) are written by both nodes regardless of the failover status. This allows PROVUE consoles to read PI outputs from either CHIP system.

A failover digital tag, specified by the user on the command line, specifies a digital tag that keeps the history of which node is collecting data. A digital state belonging to this tag is assigned to each of the two failover nodes, on the command line, and is the value written for this tag at each failover to track which node is scanning. This digital tag is used only for tracking which node was scanning, and when. It does not play a role in determining which node is currently scanning. A value is written to the failover digital tag when failover switches the SCANNING and STANDBY nodes.

Both copies of the interface will pickup all chiptopi tags, and will scan them at their designated scan rate. However, only the interface that is currently SCANNING will send this data to PI. The STANDBY interface will not send its data.

05/20/2311:38 AM 49

General Failover Information

Enabling Failover on All PlatformsTo configure the interface startup file to enable failover on VMS, specify /fo on the command line. To configure the interface startup file to enable failover on NT, specify /fo=x on the command line, where x is the number discussed below in the NT specific section.

To configure the interface startup file to specify one node as primary (required), specify /primary=nodename on the command line of the primary node. On OpenVMS, this is the DECNet node name (not the tcp/ip hostname); on WinNT, this is the tcp/ip hostname. If an incorrect hostname or node name is specified, each interface will never successfully connect to its failover node. Failover is not initialized until the first successful connection between both the PRIMARY and SECONDARY nodes, and each interface will continue to attempt to connect for the duration of its up-time. Failover will never be initiated until a successful connection between the two nodes.

CHIPtoPI failover uses network objects on VMS and named pipes on NT to allow inter-process communication between the two failover nodes. Therefore, each copy of the interface needs to know the name of the other node. This is passed to each interface with the /secn=remotenode command line parameter. This is required on both nodes. For example, on wolverine, specify /secn=dragon, and on dragon, specify /secn=wolverine.

On VMS, you need to be able to set host between the two failover nodes; on NT, you need to be able to ping or telnet between the two failover nodes.

Failover Tag on All PlatformsCHIPtoPI failover uses a digital state failover status tag to record which node is collecting. This failover digital state tag requires two digital states in its digital state set, one state to signify each of the two nodes in the failover cluster. For example, if the primary node is wolverine, and the secondary node is dragon, a failover tag, such as chipfotag, needs to be created with wolverine and dragon as its digital states:

PI2 Home node

First, add the digital states representing the failover nodes to the Digital State Table

Second, create the tag with PIDiff using the following structure file and data file

Chipfotag.str:tag,1,1,12pointsource,1,14,1pointtype,1,17,1digstartcode,1,20,12dignumber,1,33,1typicalvalue,1,20,12compressing,1,36,3

Chipfotag.dat:1 2 3 4 5 6123456789012345678901234567890123456789012345678901234567890chipfailtag L D wolverine 1 0 0

05/20/2311:38 AM 50

PI 3 Home node

The following is an example PIConfig script that can be used to create the failover tag, called chipfailtag, where the failover nodes are wolverine and dragon:* Create chipfostate set@tabl pids@mode create@istr set,state,...chipfostate,wolverine,dragon@ends* Create chipfailtag@tabl pipoint@ptcl classic@mode create@istr tag,pointsource,pointtype,digitalset,compressing,excmaxchipfailtag,L,digital,chipfostate,0,0@ends@bye

Telling the interface about the Failover Tag

To configure the interface startup file for the failover tag, specify /ft=failover_tag on the command line. In the example above, this would be /ft=chipfailtag

To configure the interface startup file for the failover digital state, specify /fds=failover_ds on the command line. In the example above, this would be /fds=wolverine on wolverine, and /fds=dragon on dragon. Note that the digital state string is used on the command line, not its corresponding digital state number.

OpenVMS Failover

General RequirementsFailover requires two PINet nodes, or one PINet node and one PI2 Home node, that have Data Highway access.

Hardware Requirements Two VMS (VAX or AXP, or a mix of VAX and AXP) nodes.

Both VMS nodes must provide connections to the CHIP Data Highway.

Software Requirements Both VMS nodes must have PINet installed (any version of PI/PINet, preferably 2.0.9 or

greater).

PI/PINet versions do not have to be the same on these two PI/PINet nodes (e.g. one can be running 2.0.9, while the other is running PI/PINet 2.1.2).

Both VMS nodes must be running OpenVMS version 5.5-2 or later.

05/20/2311:38 AM 51

VMS versions do not have to be the same on these two nodes, so long as they are 5.5-2 or later.

Both VMS nodes must have DECNet running between them.

Software Setup

Example CHIPtoPI.COM file on Primary node$!Location of the CHIPtoPI executable file$ pichip :== $pisysexe:chiptopi.exe$!$! Startup Parameters$ pichip /ps=J /ec=20 /f=00:00:10 /id=1 /stopstat /db=1- /fo /primary=casaba /secn=dragon /ft=chipfailtag /fds=casaba$ exit

Example CHIPtoPI.COM file on Secondary node$!Location of the CHIPtoPI executable file$ pichip :== $pisysexe:chiptopi.exe$!$! Startup Parameters$ pichip /ps=J /ec=20 /f=00:00:10 /id=1 /stopstat /db=1- /fo /secn=casaba /ft=chipfailtag /fds=dragon$ exit

Windows NT Failover

General RequirementsFailover testing will require two PI-API nodes that have Data Highway access, and can be stopped and rebooted during the failover testing.

Hardware Requirements Two Windows NT nodes that appear on the Microsoft Hardware Compatibility list

(http://www.microsoft.com/hwtest/hcl/)

Both nodes must provide connections to the CHIP Data Highway.

Software Requirements Both NT nodes must have the PI-API (version 1.2.3.1 or greater) installed.

Both NT nodes must be running Microsoft Windows NT 4.0 Enterprise Edition.

Both NT nodes must have TCP/IP running between them.

General Failover Strategy

API Buffering (Bufserv)

If API Buffering is to be used with MSCS-PI Failover, Bufserv must be installed on both the Primary and secondary interface nodes before failover is setup. Buffering must be started before the interface. The Bufserv service must be run from the local Administrator account,

05/20/2311:38 AM 52

and must be setup to startup automatically on reboot. For more information about setting up API Buffering, please see the Bufserv documentation (Bufserv.doc).

APIOnline#

APIOnline is configured to be dependent upon the interface process using a /proc=interface parameter in the apionline.bat file, where interface stands for the name of the interface service which is using failover. If the interface stops, APIOnline stops. Microsoft Cluster Server then attempts to start up both again. The node on which these processes are started is determined by how the threshold parameter of the apionline resource is configured in the Cluster Administrator. This is discussed later in this section. If APIOnline is started up on the former backup node, the backup interface will check and see that it is now a data collector. It will then start sending data to PI (the backup node is always scanning along with the Scanning node, but the backup node does not send data to PI). Following is an example apionline.bat file using the /proc flag:

C:\pipc\interfaces\apionline\apionline.exe /proc=chiptopi

APIOnline must be installed as a service on both cluster nodes. The example below shows how to install APIOnline as a service and make it dependent upon the CHIPtoPI interface and bufserv:

APIOnline -install -depend “CHIPtoPI bufserv”

This command must be run from the directory in which the APIOnline executable is installed. The next example shows how to remove the APIOnline service, if it is no longer needed:

APIOnline –remove

This command must also be run from the directory in which APIOnline.exe is installed.

APIOnline must then be registered with the Cluster Administrator:

1. Run the Cluster Administrator

2. Add a new group that will contain the APIOnline Resource. The Cluster Group can be used, as well.

3. Add a new resource called APIOnline. Enter the appropriate information when prompted by the New Resource Wizard. The APIOnline resource should be set up as a Generic Service with no dependencies and automatic restart capability. The service that it points to will be APIOnline with no command line parameters.

4. Bring the new APIOnline resource online. To do this, highlight the new resource, right click, and then select Bring Online.

APIOnline is now registered with the Cluster Administrator and is actively being monitored.

Normally, APIOnline will only switch from one node to the other when the Primary node shuts down for whatever reason. It is also possible to simulate a Failover using the Cluster Administrator. To simulate a failover:

05/20/2311:38 AM 53

1. Run the Cluster Administrator.

2. Highlight the APIOnline resource, right click, and select Initiate Failover.

3. This should cause the APIOnline service to stop on the current node and start on the other node. Sometimes, Initiate Failover must be selected 3 or 4 times in order to force the failover successfully.

CHIPtoPI# Service

The CHIPtoPI service should be set to automatic, with a dependency on Chipservice, and a dependency on bufserv, if API Buffering is to be used. With API Buffering:

Chiptopi –install –auto –depend “chipservice bufserv”

Without API Buffering:

Chiptopi –install –auto –depend chipservice

Typical ConfigurationData Collecting API Node – Processes Running

Interface

APIOnline

Backup API Node

interface

Scenarios Covered1. Backup API node goes down

No immediate impact but there is no backup API node available

2. Scanning API node goes down

Microsoft Cluster Server starts APIOnline on backup API node

Backup interface now starts scanning on backup API node

3. Data collecting interface either crashes or is stopped

APIOnline stops running on data collecting node

Microsoft Cluster Server starts APIOnline on backup API node

Backup interface now starts scanning on backup API node

05/20/2311:38 AM 54

Multiple Interfaces on API nodeFailover for multiple copies of an interface running on the same data collector and backup nodes require a unique copy of the APIOnline program for each copy of the interface. A suggested convention is to pass the interface a /FO parameter to indicate that the failover option will be used and that APIOnline will be the name of the service required for failover.

In case multiple failover interfaces must be run, a /FO=X parameter can be passed to the interface, where X is an integer, indicating that the name of the service required for failover is APIOnlineX for interfaceX.

Primary/Secondary Interface FailoverThe secondary interface assumes data collection when the primary node stops running or it directs the secondary interface to assume data collection by stopping its APIOnline service. The most common scenario for the primary interface to stop its APIOnline service is when it is unable to communicate to its DCS gateway. When the primary APIOnline service is stopped, Microsoft Cluster Server automatically starts the APIOnline service on the secondary node and it assumes data collection.

When the primary interface either comes back up or is then able to communicate with its DCS gateway, the primary node stops the APIOnline service on the secondary node. Microsoft Cluster Server then starts APIOnline on the primary node and the primary node assumes data collection.

The interface startup file for the primary interface must specify the name of the secondary node. A suggested convention is to pass the primary interface a /secn=xxx where xxx is the name of the secondary API node.

Note - the primary interface must be able to resolve the name of the secondary node.

CHIPtoPI Interface Software Setup for Failover

Example CHIPtoPI.BAT file on Primary nodechiptopi /db /ps=F /id=1 /host=localhost /f=00:00:10 /ec=1

/fo=1 /primary=wolverine /secn=dragon /ft=chipfailtag /fds=wolverine /stopstat

Example CHIPtoPI.BAT file on Secondary nodechiptopi /db /ps=F /id=1 /host=localhost /f=00:00:10 /ec=1

/fo=1 /secn=wolverine /ft=chipfailtag /fds=dragon /stopstat

05/20/2311:38 AM 55

Appendix G: TroubleshootingBelow is a list of potential errors from the CHIPtoPI interface.

communication failure for tag>xThe meaning of this error taken from the Fisher-Rosemount Systems Technical Referenence manual is:“No data is available, due to communications failure”

These "communication failure" messages are a regurgitation of the errors the Chip software on the NT is getting when communicating with the gateway. This is the return code from one of the CHIP API calls. Since it is on the CHIP/Highway side, users should contact their FR CHIP support folks if these error persist.

Fail to initialize Chip, err: 9469, 36/253or

CHIP internal operational status error: 44, Shared memory erroror

chip_util is unable to execute due to one of the above errorsor

Error Access Denied PID xx could not access the PID yy found in CH_Security.log

According to the "Installing Type DH621 NT software" manual in section 3.2, it says the following:

Same Account should not be used if Chip is exexcuted as NT service and user's program is executing as NT service.

Modify CHIP_SCOPE to Global or Group. If Group is chosen, make sure that the chiptopi interface, and any other utility, such as chip_util, that connects to the CHIP database are run from accounts in the same Group from which the chipservice is run. If CHIP_SCOPE is set to Global, set the CHIPtoPI interface service to use the System Account by modifying the Service (Start>Control Panel>Services) via the Services Applet. Click on “Startup…”, then modify the section titled “Log On As” so that the “System account” option is selected.

05/20/2311:38 AM 56

Revision HistoryDate Author Comments

May 95 JQD First Copy of Interface Manual Completed

Feb 97 JQD Updated for NT

24-Jul-97 HAO Updated for running CHIP and CHIPtoPI as services

10-Sep-97 HAO Updated for HP-UX

1-Dec-97 HAO Updated to 32 Unit Variables in CHIP type 10 (was 16)

5-Dec-97 HAO Updated to include new CHIP 5.0 8 & 16-bit statuses

10-Dec-97 HAO Updated to include Highway Output info

11-Dec-97 HAO Migrating points from old PI-CHIP to CHIPtoPI i/f

13-Apr-98 HAO Added Highway DDP and Activity Batch ID Inputs

15-Apr-98 HAO Added doc on /ver startup parameter

10-Jun-98 HAO Added column of recommended PI point types

15-Jun-98 HAO Added doc on CHIPPTCONVERT point conversion util for PI 2, old VMS CHIP points to new CHIPTOPI points.

10-Sep-98 HAO Added info on installing on VMS from diskette

02-Nov-98 HAO Added /sp=milliseconds to pause on startup (1.1.9.3)

01-Dec-98 HAO Added local CV type 31 outputs (1.1.9.4)

03-Dec98 HAO Added note about CHIP P4.3/P5.0 compatibility (1.2.0). Added Appendix D, modified Appendix E to match web.

14-Dec-98 HAO Fixed references to /ec (1.2.0)

24-Dec-98 HAO Added documentation on using PINET to PI 3 String Tag support; Auto FTP.

5-Jan-99 HAO Incremented version number to 2.0.4

27-Jan-99 HAO Added section on Batch File for PINet/PI3 string tags supt.

24-Feb-99 HAO Added Failover (2.0.6)

3-Mar-99 HAO Added changes noted by Merck (2.0.8)

11-Mar-99 HAO Added /udbi=x, Update DBIs every x hours. (2.0.9)Added FR Type 10, Activity Point DBI and Highway Address of Console Reads. (2.1.0)

14-Apr-99 HAO Added Appendix on Troubleshooting and on GNR2PI util. (2.1.0)

05-May-99 HAO CHIP Programming License is not needed on NT or UNIX. (2.1.0)

18-May-99 HAO Modified sections on Input versus Output point defs; added

05/20/2311:38 AM 57

section on setting CHIP_SCOPE environmental variable. (2.1.0)

21-Jul-99 HAO Added section on .dbg debug symbols file on NTI (2.1.3)

06-Oct-99 HAO Error 9 write I/O Timeout; error 8 write no error. (2.1.5)

15-Nov-99 HAO UserInt1 = 1 to convert CV5-CV8 to FP from % (2.1.8)

7-Dec-99 HAO Added note to ASCIIMSG and BATCHID pointing users to the section on CHIPtoPIFTP and BatchFile interface. (2.1.8, rev A)

28-Dec-99 HAO Modified PIFTP doc (was chiptopiftp) (2.1.8, rev B)

04-Jan-00 HAO Added NT Failover (2.5.0)

28-Jan-00 HAO Cleaned up Failover for VMS - Released (2.5.1)

06-Apr-00 HAO Added ability to read the first bit set to ON from the 8-bit statuses (2.5.4.0)

24-Apr-00 HAO Changed references to diskette to CD. (2.5.4.0, rev A)

05/20/2311:38 AM 58

fisher-rosemount chip on nt/vms/hp-uxcdn.osisoft.com/interfaces/844/pi_chiptopi_axp_2.5.4.doc ·...

Documents