Interface to the pi system
Diagram of Hardware Connection
Download 0.56 Mb.
|
- Navigate this page:
- Installation Checklist
- Windows
- Interface Installation on Windows
Diagram of Hardware Connection
Principles of OperationThe 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 ChecklistFor 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
Stop interface, start buffering, start interface. Interface Installation on WindowsOSIsoft 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.
Directory: interfaces interfaces -> Pi interface for Siemens Spectrum Power tg (Linux) interfaces -> Interface to the pi system Version 37 and Greater interfaces -> Citect Interface interfaces -> How to Contact Us interfaces -> How to Contact Us interfaces -> Emerson Deltav batch Interface Download 0.56 Mb. Share with your friends:
|