Siemens Teleperm XP via XU Interface to the PI System
Siemens Teleperm XP via XU
Interface to the PI System
Version 2.1.0.5
How to Contact Us
|Phone |(510) 297-5800 (main number) |
| |(510) 297-5828 (technical support) |
|Fax |(510) 357-8136 |
|E-mail |techsupport@ |
|World Wide Web | |
|Mail |OSIsoft |OSI Software, Ltd |
| |P.O. Box 727 |P O Box 8256 |
| |San Leandro, CA 94577-0427 |Symonds Street |
| |USA |Auckland 1035 New Zealand |
| | | |
| |OSI Software GmbH |OSI Software, Asia Pte Ltd |
| |Hauptstra(e 30 |152 Beach Road |
| |D-63674 Altenstadt 1 |#09-06 Gateway East |
| |Deutschland |Singapore, 189721 |
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.
PI_SiTeleXPXU.doc
( 2000-2002 OSI Software, Inc. All rights reserved
777 Davis Street, Suite 250, San Leandro, CA 94577
Table of Contents
Introduction 1
Reference Manuals 1
Supported Features 2
Diagram of Hardware Connection 4
Principles of Operation 5
Communication 5
Installation Checklist 7
Interface Installation 9
Naming Conventions and Requirements 9
Microsoft DLLs 10
Interface Directories 10
The PIHOME Directory Tree 10
Interface Installation Directory 10
Interface Installation Procedure 11
Interface Files 11
Installing/Upgrading from CD-ROM or a Downloaded File 11
Installing the Interface as an NT Service 12
Installing the Interface Service with PI-Interface Configuration Utility 12
Installing the Interface Service Manually 20
Digital States 21
PointSource 23
PI Point Configuration 25
TXP Tag Address Format 25
General PI Tag Configuration Information 25
Point Attributes 25
Tag 25
PointSource 25
PointType 26
Location1 26
Location2 26
Location3 26
Location4 27
Location5 28
InstrumentTag 28
ExDesc 28
Scan 28
Shutdown 29
Performance Point Configuration 31
Configuring Performance Points with PI-ICU (NT-Intel) 31
Configuring Performance Points Manually 32
I/O Rate Tag Configuration 33
Monitoring I/O Rates on the Interface Node 33
Configuring I/O Rate Tags with PI-ICU (NT-Intel) 33
Configuring I/O Rate Tags Manually 34
Configuring the PI Point on the PI Server 34
Configuration on the Interface Node 35
Startup Command File 37
Command-line Parameters 37
Sample pitxp.bat File 42
Interface Node Clock 43
Security 45
Starting / Stopping the Interface 47
Starting Interface as a Service 47
Stopping Interface Running as a Service 47
Buffering 49
Configuring Buffering with PI-ICU (NT-Intel) 49
Configuring Buffering Manually 52
Example piclient.ini File 53
Appendix A: Error and Informational Messages 55
Message Logs 55
System Errors and PI Errors 55
Appendix B: Communication Error Recovery 57
Appendix C: Troubleshooting 59
Questions and Answers 59
Appendix D: Message Logging 61
Logging Configuration 61
Run Time Logging Configuration 61
Appendix E : Version 2.x Enhancements 63
Archive Recovery 63
Sub-Second Events 63
Sub-Second Time Stamps 63
Appendix F: Microsoft Winsock Errors 65
Appendix G: Detailed Time Considerations 69
Revision History 71
Introduction
This is a description of the Siemens Teleperm XP via XU Interface to the PI System (following referred to as PI-TXP-XU Interface). The interface can be run on one of the following:
• An Intel NT or Windows 2000 PI3 Server
• An Intel NT or Windows 2000 PI-API Node with network access to a PI2 or PI3 Server
TCP/IP services must be enabled.
A single interface can collect data from one XP system at a time, via an XU. The interface may also be configured to use a backup XU in the event that the primary fails. The interface will accept data from whichever XU is leading.
The XU is available for connection to two types of OM (“Operating and Monitoring System”):
• TXP OM650
• TXP OM690, previously called TXP-IN (“In Nuclear power plants”)
This has an influence on the way the XU operates internally.
The interface supports both OM650 and OM690.
The XU itself is a computer running SCO Unix; however, the PI-TXP-XU interface runs on NT or Windows 2000 and just establishes a TCP/IP socket connection to the XU via the network.
This version of the interface uses the /EXT switch to transfer the sub-second portion of the time stamps into PI. Without this parameter the sub-second portion of the time stamps is still truncated as in version 1.
When the interface first submits a subscription list to the XU, it requests an “initial image” of the subscribed values. When the interface receives this image, it considers the data values to be “current” and changes the timestamps to the current time.
• Due to the fact that PI will be receiving foreign timestamps, the two systems should be synchronized to the same clock time. OSI recommends the YAT32 program available from .
Reference Manuals
OSIsoft
• UniInt End User Document
• PI Data Archive Manual
• PI-API Installation Instructions
• PI-Interface Configuration Utility User Manual
Siemens
• Application Software Documentation
Product: External Unit
Foreign System Connection to TXP-OM
Handling of the XU
ZXX206-E.01-8700-185.980224
V2.0
1998-12-14
• Application Software Documentation
Product: External Unit
Foreign system connection to TXP-OM
interface description
ZXX206-E.01-8700-185.96115
V5.0
1998-11-16
• Anwender-Software-Dokumentation
Produkt: External Unit
Fremdsystemanschluß an TXP-OM650 / TXP-OM690
Funktionsschnittstelle
ZXX206-E.01-8700-185.000518
V1.0
2000-05-18
• Anwender-Software-Dokumentation
Produkt: External Unit
Fremdsystemanschluß an TXP-OM650 / TXP-OM690
Schnittstellenbeschreibung
ZXX206-E.01-8700-185.961115
V5.2
2001-01-12
• TELEPERM XP
OM Prozessführungs- und Informationssystem
External Unit (XU)
Technische Beschreibung V1.00
2000-07-26
Supported Features
|Feature |Support |
|Part Number |PI-IN-SI-TLXP-NTI |
|Platforms |NTI |
|PI Point Types |R, I, D (PI2 Home Node) |
| |Float16, Float32, Float64, Int16, Int32, Digital) (PI3|
| |Home Node) |
|Sub-Second Timestamps |Yes |
|* Sub-Second Scan Classes |Not applicable |
|Automatically Incorporates PI Point Attribute Changes |Yes |
|Exception Reporting |Yes |
|Outputs from PI |No |
|* Inputs to PI: Scan-Based / Unsolicited / Event Tags |Scan-based reading of DCS events |
|Maximum Point Count |Unlimited |
|Uses PI-SDK |No |
|PINet to PI 3 String Support |No |
|* Source of Timestamps |Teleperm XP System |
|* History Recovery |Yes |
|* Failover |Yes |
|* UniInt-Based |Yes |
|Vendor Software Required on PI-API Node |No |
|* Device Point Types |analog, digital, and counter |
* See paragraphs below for further explanation.
Sub-Second Scan Classes
Although sub-second scan-classes can be specified on the command line, they do not really make sense because the interface just subscribes for DCS events in the XU, then scans the memory containing the received values according to the scan cycle defined.
Sub-second timestamps, though, may be obtained from the XU by using the /ext parameter.
Inputs to PI
The interface subscribes for DCS events in the XU. During each scan period the interface processes the values received since the last scan.
Source of Timestamps
Values sent to the PI data archive retain the time-stamp received from the XP system except for values belonging to the “Initial Image”. See “ Appendix G, “More Detailed Time Considerations” for more information.
History Recovery
The interface is able to access the history stored in the XU. See chapter “Startup Command File” for details.
Failover
The interface may also be configured to use a backup XU in the event that the primary fails.
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-TXP interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.
The UniInt End User Document is a supplement to this manual.
Device Point Types
The Teleperm XP interface provides support for analog, digital, and counter (integer) values from the XP system. The data type of the data in the XP system must be known ahead of time and so analog values may only be retrieved into real (float) tags, digital values into discrete tags, and counter values into integer tags (in PI).
Diagram of Hardware Connection
Principles of Operation
For proper interface operation, the user must configure input points (input tags) on a PI2 or PI3 home node (the words "point" and "tag" are used interchangeably in this manual). These tags are used to receive data values from an XP system, either at a given frequency or whenever the value of a given “trigger tag” changes.
At startup, the interface scans the PI Point Database for all associated points and builds its own point list. During runtime, the interface continues to check the PI Point Database for point updates and modifies its point list accordingly.
If the Scan field of any point on the point list is set to off, the point is removed from the point list. The point is added once again after the Scan field is turned back on. If neither a fixed scan rate nor a valid trigger tag is found for a given point, then it will be removed from or will not be added to the point list.
The interface subscribes for events in the Teleperm XP system. The XU permanently sends exceptions to the subscribing application (the PI-TXP-XU Interface) which in turn sends the values to PI. Although the interface is scan based, it just scans the memory that has been filled with values sent from the XU.
A system digital state is sent to the input tag if a communication error occurs.
If the interface determines that the KKS does not exist in the XP system, then the tag is ignored. If the interface still has not received a value for a particular KKS by the time the initial image is complete, then that KKS is considered to be non-existent.
Communication
The PITXP interface communicates with the XP system over a TCP/IP link. Due to the licensing requirements of the XU, each interface must be assigned a client ID number (entered in a file /usr/madamxenv/project/txp_xu_clients.p on the XU) that is unique among all clients connected to the system.
As part of the communication process, the interface is always aware of the state of the XU (i.e. leading, stand-by, etc). Signal data may only be collected from an XU if it is leading. If both a primary and a backup XU are specified on the command-line, then the interface will query the one that is leading for data. The interface maintains a connection to both primary and backup to prevent a loss of data.
Signals are requested by subscribing to “events” in the XP system. The interface passively receives these events until the list of requested events (determined by the PI input tags) changes. The interface checks the subscription list for changes every minute.
When the subscription list has changed, the interface cancels its current subscription and issues a new one. PI tags should always be configured before the interface is started in order to prevent any loss of data that may occur during the cancellation and re-subscription. The interface waits for a period of time after the last change to the subscription list before re-issuing the subscription.
All signal values are received into a data cache. PI input tags retrieve cached values at their designated scan rates. Version 2 gathers all events and sends them to PI at the configured scan rates.
Installation Checklist
For those users who are familiar with running PI data collection interface programs, this checklist helps you get the PI-TXP interface running. If you are not familiar with PI interfaces, you should return to this section after reading the rest of the manual in detail.
1. Install the PI-Interface Configuration Utility (which installs PI-SDK and PI-API)
2. Verify that PI-API has been installed.
3. Install the interface.
4. Define digital states.
5. Choose a point source. If PI 2 home node, create the point source.
6. Configure PI points.
Location1 is the interface instance.
Location2 must be 0.
Location3 controls reading of process value or quality value
Location4 is the scan class.
Location5 is not used.
InstrumentTag is the KKS if in an OM650 environment.
ExDesc is the KKS if in an OM690 environment.
7. Configure performance points.
8. Configure I/O Rate tag.
9. Edit startup command file.
10. Set interface node clock.
11. Set up security.
12. Start the interface without buffering.
13. Verify data.
14. Stop interface, start buffering, start interface.
Interface Installation
OSIsoft recommends that interfaces be installed on PI-API nodes instead of directly on the PI Server node. A PI-API node is any node other than the PI Server node where the PI Application Programming Interface (PI-API) has been installed (see the PI-API Installation Instructions manual). With this approach, the PI Server need not compete with interfaces for the machine’s resources. The primary function of the PI Server is to archive data and to service clients that request data.
After the interface has been installed and tested, Bufserv should be enabled on the PI-API node (once again, see the PI-API Installation Instructions manual). Bufserv is distributed with the PI-API. It is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when communication to the PI Server is lost. Communication will be lost when there are network problems or when the PI Server is shut down for maintenance, upgrades, backups, or unexpected failures.
In most cases, interfaces on PI-API nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.
The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and interfaces as manual services that are launched by site-specific command files when the PI Server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI Server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI Server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI Server node. See the UniInt End User Document for special procedural information.
Naming Conventions and Requirements
In the installation procedure below, it is assumed that the name of the interface executable is pitxp.exe and that the startup command file is called pitxp.bat.
It is customary for the user to rename the executable and the startup command file when multiple copies of the interface are run. For example, one would typically use pitxp1.exe and pitxp1.bat for interface number 1, pitxp2.exe and pitxp2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in a file that has the same root name.
Microsoft DLLs
The following Microsoft DLLs are distributed on the installation CD-ROM. Copy these files to the winnt\system32 directory only if the files in the winnt\system32 directory are older than the files on the CD-ROM.
|MSVCIRT.DLL |
|MSVCRT.DLL |
|MSVCRT40.DLL |
|MSVCP50.DLL |
|MSVCP60.DLL |
The following additional Microsoft DLLs are also distributed on the CD-ROM. These DLLs are only used by a debug version of the interface. Copy these files to the Winnt\system32 directory only if the files in the winnt\system32 directory are older than the files on the CD-ROM.
|MSVCIRTD.DLL |
|MSVCRTD.DLL |
|MSVCP50D.DLL |
|MSVCP60D.DLL |
Interface Directories
The PIHOME Directory Tree
The PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the WinNT directory. A typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=c:\pipc
The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
Place all copies of the interface into a single directory. The suggested directory is:
PIHOME\interfaces\pitxp\
Replace PIHOME with the corresponding entry in the pipc.ini file.
Interface Installation Procedure
Interface Files
|File |Description |
|PITxp_OM650.exe |Interface executable (OM650 Version) |
|PITxp_OM690.exe |Interface executable (OM690 Version) |
|PITxp.bat_new |Sample interface startup template |
|Debug.cfg |Logging configuration file template |
|PI_SiTeleXPXU.doc |This manual |
|PI_SiTeleXPXU_2.1.0.5.txt |Release notes |
Installing/Upgrading from CD-ROM or a Downloaded File
1. Copy the interface files from the installation media to
PIHOME\interfaces\pitxp\. Create the directory if necessary.
Nowadays, interfaces are shipped on CD-ROM. Furthermore; files can easily be exchanged via e-mail or supplied and downloaded from an ftp server. You may get authorized to download an interface update from ftp. or receive a bug fix by e-mail. The file you receive via ftp, e-mail or on the CD-ROM is a self-extracting executable for Intel NT, containing two versions of the interface executable, an interface startup template file, a logging configuration template file, the current Interface manual and the Release Notes. For example, you may receive version 2.1.0.5 of the PI-TXP Interface in the file PITxp_2.1.0.5.exe. Detach this file to your PC and double-click it in the Windows Explorer.
Don’t forget to create a backup of your existing interface files if this is an upgrade and you extract the files of the setup kit into the final interface directory. In this example, after extraction, you will have the following files in c:\pipc\Interfaces\pitxp
debug.cfg
PITxp.bat_new
PI_SiTeleXPXU.doc
PI_SiTeleXPXU_2.1.0.5.txt
PITxp_OM650.exe
PITxp_OM690.exe
2. At current time, two versions of the interface exist and get shipped: one (PITxp_OM650.exe) that supports OM650, and one (PITxp_OM690.exe) that supports OM690. Copy the one that applies to your scenario to pitxp.exe (or pitxp1.exe, pitxp2.exe etc., according to your needs).
This may change in a later interface version.
3. If multiple interface copies are to be run, create a separate directory for each copy. This is of special importance if the interfaces use archive recovery (/AR). In order to keep a designated PITxpAR.Tim for each interface, there must be different directories. Example:
PIHOME\interfaces\pitxp1\
PIHOME\interfaces\pitxp2\
4. If necessary, rename the command file so that it has the same root name of the executable.
5. Alter the command-line arguments in the .bat file as discussed in this manual.
6. Try to start the interface interactively with the command:
pitxp.bat
If the interface cannot be started interactively, one will not be able to run the interface as a service. It is easier to debug interactively started processes because error messages are echoed directly to the screen. Once the interface is successfully running interactively, one can try to run it as a service by following the instructions below.
Installing the Interface as an NT Service
The Teleperm XP interface service can be created with the PI-Interface Configuration & Management Utility, or can be created manually.
Installing the Interface Service with PI-Interface Configuration Utility
The PI-Interface Configuration & Management Utility (PI-ICU) provides a user interface for creating, editing, and deleting the interface service. For details, please refer to the PI-Interface Configuration Utility User Manual. Note that PI-ICU always assumes an interface number to be part of the file name, even if you run one copy only. So, as opposed to the manual interface installation described later in this manual, where having an executable pitxp.exe and a related startup file pitxp.bat is possible, PI-ICU will create a file pitxp1.bat, even if you don’t specify an interface number in the ‘Configure a New Interface” screen and browse for pitxp.exe. So, in order to have consistent .exe and .bat file names, name the interface executable pitxp1.exe, for example.
To start, run PI-ICU, and then choose Interface ( New… or click on the ‘New’ icon on the toolbar.
[pic]
Next click the ‘Browse’ button to navigate to the interface executable:
[pic]
[pic]
Click 'Open', then enter the Point Source character in to the ‘Point Source’ field and click on ‘Add’. Choose an interface number (1 in this example).
[pic]
Afterwards, you should get this message:
[pic]
Choose the interface type to be ‘Siemens Teleperm XP via XU’. For this to happen, select ‘sitelexp’ in the drop-down list. Create scan classes as desired by clicking on the ‘Add a scan class’ button. Then click ‘Apply’. Your screen will look like this:
[pic]
PI-TXP-specific Startup Parameters
Note that currently, no interface-specific PI-ICU Control exists for the PI-TXP Interface. Nevertheless, configuration actions can be performed. However, the PI-TXP (not UniInt) specific arguments must manually be entered under the tab ‘sitelexp’. For example:
[pic]
Service Configuration
Service Name
The Service to Add box shows the name of the current interface service. This service name is obtained from the interface executable.
Display Name
The Display Name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of the OSI suite of products.
Service Startup Type
The Service Startup Type indicates whether the interface service will start automatically or need to be started manually on reboot.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, interface services are set to start automatically.
Interface Dependencies
The Installed Services list is a list of the services currently installed on this machine. Services upon which this Interface is dependant should be moved into the Interface Dependencies list using the “Add>>” button. For example, if API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left.
When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.
Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.
Add [pic]
To add a dependency from the list of Installed Services, select the dependency name, and click the Add button.
Remove [pic]
To remove a selected dependency, highlight the service name in the Installed Dependencies list, and click the Remove button.
The full name of the service selected in the Installed Services list is displayed below the Installed Services list box.
[pic]
Create or Remove Interface Service
Create
The Create button adds the displayed service with the specified Dependencies and with the specified Startup Type.
Remove
The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out.
Start or Stop Service
The Start / Stop section contains a Start button [pic] and a Stop button [pic]. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.
The status of the Interface service is indicated in the lower portion of the PI-ICU dialog.
[pic]
Installing the Interface Service Manually
One can get help for installing the interface as a service at any time with the command:
pitxp.exe –help
Change to the directory where the pitxp.exe executable is located. Then, consult the following table to determine the appropriate service installation command.
|NT Service Installation Commands on a PI-API node or a PI Server node |
|with Bufserv implemented |
|Manual service |pitxp.exe –install –depend “tcpip bufserv” |
|Automatic service |pitxp.exe –install –auto –depend “tcpip bufserv” |
|NT Service Installation Commands on a PI-API node or a PI Server node |
|without Bufserv implemented |
|Manual service |pitxp.exe –install –depend tcpip |
|Automatic service |pitxp.exe –install –auto –depend tcpip |
When the interface is installed as a service on the PI Server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will repeatedly attempt to connect to the PI Server until it is successful.
Note: Interfaces are typically not installed as automatic services when the interface is installed on the PI Server node.
Check the Microsoft Windows NT services control panel to verify that the service was added successfully. One can use the services control panel at any time to change the interface from an automatic service to a manual service or vice versa.
Digital States
For more information regarding Digital States, refer to the Data Archive Manuals.
PI 2 Home Node
Digital states are defined by running the Digtl Stat display from the PI menu. The states must be contiguous for each status type and may be anywhere within the Digital State Table outside of the range 193 - 320, which is reserved for OSIsoft. The digital states need to be defined prior to point configuration. The digital state sets described in the PI 3 sections below should be entered into the PI 2 Digital State Table.
For more information, see the DA manual.
For PI 2 systems only, check that the following codes are defined in the Digital States Table (the states are already present in PI 3):
|Digital State Code |Digital State String |
|237 |Bad Output |
|238 |Scan Off |
|239 |Scan On |
|246 |I/O Timeout |
|251 |Under Range |
|252 |Over Range |
|255 |Bad Input |
|299 |Invalid Data |
PI 3 Home Node
Digital State Sets
PI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI digital tags and editing digital state sets, see the PI Data Archive Manual for Windows NT and Unix manual.
An interface point that contains discrete data can be stored in PI as a digital tag. A Digital tag associates discrete data with a digital state set, as specified by the user.
System Digital State Set
Similar to digital state sets is the system digital state set. This set is used for all tags, regardless of type to indicate the state of a tag at a particular time. For example, if the interface receives bad data from an interface point, it writes the system digital state bad input to PI instead of a value. The system digital state set has many unused states that can be used by the interface and other PI clients.
PointSource
The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For example, one may choose the letter X to identify points that belong to the PI-TXP-XU interface. To implement this, one would set the PointSource attribute to X for every PI Point that is configured for the PI-TXP-XU interface. Then, if one uses /ps=X on the startup-command line of the PI-TXP-XU interface, the PI-TXP-XU interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of X. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps argument.
Case-sensitivity for PointSource Attributes
In all cases, the point source character that is supplied with the /ps command-line argument is not case sensitive. That is, /ps=X and /ps=x are equivalent.
PI 2 Server Nodes
The following point source characters are reserved on PI 2 systems and cannot be used as the point source character for an interface: C, ?, @, Q, T. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.
Before a PI point with a given point source can be created, the point source character must be added to the PI 2 point source table. For example, if point source X is not defined in the PI 2 point source table, a point with a point source of X cannot be created. This prevents the user from accidentally creating a point with an incorrect point source character.
Defining a Point Source Character in the PI 2 Point Source Table
1. Enter PI by typing the following command from a VMS command prompt:
@pisysexe:pi
2. Select the PointSrc option from the menu.
3. Select New from the menu.
4. Assign a point source next to the Code: field. Also, assign minimum and maximum values for the Location1 to Location5 attributes.
| |Location1 |Location2 |Location3 |Location4 |Location5 |
|Minimum |1 |0 |-20000000 |1 |-20000000 |
|Maximum |99 |1 | 20000000 |256 |20000000 |
5. Select “Save” from the menu.
PI 3 Server Nodes
No point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character. Several subsystems and applications that ship with PI 3 are associated with default point source characters. The Totalizer Subsystem uses the point source character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Either do not use these point source characters or change the default point source characters for these applications. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.
PI Point Configuration
The PI point is the basic building block for controlling data flow to and from the PI Data Archive. A single point is configured for each measurement value that needs to be archived. Use the point attributes below to define what data to transfer.
TXP Tag Address Format
The Teleperm XP interface uses a KKS (German, literally “plant identification system”) to reference specific data sources in the XP system. A KKS consists of a combination of a process ID and a signal ID. In total, a KKS can be up to 25 characters in an OM650 environment, up to 34 characters in an OM690 environment, and spaces are important.
The exact format of the KKS is determined by the configuration of the XP system. Check the value status log display to determine the correct format for a particular KKS. In general, a certain number of characters are reserved for the name of the function block, while the remaining characters are reserved for the signal.
The interface is only able to receive events via the XU for signals that have been configured for archiving.
General PI Tag Configuration Information
One PI point (tag) must be configured for each TXP signal that the user wishes to work with. The points can be configured on a PI2 or PI3 home node.
The following describes the field names associated with PI point configuration that have specific meaning for use with the TXP interface. Other fields may also need to be specified for proper configuration of the PI point. Some of these fields include point name, typical value, engineering units, resolution code (PI2 only), filter code, etc. The user may also wish to create I/O Rate Tags for each interface. For more information on PI Point configuration see the Data Archive (DA) section of the PI System Manual (for PI2 home nodes) or the PI Data Archive Manual for Windows NT and UNIX (for PI3 home nodes).
The field names in the table below are consistent with the field names in the Data Archive Manual for PI3.
Point Attributes
Tag
A tag is a label or name for a point. Any tag name can be used in accordance to the normal PI point naming conventions.
PointSource
The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line argument and the “Point Source” section.
PointType
PI 2 Server Nodes
Scaled real, full-precision real, integer, and digital point types are supported on PI 2 Servers. For more information on the individual point types, refer to the Data Archive (DA) section of PI System Manual I.
The PI-TXP interface supports Real, Integer, and Discrete point types for PI2.
PI 3 Server Nodes
Float16, float32, int16, int32, digital, string, and blob point types are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for NT and UNIX.
The PI-TXP interface supports Float16, Float32, Int16, Int32, and Digital point types for PI3.
These data types indicate to the interface the type of the data in the XP system (which must be known ahead of time). Real tags imply analog data, integer tags imply counter values, and discrete tags imply digital data.
In particular:
Data telegrams received from the XU contain 3 components: ‘MeasValue’, ‘Counter’ and ‘SigState’, accompanied by time stamp and quality code.
For Float/Real tags, the interface will send ‘MeasValue’ to PI.
For Integer tags, the interface will send ‘Counter’ to PI.
For Digital tags, the interface will send ‘SigState’ to PI.
In other words:
If you want to store the ‘MeasValue’ of a KKS, the corresponding PI tag must be a Float/Real.
If you want to store the ‘Counter’ of a KKS, the corresponding PI tag must be of type Integer.
If you want to store the ‘SigState’ of a KKS, the corresponding PI tag must be of type Digital.
Location1
This parameter is used to specify the interface number, which corresponds to the /id=# flag in the PITXP#.bat file. Valid interface numbers are integer values 1 to 99, inclusive.
Location2
This parameter identifies the I/O type for the tag. Since the interface only supports input tags at this time, this attribute must be set to zero.
Location3
This parameter indicates whether the tag refers to the process value or status value of the signal.
= 0 process value
= 1 quality value
The XU passes the process signals from the connected PU's to the interface "as they are". A signal passed by the XU can be Invalid, Simulated, it can have a Corrected Time Stamp, a Replacement Value and so on. The XU does not only pass the process signal itself, but also a Bit mask called a Quality Code to the interface. This Quality Code can be checked by the interface. If you configure a tag to have a "1" in Location3, the interface will not send you the process signal from the PU (via XU). Instead you will receive the Quality Code mentioned above, that belongs to the PU signal. Chapter "Input Tag Configuration" contains a table that shows the meaning of each bit in the Bit mask. If you want to use the Quality Code for a tag, you should also use the /qcm=# switch according to your needs. The /QCM switch (= Quality Code Mask) is set to 34 by default. That means if Bit 1 (=Invalid) (2^1 = 2) or Bit 5 (=HW Failure) (2^5 = 32) are set, the event of a tag that was configured accordingly, will be set to "Bad Input" because Bit mask and QCM will be logically ANDed. If you set the /QCM=38, you would also receive a "Bad Input" event for the tag, if the quality code has Bit 2 (=Replacement Value) set. Setting Location3 to "0" will provide the Tag with the "normal" process values of the PU's connected to the XU.
If the quality code associated with an incoming value is a non-zero value when logically AND’ed with the quality code mask, then the tag is set to “Bad Input”. The quality code is a set of eight bits, as described in the following table.
|Bit |Meaning |
|0 |Not Initialized |
|1 |Invalid |
|2 |Replacement Value |
|3 |Simulated |
|4 |Doubtful |
|5 |HW Failure |
|6 |In service |
|7 |Time adjusted |
Location4
Location4 defines the scan class for the PI point. This field determines the frequency at which an input tag is scanned. The possible scanning frequencies for a given interface are specified by the user on the command line in the PITXP#.bat file (see the section entitled "Startup Command File"). Say part of the command line is as follows:
/f=00:00:05 /f=00:00:15 /f=00:01:00
Then, a point can be configured to ‘scan’ TXP every 5 seconds (Location4=1), every 15 seconds (Location4=2), or every minute (Location4=3).
However, data are delivered from the XU on exception. Thus, Location4 just determines the frequency the interface checks for exceptions for a specific tag. In other words: the interface does not really perform scan-based collection of data. One interface thread fills an internal data structure with the incoming events received by the XU. A second thread scans this structure in a period determined by the scan class and sends all values to PI. Therefore all data transfer is actually event-based. The scan class only determines the system load. Using a large time interval as scan class will be more memory consuming, using a small time interval will be more CPU Time consuming. For more information, see the description of the /f flag in the section called “The Startup Command File”.
Location5
Not used.
InstrumentTag
OM650 – KKS length 25 characters: The KKS (process ID and signal ID) for the data source in the XP system is placed here. Note that spaces, even trailing spaces, are important, and so the interface preserves all leading and internal spaces in the KKS. Additionally, the KKS is padded with spaces or else truncated to 25 characters.
For example, in order to reference the KKS on an XP system that refers to the analog signal value of the function block “00ANA00AI001”, the InstrumentTag might appear as follows.
00ANA00AI001 XQ01
In the above format, the XP system has been configured such that the first fifteen characters are reserved for the function block, while the last ten are reserved for the signal name. The remaining empty characters are filled with spaces.
Due to limitations of the PI configuration utility, it is not possible to enter leading spaces in the instrument tag. In this situation, use the @ symbol as a placeholder. The interface automatically replaces all @ symbols with a space. Thus, the above KKS could also be entered as follows.
00ANA00AI001@@@XQ01@@@@@@
OM690 – KKS length 34 characters: Use ExDesc.
ExDesc
In an OM690 environment, the KKS is 34 characters long, i.e. the KKS will not fit into the InstrumentTag. In this case, store the KKS in the Extended Descriptor like in the following example:
KKS=0GB99M001@@@@@@@@@@@@@@@@XG01@@@@@
Note the keyword “KKS=” as opposed to how an OM650 KKS is specified in the InstrumentTag. The other remarks noted under InstrumentTag apply analogously.
Scan
By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.
There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.
Shutdown
PI 2 Server Nodes
The Shutdown attribute is not used if the server node is a PI 2 system. For information on configuring shutdown events for PI 2, see Data Archive (DA) section 4.2.3 of PI System Manual I.
PI 3 Server Nodes
The shutdown attribute is used only if the server node is a PI 3 system.
The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of a power failure. For additional information on shutdown events, refer to PI Data Archive for NT and UNIX.
Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat=Shutdown command-line argument is specified.
One can disable SHUTDOWN events from being written to PI when PI is restarted, by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Data Archive for NT and UNIX.
Bufserv
It is undesirable to write shutdown events when Bufserv is being used. Bufserv is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when the Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when PI is shut down, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.
Performance Point Configuration
One can configure performance points to monitor the amount of time in seconds that an interface takes to complete a scan for a particular scan class. The closer the scan completion time is to 0 seconds, the better the performance. The scan completion time is recorded to millisecond resolution. PI-ICU suggests the following name for the Performance Point monitoring scan class 1: sy.st.PITxp1.sc1. You may wish to use the same name if you configure the tag manually.
Configuring Performance Points with PI-ICU (NT-Intel)
The PI-Interface Configuration & Management Utility (PI-ICU) provides a user interface for creating and managing Performance Points.
[pic]
To create or delete a Performance Point, right mouse click the line belonging to the tag to be created, and click Create or Delete. If a tag already exists, the status is marked “Created”, the Delete option will be enabled. If a tag does not exist, the status is marked “Not Created” or “Deleted”, and the Create option is enabled.
The Performance Points are created with the following PI attribute values:
|Attribute |Details |
|Tag |Tag name that appears in the list box |
|Point Source |Point Source for tags for this interface, as specified on the first tab |
|Compressing |Off |
|Excmax |0 |
|Descriptor |Interface name + " Scan Class # Performance Point" |
Status
The Status column in the Performance Points table indicates whether the Performance Point exists for the scan class in column 2. If a Performance Point does exist, a status of “Created” is displayed. If the Performance Point does not exist, a status of “Not Created” is displayed. If a Performance Point exists, and is deleted, a status of “Deleted” is displayed.
Scan Class
The Scan Class column indicates which scan class the Performance Point in the Tagname column belongs to. There will be one scan class in the Scan Class column for each scan class listed in the Scan Classes combo box on the Uniint Parameters tab.
Tagname
The Tagname column holds the Performance Point tag name, for example sy.st.PITxp1.sc1.
Configuring Performance Points Manually
Performance point configuration is the same on all operating system platforms. Performance points are configured as follows.
1. Set the extended descriptor to:
PERFORMANCE_POINT
or to:
PERFORMANCE_POINT=interface_id
where interface_id corresponds to the identifier that is specified with the /id flag on the startup command line of the interface. The character string PERFORMANCE_POINT is case insenstive. The interface_id does not need to be specified if there is only one copy of an interface that is associated with a particular point source.
2. Set Location4 to correspond to the scan class whose performance is to be monitored. For example, to monitor scan class 2, set Location4 to 2. See the /f flag for a description of scan classes.
3. Set the PointSource attribute to correspond to the /ps flag on the startup command line of the interface.
4. Set the PointType attribute to float32.
I/O Rate Tag Configuration
An I/O Rate point can be configured to receive 10-minute averages of the total number of exceptions per minute that are sent to PI by the interface. An exception is a value that has passed the exception specifications for a given PI point. Since 10-minute averages are taken, the first average is not written to PI until 10 minutes after the interface has started. One I/O Rate tag can be configured for each copy of the interface that is in use. PI-ICU suggests the following name for the I/O Rate Tag: sy.io.PITxp1. You may wish to use the same name if you configure the tag manually.
Monitoring I/O Rates on the Interface Node
For NT and UNIX nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.
Configuring I/O Rate Tags with PI-ICU (NT-Intel)
The PI-Interface Configuration & Management Utility (PI-ICU) provides a user interface for creating and managing I/O Rates Tags.
[pic]
PI-ICU currently allows for one I/O Rate tag to be configured for each copy of the interface that is in use. Some interfaces allow for multiple I/O Rates tags.
Enable IORates for this Interface
The Enable IORates for this interface check box enables or disables I/O Rates for the current interface. To disable I/O Rates for the selected interface, uncheck this box. To enable I/O Rates for the selected interface, check this box.
Tag Status
The Tag Status column indicates whether the I/O Rates tag exists in PI. The possible states are:
• Created – This status indicates that the tag exist in PI
• Not Created – This status indicates that the tag does not yet exist in PI
• Deleted – This status indicates that the tag has just been deleted
• Unknown – This status indicates that the ICU is not able to access the PI Server
In File
The In File column indicates whether the I/O Rates tag listed in the tag name and the event counter is in the IORates.dat file. The possible states are:
• Yes – This status indicates that the tag name and event counter are in the IORates.dat file
• No – This status indicates that the tag name and event counter are not in the IORates.dat file
Event Counter
The Event Counter correlates a tag specified in the iorates.dat file with this copy of the interface. The command line equivalent is /ec=x, where x is the same number that is assigned to a tag name in the iorates.dat file.
Tagname
The tag name listed under the Tagname column is the name of the I/O Rates tag.
Right Mouse Button Menu Options
Create
Create the suggested I/O Rates tag with the tag name indicated in the Tagname column.
Delete
Delete the I/O Rates tag listed in the Tagname column.
Rename
Allow the user to specify a new name for the I/O Rates tag listed in the Tagname column.
Add to File
Add the tag to the IORates.dat file with the event counter listed in the Event Counter Column.
Search
Allow the user to search the PI Server for a previously defined I/O Rates tag.
Configuring I/O Rate Tags Manually
There are two configuration steps.
Configuring the PI Point on the PI Server
PI 2 Server Nodes
A listing of the I/O Rate Tags that are currently being monitored can be obtained with the command:
@PISysDat:
Create an I/O Rate Tag using one of the existing I/O Rate Tags as a template.
PI 3 Server Nodes
Create an I/O Rate Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |float32 |
|Compressing |0 |
|ExcDev |0 |
Configuration on the Interface Node
For the following examples, assume that the name of the PI tag is sy.io.PITxp1, and that the name of the I/O Rate on the home node is sy.io.PITxp1.
1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the \WinNT directory. If both are specified, the PIPCSHARE entry takes precedence.
Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.
Add a line in the iorates.dat file of the form:
sy.io.PITxp1, x
where sy.io.PITxp1 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. x can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.
2. Set the /ec=x flag on the startup command file of the interface to match the event counter in the iorates.dat file.
The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.
Startup Command File
The Teleperm XP interface requires several command-line arguments for successful execution. For convenience, the arguments are defined in a startup command file called PITXP#.bat. A sample PITXP#.bat file is included on the installation disks.
Command-line arguments can begin with a / or with a -. For example, the /ps=X and -ps=X command-line arguments are equivalent.
For NT, command file names have a .bat extension. The NT continuation character (^) allows one to use multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of flags is unlimited, and the maximum length of each flag is 1024 characters.
The PI-Interface Configuration & Management Utility (PI-ICU) provides a tool for configuring the Interface startup command file. See chapter ‘Installing the Interface Service with PI-Interface Configuration Utility’ for more details on interface setup with PI-ICU. In particular, see ‘PI-TXP-specific Startup Parameters’. Example:
[pic]
Note: The UniInt End User Document includes details about other command line parameters, which may be useful.
Command-line Parameters
|Parameter |Description |
|/cid=# |Defines the client ID number, as assigned by the administration of the XU. This ID is |
|Required |used for all communication with the XP system. The client id is given by Siemens. It can |
| |be found on the XU in the following ASCII file: |
| |/usr/madamxenv/project/txp_xu_clients.p |
|/xu=x[:y] |Defines the host name and port number used to connect to the XU. If the port number |
|Required |(separated from the host name by a colon) is omitted, then a default port number of 18000|
| |will be used. This argument is required. |
| |If a second XU is specified, it is used as a backup with fail-over logic. |
|/L=fff |This parameter specifies the logging configuration file. The interface provides logging |
|Optional |facilities beyond the standard PI logging. See “Error! Not a valid result for table.” |
|Default: No extended logging |later in this manual for a full explanation. |
|to=# |Read time-out in seconds. The interface will reset the connection to the XU if it does |
|Optional |not receive any communication for this period of time. The default value is 1 minute. |
|Default: 60 | |
|/cyc=# |Amount of time in seconds, after which the XU is forced by the interface to send a |
|Optional |telegram in any case. If there are currently no events, it may be an empty telegram. The |
|Default: 300 |interface interprets these telegrams as life signals. During massive data retrieval, for |
| |example during processing a request for archive recovery, the XU may temporarily be |
| |unable to guarantee exact delivery of life signals. Be sure to choose this parameter big |
| |enough in order not to run into timeouts in case you request a lot of data. . The default|
| |is 300 seconds. |
| |The value of /cyc… is assigned to the 'ActCycle' request datagram part and passed to the |
| |XU |
|/chk=# |Subscriptions check interval in seconds. The interface will cancel the current |
|Optional |subscription and send the revised subscription when this period of time has passed |
|Default: 5 |without any new changes to the subscription list. The default value is 5 seconds. |
|/rec=# |The period of time that the interface waits before attempting to reconnect to the XU |
|Optional |after the connection has been lost. The default value is 1 minute. |
|Default: 60 | |
|/qcm=# |The bit mask that is logically AND’ed with the quality code to determine whether the tag |
|Optional |should be set to “Bad Input”. The default value is 34 (TXP_XU_QC_INVALID | |
|Default: 34 |TXP_XU_QC_HWFAIL), under which a quality code where the value is invalid, or there is a |
| |hardware failure, will result in a “Bad Input”. |
|/img=# |Request Initial Image. By default an Initial Image is requested. Normally the XU time is |
|Optional |passed to PI. There is only one exception to this rule: All events received in the |
|Default: 1 |Initial Image will have the time stamp of the current PI-Server time. Setting /img=0 will|
| |switch off the request of an Initial Image. |
| |Note that if /AR is specified, then no Initial Image is requested in any case, in order |
| |to avoid out-of-order data to be sent to PI. In other words, the /img switch is ignored |
| |and has no effect. |
|/ext |Switch on EXTended PI-Mode. Using this switch, you will get sub-second time stamps. If |
|Optional |omitted, the sub-second portion will be truncated. |
|Default: No sub-second time | |
|stamps | |
|/ar[=#] |Switch on Archive Recovery. Normally you don’t need anything else than the /AR switch. In|
|Optional |that case the interface handles the time stamps automatically in a text-file named |
|Default: No Archive Recovery |‘PITxpAR.Tim’. You can also create this file manually in the interface directory and |
| |enter a start time. This is the recommended method, if you want to transfer old data from|
| |the XU to PI. |
| |The optional time stamp for the /AR switch allows you, to start with the given time in |
| |the past from the command line. Caution: This time will be used any time you restart the |
| |interface with the same start script. |
| |In both cases the start date requires the following format: YYYY:MM:DD:HH:MM:SS, for |
| |example 1999:12:3:12:00:00. The colon character is used as separator, therefore you can |
| |write for example 3 minutes as 3 or 03. |
| |Note: The time stamps in ‘PITxpAR.Tim’ are expected to be in local time. |
| |During normal operation ‘PITxpAR.Tim’ is being updated periodically to mark a time up to |
| |which data could be read successfully. |
| |Annotation: |
| |Archive Recovery works with continuous transfer from past to present data i.e. if the |
| |requested past data has been transferred the interface will continue with transfer of |
| |current data. |
| |Error Messages regarding /AR: |
| |If you enter a start time and receive the error message “TXP_SERV_NO_MEDIUM” it means |
| |that the XU cannot find a medium that contains data for the given startup time. Reduce |
| |the start time or insert a medium that contains the requested data. |
|/OM=# |You can specify /OM=650 or /OM=690. This switch can be omitted if you have an OM650. |
|Optional | |
|Default: OM650 | |
|/ps=x |The /ps flag specifies the point source for the interface. x is not case sensitive and |
|Required |can be any single character. For example, /ps=X and /ps=x are equivalent. |
| |The point source that is assigned with the /ps flag corresponds to the PointSource |
| |attribute of individual PI Points. The interface will attempt to load only those PI |
| |points with the appropriate point source. |
|/id=x |The /id flag is used to specify the interface identifier. |
|Required |The interface identifier is a string that is no longer than 9 characters in length. |
| |UniInt concatenates this string to the header that is used to identify error messages as |
| |belonging to a particular interface. See the section called “Error and Informational |
| |Messages” for more information, page 57. |
| |UniInt always uses the /id flag in the fashion described above. This interface also uses |
| |the /id flag to identify a particular interface copy number that corresponds to an |
| |integer value that is assigned to Location1. For this interface, one should use only |
| |numeric characters in the identifier. For example, |
| |/id=1 |
|/f=SS |Defines the time period in between scans in terms of hours (hh), minutes (mm), and |
|or |seconds (ss). Several time periods can be defined on a single command line. Location4 |
|/f=SS,SS |determines which time period is used. The value in Location4 corresponds to a position in|
|or |the list of /f switches. |
|/f=HH:MM:SS |Please note that all values are transferred exception based. In other words, the exact |
|or |time when a scan happens is less important than for other, really scan based interfaces. |
|/f=HH:MM:SS,hh:mm:ss | |
|Required | |
|/host=host:port |The /host flag is used to specify the PI Home node. host is the IP address of the PI |
|Optional |Sever node or the domain name of the PI Server node. port is the port number for TCP/IP |
|Default: see right |communication. The port is always 5450 for a PI 3 Server and 545 for a PI 2 Server. It is|
| |recommended to explicitly define the host and port on the command line with the /host |
| |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 a PI-API node, the domain name of the PI 3 home node is |
| |Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host flags would be: |
| |/host=marvin |
| |/host=marvin:5450 |
| |/host=206.79.198.30 |
| |/host=206.79.198.30:5450 |
|/stopstat |If the /stopstat flag is present on the startup command line, then the digital state I/O |
|or |Timeout will be written to each PI Point when the interface is stopped. |
|/stopstat= |If /stopstat=digstate is present on the command line, then the digital state, digstate, |
|digstate |will be written to each PI Point when the interface is stopped. For a PI 3 Server, |
|Default: |digstate must be in the system digital state table. For a PI 2 Server, where there is |
|/stopstat= |only one digital state table available, digstate must simply be somewhere in the table. |
|”Intf shut” |UniInt uses the first occurrence in the table. |
|Optional |If neither /stopstat nor /stopstat=digstate is specified on the command line, then no |
|Default: see right |digital states will be written when the interface is shut down. |
| |Examples: |
| |/stopstat=”Intf shut” |
| |The entire parameter is enclosed within double quotes when there is a space in digstate. |
|/ec=x |The first instance of the /ec flag on the command line is used to specify a counter |
|Optional |number, x, for an I/O Rate point. If x is not specified, then the default event counter |
| |is 1. Also, if the /ec flag is not specified at all, there is still a default event |
| |counter of 1 associated with the interface. If there is an I/O Rate point that is |
| |associated with an event counter of 1, each copy of the interface that is running without|
| |/ec=x explicitly defined will write to the same I/O Rate point. This means that one |
| |should either explicitly define an event counter other than 1 for each copy of the |
| |interface or one should not associate any I/O Rate points with event counter 1. |
| |Configuration of I/O Rate points is discussed in the section called “I/O Rate Tag |
| |Configuration” p. 35. |
| |For interfaces that run on NT nodes, subsequent instances of the /ec flag may be used by |
| |specific interfaces to keep track of various input or output operations. One must consult|
| |the interface-specific documentation to see whether subsequent instances of the /ec flag |
| |have any effect. Subsequent instances of the /ec flag can be of the form /ec*, where * is|
| |any ASCII character sequence. For example, /ecinput=10, /ecoutput=11, and /ec=12 are |
| |legitimate choices for the second, third, and fourth event counter strings. |
|/sio |The /sio flag stands for “suppress initial outputs.” The flag normally applies only for |
|Optional |interfaces that support outputs. The PI-TXP-XU interface does not support outputs. |
| |However, the Logging Tags are configured as output tags. If the /sio flag is not |
| |specified, the interface will behave in the following manner. |
| |When the interface is started, the interface determines the current snapshot value of |
| |each output tag (i.e. of each Logging Tag). Next, the interface writes this value to |
| |each output tag. In addition, whenever an individual output tag is edited while the |
| |interface is running, the interface will write the current snapshot value to the edited |
| |output tag. |
| |This behavior is suppressed if the /sio flag is specified on the command line. That is, |
| |outputs will not be written when the interface starts or when an output tag is edited. |
| |In other words, when the /sio flag is specified, outputs will only be written when they |
| |are explicitly triggered. |
| |If you use the enhanced run-time operation logging facilities, it is recommended to |
| |specify /sio. |
| |Say your logging configuration file specifies the debug level to be at zero (which is |
| |quite common), via -D0, but the value of L$LOG_LEVEL is at a value of 9, left from a |
| |previous interface run where you encountered problems. In this case, the interface would |
| |read the "9" out of the tag at startup and override the "0" given in the configuration |
| |file. Specifying /sio will prevent this and keep the settings of the configuration file |
| |until a new value is explicitly sent to the trigger tag. |
|/q |When the /q flag is present, Snapshots and exceptions are queued before they are sent to |
|Optional |the PI Server node. |
| |Extended API mode behavior: |
| |The maximum queue size is close to 4000 bytes. The queue is flushed between scans if it |
| |is not filled. |
| |Non-Extended API mode behavior: |
| |The maximum queue size is 255 bytes for a PI 3 Server and 36 bytes for a PI 2 Server. For|
| |example, if the interface is running on a UNIX node and is communicating to a PI 2 |
| |Server, then the maximum queue size is 36. The queue is flushed between scans if it is |
| |not filled. |
| |When the /q flag is specified in non-extended API mode, the PI-API sends integer values |
| |as 16-bit integers instead of 32-bit integers. Therefore, integer points will be limited |
| |to values between 0 and 32767. Values higher than 32767 need to be sent to floating-point|
| |PI tags. |
Sample pitxp.bat File
The following is an example file:
REM PITxp.bat
REM
REM Sample startup file for the Siemens Teleperm XP Interface via XU Interface PI System
REM --------------------------------------------------------------------------
REM Required Parameters
REM /ps Point source
REM /f Scan frequency
REM /cid Client id number
REM /xu=xuhost:port XU host name and port
REM /id Interface instance number
REM
REM Optional Parameters
REM /l Logging configuration file
REM /to Read timeout in seconds
REM /cyc How often interface forces XU to send data
REM /chk Subscriptions check interval in seconds
REM /rec Period to wait before attempting a reconnect to XU
REM /qcm Bit mask for quality code
REM /img Request initial image
REM /ext Use sub-second timestamps
REM /ar Archive recovery
REM /OM=650 or /OM=690 Default: /OM=650
REM /host=name:port PI host and port
REM /stopstat State to write when interface stops
REM /ec Event counter
REM /sio Suppress initial outputs
REM /q Queue data before send to home node
REM --------------------------------------------------------------------------
REM Sample startup command line
Start "Siemens Teleperm XP Interface via XU" .\pitxp /id=1 /ps=S /cid=80 ^
/xu=142.125.66.1 /f=00:00:10 /host=mypi3server:5450 /q /ext ^
/L=c:\pipc\interfaces\pitxp\debug.cfg /ar /ec=1 /sio
REM --------------------------------------------------------------------------
REM Revision History
REM Date Author Comment
REM 23-Jul-02 CG Written
REM --------------------------------------------------------------------------
Interface Node Clock
The correct settings for the time and time zone should be set in the Date/Time control panel. If local time participates in Daylight Savings, from the control panel, configure the time to be automatically adjusted for Daylight Savings Time. The correct local settings should be used even if the interface node runs in a different time zone than the PI Server node.
Make sure that the TZ environment variable is not defined. The currently defined environment variables can be listed by going to Start | Settings | Control Panel, double clicking on the system icon, and selecting the environment tab on the resulting dialog box. Also, make sure that the TZ variable is not defined in an autoexec.bat file. When the TZ variable is defined in an autoexec.bat file, the TZ variable may not appear as being defined in the System control panel even though the variable is defined. Admittedly, autoexec.bat files are not typically used on NT, but this does not prevent a rogue user from creating such a file and defining the TZ variable unbeknownst to the System Administrator.
Security
If the home node is a PI 3 Server, the PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Data Archive. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Data Archive Manual. (Starting with PI 3.3, the Proxy Database has been replaced by the PI Trust Table – please consult the corresponding section in the PI-UDS manual.)
If the home node is a PI 2 Server, the read/write permissions should be set appropriately in the pisysdat:piserver.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the pibuild:piserver.txt file on the PI 2 home node.
If the interface cannot write data to a PI 3 Server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Serve, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging, p.57.
Starting / Stopping the Interface
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.
Starting Interface as a Service
If the interface was installed a service, it can be started from the services control panel or with the command:
pitxp.exe –start
A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. One is that the service may not be able to find the command-line arguments in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See the section “Appendix A: Error and Informational Messages,” p. 57, for additional information.
Stopping Interface Running as a Service
If the interface was installed a service, it can be stopped at any time from the services control panel or with the command:
pitxp.exe –stop
The service can be removed by:
pitxp.exe –remove
Buffering
For complete information on buffering, please refer to the Uniint End User.
PI-API Node buffering consists of a buffering process which runs continuously on the local node, a PI-API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.
Configuring Buffering with PI-ICU (NT-Intel)
Buffering is enabled through the PI-Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI-API will not buffer data, sending data directly to the home node.
The API Buffering… dialog allows the user to view and configure the parameters associated with the API Buffering (bufserv) process. The user can start and stop the API Buffering process from the Service tab:
[pic]
Service Tab
The Service tab allows for some API Buffering service configuration. For further configuration changes, use the Services applet.
Service Name
The Service name displays the name of the API Buffering Service.
Display Name
The Display name displays the full name associated with the API Buffering service.
Log On As
Log on as indicates the Windows user account under which the API Buffering service is setup to start automatically on reboot, or manually. To modify the user account or password under which bufserv runs, use the Microsoft Windows “Services” applet.
Dependencies
The Dependencies lists the Windows services on which the API Buffering service is dependent.
Service Startup Type
The Startup Type indicates whether the API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, the API Buffering service is set to start automatically.
Start / Stop Service
The Start / Stop buttons allow for the API Buffering service to be started and stopped.
After a change is made to any of the settings on the Settings tab, the Save button must be clicked, and then the service must be stopped and restarted for the changes to be picked up by bufserv.
Settings Tab
The Settings tab allows for configuration of the 7 configurable settings used by API Buffering. Default values are used if no other value is provided.
[pic]
Enable API Buffering
Enables the API Buffering feature.
Maximum File Size
Maximum buffer file size in kilobytes before buffering fails and discards events. Default value is 100,000. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Send Rate
Send rate is the time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds). Default value is 100. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Primary Memory Buffer Size
Primary memory buffer size is the size in bytes of the Primary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Secondary Memory Buffer Size
Secondary memory buffer size is the size in bytes of the Secondary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Transfer Objects
Max transfer objects is the maximum number of events to send between each SENDRATE pause. Default value is 500. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Pause Rate
When buffers are empty the buffering process will wait for this number of seconds before attempting to send more data to the home node. Default value is 2. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Retry Rate
When the buffering process discovers the home node is unavailable it will wait this number of seconds before attempting to reconnect. Default value is 120. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Theoretical Send Rate
This is the theoretical max send rate is calculated like this:
max = MAXTRANSFEROBJS / SENDRATE * 1000
Default value is 5000.
There are no additional steps needed to install buffering after installing the PI-API. The delivered PI-API library supports both buffered and un-buffered calls.
Configuring Buffering Manually
Buffering is enabled through the use of a configuration file, piclient.ini. Unless this file is modified to explicitly enable buffering, the PI-API will not buffer data, sending data directly to the home node.
There are no additional steps needed to install buffering after installing the PI-API. The delivered PI-API library supports both buffered and un-buffered calls.
Note: When buffering is configured to be on, the bufserv process must be started before other programs using the PI-API, so that these programs can access the shared buffering resources. Any program that makes a connection to a PI Server has this requirement even if it does not write to PI.
Configuration of buffering is achieved through entries in the piclient.ini file. The file is found in the dat subdirectory of the PIHOME directory (typically c:\pipc\dat) under Windows NT. This file follows the conventions of Microsoft Windows initialization files with sections, keywords within sections, and values for keywords. All buffering settings are entered in a section called [APIBUFFER]. To modify settings, simply edit the piclient.ini file in a text editor (Notepad on Windows) to the desired values.
The following settings are available for buffering configuration:
|Keywords |Values |Default |Description |
|BUFFERING |0,1 |0 |Turn off/on buffering. OFF = 0, ON = 1, |
|PAUSERATE |0 - 2,000,000 |2 |When buffers are empty the buffering process will wait for|
| | | |this long before attempting to send more data to the home |
| | | |node (seconds) |
|RETRYRATE |0 - 2,000,000 |120 |When the buffering process discovers the home node is |
| | | |unavailable it will wait this long before attempting to |
| | | |reconnect (seconds) |
|MAXFILESIZE |1 - 2,000,000 |100,000 |Maximum buffer file size before buffering fails and |
| | | |discards events. (Kbytes) |
|MAXTRANSFEROBJS |1 - 2,000,000 |500 |Maximum number of events to send between each SENDRATE |
| | | |pause. |
|BUF1SIZE |64 - 2,000,000 |32768 |Primary memory buffer size. (bytes) |
|BUF2SIZE |64 - 2,000,000 |32768 |Secondary memory buffer size. (bytes) |
|SENDRATE |0 - 2,000,000 |100 |The time to wait between sending up to MAXTRANSFEROBJS to |
| | | |the server (milliseconds) |
In addition to the [APIBUFFER] section, the [PISERVER] section may be used to define the default PI server and an optional time offset change that may occur between the client and server.
|Keywords |Values |Default |Description |
|PIHOMENODE |string |none |Windows default server is in pilogin.ini |
|DSTMISMATCH |0 - 2,000,000 |0 |The time that the server and client local time |
| | | |offset is allowed to jump. Typically, 3600 if the |
| | | |nodes are in time zones whose DST rules differ |
| | | |(seconds) |
Example piclient.ini File
On Windows NT the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds meaning wait 10 minutes after losing a connection before retrying.
On NT a piclient.ini file might look like:
[APIBUFFER]
BUFFERING=1
MAXFILESIZE=100000
; The PI-API connection routines have a 1 minute default timeout.
RETRYRATE=600
Appendix A:
Error and Informational Messages
A string NameID is pre-pended to error messages written to the message log. Name is a non-configurable identifier that is no longer than 9 characters. ID is a configurable identifier that is no longer than 9 characters and is specified using the /id flag on the startup command line.
Message Logs
The location of the message log depends upon the platform on which the interface is running. See the UniInt End User Document for more information.
Messages are written to PIHOME\dat\pipc.log at the following times.
• When the interface starts many informational messages are written to the log. These include the version of the interface, the version of UniInt, the command-line parameters used, and the number of points.
• As the interface retrieves points, messages are sent to the log if there are any problems with the configuration of the points.
• If the /db is used on the command line, then various informational messages are written to the log file.
System Errors and PI Errors
System errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers. The interface will report all the XP system errors with a context-sensitive description.
Error Descriptions on NT
On NT, descriptions of system and PI errors can be obtained with the pidiag utility:
\PI\adm\pidiag –e error_number
Appendix B:
Communication Error Recovery
If the XP system "goes down" (becomes disconnected), the tags associated with that node will not report any future values to PI until the interface reestablishes communication with the system.
In pipc.dat, you will see messages like:
09-Jun-00 19:06:00
PI-TXP 1> [195.211.175.131:18000] Error 10054 occurred receiving response from XU.
09-Jun-00 19:07:02
PI-TXP 1> [195.211.175.131:18000] Error 10061 occurred connecting to XU.
Once the XP system reconnects, the interface automatically starts sending data to PI.
Additionally, the interface requests an event time-out of 5 minutes from each XU. If more than 5 minutes elapse with no new data, the XU sends an “empty” message to the interface, indicating that it is still functioning. If more than 10 minutes elapse with no communication from the XU, the interface will then reset the connection with the XU.
The interface always waits for one full minute before re-establishing a connection with any XU. This is in concordance with the specifications of Siemens.
Note: The error numbers in the above messages correspond to Windows Sockets (winsock) errors. Please consult appropriate documentation for more details. For example, the description of all Win32 error codes can be found in the MSDN Library.
Appendix F Microsoft Winsock Errors lists a subset of error codes and their descriptions.
Appendix C:
Troubleshooting
If the interface is behaving in an unexpected manner, check the pipc.log file and the user-specified log file (see "Appendix D Message Logging”.) Even when the interface runs in interactive mode, not all error messages are written to the screen). In general, the user-specified log file will contain greater detail than the pipc.log file.
Questions and Answers
Question: As soon as I start the interface, it exits. What could cause this?
A. First, check the log files. A detailed explanation may be found there. Common causes may be:
• PI is not running on the specified host
• TCP/IP services are not enabled
Question: Why does it take several minutes to see new values after I add a new tag while the interface is running?
Answer: The interface checks for changes in the PI point database every two minutes. Any new values won’t be sent to PI until the first scan after the tag was added.
Question: What does the following message mean? What to do about it?
Received TXP_QUIT (NAK): order 14, code -5, module 20, line 574. Resetting connection.
Answer: Check whether you are using a wrong client id. Ask a field engineer for the client id of the XU you are connecting to. Use this number in the /cid=… interface startup switch. The client id is given by Siemens. It can be found on the XU in the following file:
/usr/madamxenv/project/txp_xu_clients.p
It is an ASCII file.
Appendix D:
Message Logging
The Teleperm XP interface provides extensive run-time operation logging facilities. The logging facility provides the following capabilities:
• Multiple detail levels: low, medium, high, none, all;
• A forced writes option that, when enabled, commits all data to the drive after each write (slows the process significantly);
• A screen logging option that will echo the log entries to the console;
• Ability to append or overwrite existing log;
• Circular log file format with selectable size; and
• A common log file viewer for Windows95 and Windows NT.
Logging Configuration
These options can set or selected using a logging configuration file. The configuration file is a text file with a "loose" format, that is, only lines beginning with a minus sign (-) are treated as parameters, and all parameters are case-insensitive. Any parameters not included in the file will be set to the default values.
The following parameters are supported:
-F = forced writes, either TRUE or FALSE, default=FALSE
-D = detail level, 0 to 9 (see table later in this appendix) default=LOG_MEDIUM
-L = log file name, required
-M = max log file size, in bytes, default=50000
-N = overwrite old log files, either TRUE or FALSE, default=TRUE
-S = enable screen logging, either TRUE or FALSE, default=TRUE
There are no limits on the size or filename of the configuration file. A sample configuration file is shown below.
** Set log level to LOG_MEDIUM
-D2
** Set log filename
-Lc:\temp\test.log
** Enable screen logging
-Strue
** Set max logfile size to 10K
-M10240
Run Time Logging Configuration
The user has the ability to change the operation of the logging facilities at runtime by creating several Logging Tags. The logging tags provide a mechanism for changing the logging configuration during run-time. When the logging configuration needs to be changed, a value can be written to the appropriate tag. For each possible logging configuration change, there is a specific PI tag.
The following table describes the configuration changes that are permitted and the associated tags and values:
|Configuration Parameter |Tag name |Appropriate Values |
|Detail level |L$LOG_LEVEL |9 = All logs (most detailed level) |
| | |8 = No logs |
| | |3 = High detail |
| | |2 = Medium detail |
| | |1 = Low detail |
|Log to screen |L$LOG_SCREEN |0 = off, 1 = log to screen |
|Enable forced writes |L$LOG_FORCED |0 = off, 1 = writes committed immediately |
All logging tags must be configured as output tags of type Integer. No source point parameter is required.
Note that these tags, once they have been created, will override the settings in the configuration file specified via the /L startup switch. If you want to start with the values set in the configuration file, you should suppress the initial output from these tags (to the interface) when the interface starts, by specifying the /sio startup parameter. See the description of /sio for more details.
Appendix E :
Version 2.x Enhancements
Archive Recovery
The interface now supports Archive Recovery. Whenever the interface shuts down a Time Stamp is written to a file named “PITxpAR.Tim”. After a restart the interface automatically starts with the Time Stamp found in this file.
Enabling of Archive Recovery is done by using the /AR switch. You can also use this feature for transferring old data to PI when starting up the interface for the first time. Simply create a Text file in the interface directory, name it “PITxpAR.Tim” and insert the Time Stamp you want the interface to start with (for the correct notation of the Time Stamp see the description of the /AR switch in this manual in chapter “Startup Command File”).
Note: The time expected in and written to “PITxpAR.Tim” is local time.
Sub-Second Events
The interface now passes all events received between 2 scan cycles to PI. If you do not need all of the information received by the XU you can use Exception and Compression point attributes of the PI System to extract the relevant information.
Sub-Second Time Stamps
You can now use the /EXT switch to enable support for EXTended PI-API mode. This will cause the interface to transfer the Sub-Second part of a Time Stamp to PI. If you do not use this switch, the interface will behave like Version 1 and truncate the Sub-Second part of the Time Stamp.
Appendix F:
Microsoft Winsock Errors
Unfortunately, there is currently no routine that translates Windows socket error numbers to text. Therefore, a partial table is included here for reference.
|Error Code|Description |Symbolic Name |
|10004 |A blocking operation was interrupted by a call to |WSAEINTR |
| |WSACancelBlockingCall | |
|10013 |An attempt was made to access a socket in a way forbidden by its |WSAEACCES |
| |access permissions | |
|10014 |The system detected an invalid pointer address in attempting to use a|WSAEFAULT |
| |pointer argument in a call | |
|10022 |An invalid argument was supplied |WSAEINVAL |
|10024 |Too many open sockets |WSAEMFILE |
|10035 |A non-blocking socket operation could not be completed immediately |WSAEWOULDBLOCK |
|10036 |A blocking operation is currently executing |WSAEINPROGRESS |
|10037 |An operation was attempted on a non-blocking socket that already had |WSAEALREADY |
| |an operation in progress | |
|10038 |An operation was attempted on something that is not a socket |WSAENOTSOCK |
|10039 |A required address was omitted from an operation on a socket |WSAEDESTADDRREQ |
|10040 |A message sent on a datagram socket was larger than the internal |WSAEMSGSIZE |
| |message buffer or some other network limit, or the buffer used to | |
| |receive a datagram into was smaller than the datagram itself | |
|10041 |A protocol was specified in the socket function call that does not |WSAEPROTOTYPE |
| |support the semantics of the socket type requested | |
|10042 |An unknown, invalid, or unsupported option or level was specified in |WSAENOPROTOOPT |
| |a getsockopt or setsockopt call | |
|10043 |The requested protocol has not been configured into the system, or no|WSAEPROTONOSUPPORT |
| |implementation for it exists | |
|10044 |The support for the specified socket type does not exist in this |WSAESOCKTNOSUPPORT |
| |address family | |
|10045 |The attempted operation is not supported for the type of object |WSAEOPNOTSUPP |
| |referenced | |
|10046 |The protocol family has not been configured into the system or no |WSAEPFNOSUPPORT |
| |implementation for it exists | |
|10047 |An address incompatible with the requested protocol was used |WSAEAFNOSUPPORT |
|10048 |Only one usage of each socket address (protocol/network address/port)|WSAEADDRINUSE |
| |is normally permitted | |
|10049 |The requested address is not valid in its context |WSAEADDRNOTAVAIL |
|10050 |A socket operation encountered a dead network. |WSAENETDOWN |
|10051 |A socket operation was attempted to an unreachable network |WSAENETUNREACH |
|10052 |The connection has been broken due to keep-alive activity detecting a|WSAENETRESET |
| |failure while the operation was in progress | |
|10053 |An established connection was aborted by the software in your host |WSAECONNABORTED |
| |machine | |
|10054 |An existing connection was forcibly closed by the remote host |WSAECONNRESET |
|10055 |An operation on a socket could not be performed because the system |WSAENOBUFS |
| |lacked sufficient buffer space or because a queue was full | |
|10056 |A connect request was made on an already connected socket |WSAEISCONN |
|10057 |A request to send or receive data was disallowed because the socket |WSAENOTCONN |
| |is not connected and (when sending on a datagram socket using a | |
| |sendto call) no address was supplied | |
|10058 |A request to send or receive data was disallowed because the socket |WSAESHUTDOWN |
| |had already been shut down in that direction with a previous shutdown| |
| |call | |
|10060 |A connection attempt failed because the connected party did not |WSAETIMEDOUT |
| |properly respond after a period of time, or established connection | |
| |failed because connected host has failed to respond | |
|10061 |No connection could be made because the target machine actively |WSAECONNREFUSED |
| |refused it | |
|10064 |A socket operation failed because the destination host was down. |WSAEHOSTDOWN |
|10065 |A socket operation was attempted to an unreachable host |WSAEHOSTUNREACH |
|10067 |A Windows Sockets implementation may have a limit on the number of |WSAEPROCLIM |
| |applications that may use it simultaneously | |
|10091 |WSAStartup cannot function at this time because the underlying system|WSASYSNOTREADY |
| |it uses to provide network services is currently unavailable | |
|10092 |The Windows Sockets version requested is not supported |WSAVERNOTSUPPORTED |
|10093 |Either the application has not called WSAStartup, or WSAStartup |WSANOTINITIALISED |
| |failed | |
|10101 |Graceful shutdown in progress |WSAEDISCON |
|10109 |Class type not found |WSATYPE_NOT_FOUND |
|11001 |Host not found |WSAHOST_NOT_FOUND |
|11002 |Nonauthoritative host not found |WSATRY_AGAIN |
|11003 |This is a nonrecoverable error |WSANO_RECOVERY |
|11004 |Valid name, no data record of requested type |WSANO_DATA |
Appendix G:
Detailed Time Considerations
A time stamp associated with a process value is generated in the AS (Automation System) using local wintertime. This time stamp is being converted to UTC time on the Teleperm XP system (PU - Processing Unit), based on the Time Zone settings on the PU.
Then, this time stamp, being assumed to be correct UTC, is forwarded to the XU. The XU itself simply forwards it to the foreign system requesting it (the PI-TXP-XU Interface).
The Interface uses the function localtime, which expects a UTC time stamp to generate correct local time, taking Time Zone and DST information into account. This time is used in the PI-API functions. Internally in PI, times end up in UTC.
The following notes have been taken at a site in Germany, one hour west from the UK, at Thu May 18 10:56:14 2000 local time.
PI clients were showing process data with correct time stamps.
Settings on the PU (TXP):
$ echo $TZ
MET-1MEST-2,M3.5.0/2:00,M10.5.0/3:00 (This setting can also be found in /etc/TIMEZONE)
$ date
Thu May 18 10:56:14 2000
Settings on the XU: (have no influence)
$ echo $TZ
MET-1MEST-2,M3.5.0/2:00,M10.5.0/3:00
$ date
Thu May 18 10:56:14 2000
Date/Time properties on the PI Server (also acting as PI-API Node running the PI-TXP-XU interface):
May 18 2000 10:56:14 a.m.
Time Zone: (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
The checkbox "Automatically adjust clock for daylight saving changes" is checked.
The TZ environment variable is not set.
What the parts of the TZ information on the PU shown above mean
MET-1MEST-2,M3.5.0/2:00,M10.5.0/3:00
The line consists of three parts, separated by commas.
The time zone names are MET or MEST, respectively. They are just ASCII text. The crucial information is in "-1" and "-2".
The first part, MET-1MEST-2, means that we are sometimes one hour, sometimes two hours ahead of UTC. The exact times when to switch are defined further right in the line, in parts two and three.
Part two, M3.5.0/2:00, means that we are switching from UTC-1 to UTC-2 in March (M3 = Month 3), in the last week (5), on Sunday (day 0), at 2:00.
We switch back from UTC-2 to UTC-1 in October (M10 = Month 10), in the last week (5), on Sunday (day 0), at 3:00.
Note: If the TZ variable on the PU (not XU!) is incorrectly set, i.e. it has wrong offsets from UTC, then the time conversion to UTC in the PU (later transferred to the interface) is done in a wrong way, based on wrong assumptions, and you will have incorrect time stamps in PI.
In case of unexpected offsets in PI time stamps, please check whether the time related settings in the PU are correct. It must have correct local time, and the TZ variable must be set according to your physical location.
Revision History
|Date |Author |Comments |
|07-Jan-99 |JC |First draft |
|12-Oct-99 |AB |Version 2.0 draft |
|19-May-00 |KP |Add detailed time considerations |
|09-Jun-00 |KP |Tags that point to non-existing KKSs don't get "Failed" |
|26-Jun-00 |KP |Point out that time stamps in PITxpAR.Tim are in local time |
|28-Aug-00 |KP |- Correct names of Logging Tags: L$LOG_LEVEL, not $LOG_LEVEL, etc.|
| | |- Explicitly document /sio uniint startup parameter |
| | |- Include Microsoft Winsock errors in the manual |
| | |- document /cyc=… switch |
|12-Jun-01 |KP |Version 2.0.1.8 |
| | |Remove remark that PITxpAR.Tim must reside in winnt\system32 when |
| | |the interface is run as service. Now, in all cases, this file must|
| | |reside in the interface directory. The path is derived from the |
| | |interface executable path. |
|15-Nov-01 |KP |Added explanation of client id (/cid) |
|23-Apr-01 |KP |Use Interface Manual Skeleton Version 1.11 |
|23-Jul-02 |CG |Formatting; edited text about sub-second timestamps; removed |
| | |requirement in installation checklist for On & Off digital states;|
| | |installed filenames have changed; fixed page numbers; included |
| | |more detailed .bat file |
-----------------------
[pic]
Status of the Interface Service
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- why the school system is bad
- is the education system broken
- the school system is broken
- the education system is failing
- why the education system is good
- changing the school system essay
- the college system is broken
- calculator with the pi button
- how to cleanse the lymphatic system naturally
- the planets of the solar system song
- the organs in the circulatory system include
- label the conduction system of the heart