PI Bailey Sem API Interface Manual
PI Bailey Sem API Interface Manual
Interface to the PI System
Windows Version 1.4.2.0
How to Contact Us
|OSIsoft, Inc. |Worldwide Offices |
|777 Davis St., Suite 250 |OSIsoft Australia |
|San Leandro, CA 94577 USA |Perth, Australia |
| |Auckland, New Zealand |
|Telephone |OSI Software GmbH |
|(01) 510-297-5800 (main phone) |Altenstadt, Germany |
|(01) 510-357-8136 (fax) |OSI Software Asia Pte Ltd. |
|(01) 510-297-5828 (support phone) |Singapore |
| |OSIsoft Canada ULC |
|techsupport@ |Montreal, Canada |
| |OSIsoft, Inc. Representative Office |
|Houston, TX |Shanghai, People’s Republic of China |
|Johnson City, TN |OSIsoft Japan KK |
|Mayfield Heights, OH |Tokyo, Japan |
|Phoenix, AZ |OSIsoft Mexico S. De R.L. De C.V. |
|Savannah, GA |Mexico City, Mexico |
|Seattle, WA | |
|Yardley, PA | |
|Sales Outlets and Distributors |
|Brazil |South America/Caribbean |
|Middle East/North Africa |Southeast Asia |
|Republic of South Africa |South Korea |
|Russia/Central Asia |Taiwan |
|WWW. |
|OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI ProcessBook, Sequencia, |
|Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in this book that are known to be trademarks or service marks |
|have been appropriately capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the |
|property of its owner and use herein in no way indicates an endorsement, recommendation, or warranty of such party’s |
|products or any affiliation with such party of any kind. |
|RESTRICTED RIGHTS 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 |
|Unpublished – rights reserved under the copyright laws of the United States. |
| |
|© 1997-2008 OSIsoft, Inc. PI_BaSemAPI.doc |
Table of Contents
Introduction 1
Reference Manuals 1
Supported Features 2
Diagram of Hardware Connection 5
Principles of Operation 7
Installation Checklist 9
Windows 9
Interface Installation on Windows 11
Naming Conventions and Requirements 11
Interface Directories 11
The PIHOME Directory Tree 11
Interface Installation Directory 12
Interface Installation Procedure 12
Installing the Interface as a Windows Service 12
Installing Interface Service with PI ICU 12
Installing the Interface Service Manually 14
Testing Connection to ICI 17
Digital States 19
PointSource 21
PI Point Configuration 23
Point Attributes 23
Tag 23
PointSource 23
PointType 23
Location1 23
Location2 24
Location3 24
Location4 24
Location5 24
InstrumentTag 25
ExDesc 25
Scan 26
SourceTag 26
Shutdown 27
Output Points 27
Trigger Method 1 (Recommended) 27
Trigger Method 2 28
Bailey Point Types 29
Supported Input Point Types (Bailey Data to PI) 29
Output Point Types (PI Data to Bailey) 30
Detailed Description of Bailey Point Types 31
Tag Configuration from Bailey Database 40
Performance Point Configuration 43
I/O Rate Tag Configuration 45
Monitoring I/O Rates on the Interface Node 45
Configuring I/O Rate Tags with PI ICU (Windows) 45
Configuring I/O Rate Tags Manually 47
Configuring the PI Point on the PI Server 47
Configuring on the Interface Node 47
Startup Command File 49
Configuring the Interface with PI ICU 49
Basemapi Interface Page 51
General Tab 52
Failover / Debug Tab 54
Command-line Parameters 56
Sample blysem.bat File 61
Interface Node Clock 63
Windows 63
Security 65
Windows 65
Starting / Stopping the Interface on Windows 67
Starting Interface as a Service 67
Stopping Interface Running as a Service 67
Buffering 69
Configuring Buffering with PI ICU (Windows) 69
Configuring Buffering Manually 72
Example piclient.ini File 74
Restrictions and Other Information 75
Exclusive Control of ICI Device 75
Interface and semAPI Version Compatibility 75
OSM01 Not Recommended 75
semAPI 1.2 Disconnection Problems 75
Timeout in the Middle of the Connect Point Command 75
Adaptec 2940 U SCSI, 50-pin Card with the ICI03 76
Install the semAPI Device Driver as a Service 76
Invalid Security Device Present 76
Appendix A: Error and Informational Messages 79
Message Logs 79
Messages 79
System Errors and PI Errors 79
Revision History 81
Introduction
The PI Bailey semAPI interface provides bi-directional data transfer between a PI system and a Bailey Infi90 instrument system. The interface runs on Windows-Intel computers.
This interface was developed to take advantage of Bailey’s semAPI library. The semAPI software handles all of the Bailey communications protocol and thereby makes it possible for the PI interface to communicate to Bailey ICI modules via a variety of transport methods (serial, Ethernet, and SCSI).
Note: Currently, interface version 1.3 and greater is compatible with semAPI version 2.0 and greater. Interface version 1.2 is compatible with semAPI version 1.2. For version compatibility and other semAPI issues, see the restriction section at the end of the manual.
The new features introduced in version 1.4.2.0 of the interface consist of Disconnected Startup, Multi-Character Point Source, UniInt Health Tags including SetDeviceStatus and are only supported by the version built for use with semAPI 2.0 and higher (blysem.exe).
Communication using the semAPI software requires that the customer purchase the Bailey semAPI software and computer interface module as well as the PI interface software.
The interface works with the following Bailey computer interface modules:
1. INICI03, INFI-NET to Computer Interface.
2. HNCC, Harmony Network Communications Coupler
The INICI03 supports serial and SCSI connection to the host computer. The module supports a maximum of 30,000 points. Each instance of the interface connects to one computer interface module.
Bailey has come out with an ICI12 communications module. This module only supports a serial connection to the host computer and per Bailey; communication is through use of the Bailey semAPI. The PI Bailey semAPI interface should be compatible with this module but we have not yet had a chance to test it.
Reference Manuals
OSIsoft
• UniInt Interface User Manual
• PI Data Archive Manual
• PI API Installation Instructions
Vendor
• SemAPI Instruction Manual
• Function Code Application Manual
Supported Features
|Feature |Support |
|Part Number |PI IN-BA-SEMAP-NTI |
|*Platforms |Windows 2000/XP/2003 Server |
|APS Connector |Yes |
|Point Builder Utility |No |
|ICU Control |Yes |
|PI Point Types |Float32 / Float16 / Digital / Int16 / Int32 / |
| |string |
|Sub-second Timestamps |No |
|Sub-second Scan Classes |No |
|Automatically Incorporates PI Point Attribute Changes |Yes |
|* Exception Reporting |Done by Bailey System |
|Outputs from PI |Yes |
|Inputs to PI: Scan-based / Unsolicited / Event Tags |Unsolicited |
|Supports Questionable Bit |No |
|Supports Multi-character PointSource |Yes |
|Maximum Point Count |30,000 |
|* Uses PI SDK |No |
|PINet String Support |Yes |
|* Source of Timestamps |PI server |
|History Recovery |No |
|* UniInt-based |Yes |
|* Disconnected Startup |Yes |
|* SetDeviceStatus |Yes |
|* Failover |Yes |
|Vendor Software Required on PI Interface Node |Yes |
|* Vendor Software Required on Foreign Device |Yes |
|* Vendor Hardware Required |Yes |
|Additional PI Software Included with Interface |No |
|* Serial-Based Interface |Yes |
See paragraphs below for further explanation.
Platforms
The Interface is designed to run on the above mentioned Microsoft Windows operating systems. Because it is dependent on vendor software, newer platforms may not yet be supported.
Please contact OSIsoft Technical Support for more information.
Exception Reporting
The Bailey System sends data to the PI interface by exception. Hence, by default, the interface does not apply the PI tag’s exception reporting on top of the Bailey events.
Uses PI SDK
The PI SDK and the PI API are bundled together and must be installed on each PI Interface node. This Interface does not specifically make PI SDK calls.
Source of Timestamps
The interface keeps tracks of the current time of the PI server. It applies that time to the timestamp of the exception-based event sent from Bailey.
Failover
The interface supports failover to provide redundant data collection on both VMS platform and on Windows platform. The failover setup involves two instances of the interface, one in primary data collection mode and one in secondary or standby data collection mode. Each interface communicates to a separate ICI module. The secondary interface would monitor the ICI module status of the primary interface. If the primary ICI module is not in execute mode, the secondary interface will start collecting data. When the primary ICI module comes back on-line, the secondary interface would go back to standby mode.
Since the failover mechanism depends on the ICI module, do not set the ICI watch dog timer to 0 for the primary interface. Otherwise, the ICI module will continue to be in execute mode even if the primary interface stops communicating to the ICI module.
When installing the interface in failover setup, test the failover configuration by stopping the primary interface program and verifying that the secondary interface picks up data collection. If the secondary interface cannot read the module status of the primary ICI module within five minutes of the interface startup, the interface program will terminate, assuming the PCU address provided by the command file is incorrect. This safety check is designed to avoid having both instances of the interface collecting data at the same time.
UniInt-based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by developers, and is integrated into many interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of OSIsoft’s 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 Interface User Manual is a supplement to this manual.
Disconnected Start-Up
The PI Bailey semAPI interface is built with a version of UniInt that supports disconnected start-up. Disconnected start-up is the ability to start the interface without a connection to the PI server. This functionality is enabled by adding /cachemode to the list of start-up parameters or by enabling disconnected startup using the ICU. Refer to the UniInt Interface User Manual for more details on UniInt Disconnect startup.
SetDeviceStatus
New functionality added to support Health tags. The Health tag with the point attribute Exdesc = [UI_DEVSTAT], is used to represent the status of the source device. The following events can be written into the tag:
a) “1 | Starting” – the interface is starting.
b) “Good” – the interface is properly communicating and reading data from the Bailey semAPI system.
c) “2 | Connected/No data | ICI Offline” – this event represents that the Bailey semAPI system is offline.
d) “3 | 1 device(s) in error | Not connected to semAPI” – This event represents a failure to communicate with the Bailey semAPI system.
e) “4 | Intf Shutdown” – the interface is stopped.
Please refer to the UniInt Interface User Manual.doc for more information on how to configure UniInt health points.
Vendor Software Required
The interface needs the Bailey semAPI Runtime, Supervisory Control, or Development Kit to be installed on the interface node.
Vendor Hardware Required
The interface connects to ICI03 via SCSI or serial connection.
Serial Based Interface
The semAPI software handles all of the Bailey communications protocol and thereby makes it possible for the PI interface to communicate to Bailey ICI modules via a variety of transport methods (serial, Ethernet, and SCSI).
Server class machines often have inferior serial ports. Server class machines are not required for most interfaces and should not be used, especially not when serial port connections are required.
Diagram of Hardware Connection
[pic]
Principles of Operation
The PI Bailey semAPI interface supports the major Bailey point types for reading data from the Bailey Infi90. It also supports data output to the Bailey Infi90 system via the Analog and Digital Report functions.
All data read by the interface come from the Bailey system as exception reports. Bailey generates an exception report whenever the value or the status changes, or when a specific amount of time has elapsed since the last report (exception maximum time). Data is output to Bailey with any change in the related value or the event time in PI.
The most common network topology used by the interface is peer-to-peer. With this approach, the interface process and semAPI software reside on the same computer. The computer is physically connected via serial, SCSI or Ethernet cable to a Bailey communications module, which is connected to the Bailey Infi90 network.
At startup, the interface retrieves all the PI tags for the specified point source and processes only those tags with matching ICI number. The interface builds the tags into a sequential list keyed by list index position.
The interface attempts to initiate communication with the Bailey communications modules via calls to Bailey semAPI libraries. These, in turn, establish a device driver process to talk to the Bailey communications module. The Bailey device driver handles physical and low-level protocol communication.
Via the semAPI call, the interface then establishes the tags in the Bailey communications module point table. After all points are established and connected, the interface enters the data collection phase.
The interface keeps reading exception data from the Bailey communications module until the maximum number of exceptions specified in the interface startup parameters have been reached or ten read exception calls have been made.
The interface checks for output events to be processed. Whenever output tags are triggered within PI, data will be sent to the Bailey system.
If more than two minutes have been passed since the last PI point database check, the interface will check for point database changes. Tags are added, modified, or deleted from the interface if necessary.
When the interface encounters ten consecutive communication errors with the ICI, the interface will attempt to clear the error by going through the error recovery procedure. The error recovery starts with disconnecting from the semAPI. Then the interface goes back to the startup phase of the operation, as described in the beginning of the manual. This auto error recovery feature normally clears problems caused by line noise. However, hardware failure will still require human intervention.
Note: Since the ICI point table can only buffer one exception for each point, it is possible for the interface to miss exception reports for Bailey tags that are changing values too rapidly. For example, if the control engineer has configured an RCM to reset itself after the operator has set the RCM to the ‘on’ state, the PCU module will generate two exception reports within a second. Most likely, the interface will not be able to catch the first exception report before it is over-written by the second exception on the ICI module.
Installation Checklist
For those users who are familiar with running PI data collection interface programs, this checklist helps get the PI Bailey semAPI interface running. For readers who are not familiar with PI interfaces, return to this section after reading the rest of the manual in detail.
Windows
1. Install Bailey semAPI software as per Bailey Document E96-827-1, installation section.
2. Define a logical ICI for each ICI module with the program ICICONF.
3. Install the PI Interface Configuration Utility (which installs PI SDK and PI API)
4. Verify that the PI API has been installed.
5. Install the interface.
6. After configuring the logical ICI, always test the communication to the ICI using the TALK90 program. TALK90 is an important communication trouble shooting tool. If TALK90 is having a problem communicating to the ICI module, the PI interface cannot be expected to function properly. At least execute command 100(connect to ICI) and 19(restart ICI). Other commands to try are 43 (read time) and 84 (establish import point). Command 84 is on the second page of commands.
7. Define digital states for digital tags.
8. Choose a point source.
9. Configure PI points.
Location1 is the interface instance (Use the logical ICI number).
Location2 for inputs is Loop Number * 256 + PCU Number
for outputs is the CIU index.
Location3 for inputs is Module Number
for outputs is always 1.
Location4 for inputs is the Block Number
for outputs is always 1.
Location5 is the Bailey point type.
ExDesc uses /BLY=x for extended attributes.
InstrumentTag is not used.
10. Configure the interface using the PI ICU utility or edit startup command file manually. It is recommended to use PI ICU whenever possible.
11. Configure I/O Rate tag.
12. Set interface node clock.
13. Set up security.
14. Start the interface without buffering.
15. Verify data.
Stop interface, start buffering, start interface.
Interface Installation on Windows
OSIsoft recommends that interfaces be installed on PI Interface Nodes instead of directly on the PI Server node. A PI Interface 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 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 Interface Node (once again, see the PI API 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 Interface 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 install the interface as an automatic service that depends on the PI Update Manager and PI Network Manager services. 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 Interface User Manual for special procedural information.
Naming Conventions and Requirements
In the installation procedure below, it is assumed that the name of the interface executable is blysem.exe and that the startup command file is called blysem.bat.
When Configuring the Interface Manually
When configuring the interface manually 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, blysem1.exe and blysem1.bat would typically be used for interface number 1, blysem2.exe and blysem2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line parameters in a file that has the same root name.
Interface 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 %windir% directory. A typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=c:\pipc
The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
Place all copies of the interface into a single directory. The suggested directory is:
PIHOME\Interfaces\blysem\
Replace PIHOME with the corresponding entry in the pipc.ini file.
Interface Installation Procedure
The interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000. To install, run the BaSemAPI_x.x.x.x.exe installation kit.
Note: Two executables are delivered with this interface. Copy the Blysem_v122.exe to blysem.exe if using semAPI version 1.2 and leave blysem.exe if using semAPI version 2.0 and higher.
Installing the Interface as a Windows Service
The PI Bailey semAPI Interface service can be created, preferably, with the PI Interface Configuration Utility, or can be created manually.
Installing Interface Service with PI ICU
The PI Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service:
[pic]
Service Configuration
Service name
The Service name box shows the name of the current interface service. This service name is obtained from the interface executable.
ID
This is the service id used to distinguish multiple instances of the same interface using the same 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 OSIsoft suite of products.
Log on as
The Log on as text box shows the current “Log on as” Windows User Account of the interface service. If the service is configured to use the Local System account, the Log on as text box will show “LocalSystem.” Users may specify a different Windows User account for the service to use.
Password
If a Windows User account is entered in the Log on as text box, then a password must be provided in the Password text box, unless the account requires no password.
Confirm Password
If a password is entered in the Password text box, then it must be confirmed in the Confirm Password text box.
Startup Type
The Startup Type indicates whether the interface service will start automatically or needs to be started manually on reboot.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, interface services are set to start automatically.
Dependencies
The Installed services list is a list of the services currently installed on this machine. Services upon which this Interface is dependent should be moved into the Dependencies list using the [pic] button. For example, if PI API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left. To remove a service from the list of dependencies, use the [pic] button, and the service name will be removed from the “Dependencies” list.
When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.
Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.
[pic] - Add Button
To add a dependency from the list of Installed services, select the dependency name, and click the Add button.
[pic] - Remove Button
To remove a selected dependency, highlight the service name in the Dependencies list, and click the Remove button.
The full name of the service selected in the Installed services list is displayed below the Installed services list box.
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
To Start or Stop an interface service, use the Start button [pic] and a Stop button [pic] on the ICU toolbar. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.
The status of the Interface service is indicated in the lower portion of the PI ICU dialog.
[pic]
Installing the Interface Service Manually
One can get help for installing the interface as a service at any time with the command:
blysem.exe –help
Change to the directory where the blysem.exe executable is located. Then, consult the following table to determine the appropriate service installation command.
|Windows Service Installation Commands on a PI Interface Node or a PI Server Node |
|with Bufserv implemented |
|Manual service |blysem.exe –install –depend “tcpip bufserv” |
|Automatic service |blysem.exe –install –auto –depend “tcpip bufserv” |
|*Automatic service with service|blysem.exe –serviceid X –install –auto –depend “tcpip bufserv” |
|id | |
|Windows Service Installation Commands on a PI Interface Node or a PI Server Node |
|without Bufserv implemented |
|Manual service |blysem.exe –install –depend tcpip |
|Automatic service |blysem.exe –install –auto –depend tcpip |
|*Automatic service with service|blysem.exe –serviceid X –install –auto –depend tcpip |
|id | |
*When specifying service id, the user must include an id number. It is suggested that this number correspond to the interface id (/id) parameter found in the interface .bat file.
Check the Microsoft Windows services control panel to verify that the service was added successfully. The services control panel can be used at any time to change the interface from an automatic service to a manual service or vice versa.
Testing Connection to ICI
Bailey created a connection test utility called Talk90. This utility was distributed with the runtime kit in the past, but as of Bailey semAPI 2.0, it is no longer distributed in the runtime kit. It is still distributed with the supervisory control kit.
Running the test utility looks similar to this:
|1-Establish Point |2-Establish Report |3-Output Miscellaneous |
|4-Connect Point List |5-Disconnect Point List |6-Read Value List |
|7-Read Status List |8-Read Exceptions |10-Output Value |
|11-Output Status |12-Module Operation |13-Read Block |
|14-Read Next Block |15-Read Default Block |16-Write Block |
|17-Tune Block |18-Delete Block |19-ICI Restart |
|20-Read Block Output |21-Read Misc Status List |22-Read Misc Stat Excep |
|23-Disestablish Point |24-Read Excep Report Spec |26-Read Problem Report |
|27-Demand Module Status |28-Regenerate Specs |29-Output General Msg |
|33-Set ICI Status |34-Read Work Flag |35-Read Value Group |
|36-Disconnect Point Group |37-Connect Point Group |38-Read Status Group |
|39-Read Misc Status Group |40-Output Value Group |41-ICI Callup |
|42-ICI Hangup |43-Read System Time/Date |44-ICI Online/Offline |
|45-Output Misc Group |46-Read Ext Prob Report |47-Output Status Group |
|100-Connect to ICI |101-Disconnect from ICI |102-ICI Management |
|103-Quick Commands |104-Get Exceptions |105-Enet Commands |
|106-Block I/O Commands |107-DBUS Commands |108-Firmware Commands |
|109-Misc. Module Info |110-Decode Error Number | |
|777-Repeat Last Command |888-Next Page |999-Exit |
Option: 100
Logical ICI: 1
Timeout is in seconds.
Timeout: 5
Valid Users:
0 = SHARED
1 = EXCLUSIVE
Type of User: 1
Tagnames: 0 = DO NOT RETURN TAGNAMES, 1 = RETURN TAGNAMES
Tagnames: 0
Option 100 should be used to make sure that at least a connection to the ICI can be made. If the connection is not successful, Bailey should be contacted.
Digital States
For more information regarding Digital States, refer to the Data Archive Manuals.
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 Server manuals.
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.
A PI tag for the Station Status is normally defined as a digital point. A set should be defined with these states in this order:
• Manual (unlocked)
• Auto (unlocked)
• Cascade (unlocked)
• Digital Station Failure
• Manual (locked)
• Control station bypassed
• Auto (locked)
• Cascade (locked)
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. Digital States 193-320 are reserved for OSIsoft applications.
For more information regarding Digital States, refer to the Data Archive Manuals.
System Digital States Written to Tags
During normal operation, the interface may set the status of PI tags to a system digital state under the following circumstances:
3. All tags are set to Intf Shut at interface shutdown, or the state specified in the /stopstat=state parameter.
4. When the interface fails to establish a point in the ICI module, the related PI tags are set to the digital state Configure.
5. When a tag is removed from the interface, the tag status is set to No Data.
6. If there are 10 sequential failures in obtaining exception data from Bailey semAPI, the interface will set all tags to No Data.
7. An input tag is set to Bad Input if Bailey’s BAD QUALITY flag is set or if a digital value is out of range for that tag.
8. An output tag is set to Bad Output if the PI value is a digital state code such as Shutdown or OverRange.
PointSource
The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For example, the string Bailey may be used to identify points that belong to the Bailey semAPI Interface. To implement this, the PointSource attribute would be set to Bailey for every PI Point that is configured for the Bailey semAPI Interface. Then, if /ps=Bailey is used on the startup command-line of the Bailey semAPI Interface, the Interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of Bailey. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps parameter.
Case-sensitivity for PointSource Attributes
In all cases, the point source character that is supplied with the /ps command-line parameter is not case sensitive. That is, /ps=B and /ps=B are equivalent. One only needs to be careful with the case of the PointSource during point definition, and only if the interface will be running on a PINet node communicating to a PI 3 Server.
Reserved Point Sources
Several subsystems and applications that ship with PI are associated with default PointSource characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Do not use these PointSource characters or change the default point source characters for these applications. Also, if a PointSource character is not explicitly defined when creating a PI point; the point is assigned a default PointSource character of Lab (PI 3). Therefore, it would be confusing to use Lab as the PointSource character for an interface.
Note: Do not use a point source character that is already associated with another interface program. However it is acceptable to use the same point source for multiple instances of an interface.
PI Point Configuration
The PI point is the basic building block for controlling data flow to and from the PI Server. A single point is configured for each measurement value that needs to be archived.
Point Attributes
Use the point attributes below to define the PI Point configuration for the Interface, including specifically what data to transfer.
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.
Length
The length of the Tag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |24 |
|1.6 or higher |Below 3.4.370.x |24 |
|Below 1.6 |3.4.370.x or higher |24 |
|Below 1.6 |Below 3.4.370.x |24 |
PointSource
The PointSource is a unique single or multiple character string that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps=x command-line parameter and the PointSource section.
PointType
Typically, device point types do not need to correspond to PI point types. For example, integer values from a device can be sent to floating point or digital PI tags. Similarly, a floating-point value from the device can be sent to integer or digital PI tags, although the values will be truncated.
Float16, float32, int16, int32, digital, and string are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for NT and UNIX.
Location1
Location 1 is the interface number.
It is common for the interface number to match the logical ICI Number used by the Bailey semAPI software; where the logical ICI Number is configured via the utility: [ICI.EXE]ICICONF.
Location2
Input Points
Location 2 is the Infi90 Loop Number * 256 + the Infi90 PCU (Node) Number.
Output Points
Location 2 is the CIU index where the interface writes data. Assign a unique CIU index for each output point. This index is used to compute the block number when configuring Infi90 PCU modules to read the output:
Block = index
Module = 2
PCU (Node) = node address of the ICI
For example, a PI tag with CIU index number 49 connecting to an ICI whose node address is 25 could be read from another node on the Bailey Loop with an analog input block (FC26) by:
PCU-Module-Block = 25-2-49
Index 2049 can be read as PCU-Module-Block of 25-2-2049.
Location3
Input Points
Location3 is the Infi90 Module Number for inputs.
Output Points
For outputs, Location3 must be 1.
Location4
Input Points
Location4 is the Infi90 Block Number for inputs.
For Station Blocks, use the block number of the Station block for all parameters for that block. A process variable, setpoint, mode, and control output would all have the same block number as far as the ICI is concerned. They would have different Infi90 point types (Location 5).
Output Points
For outputs, Location4 must be 1.
Location5
Location5 is the Bailey point type. This defines the kind of Bailey point sending or receiving the data. See list of available types in the Bailey Point Types section.
InstrumentTag
The PI Bailey SemAPI interface does not use the InstrumentTag attribute.
ExDesc
Length
The length of the Extended Descriptor field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |80 |
|Below 1.6 |3.4.370.x or higher |80 |
|Below 1.6 |Below 3.4.370.x |80 |
This is the extended descriptor attribute, which is limited to 80 characters.
Some Bailey function types provide multiple fields of information (e.g. RCMs, Device Drivers). It is possible to retrieve any subset or all of these fields of information into a single PI tag or into multiple PI tags. The fields can be retrieved into a single PI tag in any order. The user specifies the field number and the extraction order by using the keyword /BLY=# or /BLY=#,#,# in the Extended Descriptor of the PI tag. Data retrieved in this manner are referred to as extended attributes in the rest of this manual. Here are a few examples:
Case 1: Single PI Tag Retrieving Multiple Fields from a DAANG Block
To get the fields in this specific order, Auto/Manual, Alarm Level, High Alarm, Low Alarm, High Deviation Alarm, Location5 would be 29 and the following configuration would be added to the extended descriptor: /BLY=7,4,2,3,17 where the field definitions are as follows:
|Data Field |Definition |
|7 |Auto/Manual |
|4 |Alarm Level |
|2 |High Alarm |
|3 |Low Alarm |
|17 |High Deviation Alarm |
The resultant value would be built from the value in the data field or fields. Additionally, the place value assigned to each data piece depends upon its position in the extended descriptor parameter list. Thus, assuming that the Alarm Level has a value of 3, and the High Deviation Alarm is ON, the value sent to the PI tag would be as follows:
|Data Field |Field Length |Bailey Value |Position in PI Value |PI Value |
|Auto/Manual |1 |0 |bit 0 |0 |
|AlarmLeve1 |2 |3 |bits 1, 2 |6 |
|High Alarm |1 |0 |bit 3 |0 |
|Low Alarm |1 |0 |bit 4 |0 |
|High Deviation Alarm |1 |1 |bit 5 |32 |
|Value for this PI Tag | | |00100110 |38 |
The sum of the bit length for all the extracted fields cannot exceed 15 for each tag. An error will be printed in the log file if more than that is specified. Specific data fields may be duplicated within a single tag.
Case 2: Multiple PI Tags for this Bailey Block Address and Point Type
Each tag retrieves single or multiple fields from a DAANG block. The location parameters for each of these tags will be the same; however, they will have different extended descriptors. For example, tag 1 might have an extended descriptor /BLY=7,17, and tag 2 might have an extended descriptor, /BLY=4,2,3.
Note: Even though there are multiple PI tags, the interface will only retrieve the data once from Bailey and push the correct values into the correct tags.
Performance Points
Performance Points are not supported by this interface.
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.
SourceTag
Source Tag is used only for the output points. It is the PI tag from which the output points get the values to send to Infi90. For example, the source tag can be a performance equation calculation tag or a lab (manual input) tag.
When the source tag is not defined for an output point, the interface will get the output value from the output tag snapshot. In this case, the user is responsible for updating the value directly.
Note: The source tag should have the same PI point type as the output tag in order to assure that the correct value is sent to Bailey. However, it is not necessary that the tag be a real (integer or digital) type in order to send analog or digital data to Bailey, respectively.
Shutdown
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 command-line parameter is specified.
One can disable SHUTDOWN events from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Data Archive for NT and UNIX.
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 shutdown, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.
Output Points
Output points control the flow of data from the PI Data Archive to any destination that is external to the PI Data Archive, such as a PLC or a third-party database. For example, to write a value to a register in a PLC, one would use an output point. Each interface has its own rules for determining whether a given point is an input point or an output point. There is no de facto PI point attribute that distinguishes a point as an input point or an output point.
Outputs are triggered for UniInt-based interfaces. That is, outputs are typically not scheduled to occur on a periodic basis. There are two mechanisms for triggering an output.
Trigger Method 1 (Recommended)
For trigger method 1, a separate trigger point must be configured. The output point must have the same point source as the interface. The trigger point can be associated with any point source, including the point source of the interface. Also, the point type of the trigger point does not need to be the same as the point type of the output point.
The output point is associated with the trigger point by setting the SourceTag attribute of the output point equal to the tag name of the trigger point. An output is triggered when a new value is sent to the Snapshot of the trigger point. The new value does not need to be different than the previous value that was sent to the Snapshot to trigger an output, but the timestamp of the new value needs to be more recent than the previous value. If no error is indicated, then the value that was sent to the trigger point is also written to the output point. If the output is unsuccessful, then an appropriate digital state that is indicative of the failure is usually written to the output point. If an error is not indicated, the output still may not have succeeded because the interface may not be able to tell with certainty that an output has failed.
Trigger Method 2
For trigger method 2, a separate trigger point is not configured. To trigger an output, write a new value to the Snapshot of the output point itself. The new value does not need to be different than the previous value to trigger an output, but the timestamp of the new value must be more recent than the previous value.
Trigger method 2 may be easier to configure than trigger method 1, but trigger method 2 has a significant disadvantage. If the output is unsuccessful, there is no tag to receive a digital state that is indicative of the failure, which is very important for troubleshooting.
Bailey Point Types
Analog data from Bailey should be defined in the PI system as a float. If the Quality of the value is good, the floating-point value from Bailey is stored in the PI System. If the passed Quality is bad, the digital code for Bad Input is stored for that tag. Other Bailey status information such as alarm fields are not used by the interface except in the case of extended attributes specified in the extended descriptor.
If a Bailey analog point is defined as a digital point in the PI system, the value is interpreted as the offset from the digital starting code of the point. Any value out of the range of 0 and the number of digital states minus one is stored as Bad Input.
For most point types, the interface supports the retrieval of additional attributes from the exception reports. Thus, the user can define more than one PI tag pointing to the same Bailey block and extract different pieces of information from the same exception report.
For all Bailey data, the interface always checks the Quality of the Bailey value. If the Quality is bad, no further processing is done and the digital state Bad Input is put into the PI value. This Quality check also applies to PI tags retrieving extended attributes from the Bailey values.
Note: If the Bailey Quality is bad, the interface will not retrieve other fields or fields within the Bailey Exception Report.
The supported input Bailey point types are listed in the following tables and further described below.
Supported Input Point Types (Bailey Data to PI)
|Bailey |Description |Data Type |Bailey |OIS Type Name |Extended Attribute |
|Point Type | | |Function Code | | |
|1 |Process Variable |A |Note 1 |Station |No |
|2 |Set Point Read |A |Note 1 |Station |No |
|3 |Control Output Read |A |Note 1 |Station |No |
|4 |Ratio Index Read |A |80, 23 |Station |No |
|5 |Analog Read |A |30 |Analog |Yes |
|6 |Station Status |D |Note 1 |Station |Yes |
|7 |Digital Read |D |45 |Digital |No |
|14 |Module Status |D | | |No |
|15 |RCM Read |D |62, Note 3 |RCM |Yes |
|19 |RMSC Read |A |68 |RMSC |Yes |
|21 |4-byte Analog Read |A | | |Yes |
|29 |DAANG |A | | |Yes |
|30 |ASCII string |S | | |No |
|51 |MSDD |D |129 | |Yes |
|52 |DD |D |123 | |Yes |
|53 |RMC |D | | |Yes |
|54 |DADIG |D | | |Yes |
|60 |Text Selector |I | | |No |
|70 |Harmony Analog Input |A |Note 2 | |Yes |
|71 |Harmony Analog Output|A |Note 2 | |Yes |
|72 |Harmony Digital Input|D |Note 2 | |Yes |
|73 |Harmony Digital |D |Note 2 | |Yes |
| |Output | | | | |
Note 1: For Station points, the Bailey function code can be 80, 21, 22 or 23. Use the same Bailey address for the PV, SP and CO of the station point.
Note 2: The Harmony point types (70-73) are supported only for interface version 1.3 and greater running on Windows.
Note 3: The Bailey point type specifications for this interface are almost the same as those in the PI BA-I90, the serial communication based interface. For those customers who will convert from the serial based Infi90 interface to the semAPI, NO changes to the location parameters are required except for Bailey point type 15. The serial based interface uses a point type of 15 to get data from RCM, MSDD, and DD point types. The semAPI interface uses 15 for RCM, 51 for MSDD, and 52 for DD point types.
Output Point Types (PI Data to Bailey)
|Bailey Point Type |Description |Data Type |Extended Attributes |
|12 |Analog Report |Analog |No |
|13 |Digital Report |Digital |No |
|22 |4-byte Analog Report |Analog |No |
After the output tags are defined in PI, the data can be read from the ICI into any Bailey Node as a Analog point or a Digital Point. Use function code 26 to read point type 12 (Analog Report). Use function code 42 to read point type 13 (Digital Report). The address used in the function code 26 or 42 can be calculated from the Location2 parameter of the PI tag as described in the Location2 point attribute section.
Detailed Description of Bailey Point Types
Process Variable (Bailey Point Type 1)
This is the process variable of a control Station block (Bailey function code 80, 21, 22 or 23). The block address should be that of the Station block. The alarm attributes for the station can be accessed through the extended attributes of the station status. See point type 6.
Setpoint Read (Bailey Point Type 2)
This is the set point of a control Station block. See point type 1.
Control Output Read (Bailey Point Type 3)
This is the control output of a control Station block. See point type 1.
Ratio Index Read (Bailey Point Type 4)
This is the ratio index of a ratio control Station block. See point type 1.
Analog Read (Bailey Point Type 5)
This gets the value from an analog block (function code 30) on the Infi90 system.
The status of the analog value can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (q) |
|2 |2 |Limit Alarm (la) |
|3 |2 |Deviation Alarm (da) |
|4 |1 |Red Tagged Status (rt) |
|5 |1 |Point Tracking (pt) |
|6 |1 |Calibration (ccv) |
Station Status (Bailey Point Type 6)
By default, the interface extracts only the fields indicating the Station mode and combines them into an eight-state status, even though the Station status contains other information.
A PI tag for the Station Status is normally defined as a digital point in the PI system.
• Manual (unlocked)
• Auto (unlocked)
• Cascade (unlocked)
• Digital Station Failure
• Manual (locked)
• Control Station Bypassed
• Auto (locked)
• Cascade (locked)
Station status is processed one field at a time according to the following order. If any field is set, the evaluation is stopped at that field and the digital state is set.
Processing Order for Station Status
IF (QUALITY field is set) THEN
Tag Digital State is BAD INPUT
ELSE IF (BYPASS field is set) THEN
Tag Digital State is Control Station Bypassed
ELSE IF (DIGITAL STATION FAILURE field is set) THEN
Tag Digital State is Digital Station Failure
ELSE IF (CASCADE RATIO field is set) THEN
IF (MANUAL INTERLOCK field is set) THEN
Tag Digital State is Cascade (locked)
ELSE
Tag Digital State is Cascade (unlocked)
ELSE IF (AUTO MODE field is set) THEN
IF (MANUAL INTERLOCK field is set) THEN
Tag Digital State is Auto (locked)
ELSE
Tag Digital State is Auto (unlocked)
ELSE IF (MANUAL INTERLOCK field is set) THEN
Tag Digital State is Manual (locked)
ELSE
Tag Digital State is Manual (unlocked)
Also, the following attributes of the Station Status may be accessed through the use of the extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (q) |
|2 |2 |Limit Alarm (la) |
|3 |2 |Deviation Alarm (da) |
|4 |1 |Red Tagged Status (rt) |
|5 |1 |Point Tracking (spt) |
|6 |1 |Station Bypass (byp) |
|7 |1 |Manual Interlock (mi) |
|8 |1 |Output Tracking (ot) |
|9 |1 |Digital Station Failure (dsf) |
|10 |1 |Computer OK (cok) |
|11 |1 |Computer Control Level (lev) |
|12 |1 |Cascade/Ratio Mode (crn) |
|13 |1 |Auto Mode (am) |
Digital Read (Bailey Point Type 7)
These points should be defined as point type digital in the PI system. If the Quality of the exception report is good, the interface extracts the value field of the report into PI. Otherwise, Bad Input is reported.
Analog Report (Bailey Point Type 12)
This is one of the point types for writing from the PI system to Infi90. Infi90 real points are in the range -9.2E18 to 9.2E18. The output is set to BAD QUALITY and the value 0 is sent to Infi90 when the PI value is a digital state code (such as Shutdown or Over Range) and the SourceTag PI point type is a float or an integer.
If the SourceTag is defined as a digital point type, the interface will convert the absolute digital state to an offset of the digital start code of the point and send the offset as an analog value to the Infi90.
Digital Report (Bailey Point Type 13)
This is another point type for sending data from the PI system to Infi90. A source tag for the digital output can be either a real, integer, or digital point in the PI database. BAD QUALITY status is sent to Infi90 when the PI value is a digital state for real or integer source points. For a digital source point, a digital state out of the point’s range is considered BAD QUALITY.
For conversion of PI values to Infi90 values, a status of 1 is sent if the source PI value is not equal to 0. Otherwise 0 is sent. For PI source tag with point type D, the PI value is converted to a digital offset before sending to the Infi90.
Module Status (Bailey Point Type 14)
On the PI 3 server, use a digital set with 4 states to represent the module status. The four states of the Module status are:
• Configure
• Failed
• Error
• Execute
The block number (Location4) should be 0 for this point type.
RCM Read (Bailey Point Type 15)
An RCM (function code 62) has many attributes that could be of interest to the user. By default, the interface extracts only the output field into the PI value for PI tags with Location5 set to 15. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field length |Description |
|1 |1 |Quality (q) |
|2 |1 |Alarm (alm) |
|3 |1 |Block tagged (tag) |
|4 |1 |Output value (ov) |
|5 |1 |Logic set input received (si) |
|6 |1 |Set permissive input received (sp) |
|7 |1 |Logic reset input received (ri) |
|8 |1 |Override (or) |
|9 |1 |Feedback (fb) |
|10 |1 |Set command received (sc) |
|11 |1 |Reset command received (rc) |
RMSC Read (Bailey Point Type 19)
The conversion is the same as the other analog point types. (RMSC is function code 68.) The status of the analog value can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (q) |
|2 |2 |Limit Alarm (la) |
|3 |2 |Deviation Alarm (da) |
|4 |1 |Red Tagged Status (rt) |
|5 |1 |Point Tracking (pt) |
|6 |1 |Calibration (ccv) |
4-byte Analog Read (Bailey Point Type 21)
It is handled like other analog point types except that the precision is higher (about 7 significant digits) and the range is larger (-3.4E38 to 3.4E38). The status of the analog value can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (q) |
|2 |2 |Limit Alarm (la) |
|3 |2 |Deviation Alarm (da) |
|4 |1 |Red Tagged Status (rt) |
|5 |1 |Point Tracking (pt) |
|6 |1 |Calibration (ccv) |
4-byte Analog Report (Bailey Point Type 22)
This is one of the point types for sending data from the PI system to Infi90. 4-byte analog reports are processed in the same way as the 3-byte analog report (type 12) except that the 4-byte analog points have greater range and higher precision. They are in the range of -3.4E38 to 3.4E38.
DAANG (Bailey Point Type 29)
The data acquisition analog block has many attributes that may be of interest to the user. By default, the interface extracts the analog output value of the block into the PI value for PI tags with location 5 set to 29. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field Length |Description |
|1 |1 |Quality (q) |
|2 |1 |high alarm (ha) |
|3 |1 |low alarm (la) |
|4 |2 |alarm level (al) |
|5 |1 |(x) |
|6 |1 |block tagged (tag1) |
|7 |1 |auto/manual (am1) |
|8 |1 |constant value 1 (constant_1) |
|9 |1 |block tagged (tag3) |
|10 |1 |hardware fault/bad input (fq3) |
|11 |1 |out of range (or) |
|12 |1 |limited (lim) |
|13 |1 |auto/manual (am3) |
|14 |1 |calculated value (cal3) |
|15 |1 |Quality override (qo) |
|16 |1 |off scan (ss) |
|17 |1 |high deviation alarm (I) |
|18 |1 |low deviation alarm (lda) |
|19 |1 |high rate (hr) |
|20 |1 |low rate (lr) |
|21 |1 |variable alarms (va) |
|22 |1 |alarm suppression indication (asi) |
|23 |1 |in re-alarm (ra) |
|24 |1 |permit input select (pis) |
|25 |1 |constraints enabled (ce) |
|26 |1 |calculated value (cal5) |
|27 |1 |hardware fault/bad input (fq5) |
|28 |1 |multilevel alarming (ma) |
|29 |1 |auto/manual (am5) |
String (Bailey Point Type 30)
For the Windows version of the interface talking to a PI 3 server, the user has the option of putting the string data to string tags or into the Event Logger. If the PI tag is of point type String, then the string data from Bailey will be put into the string tag directly, else the string data will be put into the PI Event logger. If the PI tag is configured as string type, the Bailey string is put into the PI tag without the prefix of time stamp, tag name and quality flag like the data going into the Event Logger. If the Bailey string has bad quality, the digital string “bad input” will be written to the PI string tag.
Since Bailey will transmit exception reports (on a rate) for the ASCII data even if it doesn’t change, the interface provides a rudimentary filtering function. The interface will send the data to the Event Logger or PI string tags only if the ASCII string or status of the related PI tag have changed.
MSDD (Bailey Point Type 51)
The multi-state device driver (Bailey function code 129) has many attributes that could be of interest to the user. By default, the interface extracts only the output field into the PI value for PI tags with location 5 set to 51. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field Length |Description |
|1 |1 |Quality (q) |
|2 |1 |Alarm (alm) |
|3 |1 |status override value (sor) |
|4 |1 |control override value (cor) |
|5 |1 |operation mode (m) |
|6 |1 |block tagged (tag) |
|7 |1 |command output value (co) |
|8 |1 |feedback state 1 (fb1) |
|9 |1 |feedback state 2 (fb2) |
|10 |1 |feedback state 3 (fb3) |
|11 |1 |feedback state 4 (fb4) |
|12 |2 |good state table (gs) |
|13 |2 |requested state table (rs) |
DD (Bailey Point Type 52)
The device driver (Bailey function code 123) has many attributes that could be of interest to the user. By default, the interface extracts only the output field into the PI value for PI tags with location 5 set to 52. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field Length |Description |
|1 |1 |Quality (q) |
|2 |1 |Alarm (alm) |
|3 |1 |block tagged (tag) |
|4 |1 |output value (ov) |
|5 |1 |feedback state 1 (fb1) |
|6 |1 |feedback state 2 (fb2) |
|7 |1 |feedback status (fs) |
|8 |1 |override value (or) |
|9 |2 |operation mode (mode) |
RMC (Bailey Point Type 53)
The remote motor control block has many attributes that could be of interest to the user. By default, the interface extracts only the output field into the PI value for PI tags with location 5 set to 53. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field Length |Description |
|1 |1 |Quality (q) |
|2 |1 |Alarm (alm) |
|3 |1 |feedback state 1 (fb1) |
|4 |1 |feedback state 2 (fb2) |
|5 |1 |block tagged (tag) |
|6 |1 |output value (ov) |
|7 |1 |bad start (bs) |
|8 |1 |fault (f) |
|9 |1 |start permissive state 1 (sp1) |
|10 |1 |start permissive state 2 (sp2) |
|11 |4 |error code for bad start (rmc_err) |
DADIG (Bailey Point Type 54)
The data acquisition digital block has many attributes that could be of interest to the user. By default, the interface extracts only the output field into the PI value for PI tags with location 5 set to 54. To get the other attributes, use the extended descriptor keyword /BLY=x,y,etc. followed by the attributes code as described below:
|Code |Field Length |Description |
|1 |1 |Quality (q) |
|2 |1 |Alarm (alm) |
|3 |1 |time in alarm re-alarm (field is toggled) (realm) |
|4 |1 |alarms suppressed (sup) |
|5 |1 |output suspect (os) |
|6 |1 |point off scan (nr) |
|7 |1 |block tagged (tag) |
|8 |1 |output value (ov) |
|9 |1 |extended status transition latched (lat) |
|10 |1 |Quality override (qo) |
|11 |1 |set permissive (sp) |
|12 |1 |primary input selected (pi) |
|13 |1 |alternate input selected (ai) |
Text Selector (Bailey Point Type 60)
The text selector returns a message code number to PI. User can define the PI tag as digital point and put the corresponding message text in the digital state table or define the PI tag as integer point.
Harmony Analog Input (Bailey Point Type 70)
This point type is supported only through Bailey semAPI version 2.0 and greater, which necessitates PI semAPI interface version 1.3 or greater. The conversion is the same as the other analog point types. The status of the analog value can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (uc_q) |
|2 |1 |high Alarm (uc_h_alrm) |
|3 |1 |low Alarm (uc_l_alrm) |
|4 |1 |Status errors are inhibited (uc_sei) |
|5 |1 |Simulated (uc_sim) |
|6 |1 |Overridden value (uc_oe) |
|7 |1 |Value is suspect (uc_susp) |
|8 |1 |Propagated quality (uc_pq) |
|9 |1 |Extended range (uc_er) |
|10 |1 |Configuration error exists (uc_cerr) |
|11 |2 |Channel condition (uc_range) |
|12 |1 |Readback status (uc_rbst) |
|13 |1 |Reference status (uc_ref) |
|14 |1 |Calibration status (uc_cal) |
Harmony Analog Output (Bailey Point Type 71)
This point type is supported only through Bailey semAPI version 2.0 and greater, which necessitates PI semAPI interface version 1.3 or greater. The conversion is the same as the other analog point types. The status of the analog value can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (uc_q) |
|2 |1 |high Alarm (uc_h_alrm) |
|3 |1 |low Alarm (uc_l_alrm) |
|4 |1 |Status errors are inhibited (uc_sei) |
|5 |1 |Simulated (uc_sim) |
|6 |1 |Overridden value (uc_oe) |
|7 |1 |Value is suspect (uc_susp) |
|8 |1 |Propagated quality (uc_pq) |
|9 |1 |Extended range (uc_er) |
|10 |1 |Configuration error exists (uc_cerr) |
|11 |2 |Channel condition (uc_range) |
|12 |1 |Readback status (uc_rbst) |
|13 |1 |Reference status (uc_ref) |
|14 |1 |Calibration status (uc_cal) |
Harmony Digital Input (Bailey Point Type 72)
This point type is supported only through Bailey semAPI version 2.0 and greater, which necessitates PI semAPI interface version 1.3 or greater. These points should be defined as type digital (D) or integer (I) in the PI system. If the Quality of the exception report is good, the interface extracts the value field of the report into the PI system. Otherwise, “Bad Input” is reported. Also, the rest of the status attribute can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (uc_q) |
|2 |1 |Alarm (uc_alm) |
|3 |1 |Status errors are inhibited (uc_sei) |
|4 |1 |Simulated (uc_sim) |
|5 |1 |Overridden value (uc_ovvl) |
|6 |1 |Value is suspect (uc_susp) |
|7 |1 |Propagated quality (uc_pq) |
|8 |1 |Configuration error exists (uc_cerr) |
|9 |2 |Channel condition (uc_range) |
|10 |1 |Readback status (uc_rbst) |
|11 |1 |Value (uc_val) |
Harmony Digital Output (Bailey Point Type 73)
This point type is supported only through Bailey semAPI version 2.0 and greater, which necessitates PI semAPI interface version 1.3 or greater. These points should be defined as PI point type digital or integer. If the Quality of the exception report is good, the interface extracts the value field of the report into the PI system. Otherwise, Bad Output is reported. Also, the rest of the status attribute can be accessed through the following extended attributes:
|Code |Field length |Description |
|1 |1 |Quality (uc_q) |
|2 |1 |Alarm (uc_alm) |
|3 |1 |Status errors are inhibited (uc_sei) |
|4 |1 |Simulated (uc_sim) |
|5 |1 |Overridden value (uc_ovvl) |
|6 |1 |Value is suspect (uc_susp) |
|7 |1 |Propagated quality (uc_pq) |
|8 |1 |Configuration error exists (uc_cerr) |
|9 |2 |Channel condition (uc_range) |
|10 |1 |Readback status (uc_rbst) |
|11 |1 |Value (uc_val) |
Tag Configuration from Bailey Database
The Bailey MCS Operator Console configuration contains much of the information needed for the PI Point database. The MCS can be configured from DBASE files on a personal computer. It is possible to create text files for PIDIFF or PIConfig from the DBASE files created for the MCS.
Start by entering DBASE and creating a new database with several of the same fields as the MCSTAG.dbf file. The following PI attributes can be extracted.
|PI Attribute |MCS Database Field Name and Comment |
|Tag |The field name in the MCS database is TagName. The MCS field is 14 characters long so |
| |some conversion may be necessary. |
|Descriptor |The field name in the MCS database is TagDescriptor. The MCS field is 32 characters |
| |long. The PI Descriptor is only 26 characters long. |
|EngUnits |The field name in the MCS database is EngineeringUnitDescriptor. |
| |Note: The Engineering Unit strings must be configured in PI before configuring points |
| |that will use them. |
|Zero |The field name in the MCS database is ValueZero. |
|Span |The field name in the MCS database is Span. |
|DigStCode |The MCS database field ZeroState points to a string in the MCS state table. |
| |PI2 Server: The ZeroState could be replaced with PI digital state code numbers. |
| |Note: Most Infi90 digital points represent two-state devices, thus the DigNumber for |
| |these points in PI would be 1. The PI digital state table can be configured to have |
| |similar strings. These digital state strings must be configured before building PI |
| |points. |
| |PI3 Server: PI3 requires that a digital state set be defined for each unique set of |
| |digital states. The digital state set must be defined before building PI points. |
|Location2 |This is 256 times the MCS field Loop plus the MCS field Node. |
|Location3 |This is the MCS field Module. |
|Location4 |This is the MCS field Block. |
|Location5 |The field name in the MCS database is TagType. The MCS field has string descriptions of |
| |the type (e.g., ANALOG, RCM) rather than the number of the CIU point type. These can be |
| |converted with DBASE or a text editor. |
Performance Point Configuration
One can configure performance points to monitor the amount of time in seconds that it takes an interface to complete a scan for a particular scan class. The closer the scan time is to 0 seconds, the better the performance. The scan time is recorded to millisecond resolution. Because this interface is not scan-based, performance points are not applicable.
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.
Monitoring I/O Rates on the Interface Node
For Windows 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 (Windows)
The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing I/O Rate 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 Rate 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 Rate tag exists in PI. The possible states are:
• Created – This status indicates that the tag exist in PI
• Not Created – This status indicates that the tag does not yet exist in PI
• Deleted – This status indicates that the tag has just been deleted
• Unknown – This status indicates that the PI ICU is not able to access the PI Server
In File
The In File column indicates whether the I/O Rate tag listed in the tag name and the event counter is in the IORates.dat file. The possible states are:
• Yes – This status indicates that the tag name and event counter are in the IORates.dat file
• No – This status indicates that the tag name and event counter are not in the IORates.dat file
Event 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 Rate tag.
Snapshot
The Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists in PI. The Snapshot column is updated when the IORates/Status Tags tab is clicked, and when the Interface is first loaded.
Button Menu Options
Create
Create the suggested I/O Rates point with the tag name indicated in the Tagname column.
Delete
Delete the I/O Rate point listed in the Tagname column.
Reset
Change the value in the Tagname text box back to the default value.
Rename
Allow the user to specify a new name for the I/O Rate point listed in the Tagname column.
Add to File
Add the I/O Rate point and the event counter number to the IORates.dat file.
Search [pic]
Allow the user to search the PI Server a previously defined I/O Rate points.
Update Snapshot [pic]
Allow the user to refresh the snapshot value.
Configuring I/O Rate Tags Manually
There are two configuration steps.
1. Configuring the PI Point on the PI Server
2. Configuration on the Interface Node
Configuring the PI Point on the PI Server
Create an I/O Rate Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |float32 |
|Compressing |0 |
|ExcDev |0 |
Configuring on the Interface Node
For the following examples, assume that the name of the PI tag is blysem001, and that the name of the I/O Rate on the home node is blysem001.
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 %windir% directory. If both are specified, the PIPCSHARE entry takes precedence.
Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.
Add a line in the iorates.dat file of the form:
blysem001, x
where blysem001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x parameter in the startup command file. X can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.
2. Set the /ec=x parameter on the startup command file of the interface to match the event counter in the iorates.dat file.
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
Command-line parameters can begin with a / or with a -. For example, the /ps=M and
–ps=M command-line parameters are equivalent.
For Windows, command file names have a .bat extension. The Windows continuation character (^) allows for the use of multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of parameters is unlimited, and the maximum length of each parameter is 1024 characters.
The PI Interface Configuration Utility (PI ICU) provides a tool for configuring the Interface startup command file.
Configuring the Interface with PI ICU
Note: PI ICU requires PI 3.3 or greater.
The PI Interface Configuration Utility provides a graphical user interface for configuring PI interfaces. If the interface is configured by the PI ICU, the batch file of the interface (Blysem.bat) will be maintained by the PI ICU and all configuration changes will be kept in that file and the module database. The procedure below describes the necessary steps for using PI ICU to configure the PI Bailey SemAPI Interface.
From the PI ICU menu, select Interface, then NewWindows Interface Instance from EXE..., and then Browse to the Blysem.exe executable file. Then, enter values for Point Source and Interface ID#. A window such as the following results:
[pic]
“Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name and it will be the display name in the services menu.
Click on Add.
The following display should appear:
[pic]
Note that in this example the Host PI System is STARSHOLLOW. However, to configure the interface to communicate with a different PI Server, select ‘Interface => Connections…’ item from PI ICU menu and make it the default server. If the remote node is not present in the list of servers, it can be added.
Once the interface is added to PI ICU, near the top of the main PI ICU screen, the Interface Type should be basemapi. If not, use the drop-down box to change the Interface Type to be basemapi.
Click on Apply to enable the PI ICU to manage this copy of the PI Bailey SemAPI Interface.
[pic]
[pic]
The next step is to make selections in the interface-specific tab (i.e. “basemapi”) that allow the user to enter values for the startup parameters that are particular to the PI Bailey SemAPI Interface.
Since the PI Bailey SemAPI Interface is a UniInt-based interface, in some cases the user will need to make appropriate selections in the UniInt pages. These pages allows the user to access UniInt features through the PI ICU and to make changes to the behavior of the interface.
To set up the interface as a Windows Service, use the Service page. This page allows configuration of the interface to run as a service as well as to starting and stopping of the interface. The interface can also be run interactively from the PI ICU. To do that go to menu, select the Interface item and then Start Interactive.
For more detailed information on how to use the above-mentioned and other PI ICU pages and selections, please refer to the PI Interface Configuration Utility User Manual. The next section describes the selections that are available from the basemapi tab. Once selections have been made on the PI ICU GUI, press the Apply button in order for PI ICU to make these changes to the interface’s startup file.
Basemapi Interface Page
Since the startup file of the PI Bailey SemAPI Interface is maintained automatically by the PI ICU, use the basemapi page to configure the startup parameters and do not make changes in the file manually. The following is the description of interface configuration parameters used in the PI ICU Control and corresponding manual parameters.
General Tab
Basemapi
[pic]
Behavior
Enable exception screening
This option controls the exception screening behavior of the ICI module. With exception screening option enabled, the INFI90 sends only deviation exceptions, no maximum time exceptions. Though this feature will significantly reduce the communications traffic, it can prevent the PI system from reconstructing the data between two exception reports accurately.
For example: if a value changes slowly, then Bailey would not send the change until the total change exceeded the deviation limit. Therefore, one cannot distinguish a step change from a linear change. Hence, this option is set to 0 by default. The EF option is primarily used for system with mostly digital or discrete data. The command line equivalent is /ef.
Enable outputs
Enable outputs from PI to Bailey. The command line equivalent is /of.
Connection to an HNCC
This option specified that the interface is connecting to an HNCC as opposed to an ICI03.
Communication timeout
This option specifies the ICI module watch dog timer. If the interface stops communicating with the ICI module for a period longer than the specified watch dog timer, the ICI module will go off-line, setting all the output points (PI to Bailey) bad quality. For systems using PI values in the Bailey control loops, the watch dog timer will prevent old value from being used in the control loop. Also, do not set the watchdog timer to 0 if the interface is set up as fail over primary interface. Otherwise, the secondary interface will not pick up data collection when the primary interface stops communicating with the ICI module. See the Failover Operation section for details. The command line equivalent is /to=x.
Bailey logical ICI number
Bailey logical ICI number, set to interface ID number if not defined. The command line equivalent is /ici=x.
Time sync
This option controls the time synchronization behavior between Bailey and PI systems. Note that the interface cannot change the PI system time when the interface is running on Windows. Also, if the interface is linked to a Data Acquisition version of semAPI, the interface cannot set the time on the Bailey System. The time master of the loop is determined by the time accuracy factor on each node. Hence, set the time accuracy to 15 or greater on the CIU module through the CIU utilities by connecting a terminal to the CIU termination unit. See the CIU manual for details on how to use the CIU utilities.
/ts=0 disables timesync
/ts=1 sets PI time as the master time
Note: In versions prior to 1.4.1.0 of the interface, setting the time sync to use Bailey as the master time was supported (/ts=-1). This is no longer supported. If this configuration is encountered by the ICU, /ts will be disabled (set to 0).
Send string data to the Event Logger
Event logger group #
Define the Event Logger group to be used when ASCII data (type 30) is sent to the Event Logger, where # is the group number. The command line equivalent is /evg=#.
Event logger type #
Define the Event Logger type to be used when ASCII data (type 30) is sent to the Event Logger, where # is the type. The command line equivalent is /evt=#.
Data Retrieval
Seconds between get exceptions
Delay in seconds between bailey get exceptions. The default is one second. The command line equivalent is /dl=x.
Maximum exceptions per iteration
Maximum number of exceptions per iteration. The default is 2500. The command line equivalent is /me=#.
Maximum points for interface
The maximum number of points for this interface. The default is 30000. The command line equivalent is /mp=#.
Data Handling
Enable range checking
Range Checking enabled at interface level. All analog values above (Zero + Span) will be replaced with digital state OverRange. All analog values below Zero will be replaced with digital state UnderRange. The command line equivalent is /rc.
Analog filter limit and Digital code
Enables analog filter parameters. /FV specifies a limit. If the analog values from Bailey are greater than this value, they will be replaced by a digital state code (specified by /FS) by the interface. The FV parameter has to be greater than 1000 to be considered valid by the interface. If /FV is not specific, no analog filter checking will be performed by the interface (even if /FS is specified). If /FS is omitted, the interface will default to NODATA(code 248) as the digital state to substitute the analog value over the filter limit. The Analog filter check is supported starting in version 1.3.1 of the interface. The command line equivalent is /fv=x for the Analog filter limit and /fs=x for the Digital code.
Failover / Debug Tab
[pic]
Failover
A detailed discussion of failover can be found later in this manual in a section titled “Failover Operation”.
Enable failover
This option controls the failover mode of the interface. Specify /FM=1 for the primary interface and /FM=2 for the secondary interface. Also, for the secondary interface, supply the PCU number of the ICI mode communicating to the primary interface. The details of the failover mechanism are described in Failover Operation section. The command line equivalent is /fm=x.
Primary PCU address:
The failover primary PCU address is required only if failover is used, and this is the secondary interface. The command line equivalent is /fp=x.
UniInt Health Tag ID:
If failover is enabled, a UniInt Health Tag ID (UHT_ID) parameter must be specified. This parameter is used to filter UniInt Health Tags by Location3. The parameter should be different from another interface – failover member parameter. If the same /UHT_ID value is used for both instances, the text box will have yellow back color indicating a bad value. If this parameter has a bad value or missing the default value 0 for Location3 PI attribute will be used.
The command line equivalent is /UHT_ID=#, where x the number for Location3 PI Attribute.
Debug
Connect to ICI with shared access
Even though the Bailey semAPI is designed to handle multiple user clients, PI Bailey semAPI interface expects exclusive control of the ICI device, specially the configuration of the point table on the ICI. If the interface is started in trouble-shooting mode (/ICDB), the user can simultaneously communicate with the ICI via Bailey’s TALK90 program. This can be a useful debugging tool for determining the current condition of the ICI. During normal operation, this option should not be checked. The command line equivalent is /icdb.
Additional Parameters
This box is used to add any command-line parameters which are not currently supported by the ICU Control. Each command-line parameter should be separated by a space. If the argument to a command-line parameter has embedded spaces then surround the whole argument in double quotes.
Command-line Parameters
Command-line parameters can begin with a / or with a -. For example, the /ps=M and
–ps=M command-line parameters are equivalent.
Notes for Windows
Note: The UniInt Interface User Manual includes details about other command-line parameters which may be useful.
|Parameter |Description |
|/dl=# |Where # specifies the delay in seconds between bailey get exceptions. |
|Optional |Default = 1 second |
| |Minimum = 0.1 |
| |Maximum = none |
|/ec=# |The first instance of the /ec parameter on the command line is used to specify a counter|
|Optional |number, #, for an I/O Rate point. If # is not specified, then the default event counter |
| |is 1. Also, if the /ec parameter is not specified at all, there is still a default event|
| |counter of 1 associated with the interface. If there is an I/O Rate point that is |
| |associated with an event counter of 1, each copy of the interface that is running |
| |without /ec=# 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.” |
|/ef=# |This parameter controls the exception screening behavior of the ICI module. Exception |
|Optional |screening is enabled when /EF=1, in which case the INFI90 sends only deviation |
| |exceptions, no maximum time exceptions. Though this feature will significantly reduce |
| |the communications traffic, it can prevent the PI system from reconstructing the data |
| |between two exception reports accurately. For example: if a value changes slowly, then |
| |Bailey would not send the change until the total change exceeded the deviation limit. |
| |Therefore, one cannot distinguish a step change from a linear change. Hence, this option|
| |is set to 0 by default. The /EF=1 parameter is primarily used for system with mostly |
| |digital or discrete data. |
| |Default = 0 (disabled) |
| |Minimum = 0 (disabled) |
| |Maximum = 1 (enabled) |
|/evg=# |Define the Event Logger group to be used when ASCII data (type 30) is sent to the Event |
|Optional |Logger. Where # is the group number. |
| |Default = 4 |
| |Minimum = 0 |
| |Maximum = 1000 |
|/evt=# |Define the Event Logger type to be used when ASCII data (type 30) is sent to the Event |
|Optional |Logger.. Where # is the type. |
| |Default = 11 |
| |Minimum = 0 |
| |Maximum = 1000 |
|/fm=# |This parameter controls the failover mode of the interface. Specify |
|Optional |/FM=0 for no failover |
| |/FM=1 for the primary interface |
| |/FM=2 for the secondary interface. Also, for the secondary interface, the PCU number of |
| |the ICI mode communicating to the primary interface must be supplied. The details of the|
| |failover mechanism are described in Failover Operation section. |
| |Default = 0 |
| |Minimum = 0 |
| |Maximum = 2 |
|/fp=# |The failover primary PCU address is required only if failover is used, and this is the |
|Optional |secondary interface |
| |Default, not defined. |
| |Minimum = 0 |
| |Maximum = 2147483647 |
|/fs=# |/FS=# specifies the SYSTEM digital state integer value to replace an analog value that |
|Optional |is greater than the analog filter limit specified by /FV=#. This parameter has no affect|
| |if /FV=# is not specified. |
| |Default = 248 (No Data) |
| |Minimum = 0 |
| |Maximum = 1024 or maximum SYSTEM digital state value |
|/fv=# |/FV=# specifies an analog filter limit in integer or floating point with decimal format.|
|Optional |If an analog value from Bailey is greater than this value, the interface will be replace|
| |it with the digital state code specified in /FS=#. The FV parameter must be greater than|
| |1000 to be considered valid by the interface. If /FV is not specified, no analog filter |
| |checking will be performed by the interface. If /FS=# is omitted, the interface will |
| |default to /FS=248 (NO DATA) as the digital state to substitute for the analog value |
| |over the filter limit. |
| |Range {0,1001 – n ) |
| |Default = 0 (disabled) |
| |Minimum = 1001.0 |
| |Maximum = None |
|/icdb |Even though the Bailey semAPI is designed to handle multiple user clients, PI Bailey |
|Optional |semAPI interface expects exclusive control of the ICI device, specially the |
| |configuration of the point table on the ICI. If the interface is started in |
| |trouble-shooting mode (/ICDB), the user can simultaneously communicate with the ICI via |
| |Bailey’s TALK90 program. This can be a useful debugging tool for determining the current|
| |condition of the ICI. During normal operation, this option should not be checked. |
| |Default, not defined. |
|/ici=# |Where # specifies the Bailey logical ICI number, set to interface ID number if not |
|Optional |defined. |
|/id=x |The /id parameter 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. |
| |UniInt always uses the /id parameter in the fashion described above. This interface also|
| |uses the /id parameter to identify a particular interface copy number that corresponds |
| |to an integer value that is assigned to Location1. For this case, one must use only |
| |numeric characters in the identifier. For example, |
| |/id=1 |
|/host=host:port |The /host parameter is used to specify the PI Home node. Host is the IP address of the |
|Required |PI Sever node or the domain name of the PI Server node. Port is the port number for |
| |TCP/IP communication. The port is always 5450 for a PI 3 Server. It is recommended to |
| |explicitly define the host and port on the command line with the /host parameter. |
| |Nevertheless, if either the host or port is not specified, the interface will attempt to|
| |use defaults. |
| |Defaults: |
| |The default port name and server name is specified in the pilogin.ini or piclient.ini |
| |file. The piclient.ini file is ignored if a pilogin.ini file is found. Refer to the PI |
| |API manual for more information on the piclient.ini and pilogin.ini files. |
| |Examples: |
| |The interface is running on a PI Interface Node, the domain name of the PI 3 home node |
| |is Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host parameters would |
| |be: |
| |/host=marvin |
| |/host=marvin:5450 |
| |/host=206.79.198.30 |
| |/host=206.79.198.30:5450 |
|/hncc |This option must be specified if connecting to an HNCC as opposed to an ICI03. |
|Optional |Default, not defined. |
|/me=# |Maximum number of exceptions per iteration as defined by /dl=# parameter. |
|Optional |Default = 2500 |
|Default: |Minimum = 100 |
|/me=2500 |Maximum = 2147483647 |
|/mp=# |The maximum number of points for this interface. |
|Optional |Default = 30000 |
|Default: |Minimum = 1 |
|/mp=30000 |Maximum = 2147483647 |
|/of=# |Enable outputs from PI to Bailey |
|Optional |Default = 0 (disabled) |
| |Minimum = 0 (disabled) |
| |Maximum = 1 (enabled) |
|/ps= |The /ps parameter specifies the point source for the interface. The is not case|
|Required |sensitive and can be any single or multi character string. For example, /ps=P and /ps=p |
| |are equivalent. |
| |The point source that is assigned with the /ps parameter corresponds to the PointSource |
| |attribute of individual PI Points. The interface will attempt to load only those PI |
| |points with the appropriate point source. |
|/q |When the /q parameter is present, Snapshots and exceptions are queued before they are |
|Optional |sent to the PI Server node. |
| |The maximum queue size is 255 bytes for a PI 3 Server and 36 bytes for a PI 2 Server. |
| |For example, if the interface is running on a UNIX node and is communicating to a PI 2 |
| |Server, then the maximum queue size is 36. The queue is flushed between scans if it is |
| |not filled. |
| |When the /q parameter is specified in non-extended API mode, the PI API sends integer |
| |values as 16-bit integers instead of 32-bit integers. Therefore, integer points will be |
| |limited to values between 0 and 32767. Values higher than 32767 need to be sent to |
| |floating-point PI tags. |
|/rc |When defined, Range Checking enabled at interface level. All analog values above (Zero |
|Optional |+ Span) will be replaced with the digital state OverRange. All analog values below Zero|
| |will be replaced with the digital state UnderRange. |
| |Default, not defined. |
|/sio |The /sio parameter stands for “suppress initial outputs.” The parameter applies only for|
|Optional |interfaces that support outputs. If the /sio parameter is not specified, the interface |
| |will behave in the following manner. |
| |When the interface is started, the interface determines the current Snapshot value of |
| |each output tag. Next, the interface writes this value to each output tag. In addition, |
| |whenever an individual output tag is edited while the interface is running, the |
| |interface will write the current Snapshot value to the edited output tag. |
| |This behavior is suppressed if the /sio parameter is specified on the command line. That|
| |is, outputs will not be written when the interface starts or when an output tag is |
| |edited. In other words, when the /sio parameter is specified, outputs will only be |
| |written when they are explicitly triggered. |
|/stopstat |If the /stopstat parameter is present on the startup command line, then the |
|or |digital state Intf Shut 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 |
| |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.|
|/to=# |This parameter specifies the ICI module watchdog timer. If the interface stops |
|Optional |communicating with the ICI module for a period longer than the specified watchdog timer,|
|Default: |the ICI module will go off-line, setting all the output points (PI to Bailey) to bad |
|/to=90 |quality. For systems using PI values in the Bailey control loops, the watchdog timer |
|Maximum: |will prevent the old value from being used in the control loop. Also, do not set the |
|/to=240 |watchdog timer to 0 if the interface is set up as failover primary interface. Otherwise,|
| |the secondary interface will not pick up data collection when the primary interface |
| |stops communicating with the ICI module. See the Failover Operation section for details.|
|/ts=# |This parameter controls the time synchronization behavior between Bailey and PI systems.|
|Optional |Note that the interface cannot change the PI system time. Also, if the interface is |
|Default: |linked to a Data Acquisition version of semAPI, the interface cannot set the time on the|
|/ts=0 |Bailey System. The time master of the loop is determined by the time accuracy factor on |
| |each node. Hence, the time accuracy must be set to 15 or greater on the CIU module |
| |through the CIU utilities by connecting a terminal to the CIU termination unit. See the |
| |CIU manual for details on how to use the CIU utilities. |
| |/ts=0 disables time synchronization |
| |/ts=1 sets PI time as the master time |
| |Default = 0 (disabled) |
| |Minimum = 0 |
| |Maximum = 1 |
Sample blysem.bat File
The interface takes a number of optional parameters to control its operation. These parameters may be specified in the interface command file blysem#.bat for use on Windows.
The following is an example file for use on Windows:
REM=======================================================================
REM
REM BLYSEM.bat
REM
REM Sample startup file for the Bailey Sem API Interface to the PI System
REM
REM=======================================================================
REM
REM OSIsoft strongly recommends using PI ICU to modify startup files.
REM
REM Sample command line
REM
Blysem.exe /ps=BaSemAPI /sn /id=1 /of=1 /host=XXXXXX:5450
REM
REM End of BLYSEM.bat File
Interface Node Clock
Windows
Make sure that the time and time zone settings on the computer are correct. To confirm, run the Date/Time applet located in the Windows Control Panel. If the locale where the interface node resides observes Daylight Saving Time, check the box marked “Automatically adjust clock for daylight saving changes”. For example,
[pic]
In addition, make sure that the TZ environment variable is not defined. All of the currently defined environment variables can be viewed by opening a Command Prompt window and typing set. That is,
C:> set
Make sure that the TZ environment variable is not defined. All of the currently defined environment variables can be viewed by opening a Command Prompt window and typing set. Confirm that TZ is not in the resulting list. If it is, run the System applet of the Control Panel, click the Environment tab, and remove TZ from the list of environment variables.
Security
Windows
The PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Server. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Server manuals.
Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy Database used prior to PI version 3.3. The Trust Database maintains all the functionality of the proxy mechanism while being more secure.
See “Trust Login Security” in the chapter “PI System Management” of the PI Universal Data Server System Management Guide.
If the interface cannot write data to the PI 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 Server, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.
PI Server v3.3 and Higher
Security configuration using piconfig
For PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust table:
C:\PI\adm> piconfig
@table pitrust
@mode create
@istr Trust,IPAddr,NetMask,PIUser
a_trust_name,192.168.100.11,255.255.255.255,piadmin
@quit
For the above,
Trust: An arbitrary name for the trust table entry; in the above example,
a_trust_name
IPAddr: the IP Address of the computer running the Interface; in the above example,
192.168.100.11
NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr
PIUser: the PI user the Interface to be entrusted as; piadmin is usually an appropriate user
Security Configuring using Trust Editor
The Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI Trust table.
See the PI System Management chapter in the PI Server manual for more details on security configuration.
PI Server v3.2
For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:
C:\PI\adm> piconfig
@table pi_gen,piproxy
@mode create
@istr host,proxyaccount
piapimachine,piadmin
@quit
In place of piapimachine, put the name of the PI Interface node as it is seen by PI Server.
Starting / Stopping the Interface on Windows
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt Interface User Manual to run the interface interactively.
[pic]
Starting Interface as a Service
If the interface was installed a service, it can be started from PI ICU, the services control panel or with the command:
blysem.exe –start
To start the interface service with PI ICU, use the [pic] button on the PI ICU toolbar.
A message will inform the user of the the status of the interface service. Even if the message indicates that the service has started successfully, double check through the Services control panel applet. Services may terminate immediately after startup for a variety of reasons, and one typical reason is that the service is not able to find the command-line parameters in the associated .bat file. Verify that the root name of the .bat file and the .exe file are the same, and that the .bat file and the .exe file are in the same directory. Further troubleshooting of services might require consulting the pipc.log file, Windows Event Viewer, or other sources of log messages. See the section “Appendix A: Error and Informational Messages,” for additional information.
Stopping Interface Running as a Service
If the interface was installed a service, it can be stopped at any time from PI ICU, the services control panel or with the command:
blysem.exe –stop
The service can be removed by:
blysem.exe –remove
To stop the interface service with PI ICU, use the [pic] button on the PI ICU toolbar.
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt Interface User Manual to run the interface interactively.
Buffering
For complete information on buffering, please refer to the PI API Installation Instruction.
PI Interface Node buffering consists of a buffering process which runs continuously on the local node, a PI API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.
Note: Change the Local Security Policy on Windows XP.
1. Open “Administrative Tools” from the control panel.
2. Open “Local Security Policy” from administrative tools.
3. Browse to “Security Options” under “Local Policies.”
4. Double click on “System Objects: Default owner for objects created by members of the Administrators group.”
5. Change the dropdown from “Object Creator” to “Administrators group.”
The behavior of Bufserv should now be the same on Windows XP as it was for Windows and 2000.
Configuring Buffering with PI ICU (Windows)
Buffering is enabled through the PI Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI API will not buffer data, sending data directly to the home node.
The API Buffering… dialog allows the user to view and configure the parameters associated with the PI API Buffering (bufserv) process. The user can start and stop the PI API Buffering process from the Service tab:
[pic]
Service Tab
The Service tab allows for some PI API Buffering service configuration. For further configuration changes, use the Services applet.
Service Name
The Service name displays the name of the PI API Buffering Service.
Display Name
The Display name displays the full name associated with the PI API Buffering service.
Log On As
Log on as indicates the Windows user account under which the PI API Buffering service is setup to start automatically on reboot, or manually.
Password
Password is the name of the password for the Windows user account entered in the Log on as: above.
Confirm password
Reenter the password to verify it has been typed correctly both times.
Dependencies
The Dependencies lists the Windows services on which the PI API Buffering service is dependent.
Dependent Services
The Dependent services area lists the Windows services that depend on bufserv to function correctly.
Start / Stop Service
The Start / Stop buttons allow for the PI API Buffering service to be started and stopped. If the service is not created, this box will show Not Installed.
After a change is made to any of the settings on the Settings tab, the OK button must be clicked to save these settings, and then the service must be stopped and restarted for the changes to be picked up by bufserv.
Service Startup Type
The Startup Type indicates whether the PI API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, the PI API Buffering service is set to start automatically.
Create/Remove Service
The Create / Remove buttons allow for the creation or removal of the PI API Buffering service. Clicking the Create button will cause the service to be created using the Log on as and passwords given. Once the service is created the Start / Stop buttons will be activated.
Settings Tab
The Settings tab allows for configuration of the 7 configurable settings used by PI API Buffering. Default values are used if no other value is provided.
[pic]
Enable Buffering
Enable the PI 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 which is calculated like this:
max = MAXTRANSFEROBJS / SENDRATE * 1000
Default value is 5000. This value is automatically calculated for the user and can not be changed.
There are no additional steps needed to install buffering after installing the PI API. The delivered PI API library supports both buffered and un-buffered calls.
Configuring Buffering 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. 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
Windows
On Windows, the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds, meaning “Wait 10 minutes after losing a connection before retrying”.
On Windows a piclient.ini file might look like:
[APIBUFFER]
BUFFERING=1
MAXFILESIZE=100000
; The PI API connection routines have a 1 minute default timeout.
RETRYRATE=600
Restrictions and Other Information
Exclusive Control of ICI Device
Even though the Bailey semAPI is designed to handle multiple user clients, PI Bailey semAPI interface expects exclusive control of the ICI device, specifically the configuration of the point table on the ICI. If the interface is started in trouble-shooting mode (/ICDB), the user can simultaneously communicate with the ICI via Bailey’s TALK90 program. This can be a useful debugging tool for determining the current condition of the ICI.
Interface and semAPI Version Compatibility
Applications developed with the semAPI version 2.0 and greater are not compatible with older versions of the semAPI. Hence, PI Bailey semAPI interface version 1.2 can only work with semAPI version 1.2 while interface version 1.3 and greater can only work with semAPI version 2.0 and greater.
OSM01 Not Recommended
The interface sometimes loses communication with the OSM01. In most cases, the interface process cannot re-establish communication automatically. The cause of the loss of communication is still unknown. Also, the OSM01 will take ten times as long to establish an equal number of points as compared with direct SCSI connection with ICI03. For these reasons, currently, it is not recommended to use OSM01 with the PI semAPI interface.
semAPI 1.2 Disconnection Problems
If the SCSI connection between the host computer and the ICI03 was disconnected for a short while (one minute for example) while running with semAPI version 1.2 on Windows and then re-connected, subsequent calls to the semAPI would result in an error. The problem would not go away unless the Bailey device driver process was stopped. The same problem was also observed if the ICI module was reset. These problems are fixed with semAPI version 2.0 and greater.
Timeout in the Middle of the Connect Point Command
Some systems with many points on a Bailey loop different from where the ICI is located could take more than 90 seconds to connect to these points. However, the ICI watchdog timer is activated as soon as the connect point command is received by the ICI. So it is possible for the ICI to timeout in the middle of processing the connect point command. In this case, the /TO parameter must be increased to work around the problem.
Adaptec 2940 U SCSI, 50-pin Card with the ICI03
According to Bailey, customers should use the Adaptec 2940 U SCSI, 50-pin card with the ICI03. Additionally, they should order the 18-foot SCSI cable from Bailey, part no. AI1758-18.
Install the semAPI Device Driver as a Service
With semAPI 2.0 and later, the interface has been known to have problems working when the user logs off of a Windows machine. After a user logs off, the semAPI device driver stops running and our interface loses the connection to the ICI. To fix this problem, the semAPI device driver must be installed as a service. Follow the steps below:
1) Custom install the semAPI and install the DEVICE files.
2) From the installation directory, run
DeviceAsService DD_ -i
3) Configure in Control Panel for auto start.
4) Uninstall Blysem service with
blysem –remove
5) Reinstall Blysem service with
blysem –install –auto –depend “tcpip DD_ bufserv”
The is the ICI device name specified in the ICICONF utility. For instance, if COM1 is specified, then the command would be:
DeviceAsService DD_COM1 –i
Invalid Security Device Present
If the interface reports “Invalid security device present,” the user string or software key has not been entered or is incorrect. The software key is a long, alpha-numeric string and the user string is usually “LICENSE01.” Both of these strings are furnished by Bailey. The strings need to be entered in three places. The software key needs to be entered into the LICENTRY utility. However, the user string needs to be entered in BOTH the LICENTRY and the ICICONF utility. Without correct user/software key strings entered, neither the talk90 program nor the interface will be able to connect to the ICI.
ICICONF Utility
[pic]
LICENTRY Utility
[pic]
Appendix A:
Error and Informational Messages
A string NameID is pre-pended to error messages written to the message log. Name is a non-configurable identifier that is no longer than 9 characters. ID is a configurable identifier that is no longer than 9 characters and is specified using the /id parameter on the startup command line.
Message Logs
The location of the message log depends upon the platform on which the interface is running. See the UniInt Interface User Manual 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.
Messages
PBI 1> Fatal 204 (ICI): Invalid security device present.
License Parameters are not setup correctly in Bailey semAPI software. Please refer to Restrictions and other Information section for details on how to fix this.
System Errors and PI Errors
System errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers.
Error Descriptions on Windows
On Windows, descriptions of system and PI errors can be obtained with the pidiag utility:
\PI\adm\pidiag –e error_number
Revision History
|Date |Author |Comments |
|14-Apr-04 |Holly |Updated section on ICU control. Doc rev C |
|1-Nov-04 |Chrys |Removed reference to scan-based inputs in location4; noted that performance |
| | |points are not applicable; Doc rev E |
|4-Nov-04 |Chrys |Fixed headers & footers; fixed page numbers; fixed table of command-line |
| | |parameters; UniInt is standard; digital states may be anywhere is the table;|
| | |removed duplicate sections; Doc rev F |
|8-Jun-05 |Jking |Added info about ICI12 support |
|13-Jun-06 |Chrys |Added XP to platforms supported |
|19-Sep-06 |Janelle |NT Version 1.3.6; VMS Version 1.2 – 2.1.2 Rev H: Updated Supported Features |
| | |table to include APS Connector; fixed headers and footers; updated How to |
| | |Contact Us page. |
|21-Nov-06 |Janelle |Windows Version 1.3.6; VMS Version 1.2 – 2.1.2 Rev I: Added descriptions of |
| | |the following command line parameters in the startup command line parameters|
| | |table: /OF, /ICI, /ICDB, /DL, /ME, /MP, /FP; updated headers and footers; |
| | |updated manual to skeleton 2.5.2. |
|05-Feb-07 |Janelle |Windows Version 1.3.6: made new version of manual to only discuss Windows |
| | |platform. Applied new text from skeleton. |
|20-Feb-07 |MKelly |Version 1.4.0.0; Updated supported features table for Disconnected Startup |
| | |and SetDeviceStatus information. |
|20-Feb-07 |Jking |Corrected items in the Supported Features table |
|3-Apr-07 |Janelle |Version 1.4.0.0, Revision A: updated Supported Features table to state |
| | |Vendor software is required, per the explanation paragraph below the table. |
|30-Jan-08 |DRiddell |Updated to version 1.4.1.0 and update copyright date. |
|4-Mar-08 |Janelle |Version 1.4.1.0, Revision A: updated supported features table, I/O Rate tag |
| | |configuration, ICU screen shots |
|5-Mar-08 |MKelly |Version 1.4.1.0, Revision B; Updated all ICU Control screenshots, added |
| | |missing descriptions for ICU Control related items, minor formatting errors |
| | |corrected, added system digital state restricted ranges information, added |
| | |disconnected startup description. |
|6-Mar-08 |MKelly |Version 1.4.2.0, Added note about the new features only be available for the|
| | |version built for semAPI 2.0 or later (bylsem.exe). |
-----------------------
Status of the ICU
Status of the Interface Service
Service installed or uninstalled
................
................
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
- radians 18 to pi converter
- decimal to pi fraction calculator
- number to pi form calculator
- calculator with the pi button
- calculator with pi and square
- dennis daniel bailey broward county
- academic writing stephen bailey pdf
- covert bailey body fat calculator
- covert bailey formula
- bailey s crossroads community center
- bailey s crossroads shopping center
- bailey s crossroads va