PI MxOpen 4.12.8.1

PI to Measurex Open
Interface to the PI System
Version 4.04 4.12.8.1
OSI Software, Inc.

How to Contact Us
Phone (510) 297-5800 (main number)
(510) 297-5828 (technical support)
Fax (510) 357-8136
Internet techsupport@osisoft.com
World Wide http://www.osisoft.com
Web
Bulletin (510) 895-9423
Board Telebit WorldBlazer modem (Hayes, MNP, or PEP compatible)
8 data bits, 1 stop bit, no parity, up to 14400 bps download
protocols: Xmodem, Ymodem, Zmodem, Kermit
Mail OSI Software, Inc.
P.O. Box 727
San Leandro, CA 94577-0427
USA
OSI Software GmbH OSI Software, Ltd

Hauptstrae 30 P. O. Box 8256
D-63674 Altenstadt 1 Level One, 6-8 Nugent Street
Deutschland Auckland 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 statementPI 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.
PI_mxopen.doc
1999 - 2003 OSI Software, Inc. All rights reserved

777 Davis Street, Suite 250, San Leandro, CA 94577
OSI Software, Inc.

Table of Contents
Introduction.................................................................................................................... 1
Supported Features......................................................................................................2
Connection Options......................................................................................................3
PI Point Configuration....................................................................................................5
Point Parameters Definition..........................................................................................5
Point Examples.......................................................................................................... 10
Profile Status Handling...............................................................................................11
HMX DaVinci Issues...................................................................................................12
Hardware and Software Configuration.......................................................................13

Hardware.................................................................................................................... 13
Software..................................................................................................................... 13
I/O Rate Counter........................................................................................................ 13
IOStatus Codes.......................................................................................................... 14
Startup File................................................................................................................. 16
Installation Checklist VMS........................................................................................29

MXO Interface Files....................................................................................................29
Installation Tasks - VMS.............................................................................................29
Installation Checklist Windows................................................................................31

MXO Interface Files - Windows..................................................................................31
Installation Tasks........................................................................................................ 31
Setting up the Interface as a Service.........................................................................32
Running the Interface in Interactive Mode..................................................................33
Interface Startup and Shutdown Files........................................................................34
Interface Operation......................................................................................................37
Data Rate Monitoring..................................................................................................37
Error and Information Logging -- VMS........................................................................37
Error and Information Logging -- Windows.................................................................37
PI to Measurex Open Interface to the PI System iii

Table of Contents
Error Messages.......................................................................................................... 38
Error Modes................................................................................................................ 38
Appendix A: Glossary..................................................................................................43
Revision History............................................................................................................. 45
iv OSI Software, Inc.

Introduction
The PI Honeywell-HMX (HMX) Open (MXO) interface connects OSIsofts Plant
Information (PI) system to HMX LAN Devices that support HMXs ODX or
MXOPEN Server Protocols. The interface allows PI systems to access most data in
nodes on HMX LANs. It also supports PI outputs, which can be used to send data to
the HMX nodes.
This interface consists of a program running on the PI Server or PI interface node
making calls to/from the PI archive and communicating with the HMX node via
TCP/IP calls. The MXO interface can run on DEC VMS or Windows Intel
NT/2000/XP computers.
The supported HMX system configurations (from the older to the newer systems) are
as follows:
1. PI to MX Server to Data Freeway nodes, Vision 2000 systems, etc. The MX
Server communicates to its Data Freeway nodes via HMX's proprietary Data
Freeway hardware and SCO Unix operating system software. The MX Server
converts the Data Freeway protocol to the MXOPEN protocol by which it
communicates with PI.
2. PI to HMX Application Manager (AM): (AM release 1.0 and 2.0 or higher, also
referenced as MXOpen release 94). This is a Peer to Peer connection in which the
PI system communicates with only one HMX AM node per PI interface process..
On some of the older units, memory mapping may be a problem for large amounts
of profile tag retrieval. MX can supply the customer a patch to solve the memory
addressing of large amounts of profile data.
3. PI to MX Server to AM(s): The PI to MX Server connection utilizes ODX
Protocol. The MX Server can then communicate with multiple AMs.
4. PI to DaVinci: The newest generation of HMX gauging system controls operates on
the Windows NT platform. The HMX control system may or may not include
AMs. In some cases, the AM logic is programmed to run on the NT and the NT
box connects directly with the gauge. There are 2 scaled-down versions of
DaVinci. One is HMX Proline and the other is Micro CD Open. The Proline
communicates directly with the gauge and the CD Open communicates CD logic to
foreign gauging systems (such as ABBs AccuRay). In either case, the ODX
protocol available (MX Part Number: 3-5877-01 ODX Communication Software).
(OPC, DDE and ODBC protocols are also supported by the DaVinci product line,
but may require additional software from MX. Also note: The ODX
implementation on DaVinci is slightly different and will require the user to
configure the DaVinci system to handle event logic for the PI interface. See section
PI Point Definition: HMX DaVinci Issues below.)
In configurations 1 and 3, the connection is Peer to Peer with respect to the HMX
Server. Depending upon the configuration of the interface startup file (MXOn.COM for
VMS and MXOn.BAT for NT), the connection may be either Peer to Peer or Peer to
Many with respect to individual HMX nodes.
Thus, one PI interface can get data from and send data to multiple MX nodes through
the MX Server. Or one individual interface process can be dedicated to obtain/send data
from/to a single HMX node that is connected to the MX Server.
PI to Measurex Open Interface to the PI System 1

PI to Measurex Open Interface Documentation
Supported Features
Feature Support
Part Number PI-IN-MX-MXO-AXP
PI-IN-MX-MXO-NTI
PI-IN-MX-MXO-VAX
Platforms VMS / Alpha VMS / NTI (4, 2000, XP)
PI Point Types PI 3: Float16 / Float 32 / Int16 / Int32 /
Digital / String
PI 2: Float / Integer / Digital
Sub-Second Timestamps No
Sub-Second Scan Classes No
Automatically Incorporates PI Point Yes
Attribute Changes
Exception Reporting Yes
Outputs from PI Yes
Inputs to PI: Scan-Based / Unsolicited / Scan-based
Event Tags
Maximum Point Count Limited by capacity of HMX Node
Uses PI-SDK No
PINet to PI 3 String Support No
History Recovery No
Failover No
* UniInt-Based Yes
Vendor Software Required on PI-API / No
PINet Node
Vendor Software Required on Foreign No
Device
Vendor Hardware Required No
Additional PI Software Included with No
Interface
* See below for more information.
UniInt-Based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an
OSIsoft-developed template used by our developers, and is integrated into many
interfaces, such as the PI-MXO interface. The purpose of UniInt is to keep a consistent
feature set and behavior across as many of our interfaces as possible. It also allows for
the very rapid development of new interfaces. In any UniInt-based interface, the
interface uses some of the UniInt-supplied configuration parameters and some
interface-specific parameters. UniInt is constantly being upgraded with new options and
features.
2 OSI Software, Inc.

The UniInt End User Document is a supplement to this manual.
Connection Options
Connection Usage
HMX For use with AM, this interface requires HMX ODX
software version 1.4 or higher. For use with the MX Server,
it requires Server software version 1.2 or higher.
TCP/IP TCP/IP support is required on the computer executing the
interface. VMS certified with TGV Multinet on and
DEC UCX. NT Certified on MS TCP/IP stack for WinNT
3.51 and 4.0
Figure 1
Connection Topologies for
PI to Measurex Interface
PEER to PEER
Application
PI Host
Manager
Tag Process
PI Tag ODX Protocol for PM1
Database For
One MX
Node
PEER to MANY
Sample Measurex Network
PI Host MX
Process Server
PI Tag Tag MX Server
Database For DataFreeway
Protocol
Many MX Protocol
Nodes through ODX
Single Server Protocol Data Freeway
Node
for Node 3
Application Application
Manager Manager
for Node 1 for Node 2
PEER to PEER Through

Server
PI Tag
Database MX
Server
Tag For PI Host Application
Single MX Process Manager
Node MX Server for Node 1
Protocol
Tag For PI Host Application
Single MX Process Manager
Node MX Server for Node 2
Protocol
Tag For PI Host
Data Freeway
Single MX Process
MX Server for Node 3
Node
Protocol
Sample Measurex Network
Figure 1. Connection Topologies for P1 to HMX Interface
Note: Beginning with version 3.0 of this interface: The box representing PI Host
Process may also refer to a PI API node running the interface.

PI to Measurex Open Interface Documentation

PI Point Configuration
The MXO interface uses the startup file (MXOn.COM for VMS and MXOn.BAT for
NT) and PI point database to map PI tags to the corresponding HMX symbol names
and MX nodes. As shown in Figure 1, there are a number of connection topologies,
which can be utilized. In all cases, the HMX symbol name must be defined in the HMX
system before it can be accessed by this interface. For Data Freeway nodes, the symbol
names are defined in the MX Server; for Application Manager nodes, the symbol names
are defined intrinsically within the Application Manager.
Each PI point can be set up to be either an INPUT or OUTPUT tag. For the OUTPUT
tags, the interface outputs the value of the tag when triggered by changes in the tag's
value or status of the tags Source Tag.
The INPUT tags can be divided into SOLICITED and UNSOLICITED categories.
Each category can be further subdivided into EVENT- or TIME-driven:
INPUT Tags
Solicited event driven PI requests a value for this tag from the HMX node when the
Event tag defined for these tag changes.
time driven PI requests a value for this tag from the HMX node at the
repeat rate of the Scan Group in which this tag is placed.
Unsolicited event driven The HMX node sends a value to PI for this tag whenever the
specified HMX event occurs in the HMX system.
time driven The HMX node sends a value to PI for this tag at the defined
repeat rate according to the HMXs clock.
Note: It is preferable to use the Unsolicited-time-driven INPUT type of tag over the
Solicited-time-driven INPUT type of tag. The former requires less network traffic and
CPU overhead at both ends of the link.
Point Parameters Definition

When creating a PI data point to get data to/from the HMX node, the point parameters
have to be set up correctly in order that the MXO interface can correctly transform the
PI formats into formats and tables understood by HMX. The following is a description
of the important parameters.
Point Source
The point source is any one-character value that is usually the same for all points of
MXO interface. If a different point source is used, edit the file PISysExe:MXOn.COM
(or \pipc\interfaces\MXO\MXOn.BAT) to change the character specified and run Point
Src from the PI menu to define the character and establish the limits.
Notes: (1) n is the link number of the interface.

(2) The point source for each interface link should be unique within the PI
System.

If the PI Server is running PI2 then the Point Source Table needs to be edited as shown
below.
Location 1 Location 2 Location 3 Location 4 Location 5
1001 110000 0 0 0
99999 521024 99999 99 199999
Point Type
The interface supports the following PI2 point types. This is usually R (real) for data
values, and I or D for counters, flags, etc. However, any PI point type can be used for
any PI point.
The interface supports the following PI3 point types: Float16 and Float32, Int16,
Digital, and string tags. String tags can only be used when the interface is running on
NT-Intel and sending data to a PI3 Server.
Notes: (1) If D or I is used for a real value and the value is less than 0 or greater
than 32767, the point is given a status of either UNDERRANGE or OVERRANGE,
respectively.
(2) HMX status flags (in HMX parlance, Ordinals) may be stored in either D or
I type variables.
Location1
The first location contains the Process Number (PP) and the HMX System Number
(SSS) packed as:
(PP * 1,000) + SSS
i.e. PPSSS
Where:
1. Process Number refers to the ASCII name (See description of /PROC in startup
file item below.) of the group of process equipment associated with this PI tag. For
PI HMX ODX interfaces, PP=1 (there is only one Process Name per interface)
since the connection is Peer to Peer with AM nodes.
2. HMX System Number matches the startup parameter in MXOn.COM (or
MXOn.BAT).
3. The specific usage of these items depends upon the nature of the connection with
HMX and upon the startup file. See description of /MXO parameter in Software
Configuration below.
Location2
The second location is used to specify the Variable Type (V), the Data Type (D) and the
Array Element Number (AAAA) packed as:
(V * 100,000) + (D* 10,000) + AAAA
i.e. VDAAAA
where:
1. Variable Type (V) specifies the type of variable referred to by the HMX symbol
name (reference the Instrument Tag below):

Input Output
1 Single value Y Single value
2 Array: one element in a structure of equivalent
values
3 ODX Scanning Display Profile Array: one element in a
structure of equivalent values
4 ODX Scanning Reel Profile Array: one element in a
5 ODX Scanning Minislice Profile Array: one element in a
6 ODX Numbers stored in HMX (v2.14 and higher)

7 ASCII Strings (v4.09 and higher; PI versions
supporting string tags)
Variable types 3 through 6 are supported only for Peer to Peer Connections to HMX
AM Nodes via ODX. Variable types 3 - 5 provide are provided for the special
information embedded in scanner based profiles (i.e., Scanner status, sensor status, and
edge positions). In order to provide this additional information, the interface makes
assumptions that the AM follows a HMX symbol naming standard. (See Section on
Profile Status Handling below).
Variable type 6 allows the interface to receive ASCII-converted number data from
HMX and store it as a number in the PI database. The interface does not support other
types of ASCII data.
2. Data Type (D) specifies the kind of data. Two data types are supported:
1 Numeric Value
2 Digital value (In HMX terminology, an Ordinal value)
3. Array Element Number (AAAA) specifies the correspondence of this PI point with
an element within a HMX array (Variable Type 2 to 5). The maximum Array Element
Number for Variable Types 2 to 4 is now 256. For Variable Type 5, the maximum is
1024.
Location3
The third location is used to set up an UNSOLICITED TIME where HMX provides
the time trigger:
MX Trigger Time Rate (RRRRR) in seconds:
RRRRR
where:
MX Trigger Time Rate (optional) specifies how often HMX should send the data for
this PI tag to PI. This field must be zero if PI Scan Group, PI Event or HMX Event
triggers are defined. This parameter is required for UNSOLICITED TIME INPUT
tags.

Location4
The fourth location is used to set up a SOLICITED TIME where PI provides the time
trigger:
Scan Group
Scan Group number (optional) specifies the Scan Group to which this point belongs.
This parameter is required for SOLICITED TIME INPUT tags.
The user defines a scan list by specifying the time between executions for each scan list
in the interfaces startup parameters (See MXOn.COM for VMS or MXOn.BAT for
WinNT). The scan lists defined thereby, are referenced in the Location 4 parameter by
their sequential position (i.e., 1,2, 3, etc.) in the startup parameters. For example: if
there are three Scan Groups each executing at a different rate, then there will be three
Scan Groups specified in the startup parameters.
If the value for this PI tag should be requested at the rate specified by the third Scan
Group time, then Location 4 contains a Scan Group value of 3.
This parameter will be ignored if other parameters defined in the PI tag specify time or
event triggering.
Location5
Specifies the Input/Output Flag (F), the HMX Processor Number (M) and the BTI
Number (BBBB) packed as:
(F * 100,000) + (M * 10,000) + BBBB
i.e. FMBBBB
Where:
1. Input /Output Flag: If flag is set to 1, tag makes outputs to the HMX system upon
changes in its value or other PI-defined trigger.
2. MX Processor Number (optional) defines the ASCII name of the HMX processor
(LPN) associated with this point. It is used in conjunction with interface startup
parameter /LPN=ProcessorName1 /LPN=ProcessorName2 etc. Processor Number
references the nth item in the list of /LPN= startup parameters to provide the ASCII
for the Processor name.
3. BTI Number (optional) defines the ASCII name of the HMX memory bank
associated with this point. It is used in conjunction with interface startup parameter
/BTI=BTIName1 /BTI=BTIName2 etc. BTI Number references the nth item in the
list of /BTI= startup parameters to provide the ASCII for the BTI name.
Notes: (1) The LPN and BTI numbers are usually not required unless the HMX
symbol name is not unique within a HMX LPN. In practice, the symbols of interest to
PI are not likely to be so defined.
(2) If either LPN or BTI number is provided, then both must be provided.
The interface log file will report an error if HMX can not uniquely resolve the symbol
name; i.e., HMX system has more than one symbol with the same name.

InstrumentTag
HMX symbol name for input or output. Each PI tag must have a valid HMX Symbol
Name in the Instrument Tag field. When the interface is connected to an AM node, it
will report instances of undefined HMX symbol names.
Note: PI limits the Instrument Tag to 32 characters whereas HMX allows up to 40

characters.
Symbols can not be verified when the interface is communicating via the MX Server
with Data Freeway. This is because the MX Server does not support external symbol
verification for Data Freeway. Thus, for Data Freeway nodes, the interface assumes all
symbols to be properly defined in the MX Server.
Note: The MX Server sometimes has problems when attempts are made to access
undefined symbols on Data Freeway nodes. As a result, it is suggested that the user
verify the accuracy of the symbols for Data Freeway nodes by trying them at the MX
Server.
If HMX symbols are not unique within a node and require LPNx\BTIDx type
specifications, do not specify the full HMX variable in the instrument tag as
LPNx\BTIx\Variable_Name. If the LPN and BTI are specified in Location 5, the
interface will automatically prepend the LPN and BTI specification to the symbol name
specified in the Instrument Tag.
Valid characters in symbol names are _,$,0-9, a-Z, and . . No embedded
blanks are allowed.
SourceTag
PI tag (not case sensitive) used as the source of the data to be output to the HMX
Symbol specified by the Instrument Tag.
Notes: (1) To use this field requires site running PI V2.06 or higher.
(2) An alternative method for specifying a source tag is to include source =
any valid PI Tagname in the extended descriptor.
(3) A source tag name is required for OUTPUT type of tags.
Extended Descriptor
This is limited to 80 characters. The following possible delimiters and symbol names
must fit within the 80 characters.
/Tx = any defined HMX Ordinal Symbol Name (optional). It specifies a HMX
event trigger that is used to trigger its transmission of unsolicited data to PI. It has
maximum of 31 characters. This parameter is required for UNSOLICITED
EVENT INPUT tags. The HMX Symbol must refer to a HMX Ordinal (i.e., digital
flag).
Where: /Tx= may have the following values:
/T0 = Trigger on 0 to 1 transition of HMX variable
/T1 = Trigger on 1 to 0 transition of HMX variable
/T2 = Trigger on any transition of HMX variable

/Vx = any defined HMX Symbol Name (optional). It specifies a HMX

variable, which provides the validity of the HMX variable specified in the
Instrument Tag Field. Maximum of 31 characters. This is useful for attaching
status to any given HMX value. HMX Symbol can refer to any numeric data value,
where: /Vx= may have the following values:
/V0 = Value is valid if the value referenced by this HMX symbol is 0
/V1 = Value is valid if the value referenced by this HMX symbol is not 0
If a variable is not valid, it is shown in PI as UNAVAIL.
event = any valid PI Tagname (optional; not case sensitive).
If an event tag is specified, it supersedes the Scan Group specification in Location
4. This parameter is required for SOLICITED EVENT INPUT tags. It specifies a
PI triggered event. There will be an event whenever the specified Event Tag Name
changes value of status. When the event= option is used, location4 = 1.
source = any valid PI Tagname (optional; not case sensitive).
It may be used for output tags to specify the PI tag that is the source of data for
this tag. This parameter (or Source Tag) is required for OUTPUT tags.
Point Examples
The following PI point examples explain the point parameter definition specified above.
Profiles -- Unsolicited Event Input

PI tag for the 50th element of a HMX display profile named P11_BWAR, which is,
triggered by the HMX event flag P1EOS.ORD ; Process #1, HMX #1.
Location 1 1001.
Location 2 -- 310050 ( Var Type 3 * 100,000 + Data Type 1 * 10,000 + Array Element
50).
Location 3, 4, and 5 0.
Instrument Tag -- P11_BWAR
Extended Descriptor -- /T0=P1EOS.ORD (triggers on a 0 to 1 transition of HMX
flag).
Single Variable -- Unsolicited Time Input

PI tag for the machine speed named P1SPEED to be transmitted by the HMX MX
Server every 30 seconds; Process #1, HMX #1.
Location 1 1001.
Location 2 -- 110000 ( Var Type 1 * 100,000 + Data Type 1 * 10,000 + 0).
Location 3 -- 30 (HMX Trigger rate [sec]).
Location 4 and Location 5 0.
Instrument Tag -- P1SPEED.

Single Variable -- Solicited Time Input
PI tag for the machine speed named P1SPEED to be requested by PI every 30 seconds;
Process #1, HMX #1.
Location 1 1001.
Location 2 --110000 ( Var Type 1 * 100,000 + Data Type 1 * 10,000 + 0).
Location 3 0.
Location 4 -- 1 (Refers to the Scan Group number that was setup in the startup file
MXO.com to have a repeat rate of 30 seconds).
Location 5 0.
Instrument Tag -- P1SPEED.
Profile Status Handling

The interface has a built-in capability for handling the special status requirements of
scanning sensor-based profiles. In addition to values for each profile element, a profile
has scanner status, sensor status, and sheet edge positions.
For Variable Type Profile or Minislice Profile (Variable Type 3, 4, or 5 -- therefore,
only for Application Manager systems), the interface obtains the correct scanner sensor
status flags for the scanner and sensor specified by the HMX symbol in the Instrument
Tag field. It also obtains the edge of sheet slice positions for each sensor.
The interface assumes that the HMX symbol name for a profile variable has the
following format: ProcessNameScanner#SensorIDProfileID. For example, the symbol
of the scanner 1 basis weight profile is
P11_bw1tp
Where: P1 is the process name
1 is the scanner #
bw1 is the sensor ID
tp is the id for the display profile.
The MXO interface parses the HMX symbol name specified in the PI Instrument Tag
to obtain the scanner number and sensor ID. Using these, the interface builds the HMX
symbol names for the scanner status and sensor status as follows:
Scanner Status P11SCRVMODE 1 is replaced by the appropriate scanner #
Sensor Status P11bw1.badrd bw1 is replaced by the appropriate sensor ID
High Edge P11bw1BTMSLx x is replaced by T, R and Z for types 3, 4, and 5
respectively
High Edge P11bw1TOPSLx x is replaced by T, R and Z for types 3, 4, and 5
respectively
In addition, the MXO interface will make a special request for scanner status
information if no profile data is received within the time period specified by the /POLL
parameter in the MXOn.COM(or MXOn.BAT) startup file.

This can be valuable if the scanner is offsheet due to a paper break, etc. In this
situation, the PI tags for the profile will show a status of Emergency OFFSheet or
OFFSheet.
Note: If the Application Manager does not follow this convention for profile data, the
user may want to ask HMX to make the required changes.
Time Stamps
The interface uses PIs time for the all data received from HMX.
HMX DaVinci Issues

1. Version v4.11 and higher of the interface for Windows HT supports HMX
DaVincis 64 bit floats and 32 bit long values.
2. HMX DaVinci utilizes HMXs ODX protocol in a different way than the HMX
AMs. In the AMs, events names are treated as symbols: As a result, the PI/MX
interface verified each tags specified event (for example: Turnup Trigger) before
continuing with the data request. In DaVinci, event name are treated in a different
category from data symbols and can not be verified like symbols.
The simplest way to handle this is to define the event names of interest as symbols
in the DaVinci data symbol list. This will allow the interface to validate the events
as symbols.

Hardware and Software Configuration
The MXO interface uses the startup file MXOn.COM for VMS or the startup file
MXOn.BAT for WinNT and PI point database to map PI tags to the corresponding
HMX symbol names and MX nodes. As shown in Figure 1, there are a number of
connection topologies, which can be utilized. In all cases, however, the HMX symbol
name must be defined in the HMX system before it can be accessed by this interface.
For Data Freeway nodes, the symbol names are defined in the MX Server; for HMX
Application Manager nodes, the symbol names are defined intrinsically by the
Application Manager.
Hardware
The interface requires Ethernet hardware and properly connected and terminated
cabling.
Software
The interface requires TCP/IP support.
I/O Rate Counter

The I/O Rate Counter measures the rate at which the interface sends values to the PI
Snapshot, i.e. it serves as a measure of the data input load (it does not consider output
load). To use the I/O Rate counter, a rate tag should first be configured, such as
SYRNI01. Add the I/O Rate tags to the iorates.dat file. An example entry from an
iorates.dat file is given below
SYRNI01,1
If /ec=1 is used on the command line for the above iorates.dat file, then the rate (events
per minute) at which data is sent to the snapshot will be stored in SYRNI01. The rate
that is sent to iorate counters is a 10 minute average (i.e. the total number of events
collected by the interface divided by 10 minutes). Therefore the IORate will appear to
be zero for the first 10 minutes of interface operation.
On VMS, the interface rate tag should then be added to the I/O Rate List,
PISysDat:IORates.dat. The counter chosen may be any unused counter in the ranges of
1 -35 or 51 - 200. The IORates process must then be stopped and restarted for the
counter to be included. The IORates process can be stopped by:
@PISysExe:stop iorates
the IORates process can then be restarted by:
@PISysExe:iorates
For additional information see Data Rate Monitoring in the Interface Standard chapter
of the PI Interface Manual (IN).

On NT, the iorates.dat file must be The iorates.dat file must be created by hand. The
file should be placed in the dat\ directory. The dat\ directory is located in the directory
designated by the PIHOME entry in the pipc.ini file. Normally the PIHOME entry
points to the c:\PIPC\ directory so that the iorates.dat file will reside in the c:\PIPC\dat\
directory. Once the iorates.dat file is created, the interface must be stopped and
restarted before the interface begins measuring the IORate.
IOStatus Codes
The interface requires that the following digital states are defined in the Digital State
Table for a PI2 server and the System Digital State Set for a PI3 server. The default
starting code is 550 if the /IOSTAT parameter is not passed in the startup command
file.
The IOStatus Codes are shown in numerically increasing order. Thus, if IOStatus
WaitScnr is entered in the Digital State Table at number 550, then IOStatus
UndfSymMX would be positioned at number 603. Reserved items may be left blank.
Scanner/Profile Statuses
Code State Description
550 WaitScnr Scanner waiting to move
551 BkgrdScnr Scanner in background mode
552 RefScnr Scanner in reference mode
553 SmplScnr Scanner in sample mode
554 StdzScnr Scanner in standardize mode
555 ScanScnr Scanner in scan mode
556 SnglPtScnr Scanner in single point mode
557 OffShtScnr Scanner in offsheet mode
558 EmrgOffScnr Scanner in emergency offsheet mode (probably because of
sheet break)
559 2StrtScnr Scanner getting ready to start
560 LimboScnr Scanner in limbo scan mode (usually locating sheet edges)
561 SmplGrdScnr Scanner in grade sample mode
562 OfflineScnr Scanner in offline mode
563 ProfCorScnr Scanner in profile correction mode
564 ReptScnr Scanner in repeat mode
565 GrdLdScnr Scanner in load grade data mode
Data Value Statuses

566 BadRdSnsr Sensor data reading is invalid

567 NoMsmtSnsr Sensor reading is beyond edges of sheet
568 Unavail Value invalid according to status of specified validity flag
symbol
569 Unkn Status Unknown validity status if specified validity flag symbol is
undefined
570 No Update No PI tag data update occurred within the expected time
period
571 Msg Cancel Message for this PI tag is canceled
572 BdDataType MX Symbol Data type is not supported by PI (for ex: ASCII)
573 Reserved
574 Reserved
575 Reserved
576 Reserved
577 Reserved
578 Reserved
579 Reserved
MX Server or ODX Errors

580 2MnyNdRqMX MX Server: Message requests to too many nodes
581 IDNtActvMX Message ID not active
582 ProcOfflMX MX Server: HMX Process Node is offline
583 2MnyReqMX MX Server: Too many active message requests
584 ODXEFLWMX Communications Error with ODX
585 Reserved
586 Reserved
587 Reserved
588 Reserved
589 Reserved
590 BadHostMX MX Server: Bad Host Name
591 BadUsrIDMX Bad User ID
592 BadProcMX MX Server: Bad Process Name
593 BadEvSymMX MX Server: Bad Event Symbol
594 BadReqHdrMX MX Server: Bad Header in Request message
595 NoSymMX No Symbol specified in last message
596 DB ErrMX MX Server: Database error
597 NoProfilMX MX Server: Profile Not allowed
598 2MnyUndfMX Too Many Undefined Symbols in last message

599 2MnySymMX Too Many Symbols in Request

600 MsngDataMX Interface missing data in last messagemay be do requests
for ASCII valued HMX Symbols (PI doesnt support ASCII
values in tags)
601 BdDataMX Interface received uninterpretable data from MX
602 BdTrgSymMX Bad Message Trigger Symbol
603 UndfSymMX Undefined Symbol
Startup File
The set of interface parameters (defined in MXOn.COM or MXOn.BAT) used for all
connection topologies are listed below. Some of the parameters have different usage
depending upon the type of network connection intended. The command line parameters
for the MXO interface need to be edited with site specific startup parameters. The site
specific interface parameters required for MXO interface startup are the same for both
the NT and VMS platforms. However, the script files (MXOn.COM and MXOn.BAT)
differ.
Sample Startup File - NT

The startup file for the MXO interface will reside in the directory
\pipc\interfaces\mxo and is called MXOn.BAT. An example MXOn.BAT file is
shown below.
REM MXO.BAT
REM
REM Generic command file to start the MXO interface
REM For combined ODX/MX Server implementation
REM Version 3.00, 1993-1997
@echo off
cls
echo on
REM
REM revised:Last Modification
REM 20-may-97 VEF
REM
REM if multiple copies of the interface are to be run, copy MXO.BAT to
REM MXOn.BAT
REM where n is the same number passed by /id=n in the command string.
REM
REM command line arguments:
REM
REM Universal Interface parameters (in any order)
REM /PS = point source.
REM Use whatever letter you want and also setup matching

REM letter in the PI Point Source display.
REM /ID = inerface number to be used with PI/MXO in messages from particular
REM MXO interface.
REM /EC = I/O rate counter number to be used with MXO interface (optional)
REM /F = time between the scans for each scan class (f=hh:mm:ss).
REM You can define as many scan class as need.
REM /SN snapshot flag which forces the interface to ignore the exception
REM specifications of the tag and put all the events into the PI
snapshot
REM /HOST = name of PI Server Node(IP address of the host and the socket that
PI
REM Server is listening on). For PI Systems: on Windows NT, Port
REM Number=5450; on VAX/ALPHA, Port Number=545.
REM /DB turns on additional debug messages (optional).
REM
REM Interface Specific parameters (in any order ):
REM /INTFHOST = node name of computer running the MXO interface.
REM /MXO = Server number.
REM /MXINET = IP Address of MX Node to which MXO interface is connecting.
REM /KA = Rate at which to send keep alive message [sec].
REM For server, recommend 45 seconds and For ODX, recommend 25 seconds
REM (depends setup in HMX Application Manager-AM idserver.cfg file)
REM /RSPT = Rate at which to wait for MXO to respond to requests.
REM /POLL = Rate at which to solicit profile/scanner status info.
REM if there are no MX triggering events such as end of scan.
REM /PROC = MX Process names (ex: PM1) required, as many as there are proc
REM names.
REM /LPN = (optional) MX LPN - HMX Processor Names (ex: LPN1).
REM /BTI = (optional) MX BTI - HMX memory bank Names (ex: BTID4).
REM /IOSTAT = Starting number for Interface specific IO Status Codes.
REM /ODX = Account:Password combination defined in AM database.
REM This is required to use the interface for ODX operation.
REM If not present, interface will use MX Server interface protocols.
REM /DFY MX Server talks to HMX nodes via Data Freeway.
REM It is possible for the MX Server to talk to both Data Freeway nodes
REM and ODX Nodes at the same time. Since the MX Server software
does not
REM support symbol verification when it is used for data freeway
network,
REM we suggest that you run separate nterface processes:
REM One to talk to the server and its data freeway nodes with /DFY
switch
REM and one to talk to the MXServer and its ODX nodes.
REM Without the DFY switch the will verify all HMX symbols -- this
REM is a good thing to do.
REM /MXDATE MXServer was started with -date option: full date
sent by
REM server in data msgs.
REM /OUT = (optional) Name and directory of an auxiliary log file into which
REM the interface will place its trouble-shooting and normal message

REM output. This file rolls over daily (at definite time) into a
new file
REM /MSGFL = Full Path and file name of message files used
REM to to send messages to program.
REM /INTFTG = Name of PI tag that has value 1 if communications to MX Node is
up
REM and 0 if the communications are down
REM /MXSYM= Max Number of single valued HMX symbols to include in a data
REM request (Default is 20; max is 100)
REM /SYMDLY= Number of seconds to delay between each symbol verification:
REM (Default is 1.0 seconds)
REM NOSERVICE system runs PItoMXO interface as a console application
REM instead as WinNT service.
REM Edit the following to select the switches of interest
REM Run string needs a space between arguments, no spaces within argument.
pause
MXO.exe /mxdate /ps=M /id=1 /ec=7 /sn /out=c:\mxo\mxo.out /host=pltal1:545
/intfhost=namebywhichmxlistsus /mxo=1 /mxinet=167.148.253.140 /ka=20 /rspt=30
/poll=120 /proc=gppm6 /iostat=-700 /f=00:00:12 /f=00:00:05 /f=00:00:31
/stopstat=shutdown
REM end of MXO.bat
Sample Startup File VMS

$! MXO.COM
$! Generic command file to start the
$! PI/MXO Interface program
$! Informatics Controls, Inc. for Oil Systems, Inc.
$! David Sudikoff, 1993-95 for MXO
$! v2.13
$! For combined ODX/MX Server implementation
$! Modifications:
$! 950201 DBS Added log file output keyword /OUT=
$! 950201 DBS Set directory version limit for output files holding mxo out
put files
$! 950428 DBS /DFY switch for handling MXServer with data freeway version
$! 950428 DBS /MXDATE switch for if MXServer is started with -date option
-->full date
$! 950524 DBS /MSGARate was typo. Should be /MSGRate
$! 950531 DBS Noop line "SYS$OUTPUT","DEVCLASS" which seems to always
bypass the 'option'
$! 991213 DBS v4.11
$! 991213 DBS Last Modification
$! ------------------------------------------------------------
$!
$! Set Verify
$! ------------------------------------------------------------
$! ------------------------------------------------------------
$! Parameters:
$! Universal Interface parameters (in any order )

$! /ps=P P for point source for interface (Use whatever letter you want and
$! also setup matching letter in the point source d
isplay
$! /id=Link# Interface number to be used with
$! <MXOpi> in messages from intf
$! /ec=n IO rate counter
$! /f=HH:MM:SS Time between scans for each scan class
$! /db OPTIONAL turns on additional interface debugging
$! /sn OPTIONAL Overrides exception reporting to use snapshotting
$!
$! ------------------------------------------------------------
$! Interface Specific parameters (in any order )
$! /MXO=n Server number 1...
$! /MXINET=192.200.100.35 etc IP Address of MXO
$! /KA=20 [sec] Rate at which to send keep alive message
$! For server, recommend 45 seconds
$! For ODX, recommend 25 seconds (depends setup in
$! HMX Application Manager (A.M.) ids.conf file )
$! /RSPT=20 [sec] Rate at which to wait for MXO to respond to requests
$! /POLL=120 [sec] Rate at which to solicit profile/scanner status info
$! if there are no MX triggering events such as end of scan
$! /PROC=xxxxx MX Process names (ex: PM1) required, as many as
$! there are proc names
$! /LPN=xxxxx MX LPN names (ex: LPN1) optional
$! /BTI=xxxxx MX BTI names (ex: BTID4) optional
$! /IOSTAT=-550 Starting number for Interface specific
$! IO Status Codes
$! /ODX=ids:results (or any other account:password combination defined in A.
M. database)
$! This is required to use the interface for ODX operation.
$! If not present, interface will use MX Server interface protocols
$! Version 2.10 and later
$! /DFY=MX Server talks to HMX nodes via Data Freeway.
$! NOTE: IT is possible for the MX Server to talk to both Data Free
way nodes
$! and ODX Nodes at the same time.
$! Since the MX Server software does not support symbol verificatio
n
$! when it is used for data freeway network, we suggest that you ru
n separate
$! interface processes: One to talk to the server and its data free
way nodes,
$! (Use /DFY switch ) and
$! one to talk to the MXServer and its ODX nodes . Without the DFY
switch the
$! will verify all HMX symbols -- this is a good thing to do
$! /MXDATE MXServer was started with -date option -->full date sent by server in
data msgs

$! /OUT=outputfile name and directory

$! /MSGDir= Full Path name to directory containing ascii message files used to
$! to send messages to program.
$! /MSGRate= time [sec] wait between checks for external message file
$!
$! V4.00 and later
$! /INTFHOST = node name of computer running the MXO interface. MX displays this
$! name in its log files
$! /HOST=PI Host name as defined
$! /INTFTG = Name of PI tag that has value 1 if communications to MX
$! Node is up and 0 if the communications are down
$! /MXSYM = Max Number of single valued HMX symbols to include in
$! a data request (Default is 20; max is 100)
$! /SYMDLY= Number of seconds to delay between each symbol verification
$!
$ privreq = "SYSPRV,SETPRV,CMKRNL,CMEXEC,SYSNAM,GRPNAM,DETACH,"
$ privreq = privreq + "PRMCEB,PRMMBX,PSWAPM,ALTPRI,TMPMBX,WORLD,OPER,"
$ privreq = privreq + "EXQUOTA,NETMBX,PRMGBL,SYSGBL,PFNMAP,SHMEM,SYSLCK,"
$ privreq = privreq + "SHARE,GRPPRV,LOG_IO,READALL"
$ uicreq = "OSI" ! This can be run under SYSTEM UIC if desired
$!
$ privsav = f$setprv( privreq )
$ uicsav = f$user( )
$ ON CONTROL_Y then goto restore
$ set uic ['uicreq']
$!
$ cn = "_I1" ! HMX Interface number
$ dire = "PISysEXE:"
$ imag = "MXO"
$ procnam = imag + cn
$! Define name of process output file which will be rolled over on a rate
$! built into program
$ outfile = dire + procnam + ".log"
$ Set directory/version_limit=7 'dire' ! Set directory version limit
$!
$!
$ if (f$getdvi("SYS$OUTPUT","DEVCLASS") .eq. 1)
$ then
$ option = "/OUT=" + outfile
$ else
$ option = ""
$ endif
$!
$!
$ MXO:== $PISysExe:MXO.exe
$! These are examples of a setup
$! Edit the following to select the switches of interest
$! N.B. Lines continuing to next line should end in -
$ MXO -

/ps=M /id=1 /ec=7 /f=00:02:15 /f=00:03:00 /f=00:05:00 -
/sn /stopstat=shutdown-
/HOST=PINET1 /MXO=1 /MXINET=159.124.48.20 -
/KA=20 /RSPT=30 /POLL=120 /PROC=PM1 /IOSTAT=-700 -
'option' ! Log File output directory and name
! /db -
! /DFY - ! For Talking to Data Freeway nodes on MXServers
! /MXDATE - ! MXServer started with -date --> it will send full dates
! /MSGDIR=DKA300:[dirname.dirname] -
! /MSGRATE=120 ! Number of seconds between checking for 'mail' via message fil
e
$!
$!
$restore:
$ set uic 'uicsav'
$ discard = f$setprv( privsav )
$! Set NoVerify
$ exit
Parameters Common to All Types of Connections

There should be one copy of MXOn.COM or MXOn.BAT for each instance of the
interface as follows:
Parameter Description
/PS = M Point source for PI Point database, the user must specify a unique point
source such as M that is currently not in use by another process. It
must also be setup in the PI Point Src Display.
/ID = LinkName# Name for this instance of the interface to be used in messages. If there
are multiple instances of this interface, there should be different name
for each.
/ID = LinkName# Name for this instance of the interface to be used in messages. If there
are multiple instances of this interface, there should be different name
for each.
/EC = (optional) I/O Rate Counter number to be used with MXO. Used to
keep track of I/O throughput for this interface to the PI database.
(VMS only)
Range allowed is 1-34 and 51-200.
/MXINET = Internet IP address HMX node to which MXO is connecting (in dot format like
ID 159.124.80.145). If there is a MX Server, this is the IP address of the
Server, otherwise, it is the IP address of the AM node. Note: Make
sure the MX configuration file also has the TCP/IP address of the PI
interface node. The name of this file is: /database/host_sys.conf
/IOSTAT = Starting number of PI IO status codes required by interface. Either
positive or negative numbers can be added. Default is -550 if this
parameter is not passed.

/KA = Keep Alive Rate at which MXO interface queries network connection to HMX to
message rate [sec]. verify the status of that connection. For MX Server operation, it can be
set to 40 seconds. For operation with ODX, the value should be set to 5
seconds less than the value defined in the HMX configuration file
IDSERVER.CFG file located in the HMX system C:\VISION
directory.
If this file is missing set the Keep Alive rate to 25 seconds. This file
should only be changed by certified MX personnel and requires a MX
reboot to take effect.
/RSPT = Maximum time [sec] to wait for status response from HMX. The
default of 30 seconds is adequate for most situations.
/F = Scan period.
Multiple Scan Groups can be defined in the startup file by adding
additional /F = hh:mm:ss items (separated by white space).
A specific Scan Group is referenced by its enumerated position in the
startup file. Thus, if the startup file contains three Scan Groups as
follows (/F=00:01:00 /F=00:00:30 /F=1:00:00), then the 1 minute
group is referenced as Scan Group 1 because it is the first in the list;
the 30 second group is Scan Group 2; and the 1 hour group is Scan
Group 3, etc.
Individual PI tags are defined as belonging to a specific Scan Group by
using Location 4 parameter.
/DB (optional) turns on additional interface messaging. It is useful for
trouble-shooting the interface and network communications. When it
is set, all network messages between the interface and HMX will be
recorded in the interface log file.
/SN (optional) snapshot, MXO interface overrides exception reporting with
snapshot reporting. This means that exception specifications are
bypassed and data is put in the archive when the compression
specifications are exceeded. If compression is also turned off, data is
put in the archive as it is received.
/OUT=Daily Logfile (optional) name and location of an auxiliary log file into which the
Name interface will place its trouble-shooting and normal message output.
This file rolls over daily (at 12:10 A.M.) into a new file.
VMS -- (When this file is used, the interface process will also utilize
an error file MXOn.OUT which the operating system attaches to the
interface process. This file does not roll over; it contains all Operating
System specific messages).
If this parameter is not defined, the interface will send all its trouble-
shooting and normal message output to the process output file
MXOn.OUT.
WinNT -- The interface will send system error messages to the console
(if noservice option is selected) or to the PI Message Log system.
Trouble-shooting, normal and debug message output will be sent to a
file MXO_DateTime.OUT that rolls over daily to a new file. Warning:
this file can get very large.
If this parameter is not defined, the interface will send all trouble-
shooting and normal message output to the console (if noservice
option is selected) or to the PI Message Log system.

/MSGFL= MSG File (optional) name and location of a file containing real-time switch
Name settings to be sent to the interface. The interface will check every 2
minutes for the existence of this file. If it exists, it will parse the file
for the new switch settings contained in this file and then delete this
file.
Currently, this file can be used to turn trouble-shooting on or off
without having to restart the interface. To turn on debugging, create a
file with the specified MSG File Name and put /DB in line one
column one. To turn off debugging, put /NODB in line one column
one.
/MON = PI Tag Name (optional) name of a PI Tag for which trouble-shooting information will be
printed to the interface log file. When a tag is specified, the interface will
print all I/O communications and messages to PI that refer to this tag.
Multiple tags can be monitored by adding a /MON = tagname for each
tag that is monitored. The specified tag name should include blank
trailing characters if the tag name is less than 12 characters.
This can be used as an alternative to the full trouble-shooting switch
/DB.
/INTFHOST = Name of end-point of the TCP/IP link connected to HMX system; used
by HMX and interface system to display in system and error messages.
/POLL = Polling rate Rate at which to request Profile status updates from HMX for variable
[sec] types 3, 4, and 5.
/STOPSTAT= I/O Timeout will be written to all input tags when the /stopstat flag is
present.
/stopstat=system_digital_state will write the system digital state
specified instead of I/O Timeout. The recommended setting is:
/stopstat=shutdown.
/HOST=host:port The /host flag is used to specify the PI Home node. host is the IP
address of the PI Sever node or the domain name of the PI Server
node. port is the port number for TCP/IP communication. The port
is always 5450 for a PI 3 Server, and the port is always 545 for a PI 2
server. It is recommended to explicitly define the host and port on the
command line with the /host flag. Nevertheless, if either the host or
port is not specified, the interface will attempt to use defaults.
Defaults:
The default port name and server name is specified in the pilogin.ini
or piclient.ini file. The piclient.ini file is ignored if a pilogin.ini file is
found. Refer to the PI-API Installation Instructions manual for more
information on the piclient.ini and pilogin.ini files.
Examples:
The interface is running on an API node, the domain name of the PI 3
home node is Marvin, and the IP address of Marvin is 206.79.198.30.
Valid /host flags would be:
/host=marvin
/host=marvin:5450
/host=206.79.198.30
/host=206.79.198.30:5450

/SYMDLY=Sym Delay Time [sec] to delay between each symbol verification. Depends upon
capacity of MX AM to handle the cpu intensive symbol lookups. Default
is 1.0 second.
/INTFTG=Intf Tag Tag with value 1 or 0 if the communications to HMX node is up or down,
Status Name respectively.
/MXSYM=Max Maximum number of HMX symbols to include in single data request.
Symbols in single Default is 20; maximum is 100. This limit does not apply to array type
request symbols.
Parameters For Peer to Peer Connections to Single HMX AM Node

The following parameters are to be used in addition to those above.
/MXO = HMX 3 digit number used to relate PI tags to this particular instance of the
System number interface. Can be any value as long as it matches the last 3 digits of
the location 1 tag parameter. If there are multiple instances of this
interface, this number should be unique for each interface.
/PROC = Process process name of the AM System and relates to the PP digits of location
Names 1 of the PI tag. There should only be one instance of the parameter in
the MXOn.COM file. Thus, PP in location 1 should be 01.
/ODX= User Name: Password.
Tells the interface to utilize the ODX communications protocol. Also,
provides the UserName and Password required to log on to the HMX
AM. This name and password must be known to the HMX system.
These are defined in the HMX file IDSERVER.CFG. In addition, this
file defines access privileges for each UserName as FULL or
PARTIAL. The FULL privilege allows reading or writing data from/to
the HMX system. The PARTIAL allows only reading data from the
HMX system.
/ODX=user0001 :pass01 for example. Specific username/password
must be setup by the HMX system manager. It can have read and write
privileges..
The interface uses the MX System number in Location parameter 1 to map a particular
tag to a specific instance of the interface and thereby to a particular HMX AM node.
Parameters For Peer to Peer Connections through HMX Server

The following parameters are to be used in addition to the common parameters. Under
this setup, a single interface process is communicating to ONE MX Node through the
MX Server.
/MXO = HMX 3 digit number used to relate PI tags to this particular instance of the
System number interface. Can be any value as long as it matches the last 3 digits of
the location 1 tag parameter. If there are multiple instances of this
interface, each getting data from a different MX node, this number
should be unique for each interface.

/PROC = Process defines the process names of the HMX nodes connected to the MX
Names Server and relates to the PP digits of location 1 of the PI tag. There
will be a separate /PROC = ProcName parameter for each HMX
Process Name. These process names should match those defined in the
MX Server configuration files and should be the same for all instances
of the interface communicating with this MX Server.
A specific Process Name is referenced in the PP digits of Location 1 by
its enumerated position in the startup file. Thus, if the startup file
contains three Process Names as follows (/PROC=PM1
/PROC=COATER1 /PROC=PM2), then PM1 is Process 1 because it is
the first in the list; the Coater 1 is Process 2; and the PM2 is Process
3, etc.
/DFY Required if this instance of the interface is talking through the server
to HMX Data Freeway nodes.
NOTE If the MX Server is talking to both HMX Data Freeway and
Application manager nodes, you must utilize separate interface
processes and dedicate one process to communicate through the MX
Server to the Data Freeway nodes and one to each Application
Manager Node.
/MXDATE Required if the MX Server was configured with -date option. When
the MX Server uses the -date option in its startup file, the MX Server
will include both date and time stamps in its messages; otherwise it
includes only the time.
tag to a specific instance of the interface and thereby to a particular MX Server. The
Process Number in Location parameter 1 maps a particular tag to a specific MX Node
attached to the MX Server.
Parameters For Peer to Many Connections through HMX Server

The following parameters are to be used in addition to common parameters. Under this
setup, a single interface process is communicating to many MX Nodes through the MX
Server.
/MXO = HMX 3 digit number used to relate PI tags to a specific MX Server.
System number Can be any value as long as it matches the last 3 digits of the
location 1 tag parameter. This number should be unique for each
MX Server.
/PROC = Process defines the process names of the HMX nodes connected to the
Names MX Server and relates to the PP digits of location 1 of the PI tag.
There will be a separate /PROC=ProcName parameter for each
HMX Process Name. These process names should match those
defined in the MX Server configuration files and should be the
same for all instances of the MXO interface communicating
with this MX Server.
A specific Process Name is referenced in the PP digits of
Location 1 by its enumerated position in the startup file. Thus, if
the startup file contains three Process Names as follows
(/PROC=PM1 /PROC=COATER1 /PROC=PM2), then PM1 is
Process 1 because it is the first in the list; the Coater 1 is Process

2; and the PM2 is Process 3, etc.

/DFY required if this instance of the interface is talking through the
server to HMX Data Freeway nodes.
NOTE If the MX Server is talking to both HMX Data Freeway
and Application manager nodes, you must utilize separate
interface processes and dedicate one process to communicate
through the MX Server to the Data Freeway nodes and one to
each Application Manager Node.
/MXDATE required if the MX Server was configured with -date option.
When the MX Server uses the -date option in its startup file, the
MX Server will include both date and time stamps in its
messages; otherwise it includes only the time.
/LPN=HMX Processor (optional - only required in the case of non-unique HMX symbol
Names names) HMX Process Number, for example: LPN1
Can be multiple /LPN parameters in startup file; they are
referenced by their enumerated position (similarly to /PROC
above)
/BTI=HMX memory (optional -- only required in the case of non-unique HMX
bank names symbol names) HMX Memory Bank Number, for example:
BTID2.
Can be multiple /LPN parameters in startup file; they are
referenced by their enumerated position (similarly to /PROC
above)
tag to a specific instance of the interface and thereby to a particular MX Server. The
Process Number in Location parameter 1 maps a particular tag to a specific MX Node
attached to the MX Server.

Installation Checklist VMS
MXO Interface Files

There are 16 files for this interface. User has to copy the files over to PISysExe:
directory.
PISysExe: MXOBUILD.COMUsed to compiles the MXO interface files.
PISysExe: MXOLINK.COMUsed to link the modules used for the MXO
interface into an executable image.
PISysExe: MXODETACH.COMUsed to start the MXO interface as a detached
process.
PISysExe: MXO.COMUsed to start MXO PI link #1. (PISysExe: MXOn.COM
would be used for an nth HMX link, etc.)
PISysExe:DEV_FUNC.OBJ
PISysExe:DEV_LINK.OBJ
PISysExe:DEV_LINKM.OBJ (for Multinet implementations of TCP/IP)
PISysExe:DEV_MXOPEN_FUNC.OBJ
PISysExe:MESSAGEHANDLER.OBJ
PISysExe:MXODX.OBJ
PISysExe:MXSERVER.OBJ
PISysExe:TLISTA.OBJ
PISysExe:ROLLOVER.OBJ
PISysExe:MXO_UNIINT.OBJ
PISysExe:ALPHAUCX.OPT
PISysExe:RELEASENOTES.TXT
Installation Tasks - VMS

1. If necessary, install and configure TCP/IP software on the VMS system.
2. Configure the HMX systems according to the HMX MX Server Manual if the MX
Server is used.
3. Establish the physical link between MX and VMS. Test the connection by using the
TCP/IP PING utility program. It is suggested to test the link from both endpoints.
4. If the interface comes on a separate tape from the standard PI tape, follow the
instructions below to install the interface from tape. In the following example,
assume that the tape drive name is Mua0: and backup saveset on tape is
mxopen.bck which is made from another backup saveset, m3.bck at OSI. Choose a

Installation Checklist - VMS
point source for the MXO Interface Points. Define it using the Point Src Display
from the PI Menu for PI2 servers.
5. Create an I/O Rate Tag for each MXO interface and add them to the file PISysDat:
IORates.Dat. Define these tags in the PI System. Edit PISysExe: MXO.COM with
the correct rate counter. Stop and restart the IORates program:
$ @PISysExe:Stop IORates
$ @PISysExe:IORates
6. Put correct parameters in PISysExe: MXO.COM. If you have more than one HMX
interface running, copy PISysExe: MXO.COM as PISysExe: MXOn.COM for
each interface to be run, where n refers to the link number of this HMX link.
7. Modify PISysExe: ShutdownEvents.Com to shutdown all HMX PI tags in the
event of a shutdown. Additionally, the interface is programmed to mark all HMX
PI tags as I/O timeout if the interface is stopped or exits abnormally.
8. Add stop command to SiteStop.Com.
$ @PISysExe:Stop MXO_In (n refers to the HMX link number )
9. Add the Interface IOStatus Codes to either the Digital State Table for a PI2 server
or the System Digital State Set for a PI3 server.
10. Configure the data points for the MXO interface.
11. Start the MXO interface(s) manually with:
$ @PISysExe:MXOnDetach.com
Or by (re) starting the PI or PINet System.
Note: When starting multiple copies of this interface, a short delay may be required
between calls to the detach command because of operating system contention on PI
installed images.

Installation Checklist Windows
MXO Interface Files - Windows

The MXO interface consists of the MXO interface executable file MXO.exe, and the
startup batch file called MXOn.BAT to start this interface.
Installation Tasks
Create the directory to put the MXO interface into. The convention is to put the MXO
subdirectory under the pipc\interfaces directory; i.e. pipc\interfaces\mxo.
When installing TCP/IP software and PI3 system, the MXO interface batch
MXOn.BAT and executable files MXO.EXE files, as well as the utility files for point
creation should be located in this directory.
The files required for the MXO interface should be copied from the distribution
diskette directly to the \pipc\interfaces\mxo directory.
Once the above has been completed the following steps should be taken:
1. Configure the HMX systems according to the HMX MX Server Manual if the MX
Server is used
2. Establish the physical link between MX and NT. Test the connection by using the
TCP/IP PING utility program. It is suggested to test the link from both endpoints.
3. Choose a point source for the MXO Interface Points.
4. Add interface start and stop commands to the PI Site start/stop batch files.
5. Configure the IO Status codes for the interface.
6. Configure points for each copy of the MXO interface.
7. Determine an interface number for each interface to be run. This will be dependent
upon how many MXOs the host computer will read data from and write data to.
8. Edit the MXOn.BAT file(s) so that the proper parameters are passed.
9. Create a copy of the MXOn.EXE executable for each copy of the interface to be
run.
10. Install the interface as a service as discussed in Setting up the Interface as a
Service (section below).
11. Add the startup and shutdown commands to the startup and shutdown file as
discussed under Interface Startup and Shutdown Files discussed below.
Setting up the Interface as a Service

It is recommended that the interface be run as a service rather than from the DOS
prompt.
The procedure for installing the MXO interface as a service depends upon whether or
not Bufserv is being used. Once the interface has been installed as a service, the

Installation Checklist - Windows
procedure for starting, stopping, and removing the interface as a service is the same
whether or not Bufserv is used. The purpose of the Bufserv utility is to continue to
collect data from an interface in the event that the PI Data Archive is shut down for
some reason. For example, if the MXO interface is installed on the PI home node and
the PI Data Archive is shut down for an upgrade, the Bufserv utility on the PI home
node will buffer the data in a file until the PI Data Archive is brought back online.
Another possibility is that the MXO interface is installed on an API node. If there are
problems with the PI home node, then the Bufserv utility on the API node will buffer
the data in a file until the PI home node is brought back online.
The procedure for installing the interface in conjunction with the Bufserv Utility
assumes that the user has Bufserv 1.04 or higher because the procedure implicitly
assumes that Bufserv will be installed as a service. The actual installation of the
Bufserv Utility itself is not discussed. For these instructions, the user is referred to the
PI-API Bufserv 1.x Release Notes. Also, the installation procedure below does not
discuss the details related to shutdown events that the user should be aware of when the
Bufserv Utility is used. Once again, refer to the PI-API Bufserv 1.x Release Notes for
more information.
One can get help for installing the interface a service at any time by typing the
following:
mxo# -help
The mxo# service can be installed either as a manual or an automatic service.
Automatic services are started automatically when the NT operating system is
rebooted. This feature is useful in the event of a power failure. To install the interface
as a manual service, execute the following command from the \pipc\interfaces\mxo
directory.
Without Bufserv:
mxo# -install -depend tcpip
With Bufserv:
mxo# -install -depend tcpip bufserv
To install the interface as an automatic service, execute the following command from
the \pipc\interfaces\mxo directory
Without Bufserv:
mxo# -install auto -depend tcpip
With Bufserv:
mxo# -install auto -depend tcpip bufserv
Check the Microsoft Windows NT services control panel to verify that the service has
been successfully added. One can use the services control panel at any time to change
the mxo# service from an automatic service to a manual service or vice versa.
Once the mxoi# service has been installed, the rest of the procedure is the same whether
or not Bufserv has been implemented. The mxo# service can be started from the
services control panel or by executing the following command from the
\pipc\interfaces\mxo directory:
mxo# -start
A message will be echoed to the screen informing the user whether or not the interface
has been successfully started as a service. If the service is successfully started, the

interface will attempt to read the command-line arguments from the mxo#.bat file. For
this to succeed, the root name (the part of the file name before the .exe and .bat
extensions) of the batch file must be the same as the root name of the executable. Also,
the batch file and the executable file must be in the same directory. If the interface is
unable to read the command-line arguments or if the command-line arguments that the
interface reads are invalid, the service will terminate with no error messages echoed to
the screen. For this reason, the user MUST check the pipc.log file to verify that the
interface is running correctly. In the pipc.log file, messages pertaining to the MXO
interface will be prepended by mxo #>. The location of the pipc.log file is determined
by the PIHOME entry in the pipc.ini file. The pipc.ini file is located in the Winnt
directory. Usually, the pipc.log file will reside in the c:\pipc\dat\ directory.
If the service was successfully started, the user can verify that the service is still
running from the services control panel. If the service has been terminated, the reason
for its termination will be given in the pipc.log file. If the service is still running, the
user can use c:\PI\bin\apisnap.exe or Processbook to verify that data is being
successfully transferred to the PI Data Archive.
The mxo# service can be stopped at any time by issuing the following command:
mxo# -stop
The # service can be removed by
mxo# -remove
Running the Interface in Interactive Mode

Execute the following command from an MsDos prompt:
cd c:\pipc\interfaces\mxo
start "mxo#" mxo#.bat
A new MsDos window will appear, and the user will see several messages echoed to the
screen. Then the messages will simply stop. The user will not regain a command
prompt on the MsDos window until the interface has been stopped. The interface is
stopped by typing CONTROL-C while the MsDos window is selected. The user can
use c:\PI\bin\apisnap.exe or Processbook to verify that data is being successfully
transferred to the PI Data Archive.
Check whether there are any error messages to verify successful execution of the
interface. Messages that are sent to the screen are also sent to the pipc.log file. Check
the pipc.log file. Some messages are written to this file that are not echoed to the
screen when the interface is started up. Messages in the pipc.log file that pertain to the
interface will be prepended by mxo#>. The location of the pipc.log file is determined
by the PIHOME entry in the pipc.ini file. The pipc.ini file is located in the Winnt
directory. Usually, the pipc.log file will be placed in the c:\pipc\dat\ directory.
Interface Startup and Shutdown Files

The interface may be started after all the installation items have been completed.
For more information, refer the Installation section above.
Startup
Each interface should be set up to automatically start if the computer is rebooted. This
is done by setting the startup parameter in the Services Control Panel to Automatic.

Installation Checklist - Windows
The interface can also be manually started from the Services Control Panel by
highlighting the interface and clicking on Start. If the interface is running on a PIAPI
node, the interface can also be manually started by executing the following files which
should be created.
rem
rem pistart.bat 24-apr-98 jfz> OSI
rem
c:\pipc\bin\bufserv -start
rem
rem start interfaces
rem
call sitestart
rem
rem sitestart.bat 24-apr-98 jfz> osi
rem
rem start interfaces
rem
c:\pipc\interfaces\mxo\mxo1 -start & wait 5000
c:\pipc\interfaces\mxo\mxo2 -start
:theend
The file pistart.bat starts the buffering service first and then calls the file sitestart (a
.bat file) which starts mxo1 and mxo2 as services.
If the interface is running on the a PI3 Server, the interface can also be manually
started by adding line below to the pisrvsitestart.bat file found in the \PI\adm directory.
This entry should not be the last entry in the file.
C:\pipc\interfaces\mxo\mxo# -start
Shutdown
Each interface can be manually stopped from the Control Panel Services dialog box.
If the interface is running on a PIAPI node, the interface can also be manually stopped
by executing the following files which should be created.
rem
rem pistop.bat
rem
rem stop the interfaces
rem
call sitestop
rem
rem stop bufserv service
rem
c:\pipc\bin\bufserv -stop
The file pistop.bat stops the interface (running as services) first by calling sitestop.bat
and then stops buffering service.
rem

rem sitestop.bat 24-apr-98 jfz> osi
rem
rem stop the interfaces
rem
c:\pipc\interfaces\mxo\mxo1 -stop
c:\pipc\interfaces\mxo\mxo2 stop
If the interface is running on a PI3 Server, the interface can also be manually stopped
by adding the following line to the pisrvsitestop.bat file found in the \PI\adm directory.
C:\pipc\interfaces\mxo\mxo1 -stop
When the interface is shutdown, the points coming into the system should receive
shutdown events. The switch /stopstat=shutdown be added so that if the interface is
shutdown independently of any PI processes, shutdown will get written to all points
belong to the interface. If the interface is running on a PIAPI node and is sending data
to a PI server, make sure that the interface points are not included in the list of points to
receive shutdown when the server goes down. If the interface is running on a PI3
server, the points belonging to the interface should also be specified to receive
shutdown when the PI server is shutdown. This is done by including the points in the
PI\dat\shutdown.dat file.
Information and Error Messages

All messages pertaining to the interface will be written to the pipc.log file. If PI-
DataLink is loaded, the file will be located in the PIPC\dat directory, otherwise one will
be created in the \temp directory under the root directory.
The user can specify that special debug messages regarding tag get printed out both in
the interface Command Prompt window and the pipc.log file. These messages are
designed to aid in interface trouble shooting and do not need to be turned on during
ordinary circumstances. The user turns the debug messages by setting the /db flag in
the interface start up file, pi-rni#.bat. Removing the debug flag from the startup file
will result in those messages not printing out. Remember to stop and restart the
interface each time the flag is changed so that the change is picked up. The user can
also specify the /td switch which will only print out information regarding tag
configuration to the screen. A sample of the debug messages is shown in the Appendix.

Interface Operation
After configuring the hardware and software, and defining points associated with the
MXO interface, the interface may be started.
Data Rate Monitoring

The interface records the number of exception reports passed through the interface to
the PI database in the event counter tag (/EC) referenced in the interface startup file
MXOn.COM.
Error and Information Logging -- VMS

The MXO interface places error and information messages in two (or three) places:
The PI Message Log, PISysMgr: PIMessLog.txt. This file contains major
events related to the interface such as startup and shutdown messages.
The interface utilizes the output file, PISysExe: MXOn.OUT. This file
simplifies traceback and trouble-shooting of the MXO interface. It provides a
history of the interface operation. For example: If the interface encounters a fatal
error that prevents it from starting up, it puts the error message in this file. If the
interface stops because of a program error, VMS places traceback information into
this file.
If the /OUT = daily Logfile Name parameter in MXOn.COM is used, the
interface will use the daily Log File in addition to PISysExe: MXOn.OUT. The
interface will direct trouble-shooting and other information to this file. In addition,
the interface will create a new file daily at 12:10 A.M. This keeps the interfaces
log file from growing too large.
When a daily log file is specified, Operating System, I/O Communications, and Run
Time errors will be sent to PISysExe: MXOn.OUT.
The /DB parameter can be included in the startup string in the MXO interface startup
file MXO.COM in order to increase the level of error messages placed in PISysExe:
MXOn.OUT. Alternatively, the Message File specified in /MSGFL parameter can be
utilized to turn on/off debug messaging.
Error and Information Logging -- Windows

Error and information logging is the same as for VMS except for the following:
The daily rollover log file name has the date and time appended to the file name
since WinNT does not support multiple file versions.
When the interface is run as console application, system error and startup
messages are recorded to the console window. Otherwise, messages are sent to PI
message logger.

Interface Operation
Error Messages
The major kinds of messages that could appear in the log file MXO.OUT (or daily
LogFile Name if specified) include Error Modes, Fatal Error Messages, Link Status
Messages, and Tag Configuration Messages.
The messages have the following format:
<Interface Name> <Subroutine Name> Message.
Error Modes
Undefined Symbols
When the interface is talking to a HMX AM node, it can detect if a PI tag references an
undefined HMX symbol. If the symbol name is accurate, define it on the HMX system.
To force PI to be respond to this change, edit the PI tag on the PI system using the
Point Edit display (without making an actual change) or restart the interface.
A simple way to locate them in the log file is to use the SEARCH command on the log
file for the string undefined. Search can operate on a file while the interface process
locks it.
Connections
The interface checks the integrity of the communications connection with the HMX
MX Server or ODX every Keep Alive rate seconds (/KA). If the interface does not
receive a response to its message, it executes the routine DoMLIShutdown which marks
all interface tags as I/O Timeout.
The interface then attempts to re-establish the connection with HMX. The interface
prints a message to the MXO.OUT log file whenever there is a status change to the
connection.
Incomplete Messages
Occasionally, the HMX sends an incomplete message to the PI interface. This may
occur with extremely long messages (usually over 8000 bytes) when the HMX system
breaks the message into blocks of 4096 bytes. HMX may send the first and second
blocks but not the third, etc.
This may happen if the HMX system doesnt acknowledge rapidly enough (usually
within 2 seconds) from the TCP/IP System software layer. The causes of these timing
glitches can be either:
an extremely busy network
a network with some hardware problems, or
a very busy Host.
The symptoms of this type of problem appear in the archive and/or in interface log file
as follows:
I/O Timeout status occurs every now and then in the archive for the interface
tags.

The interface log contains messages similar to Didnt Get Whole Message or
Missing Func_ID.
The interface log contains messages similar to Missing Data or Bad Data
Block. In addition, the archive shows the status Missing Data for the interface tags.
When the above conditions occur, the interface log shows that the interface
executed the routine DoMLIShutdown followed by reconnection to the HMX.
Loss of Data From One of Several Nodes

When the interface is used in a Peer to Many Configurations in which the MX Server is
connected to Data Freeway nodes, the shutdown of single Data Freeway nodes can
cause the loss of interface data from other nodes. If this occurs, it is suggested to
reconfigure PI tag and interface setup to utilize the Peer to Peer configuration through
the MX Server.
Missing HMX Events

Occasionally, data triggered by HMX events can be missing. This is caused when the
MX System is either too busy to pick up the event or the event does not last long
enough in the HMX system. The HMX engineer should analyze and fix the problem.
Fatal Error Messages

These are messages that are recorded before the interface shuts itself down. When the
interface shuts itself down, it is designed to mark all of the points handled by the
interface with the IOStatus of I/O Timeout.
The interface shuts itself down in the event of memory allocation failures, illegal
pointers, or grossly uninterpretable messages received from the HMX systems. The
following actions should be taken:
Restart the interface
Notify OSI Software, Inc.
Link Status Messages

The following messages might indicate overloaded VMS/NT or HMX CPUs, TCP/IP
problems or keep alive rate that is too slow.
<DoReportMLIStatus> Disconnected: Cant talk to MX ODX
<DoReportMLIStatus> Lost Socket Connection to MX
<DoReportMLIStatus> No Keep Alive Response from MX ODX/Server
<DoHandleMLIStatus> DoHandleLogOn: Cant Wake Up ODX/Server
<DoVerifyMXDataSymNode> NO ODX/Server response to Symbol
Request: Reinit Interface
<DoBuildInputMsgQueue> Not receiving complete messages from
Peer
<DoSendOutputMsg> Lost IOConnection
The following messages are logged when they represent a change from the past
condition.
<DoReportMLIStatus> Socket Connected to MX
<DoReportMLIStatus> Logged on to MX Server/ODX

Interface Operation
<DoReportMLIStatus> Getting Keep Alive from MX Server/ODX

The following message indicates that there was a problem with a previously received
message. The interface is trying to start over again and reinitialize. If this occurs
frequently, it probably indicates a TCP/IP problem.
<DoHandleMsgList> Full or Partial Reinit is requested
Tag Configuration Messages

HMX symbol in the PI Instrument Tag field does not follow the proper syntax for a
profile-related variable:
<IsGoodProfileSetUp> MX symbol %s doesnt contain a legal 3
char sensor id
<IsGoodProfileSetUp> MX symbol %s doesnt contain a legal
scanner number
PI event specified for this tag does not exist.
<GetEventNumber> Warning, event tag %s does not exist, pt %s:
Cant get event number
<load_dev_structure> Check zeros and oohs in /T of Extended
Descriptor
<load_dev_structure> Check zeros and oohs in /V of Extended
Descriptor
HMX System number specified for this tag (part of the location 1 parameter) doesnt
match the system number given in this interfaces MXO.COM startup file (s/u =
startup).
<load_dev_structure> Tags MxOpen Sys # doesnt match s/u
parameter
Variable type or Data type specified which is out of bounds.
<load_dev_structure> Invalid Var Type
<load_dev_structure> Invalid Data Type
Array element number was specified for a single valued variable.
<load_dev_structure> VarType:Sngl: Invalid Array Elem #
Invalid Array element number was specified for this type of array or profile.
<load_dev_structure> Invalid Array Elem #
Value should be 1 or 0
<load_dev_structure> Invalid HMX Trigger Time
<load_dev_structure> Invalid Input/Output flag
Tag refers to a LPN list number that was not defined in startup parameters.
<load_dev_structure> Unknown LPN List #
Tag refers to a BTI list number that was not defined in startup parameters.
<load_dev_structure> Unknown BTI List #
Full HMX symbol representation (i.e., including LPN and BTI) is not allowed in PI
Tag Instrument name.
<load_dev_structure> Explicit LPNx\BTIxx not allowed in
Instrument Name for PI Tag

<load_dev_structure> Explicit LPNx/BTIxx not allowed in MX
Event Symbol for PI Tag
Explicit LPNx/BTIxx not allowed in MX Validity Symbol for PI Tag Instrument name
has non-alphanumeric characters (i.e., no embedded blanks are allowed) Only
_,$,0-9, a-Z, and . are allowed characters.
<load_dev_structure> Illegal Chars in Instrument Name for PI
Tag
<load_dev_structure> Illegal Chars in MX Event Symbol for PI
Tag
<load_dev_structure> Illegal Chars in MX Validity Symbol for PI
Tag
Output point requires a HMX Symbol in the Instrument Tag field.
<load_dev_structure> Invalid Output Pt: Need Instrument Symbol
for PI tag
Items not allowed with Output points.
<load_dev_structure> Invalid Output Pt: Arrays not supported
for PI tag
<load_dev_structure> Invalid Output Pt: MX Trigger Rates not
allowed for PI tag
<load_dev_structure> Invalid Output Pt: MX Trigger Symbols not
allowed for PI tag
<load_dev_structure> Invalid Output Pt: MX Validity Symbol not
allowed for PI tag
<load_dev_structure> Invalid Output Pt: PI Event Tags are not
allowed for PI tag
<load_dev_structure> Invalid Output Pt:\n\tPI Scan Group not
allowed for PI tag
Input point configuration errors.
<load_dev_structure> Invalid Input Pt:\n\tNeeds Instrument
Symbol for PI tag
<load_dev_structure> Invalid Input Pt:\n\tPI Src Pt not allowed
for PI Input tags: Tag
Solicited Input point configuration errors.
<load_dev_structure> Invalid Solicited Input Pt:\n\tBad PI
event tag %s for PI tag
<load_dev_structure> Invalid Solicited Input Pt:\n\tPI Scan
Group or Event reqd for PI tag
Unsolicited Input point configuration errors.
<load_dev_structure> Invalid UNSOL Input Pt:\n\tMX Trigger
(event or time) required for PI tag
<load_dev_structure> Invalid UNSOL Input Pt:\n\tOnly 1 MX
Trigger Type (event or time) allowed for PI tag

Interface Operation
<load_dev_structure> Invalid UNSOL Input Pt:\n\tPI Event or

Scan Group not allowed for PI tag.

Appendix A: Glossary
The following glossary contains acronyms and other terms used in this document. It
also shows the origins of some of the terms (mx for HMX Corporation and osi for OSI
Software, Inc.). The commonly used industry standardized acronyms are listed
with/without origin specified.
Terms Definition Origin

AM HMX Application Manager System mx
i/f Interface osi
MX HMX system mx
ODX HMX Open Data Exchange mx
Ordinal HMX single bit flag mx
Peer to Many A communications topology in which information flows between
one endpoint node and many nodes at the other end
Peer to Peer A communications topology in which information flows between
the two endpoint nodes
PI Plant Information System osi
Scan Group A group of tags whose values PI solicits at a common rate from osi
HMX
Source Tag Tag whose value and status is used as the value used by a PI osi
output tag
s/u startup (parameters in the startup file MXOn.COM)
where: origin=mx, defined by HMX Corp.
origin=osi, defined by OSI Software, Inc.
And used in standard PI system

Revision History
Date Author Comments
4/93 DBS First version for Beta release
2/95 DBS Version 2.10
2/96 DBS Version 2.14
6/97 DBS/VEF Version 3.00 -- VMS/NT and PI3 capable
12/99 DBS Version 4.00 VMS/NT and PI3 capable
7/31/03 CG Reformatted; added 2000 & XP; fixed headers &
footers; fixed page numbers; fixed TOC

PI MxOpen 4.12.8.1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PI MxOpen 4.12.8.1

Hochgeladen von

Copyright:

Verfügbare Formate

PI to Measurex Open

Interface to the PI System

Version 4.04 4.12.8.1

OSI Software, Inc.

OSI Software GmbH OSI Software, Ltd

1999 - 2003 OSI Software, Inc. All rights reserved

OSI Software, Inc.

Hardware and Software Configuration.......................................................................13

Installation Checklist VMS........................................................................................29

Installation Checklist Windows................................................................................31

PI to Measurex Open Interface to the PI System iii

iv OSI Software, Inc.

PI to Measurex Open Interface to the PI System 1

2 OSI Software, Inc.

PEER to PEER Through

Sample Measurex Network

Figure 1. Connection Topologies for P1 to HMX Interface

PI to Measurex Open Interface to the PI System 3

4 OSI Software, Inc.

Point Parameters Definition

Notes: (1) n is the link number of the interface.

PI to Measurex Open Interface to the PI System 5

6 OSI Software, Inc.

6 ODX Numbers stored in HMX (v2.14 and higher)

PI to Measurex Open Interface to the PI System 7

8 OSI Software, Inc.

Note: PI limits the Instrument Tag to 32 characters whereas HMX allows up to 40

PI to Measurex Open Interface to the PI System 9

/Vx = any defined HMX Symbol Name (optional). It specifies a HMX

Profiles -- Unsolicited Event Input

Single Variable -- Unsolicited Time Input

10 OSI Software, Inc.

Profile Status Handling

PI to Measurex Open Interface to the PI System 11

HMX DaVinci Issues

12 OSI Software, Inc.

I/O Rate Counter

PI to Measurex Open Interface to the PI System 13

Data Value Statuses

14 OSI Software, Inc.

MX Server or ODX Errors

PI to Measurex Open Interface to the PI System 15

Code State Description

599 2MnySymMX Too Many Symbols in Request

Sample Startup File - NT

16 OSI Software, Inc.

PI to Measurex Open Interface to the PI System 17

REM end of MXO.bat

Sample Startup File VMS

18 OSI Software, Inc.

PI to Measurex Open Interface to the PI System 19

$! /OUT=outputfile name and directory

20 OSI Software, Inc.

Parameters Common to All Types of Connections

PI to Measurex Open Interface to the PI System 21

22 OSI Software, Inc.

PI to Measurex Open Interface to the PI System 23

Parameters For Peer to Peer Connections to Single HMX AM Node

Parameters For Peer to Peer Connections through HMX Server

24 OSI Software, Inc.

Parameters For Peer to Many Connections through HMX Server

PI to Measurex Open Interface to the PI System 25

2; and the PM2 is Process 3, etc.