OPC Alarms and Events Interface to the PI System
OPC Alarms and Events
Interface to the PI System
for OPC Alarms and Event Servers
Version 1.1.0.65
Document Revision G
How to Contact Us
|Phone |(510) 297-5800 (main number) |
| |(510) 297-5828 (technical support) |
|Fax |(510) 357-8136 |
|E-mail |techsupport@ |
|World Wide Web | |
|Mail |OSIsoft |OSI Software, Ltd |
| |P.O. Box 727 |P O Box 8256 |
| |San Leandro, CA 94577-0427 |Symonds Street |
| |USA |Auckland 1035 New Zealand |
| | | |
| |OSI Software GmbH |OSI Software, Asia Pte Ltd |
| |Hauptstra(e 30 |152 Beach Road |
| |D-63674 Altenstadt 1 |#09-06 Gateway East |
| |Deutschland |Singapore, 189721 |
Unpublished – rights reserved under the copyright laws of the United States.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii)
of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013
Trademark statement—PI is a registered trademark of OSIsoft, Inc. Microsoft Windows, Microsoft Windows for Workgroups, and Microsoft NT are registered trademarks of Microsoft Corporation. Solaris is a registered trademark of Sun Microsystems. HP-UX is a registered trademark of Hewlett Packard Corp.. IBM AIX RS/6000 is a registered trademark of the IBM Corporation. DUX, DEC VAX and DEC Alpha are registered trademarks of the Digital Equipment Corporation.
PI_OPCAE.doc
( 2003-2005 OSIsoft, Inc. All rights reserved
777 Davis Street, Suite 250, San Leandro, CA 94577
Table of Contents
Introduction 1
Reference Manuals 1
Supported Features 2
Diagram of Hardware Connection 3
Principles of Operation 5
Storing Event Attributes 5
Event Categories 6
Handling Time Stamps 8
Connections - Creating, Losing, and Recreating 8
Advising 9
Installation Checklist 11
Interface Installation 13
Naming Conventions and Requirements 13
Interface Directories 13
The PIHOME Directory Tree 13
Interface Installation Directory 14
Interface Installation Procedure 14
Installing the Interface as an NT Service 14
Installing the Interface Service with PI-Interface Configuration Utility 15
Installing the Interface Service Manually 17
PI Point Configuration Tool 19
Configuration Tool Command-line Parameters 19
Digital States 21
PointSource 23
PI Point Configuration 25
Point Attributes 25
Tag 25
PointSource 25
PointType 25
Location1 25
Location2 26
Location3 26
Location4 26
Location5 26
InstrumentTag 26
ExDesc 27
Scan 29
Shutdown 30
Performance Point Configuration 31
I/O Rate Tag Configuration 33
Monitoring I/O Rates on the Interface Node 33
Configuring I/O Rate Tags with PI-ICU (NT-Intel) 33
Configuring I/O Rate Tags Manually 34
Configure the PI Point on the PI Server 35
Configuration Tag on the Interface Node 35
Interface Status Tag 37
Choosing an Interface Watchdog Tag 37
Configuring Interface Status Tag Manually 38
Startup Command File 39
Configuring the Interface with PI-ICU 39
Interface-specific Parameters 41
General Parameters 45
Other Uniint Parameters 46
Command-line Parameters 47
Sample piopcae.bat File 52
Interface Node Clock 55
Security 57
Starting / Stopping the Interface 59
Starting Interface as a Service 59
Stopping Interface Running as a Service 59
Buffering 61
Configuring Buffering with PI-ICU (NT-Intel) 61
Configuring Buffering Manually 65
Example piclient.ini File 66
Debugging 67
Appendix A: Error and Informational Messages 69
General 69
PIPC.log File 69
Troubleshooting 69
System Errors and PI Errors 69
Error Descriptions 69
Appendix B: DeltaV OPC Alarm and Events Server ® 71
Introduction 71
Event Category 71
Vendor Specific Attributes 72
Buffer Times and Max Events 73
Appendix C: DCOM Configuration Details 75
General Steps for DCOM Configuration 76
DCOM Configuration for Windows XP Systems 76
DCOM Configuration for Windows NT/2000 Systems 85
Using DCOM without a Windows NT Primary Domain Controller 92
Using DCOM with an NT Primary Domain Controller 92
OPC Server Registration 92
Revision History 93
Introduction
The OPC Alarms and Events specification defines a means for transmitting alarm and event information between OPC servers and clients. Alarms and events are process alerts that require attention and are defined as follows.
• An alarm is an abnormal condition, for example, a tank level alarm (which may also have these sub-conditions, LO, LOLO, HI, and HIHI).
• An event is a detectable occurrence that usually concerns configuration changes, operator action, system messages or errors.
This document uses the same terms and definitions found in the OPC Alarms and Events Custom Interface Document v. 1.10; and the terms alarm and event are used interchangeably.
The OSIsoft OPC Alarms and Events (PI-OPCAE) Interface receives both alarm and event data, including all three event types (Simple, Tracking-related, and Condition-related.
The PI-OPCAE Interface to PI runs under Windows NT, Windows 2000 or Windows XP Server or Workstation operating systems, on the Intel Platform. The Interface transfers data to PI from these systems.
1. An OPC Alarms and Events Server
2. An OPC DA Server that supports the OPC Alarms and Events interface.
OPC Compatibility
OPC Alarms and Events Custom Interface Standard – 1.10.
Reference Manuals
OSIsoft
• UniInt End User Document
• PI Data Archive Manual
• PI-API Installation Instructions
OPC Foundation
These manuals describe the protocols in detail:
• OPC Alarms and Events Custom Interface (Version 1.10)
• OPC Data Access and OPC Historical Data Archive
Supported Features
|Feature |Support |
|Part Number |PI-IN-OS-OPCAE-NT |
|Platforms |Windows NTI 4.0/W2K/XP/2003 |
|APS Connector |No |
|Point Builder Utility |Yes |
|ICU Control |Yes |
|PI Point Types |Int16, Int32, Float16, Float32, Float64, String, |
| |Digital |
|Sub-second Time stamps |Yes |
|Sub-second Scan Classes |No |
|Automatically Incorporates PI Point Attribute Changes |Yes |
|Exception Reporting |Done by Interface / Done by DCS |
|Outputs from PI |No |
|Inputs to PI: Scan-based / Unsolicited / Event Tags |Unsolicited |
|Maximum Point Count |Unlimited |
|Uses PI-SDK |Yes |
|PINet to PI 3 String Support |No |
|* Source of Time stamps |OPC AE Server / Interface |
|History Recovery |No |
|* Server-Level Failover |Yes |
|Interface-Level Failover |No |
|* UniInt-based |Yes |
|Vendor Software Required on PI Interface/ API / PINet |No |
|node | |
|*Vendor Software Required on DCS System |Yes |
|Vendor Hardware Required |No |
|Additional PI Software Included with Interface |No |
|* Device Point Types |Float16, Float32, Int16, Int32, Digital String |
* See paragraphs that follow for further explanation.
Source of Time Stamps
The Interface accepts time stamps from either the OPC AE server or it can provide time stamps.
Server-Level Failover
This interface supports server-level failover which allows the interface to continue to collect data from the currently active OPC AE server where two servers are running in unison in case of the primary server shutdown or unexpected communication failure.
Uniint-based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by our developers, and is integrated into many interfaces, such as the OPC Alarms and Events interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.
The UniInt End User Document is a supplement to this manual.
Vendor Software Required on DCS System
The OPC AE server can run on the same system as the Interface itself, or it can run on another system. The Interface does not ship with an OSI-supplied OPC AE server.
Diagram of Hardware Connection
[pic]
Principles of Operation
The PI-OPCAE interface is designed to retrieve alarming data from an OPC compliant Alarm and Events Server and store the data in PI. This section describes operation of the interface, including the storage of event attributes, handling of time stamps, making/breaking connections, and OPC advising.
At startup the interface attempts a connection to the OPC AE server, if the server will not start, the interface will perform retries every 5 seconds. The Interface Status Utility can be used to monitor the connections between the server and the interface. Upon connection the interface will check the status of the OPC AE server: RUNNING, FAILED, NOCONFIG, SUSPENDED and TEST. The server time is also retrieved and will be compared to the PI time to compute a bias for the timestamps associated with PI archived events.
Tags to be advised are then added to the interface, and are specific to the event type configured: Simple, Tracking or Condition. When the interface starts, optional Quality/Severity tags are built to store the quality/severity attribute(s) of events when the ExDesc field contains the directive for these optional tags. If these tags already exist, no action is taken. Optional quality/severity tags are only built for conditional event tags. If the ExDesc is edited for the parent tag and one or both directives are removed the tags will not be deleted and the interface will write Scan Off for those tags. If the parent tag is deleted the interface will write Scan-Off also.
Storing Event Attributes
Events have attributes that contain important information about the alarm or event. Some attributes are standard for all OPC AE servers and some are vendor specific attributes are unique to individual servers. There are 2 mechanisms used to store these attributes. The first is to store attributes in a PI tag based on the default set by the interface. These attributes are stored in a PI string tag. Quality and severity attributes associated with conditional events are optional and stored in separate tags
Below is the standard mechanism for storing alarms and events attributes for Simple, Tracking and Condional types:
Simple Events
Simple events are events that store information about a single event such as a system or device failure. Simple event attributes are stored in a single string tag, separated by the pipe character (|), in the order listed below.
1. EventCategory
2. Severity
3. Message
4. OPC States – Enabled/Active/Acked/AckReqd
5. Vendor specific attribute(s) (optional) – VSA(1); …VSA(n);
Tracking Events
Tracking events represent occurrences with changes directed from an OPC AE client with an object in the OPC AE server. An example of a tracking event would be logging of the operator when changes are made to a process point. Tracking event attributes are stored in a single string tag, separated by the pipe character (|), in the order listed below.
1. EventCategory
2. Severity
3. Message
4. OPC States – Enabled/Active/Acked/AckReqd
5. AckReqd
6. OperatorID
7. Vendor-specific attribute(s) (optional) – VSA(1); …VSA(n);
Condition-related Events
Condition-related events are stored as string tags, and represent changes into and out of process states. Example of a condition-related event would be a Temperature Alarm transitioning into a state of High Alarm. All event related information is stored in a single string tag and is separated by the pipe character (|). The Quality and Severity tags are created by the interface during start-up if configured in the ExDesc using the /QY and/or /SY options (Optional – See ExDesc)..
1. Conditions
2. Sub-Conditions
3. Message
4. ActorID
5. OPC States – Enabled/Active/Ackd
6. AckReqd
7. Vendor-specific attribute(s) (optional) – VSA(1);…VSA(n);
8. Quality – tag (Optional – See ExDesc)
9. Severity – tag (Optional – See ExDesc)
The second mechanism used to store alarms and events is to allow the attribute(s) to be stored to be chosen (Attribute PI Tag Identity).
Event Categories
Events are assigned category numbers by the OPC AE server. However category numbering conventions are not standard among different servers. Most OPC AE servers begin numbering event categories from 1, while others may start from a different index.
The interface always begins numbering event categories relative to 1. It is important to relate the lowest OPC AE server event category number to 1 and verify that each event category is listed sequentially. For example, an OPC AE server providing event categories 256, 257, 258, 391, 423 and 424 would be configured in the Interface Configuration Utility as shown in the screenshot below.
[pic]
Note that event category 1 is configured such that it corresponds to event category 256 (the lowest event category number provided by this particular OPC AE server). Also note that OPC AE server event categories appear in the list sequentially, despite gaps between categories 258, 391 and 423.
Proper configuration of event categories is imperative when using location2 for event category filtering (see PI Point Configuration).
Handling Time Stamps
The Interface obtains time stamps from the OPC AE server along with the AE data. The interface adjusts the time stamps to match the time on the PI server. This is done because PI cannot store data in the future, and the PI-OPCAE interface and/or the device may have a clock setting that is different from that of the PI server. The adjustments to the time stamps also correct for clock drift. The Interface attempts to get new time stamps from the PI server and the OPC AE server every 30 seconds.
Note: It is highly recommended that you set both machines to the same time-zone and the same behavior for daylight savings time.
If the OPC AE server does not provide time stamps, or does not provide time stamps for all data, you can use the /TS command line switch (See Command-line Parameters) to adjust the behavior of the Interface.
3. The preferred setting is /TS=Y. This setting causes the OPC AE server to provide time stamps, and does not adjust them only to localize them to the PI server.
4. The default setting is /TS=N. Use this setting when the OPC server cannot provide time stamps. The Interface time stamps each value as it receives it with the time stamp of the PI Server.
5. Using /TS=A causes the interface to adjust the timestamps to match the time on the PI server.
Connections - Creating, Losing, and Recreating
The Interface is very persistent in creating and maintaining a connection with both the OPC AE server and PI. If either is not available at startup, the Interface logs an entry to the pipc.log file and retries the connection periodically. If the Interface loses the connection to the PI server, it continues to gather data and attempts to send it to PI, while it tries to re-establish the connection to PI. It is recommended that you use the PI-API buffering program (bufserv) to avoid losing data if PI is unavailable (See Buffering). If the Interface loses the connection to the OPC AE server it will try to re-establish that connection.
If the connection to PI is lost, the only indication on the PI side is that no data is coming in and I/O Timeout is written to the tag values.
If the connection to the OPC AE Server is lost because the server has been shutdown or has abnormally exited, the interface will try to re-establish the connection for the amount of time specified by the /FT startup parameter. If this time elapses and the connection cannot be re-established, the interfaces attempts to connect to the Backup OPC AE Server, if one has been specified. The above steps are repeated, and the interface tries again to connect to the Primary OPC AE Server if no connection can be made to the Backup OPC AE Server and the wait time has expired. This process continues until a connection is made to one of the two OPC AE Servers specified. The interface will stay on a given server, once connected, until that server fails.
Advising
The Alarms/Events server notifies clients when a change in data has occurred. Read-on-change points are advised, which means that the OPC AE server sends data whenever a new value is read into the server's cache. The PI-OPCAE Interface does advise operations only and does not poll for new values.
Installation Checklist
For those users who are familiar with running PI data collection interface programs, this checklist helps you get the PI-OPCAE Interface running. If you are not familiar with PI interfaces, return to this section after reading the rest of the manual in detail.
1. Install the PI-Interface Configuration Utility (which installs PI-SDK and PI-API)
2. Verify that PI-API has been installed.
3. Install the Interface.
4. Configure DCOM permissions. If the PI-OPCAE Interface and the OPC Server are on different nodes, configure DCOM settings for both nodes
5. Test the connection between the Interface node and the foreign device using the configuration tool.
6. Define digital states.
7. Choose a point source.
8. Configure PI points.
InstrumentTag specifies the OPC AE server source or /ALL for all sources.
Location1 is the interface instance.
Location2 specifies the event categories for this event
Location3 specifies the event-type (Simple, Tracking, Condition-related).
Location4 should be set to zero for all points.
Location5 specifies area filtering for this event.
ExDesc specifies which attribute(s) and vendor specific attribute identities are to be stored in the PI tag, along with the optional quality and severity tag directives.
UserInt1 specifies the attribute index where the area name is stored.
9. Configure I/O Rate tag.
10. Edit start-up command file.
11. Set interface node clock.
12. Set up security.
13. Start the Interface without buffering.
14. Verify data.
15. Stop Interface, start buffering, start Interface.
Interface Installation
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 interfaces as manual services that are launched by site-specific command files when the PI Server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI Server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI Server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI Server node. See the UniInt End User Document for special procedural information.
Naming Conventions and Requirements
In the installation procedure below, it is assumed that the name of the interface executable is piopcae.exe and that the startup command file is called piopcae.bat.
It is customary for the user to rename the executable and the startup command file when multiple copies of the interface are run. For example, one would typically use piopcae1.exe and piopcae1.bat for interface number 1, piopcae2.exe and piopcae2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in a file that has the same root name.
Interface Directories
The PIHOME Directory Tree
The PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the WinNT directory. A typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=c:\pipc
The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
Place all copies of the interface into a single directory. The suggested directory is:
PIHOME\interfaces\opcae\
Replace PIHOME with the corresponding entry in the pipc.ini file.
Interface Installation Procedure
The PI-OPCAE interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000. When running on Windows NT 4.0 systems, the PI-OPCAE setup program will install the Windows Installer itself if necessary. To install, run the OPCAE _x.x.x.x.exe installation kit.
Installing the Interface as an NT Service
The PI-OPCAE interface service can be created, preferably, with the PI-Interface Configuration & Management Utility, or can be created manually.
Installing the Interface Service with PI-Interface Configuration Utility
The PI-Interface Configuration & Management Utility provides a user interface for creating, editing, and deleting the interface service. For example:
[pic]
Service Configuration
Service Name
The Service to Add box shows the name of the current interface service. This service name is obtained from the interface executable.
Display Name
The Display Name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of the OSI suite of products.
Service Type
The Service Type indicates whether the interface service will start automatically or need to be started manually on reboot.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, interface services are set to start automatically.
Dependencies
The Installed services list is a list of the services currently installed on this machine. Services upon which this Interface is dependant should be moved into the Dependencies list using the [pic] button. For example, if API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left.
When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.
Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.
[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:
piopcae.exe –help
Change to the directory where the piopcae1.exe executable is located. Then, consult the following table to determine the appropriate service installation command.
|NT Service Installation Commands on a PI Interface Node or a PI Server node |
|with Bufserv implemented |
|Manual service |piopcae.exe –install –depend “tcpip bufserv” |
|Automatic service |piopcae.exe –install –auto –depend “tcpip bufserv” |
|Automatic service with Service |piopcae.exe –serviceid x –install–auto –depend “tcpip bufserv” |
|ID | |
|NT Service Installation Commands on a PI Interface Node or a PI Server node |
|without Bufserv implemented |
|Manual service |piopcae.exe –install –depend tcpip |
|Automatic service |piopcae.exe –install –auto –depend tcpip |
|Automatic service with service |piopcae.exe –serviceid x –install –auto –depend tcpip |
|id | |
When the interface is installed as a service on the PI Server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will repeatedly attempt to connect to the PI Server until it is successful.
Note: Interfaces are typically not installed as automatic services when the interface is installed on the PI Server node.
Check the Microsoft Windows NT services control panel to verify that the service was added successfully. One can use the services control panel at any time to change the interface from an automatic service to a manual service or vice versa.
PI Point Configuration Tool
The PI-OPCAE Tag Configuration Tool is a command-line utility that aids in the creation of PI points from the OPC AE Server. When the tool is executed, it browses the OPC AE server and gets the alarm attributes needed to configure a PI tag. However, there may be a need to edit the generated file in order to change parameters such as location2 and ExDesc, which are not specified explicitly by the configuration tool.
The tool also prints out information about the OPC AE server’s supported areas, event categories and vendor specific attributes. This information is used to specify tag and interface event category support, vendor specific attribute support on an event category basis and areas.
The tool can also be run in list mode using the -lst command line argument. In list mode the tool will only list the OPC AE servers registered on the machine. This name is to be used for the –server command argument for the server name to create PI tags. If the OPC AE server exists on a separate node, use the –node argument to specify the node name. Type the following at the command prompt for list mode:
\interfaces\piopcae\AEConfig.exe –lst –node=hge1005ae
The example below shows how to execute the tool to get the information that is required to build tags. The table immediately below contains a listing of the optional and required arguments. Note that the –id and –ps must match exactly those parameters that are passed in the interface startup file.
PIHOME\interfaces\opcae\AEConfig.exe –node=hge1005ae ^
server=DELTAV.OPCEVENTSERVER.1 –ps=e -id=1
Configuration Tool Command-line Parameters
|Parameter |Description |
|-area (Optional) |Use this parameter to specify the area to start at when parsing the OPC AE Server. |
| |If this parameter is blank or not specified, the tool will parse everything on the |
| |server. |
|-db (Optional) |Logging for internal data translation and is helpful for PI Tech Support. |
|-id (Required) |The interface id to use to specify the PItags which belong to the interface. This |
| |should be the same value that is passed in the interface startup file. |
|-lst (Optional) |Use this parameter to list all the OPC AE server names registered on the server |
| |node. |
|-node |Specifies the node where the OPC AE server is running (optional). This argument is |
|(Required if interface not |needed only when executing the configuration tool on a separate node from the OPC AE|
|loaded on OPC AE server |server. |
|node, otherwise optional) | |
|-path (Optional) |The path to the directory where the .csv file will be written. If this parameter is|
| |blank or not specified, the .csv file will be written to the directory where the |
| |PI-OPC AE interface is installed. |
|-ps (Required) |The point source to use to specify the PI tags which belong to the interface. This |
| |should be the same value that is passed in the interface startup file. |
|-server (Required) |Specifies the name of the server |
| |(i.e. DELTAV.OPCEVENTSERVER.1 ) |
| |The server names will be listed when the configuration tool is run in list mode by |
| |specifying the -lst command argument |
To build PI-OPCAE interface tags, use the output file, “piopcae_config.csv”, from the configuration tool within PI-SMT to export the tags to PI. A sample file, “piopcae_sample_config.csv”, is included with the install and is located in the same directory as the AEConfig.exe tool.
Digital States
For more information regarding Digital States, refer to the Data Archive Manuals.
PI 2 Home Node
Digital states are defined by running the Digtl Stat display from the PI menu. The states must be contiguous for each status type and may be anywhere within the Digital State Table outside of the range 193 – 320, which is reserved for OSIsoft. The digital states need to be defined prior to point configuration. The digital state sets described in the PI 3 sections below should be entered into the PI 2 Digital State Table.
For more information, see the DA manual.
PI 3 Home Node
Digital State Sets
PI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI digital tags and editing digital state sets, see the PI 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.
The Interface Status Utility may be used to track the status of this interface on the PI Server. It uses a digital tag to track the status. The digital state set for that tag should contain 3 digital states. The first digital state in the set should indicate a good interface status, the second digital state should indicate a bad interface status, and the third digital state should indicate that interface watchdog tag was deleted and that the PI Interface Status tag is invalid. An example is the DigitalSet InterfaceStatus containing the digital states:
• 0: Receiving Data
• 1: Not Receiving Data
• 2: Invalid
System Digital State Set
Similar to digital state sets is the system digital state set. This set is used for all tags, regardless of type to indicate the state of a tag at a particular time. For example, if the interface receives bad data from an interface point, it writes the system digital state bad input to PI instead of a value. The system digital state set has many unused states that can be used by the interface and other PI clients.
PointSource
The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For example, one may choose the letter O to identify points that belong to the PI-OPCAE Interface. To implement this, one would set the PointSource attribute to O for every PI Point that is configured for the PI-OPCAE Interface. Then, if one uses /ps=O on the startup-command line of the PI-OPCAE Interface, the PI-OPCAE Interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of O. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps argument.
Case-sensitivity for PointSource Attributes
If the interface is running on a PINet node and the Server node is a PI 3 system, use a capital letter (or a case-insensitive character such as a number, a question mark, etc.) for the PointSource attribute when defining points. For all other scenarios, one does not need to be careful with the case of the PointSource.
In all cases, the point source character that is supplied with the /ps command-line argument is not case sensitive. That is, /ps=O and /ps=o 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.
No point source table exists on a PI 3 Server, which means that points can be immediately created on PI 3 with any point source character. Several subsystems and applications that ship with PI 3 are associated with default point source characters. The Totalizer Subsystem uses the point source character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Either do not use these point source characters or change the default point source characters for these applications. Also, if one does not specify a point source character when creating a PI point, the point is assigned a default point source character of L. Therefore, it would be confusing to use L as the point source character for an interface.
PI Point Configuration
The PI point is the basic building block for controlling data flow to and from the PI Data Archive. A single point is configured for each measurement value that needs to be archived. Use the point attributes below to define what data to transfer.
Point Attributes
The following database details are necessary for configuring a PI point for use with the OPC Alarms and Events Interface.
Tag
This attribute is the name of the PI point. Any tag name can be used, according to the normal PI point naming conventions. This tag is assigned to the condition, which is unique within the server (e.g. PI-tag “Boiler1LevelAlarm” assigned to Boiler1.FIC1001 within the OPC AE server).
PointSource
The PointSource is a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line argument and the "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.
The Interface itself supports all PI point types except the BLOB, but not all OPC AE servers support all point types. All user created tags must be of PI type string.
Float16, Float32, Int16, Int32, Digital, and String point types are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for NT and UNIX.
Location1
The Location1 attribute associates a point with a particular copy of PI-OPCAE. Location1 is a positive integer. Its value is equal to the -id= parameter used in the startup command file (described later) and must match. For example, if -id=1 then you should set Location1 to 1.
Note: It is possible to start multiple interface processes on different PI Nodes. However, a separate Software License for the Interface is required per PI Node.
Location2
Use this location to specify the event categories in a bit pattern. For example, if event categories 1, 2, and 3 (0111) are to be specified, then set location2 = 7. For those servers whose event category does not begin at 1, it is important to relate the lowest event category number to 1. . This relation may be performed either in the PI Point Configuration Tool (see PI Point Configuration Tool section), or at the command line used to start the interface (see Startup Command File section).
For example, if the first event category provided by the AE server begins at 256, the first event category configured in the Configuration Tool should be 256.
Accurate Location2 configuration can only be performed by manually editing the PI Tag.
Location3
Use this location to specify the event-type (Simple, Tracking, Condition-related).
• Use 0 to indicate a Simple Event
• Use 1 to indicate a Tracking Event.
• Use 2 to indicate a Condition-related Event.
Location4
This attribute should be set to zero.
Location5
This attribute should be set to zero.
InstrumentTag
The instrument tag can be up to 1024 characters in length.
Several attributes are associated with an OPC alarm or event. You can archive any or all these attributes, and you must specify them as a PI tag. Use the Instrument Tag attribute to configure the Alarm/Event source in the OPC AE server. Use a specification of area as a prefix to the source by using the delimiter specified by the OPC AE server as a separator, as shown in these examples. In most cases, the configuration tool will specify the source with the appropriate separator for the server. It is recommended that source names be unique. If source names are not unique then the area needs to be specified along with the source and separated by the proper separator character.
/ALL – This directive specifies ALL sources and directs the interface to archive all events generated by the OPC AE server to this PI tag.
FIC1001 – Specifies only the source.
Boiler1.FIC1001 – Specifies the area and source.
Boiler1\FIC1001 – Specifies the area and source where the separator is a slash
ExDesc
The ExDesc can be up to 1024 characters in length.
The ExDesc is used to specify multiple configuration items. This field is used to specify if the optional Quality and Severity tags are to be configured. Also this field is used to identify the attribute(s) to be stored. Finally this field is used to identify the vendor specific attributes (0-n) to be stored. Multiple parameters may be specified, each separated by a comma.
Configuring Severity and Quality Tags
Use the ExDesc attribute to configure the optional Quality (/QY) and Severity (/SY) tags associated with conditional event tags only (where the location3 field of the PI Tag contains a 2). This attribute can be up to 1024 characters in length. These tags are built by the interface when this field contains the directive. These tags will not be deleted if the parent PI tag is deleted, instead Scan-Off will be written. If the ExDesc of the parent tag is edited and one or both directives are removed the tags will not be deleted and the interface will write Scan-Off for those tags.
For example, to store the quality attribute of the event in PI, then use the /QY argument. The interface will create the tag at start-up with a _QY suffix on the PI tag name. For example, if the PI tagname is Boiler1LevelAlarm, then the tag name for the quality tag is Boiler1LevelAlarm_QY.
The PI-OPCAE interface conforms to the OPC Data Access standard. The OPC Data Access standard uses Fieldbus quality flags. The interface translates those quality flags to the closest approximation within the PI System State table, OPC_AE_QUAL (built by the interface). The low 8 bits of the Quality flags are currently defined in the form of three bit fields, Quality, Sub-status and Limit status. The 8 Quality bits are arranged as follows:
QQSSSSLL
Good Quality
|Quality |OPC Definition |PI Status |
|11SSSSLL |Non-specific |Good |
|Except | | |
|110110LL |Local Override |_SUBStituted |
Not Used by OPC
|Quality |OPC Definition |PI Status |
|10SSSSLL |Invalid |Bad Input |
Questionable
|Quality |OPC Definition |PI Status |
|010110LL |Sub-Normal |Bad_Quality |
|010101LL |Engineering Units Exceeded | |
|QQSSSS01 |Low Limited |Under LCL |
|QQSSSS10 |High Limited |Over UCL |
|Otherwise | |Inp OutRange |
|010100LL |Sensor Not Accurate | |
|QQSSSS01 |Low Limited |Under Range |
|QQSSSS10 |High Limited |Over Range |
To store the Severity tag the interface creates this tag at start-up with a _SY suffix on the PI tag name. For example, to store the severity attribute of the event in PI, then use the _SY argument. If the PI tagname is BoilerLevelAlarm, then the tag name for the severity tag is Boiler1LevelAlarm_SY.
The severity is a 4-byte integer in a range set by the server, which is normally a value from 1 to 1000.
Attribute PI Tag Identity
When storing all events/alarms attributes in separate PI tags, use the argument /att and the appropriate value(s) in the table below to identify the attribute to be stored. Using the /att allows the flexibility of what attribute(s) are stored for a particular alarm/event. A single attribute can be configured (i.e. /att=COND) or multiple attributes (i.e. /att=EVC,SUB,MES).The keywords are listed in the table below:
|Attribute |Keyword |
|Source |SRC |
|Condition |COND |
|SubCondition |SUB |
|EventCategory |EVC |
|Severity |SEV |
|Message |MES |
|ActorID/ OperatorID|ACT |
|Enabled |ENB |
|Active |ACV |
|Ackd |ACD |
|AckReqd |ARD |
|Quality |QUAL |
|VSA1…VSAn |VSA1…VSAn |
Note: When specifying multiple attributes the order stored is the same as the table above.
Using VSA1…VSAn in the Attribute PI Tag Identity
The VSA specification in the /att is a relative offset into the actual VSA offset specified by the /evc command parameter (Command-line Parameters). Consider the following Attribute PI Tag Identity when the startup command line contains the event category definition /evc1=1,1,2,3,4,11,12 or the equivalent entry exists in the Interface Configuration Utility:
When /att=COND,VSA1,VSA4,VSA5 then the event/alarm condition, VSA1,VSA4 and VSA11 are archived. Note that the VSA number in the /att setting is used as an index (1-based) into the /evc1 command line argument.
Warning: VSAs requested in this field must be configured either manually in the startup batch file or by the Interface Configuration Utility. Verify correct configuration of the /evc command argument to ensure correct behavior.
Using SRC in the Attribute PI Tag Identity
This feature may be used at anytime, although it is most useful when ‘/ALL’ has been specified in the instrumenttag (see section PI Point Configuration – InstrumentTag). It is designed to add the the source name to archived data so that when ALL events are archived to this point, events from different sources may be distinguished. Area events, however, have no source. For area events, the interface will attempt to retrieve the area name for use in place of the source name.
Vendor Specific Attributes Identity
Because vendor specific attributes are different between systems and event categories, it can sometimes be useful to label the attributes. This field can be used to ‘name’ a specific VSA attribute. This enhances the support for alarms and events client tools, such as PI-AlarmView, when identifying the attributes for display. For example, if vendor attribute 1 is the ‘Area’ then to identify it in the PItag, set the ExDesc to /vsa1=”Area”. This can be used by client tools to display the field name along with the value for this attribute.
Example use of the ExDesc
Below is an example of configuring the ExDesc attribute with the quality tag, severity tag, PI tag identity and vendor attributes identity.
/QY,/SY,/att=sub, /VSA1="Alarm Name"
Scan
The Scan attribute has the default value of 1, indicating that the Interface should collect data for the point. Setting the Scan attribute to 0 turns data collection off. If the Scan attribute is 0 when the interface starts, the Interface writes SCAN OFF to the point. If you change the Scan attribute from 1 to 0 while the interface is running, the Interface also writes SCAN OFF.
There is one other situation, which is independent of the Scan attribute, where the Interface will write SCAN OFF to a 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 Interface removes the point and writes SCAN OFF. For example, if you change the PointSource of a PI point that is currently loaded by the Interface, the Interface removes this point and writes SCAN OFF.
Shutdown
The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of a power failure. For additional information on shutdown events, refer to PI Data Archive for NT and UNIX.
Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat=Shutdown command-line argument is specified.
One can disable SHUTDOWN events from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Data Archive for NT and UNIX.
Performance Point Configuration
Many interfaces support configuration of performance points through either the PI-ICU or manually. Performance points are irrelevant for this interface since the data collection method is unsolicited.
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 NT nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.
Configuring I/O Rate Tags with PI-ICU (NT-Intel)
The PI-Interface Configuration & Management Utility (PI-ICU) provides a user interface for creating and managing IORates Tags.
[pic]
PI-ICU currently allows for one I/O Rate tag to be configured for each copy of the interface in use. Some interfaces allow for multiple I/O Rates tags.
Enable IORates for this Interface
The Enable IORates for this interface check box enables or disables IORates for the current interface. To disable IORates for the selected interface, uncheck this box. To enable IORates for the selected interface, check this box.
Tag Status
The Tag Status column indicates whether the IORates tag exists in PI. The possible states are:
• Created - tag exists in PI
• Not Created - tag does not yet exist in PI
• Deleted - tag has just been deleted
• Unknown - ICU is not able to access the PI Server
In File
The In File column indicates whether the IORates 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 IORates tag.
Right Mouse Button Menu Options
6. Create – Create the suggested IORates tag with the tag name indicated in the Tagname column.
7. Delete – Delete the IORates tag listed in the Tagname column.
8. Rename – Allows the user to specify a new name for the IORates tag listed in the Tagname column.
9. Add to File – Adds the tag to the IORates.dat file with the event counter listed in the Event Counter Column.
10. Search – Allows the user to search the PI Server for a previously defined IORates tag.
Configuring I/O Rate Tags Manually
There are two configuration procedures, described in the next sections.
Configure 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 |
Configuration Tag on the Interface Node
For the following examples, assume that the name of the PI tag is PIOPCAE001, and that the name of the I/O Rate on the home node is PIOPCAE001.
1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the \WinNT directory. If both are specified, the PIPCSHARE entry takes precedence.
Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.
2. Add a line in the iorates.dat file of the form:
PIOPCAE001, x
where PIOPCAE001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. x can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.
3. Set the /ec=x flag on the startup command file of the interface to match the event counter in the iorates.dat file.
The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.
Interface Status Tag
See the manual for the utility for more information.
The PI Interface Status Utility provides a means of indicating to a user that data from a given interface is stale; i.e. that no fresh data is being sent from the interface to the PI Server. This can occur if one of the following scenarios exists:
• The interface is running but the PI API node cannot send data to the PI Server.
• The interface is not running and a system digital state was not written to indicate that the interface has been shut down.
One PI Interface Status tag is configured per monitored interface and each tag monitors a watchdog tag collecting data from the interface. If the watchdog tag’s value on the PI server hasn’t updated after a user-specified amount of time, the PI Interface Status tag’s status changes to a bad digital state status. PI Interface Status runs on a PI server, so it will continue to display the interface’s status even if the connection between the interface and PI home node goes down.
Choosing an Interface Watchdog Tag
PI Interface Status monitors a watchdog tag to determine the status of the monitored interface. When choosing an interface watchdog tag, several things should be taken into consideration:
• Update Rate of Watchdog Tag
The interface watchdog tag’s scan rate should reflect the scan rate of the majority of the monitored interface’s tags. For example, if the majority of the monitored interface’s tags have a scan rate of 10 seconds, the interface watchdog tag should have a scan rate of 10 seconds.
The interface watchdog tag’s scan rate should be slightly more frequent than the monitor frequency (location4) of the PI Interface Status tag. For example, if you want PI Interface Status to monitor an interface every 1 minute, its interface watchdog tag should be updating around every 30 seconds.
• Monitor Frequency of PI-Interface Status Utility Tag
The monitor frequency of the PI Interface Status tag should depend upon the scan rates of the monitored interface’s tags. A monitor frequency that’s a little less frequent that the majority of the scan rates for the monitored interface’s tags should be chosen. For example, an interface with most of its tags scanning every 30 seconds could have a monitor frequency of 1 minute. An interface with most of its tags scanning every second could have a monitor frequency of 10 seconds.
Configuring Interface Status Tag Manually
Create an Interface Status Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |Digital |
|Compressing |1 |
|ExcDev |0 |
|Location1 |Interface copy number |
|Location2 |0: Do NOT write Bad status to interface tags |
|Location3 |0 |
|Location4 |Scan class: Check the startup file for the PI Interface |
| |Status Utility |
|Location5 |Don’t care |
|InstTag |Name of Watch Dog tag |
|ExDesc |/ps= |
|DigitalSet |Name of set (PI 3) |
|or | |
|DigStartCode |First digital state for this tag (PI 2) |
Startup Command File
Command-line arguments can begin with a / or with a -. For example, the /ps=M and -ps=M command-line arguments are equivalent.
Command file names have a .bat extension. The NT, 2000, XP continuation character (^) allows multiple lines to be used for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of flags is unlimited, and the maximum length of each flag is 1024 characters.
The PI-Interface Configuration & Management Utility (PI-ICU) provides a tool for configuring the Interface startup command file. You can enter parameters not provided by the PI-ICU in the Additional parameters section.
Configuring the Interface with PI-ICU
Note: PI-ICU requires PI 3.3 or greater.
The PI-OPCAE control for PI-ICU has 2 sections. A yellow text box indicates that an invalid value has been entered, or that a required value has not been entered.
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 (piopcae.bat) will be maintained by the PI-ICU and all configuration changes will be kept in that file. The procedure below describes the necessary steps for using PI-ICU to configure the PI-OPCAE Interface.
From the PI-ICU menu, select Interface, New, and then Browse to the piopcae.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.
You should then see a display such as the following:
[pic]
Note that in this example the Host PI System is localhost, which means that the interface will be configured to communicate with the local PI Server. However, if you want the interface to communicate with a remote PI Server, you can do this by selecting ‘Connections…’ item from PI-ICU menu and make it your default server. If you do not see the remote node in the list of servers, you can add that in.
Once you add the interface to PI-ICU, near the top of the main PI-ICU screen, the Interface Type should be OPCAE. If not, use the drop-down box to change the Interface Type to be OPCAE.
Click on Apply to enable the PI-ICU to manage this copy of the PI-OPCAE Interface.
[pic]
Interface-specific Parameters
The following interface-specific parameters can be configured on the General section of the OPCAE tab shown above.
Node
This optional parameter is the name of the computer (node name) where the OPC Alarms and Events Server runs. Enter the node name in the text box or use the triple dot button to browse to and select the OPC AE node. When no node is specified, it is presumed by the interface that the OPC AE server is on the interface node. The command-line parameter equivalent is (/NODE=nodename).
Server
This required parameter is the name of the OPC AE Server as registered on the OPC AE server node. The command line parameter equivalent is (/SERVER=servername).
Status tag
This optional parameter is the name of a PI digital tag to receive the status of the OPC AE server. Enter the name of the OPC status tag in the textbox or use the adjacent triple dot button to browse to the status tag. (/ST=tagname)
Area index
This optional parameter is used to specify the index into the vendor specific array that holds the Area name. Some OPC AE servers (e.g. DeltaV) specify the area separate from the source name in the event data. In those cases the element index is needed for event processing. If not specified the default is 4 for the DeltaV system. (/AI=x).
Buffer time
This optional parameter is in milliseconds and tells the server how often to send event notifications. The default value of 0 for buffer time means that the server should send event notifications as soon as it gets them. (/BTM=#)
Maximum number of events
This optional parameter is the maximum number of events that will be sent in a single notification. A value of 0 means that there is no limit to the number of events that will be sent in a single callback. (/MXE=#)
Timestamp source
Some OPC AE servers are able to provide the time stamp at which they read data from the device, while others are not. If your server is able to provide valid time stamps, select the ‘OPC AE server provides timestamps’ option in the Timestamps section of the OPCAE tab. Otherwise, the interface will time stamp the data when it receives it. (/TS=x, where x is Y, A, or N)
The preferred setting is /TS=Y. This setting causes the OPC AE server to provide time stamps, and does not adjust them only to localize them to the PI server. The default setting is /TS=N. Use this setting when the OPC server cannot provide time stamps. The Interface time stamps each value as it receives it with the time stamp of the PI Server. Using /TS=A causes the interface to adjust the timestamps to match the time on the PI server.
Use subseconds
Check this option if you want to use the subsecond portion of the time stamps being passed to PI. By default, the interface will not use subseconds and send only whole integer seconds. This means that PI will require less space, and possibly less CPU time, to store the same amount of data. The fractional part of the second is simply truncated. (Specify /UST to use subseconds, leave blank to discard subseconds)
Debugging
For debugging purposes you can set the interface to send extra interface specific messages to the pipc.log file. You can select which of 7 different types of debugging messages you want to send to the log by checking the appropriate check box(es) in the Debugging section of the opcalevt tab. For details of the available options see the Debugging section. If you want to send all possible debugging messages, check the Maximum check box. (/DB=#, where # is 1, 2, 4, 8, 16, 32, 64 or a combination of any or all values, maximum=127)
Debug tag
This optional parameter is for use with the ‘Log information for tag’ debugging option. When this option is selected information for the specified debug tag will be written to the pipc.log file. Enter the name of the debug tag in the textbox or use the adjacent triple dot button to browse to the debug tag. If the textbox is left blank, messages will be logged for the first interface tag that receives data. (/DT=tagname)
Additional Parameters
This text box is included so that any additional parameters not currently support by the ICU Control can be added to the interface. Parameters should be entered into the additional parameters textbox in command-line format with each parameter starting with a “/”character.
Event categories
The Event Categories tab shown below can be used to specify which event categories and event attributes are to be supported. Each row in the list specifies a different event category and its requested attributes.
To add an event category to the list select the [pic] button. Enter the number of the event category in the box provided in the Event category column and hit Enter. Then enter the required attributes separated by commas (eg 1,3,5,7) in the box provided in the Event attribute column. To edit an existing event category or attribute click once in the Event category or Event attribute cell to select the entry and click again to activate the text box to allow you to edit the entry.
[pic]
To delete an event category and the associated attributes from the list, select the row by clicking on the number adjacent to the event category row and then select the [pic] button. You can use the [pic] buttons to change the order of the selected event category in the list. (/EVCx=#,#,#,… where x is the event category and # are the event attributes)
For more information on event category configuration see Principles of Operation: Event Categories.
[pic]
Server-Level Failover
This selection provides you with specific parameters for setting up server-level failover options of the interface. The PI-OPC AE interface is designed to provide redundancy for the OPC AE server. For server-level failover, the interface can be configured to change to another server when the current server no longer serves data or when the server changes state. For this, primary and secondary/backup OPC AE servers must be specified.
Server-Level Failover
1. Backup OPC AE Server Name -- The name of the backup OPC AE Server (/bSERVER=BACKUP SERVERNAME).
2. Backup OPC AE Server Node – The node where the backup OPC AE server is running (/backupNode=backupNode).
3. Current Active Server Tag -- The string tag into which should be written the name of the currently active OPC AE Server (/CS=tag).
4. Number of seconds to try to connect before switching to backup server: The number of seconds to try to connect, before switching to the backup OPC AE Server (/FT=#).
5. Number of seconds to wait for RUNNING State before switching to backup server: The number of seconds to wait for RUNNING status, before switching to the backup OPC AE Server (/SW=#).
[pic]
General Parameters
The following parameters can be configured on the General PI-ICU tab shown above:
Point source
The point source is used to identify points for this interface and is a required parameter. The point source that is assigned with this 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. The point source is generally a single character but if the PI-SDK is enabled can be more than one character. The point source is case insensitive. (/PS=E)
Host
This is the PI server node. Select the PI server from the drop down list. If the server is not listed in the drop down list, use the triple dot button to browse to the Connections Dialog and add the server. The added server will then be available in the drop down list. (/HOST=hostname[:port])
Interface ID #
This required parameter is an integer that is used to identify a particular copy of an interface. The ID should match the value in Location 1 of points for this copy of the interface. This identifier is also added to the header that is used to identify error messages as belonging to a particular interface. (/ID=#)
Other Uniint Parameters
Other optional parameters that can be configured on the UniInt tab include:
Enable PI-SDK
By default, the PI-SDK is disabled. If the PI-SDK is enabled, the ExDesc tag attribute can be 1024 characters long instead of 80 characters long. In addition, the excmin and excmax tag attributes will be full 32-bit values, and the point source can have more than one character. To enable the PI-SDK select the Enable radio button in the PI-SDK section of the UniInt tab. (/PISDK=x)
Queue Data
Exceptions can be queued before they are sent to the PI Server node. Queuing exceptions causes the interface to be more efficient, if the interface is on a separate computer from the PI Server. However, it will slightly delay the update of the snapshot value if the data rate is low. The maximum queue size is close to 4000 bytes. The queue is flushed between scans if it is not filled. To use this option check “Queue data” in the Data Handling section of the UniInt tab. (/Q)
Write Digital State to Tags on Shutdown
The interface can be configured to write a digital state to each PI point serviced by the interface when the interface shuts down. To use this option check “Write status to tags on shutdown” in the Data Handling section of the UniInt tab and select the required digital state from the dropdown list. If this option is not checked nothing will be written to the interface points when the interface shuts down. (/shutdown=digstate)
Note: The UniInt End User Document includes details about other command line parameters, which may be useful.
Command-line Parameters
Before the interface starts, a file containing the configuration parameters must be created. The command-line arguments will need to be modified for your site and interface. The PI-ICU is the preferred method for modifying this file.
At startup, the interface interprets the command-line arguments. The command-line arguments define the point source, scan frequency, and many options specifying how to communicate with the OPC AE server. All arguments must begin with a slash character (/), have a space between them, and have no spaces within the argument. The arguments are not case sensitive. A point source, scan class, and OPC AE server must be defined for the interface to start.
|Parameter |Description |
|/AI=# |The /ai flag is used to specify the index into the vendor specific array that holds |
|Optional |the Area name. |
|Default: /ai=4 |Some OPC AE servers specify the area separate from the source name (i.e. DeltaV) in |
| |the event data. In those cases the element index is needed for event processing. |
| |If not specified the default is 4 for the DeltaV system. |
| |/ai= |
|/BACKUPNODE=name |Use this parameter to specify the node where the Backup OPC AE Server resides. For |
|Required if interface not loaded |example, |
|on the OPC AE Backup Server node;|/BACKUPNODE=FACT1NODE |
|otherwise optional. |where FACT1NODE is the name of the computer (node name) where the Backup OPC AE |
| |Server runs. When no node is specified then the Backup OPC AE Server is presumed by |
| |the interface to exist on the interface node. |
|/BSERVER=name |Use this parameter to specify the backup OPC AE Server to use. For example, |
|Optional |/BSERVER=DELTAV.OPCEVENTSERVER.1 |
|Default: none |where DELTAV.OPCEVENTSERVER.1 is the name of the Backup OPC AE Server as registered |
| |on that machine. |
| |If your server name has embedded spaces, enclose the name in double quote. For |
| |example: |
| |/BSERVER="Server name with spaces" |
|/BTM=# |The requested buffer time. The buffer time is in milliseconds and tells the server |
|Optional |how often to send event notifications. This is a minimum time - do not send event |
|Default: /BTM=0 |notifications any faster than the buffer time unless it is greater than 0, a value |
| |of 0 for buffer time means that the server should send event notifications as soon |
| |as it gets them. This parameter, along with the max size (/MXE) parameter, is used |
| |to improve communications efficiency between client and server. This parameter is a |
| |recommendation from the client, and the server is allowed to ignore the parameter. |
| |In some instances the default value will not function correctly, in this case, try |
| |using a value of 10000 (10 sec). If this is successful try changing this parameter |
| |to enhance performance for a particular setup. |
|/CS=tagname |The string tag into which should be written the name of the currently active OPC AE |
|Optional |Server. |
|Default: none | |
|/DB=# |This is included to allow some minimal debugging if you have difficulty figuring out|
|Optional |what you're getting from your server. See the section on Debugging for more |
|Default: none |information. |
|/DT=tagname |The name of the tag to be used with /DB=4. If this tag is not specified, the |
|Optional |interface will use the first tag for which it receives a value. |
|Default: none | |
|/EC=# |The first instance of the /ec flag on the command line is used to specify a counter |
|Optional |number, x, for an I/O Rate point. If x is not specified, then the default event |
|Default: 1 |counter is 1. Also, if the /ec flag is not specified at all, there is still a |
| |default event counter of 1 associated with the interface. If there is an I/O Rate |
| |point that is associated with an event counter of 1, each copy of the interface that|
| |is running without /ec=x explicitly defined will write to the same I/O Rate point. |
| |This means that one should either explicitly define an event counter other than 1 |
| |for each copy of the interface or one should not associate any I/O Rate points with |
| |event counter 1. Configuration of I/O Rate points is discussed in the section called|
| |I/O Rate Tag Configuration. |
| |For interfaces that run on NT nodes, subsequent instances of the /ec flag may be |
| |used by specific interfaces to keep track of various input or output operations. One|
| |must consult the interface-specific documentation to see whether subsequent |
| |instances of the /ec flag have any effect. Subsequent instances of the /ec flag can |
| |be of the form /ec*, where * is any ASCII character sequence. For example, |
| |/ecinput=10, /ecoutput=11, and /ec=12 are legitimate choices for the second, third, |
| |and fourth event counter strings. |
|/EVC1=#, EVC2=#, EVC3=#, |Use this parameter to specify which event categories and event attributes are to be |
|…/EVC32=# |supported. Each argument specifies a different event category and its requested |
|Required if location2 is |attributes. For example, if event category 1 has attributes 1 through 10, but |
|specified and event category is |attributes 3, 5 and 7 are the only requested arguments, then /EVC1=1,3,5,7 . You do|
|not 1. |not need to relate the argument number with the event category; you can specify |
| |/EVC2=10,1,2,3 . The supported event categories and attributes are printed out using|
| |the configuration tool. (Refer to section – PI Point Configuration Tool. |
|/FT=# |The number of seconds to try to connect, before switching to the Backup OPC AE |
|Optional |Server. |
|Default: /FT=10 | |
|/host=host:port |The /host flag 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 and 545 for a PI 2 |
| |Server. It is recommended to explicitly define the host and port on the command line|
| |with the /host flag. Nevertheless, if either the host or port is not specified, the |
| |interface will attempt to use defaults. |
| |Defaults: |
| |The default port name and server name is specified in the pilogin.ini or |
| |piclient.ini file. The piclient.ini file is ignored if a pilogin.ini file is found. |
| |Refer to the PI-API Installation Instructions manual for more information on the |
| |piclient.ini and pilogin.ini files. |
| |Examples: |
| |The interface is running on a PI-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 flags |
| |would be: |
| |/host=marvin |
| |/host=marvin:5450 |
| |/host=206.79.198.30 |
| |/host=206.79.198.30:5450 |
|/ID=# |The /id flag is used to specify the interface identifier. |
|Optional |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 "Appendix A: |
| |Error and Informational Messages" for more information, page 67. |
| |UniInt always uses the /id flag in the fashion described above. This interface also |
| |uses the /id flag to identify a particular interface copy number that corresponds to|
| |an integer value that is assigned to Location1. For this interface, one should use |
| |only numeric characters in the identifier. For example, |
| |/id=1 |
|/MXE=# |The requested maximum number of events that will be sent in a single notification. A|
|Optional |value of 0 means that there is no limit to the number of events that will be sent in|
|Default: /MXE=0 |a single callback. Note that a value of /MXE greater than 0 may cause the server to |
| |call the event more frequently than specified with the /BTM when a large number of |
| |events are being generated in order to limit the number of events to the max size. |
| |In some instances the default value will not function correctly, in this case, try |
| |using a value of 1000. If this is successful try changing this parameter to enhance |
| |performance for a particular setup. |
|/NODE=nodename |Use this parameter to specify the node the OPC AE Server resides. For example, |
|Required if interface not loaded |/NODE=FACT1NODE |
|on the OPC AE Server node; |where FACT1NODE is the name of the computer (node name) where the OPC Server AE |
|otherwise optional. |runs. When no node is specified then the OPC AE Server it is presumed by the |
| |interface that the server exists on the interface node. |
|/PS=E |The /ps flag specifies the point source for the interface. x is not case sensitive |
|Required |and can be any single character. For example, /ps=P and /ps=p are equivalent. |
| |The point source that is assigned with the /ps flag corresponds to the PointSource |
| |attribute of individual PI Points. The interface will attempt to load only those PI |
| |points with the appropriate point source. |
|/SERVER=srvname |Use this parameter to specify the OPC AE Server to use. For example, |
|Required |/SERVER=DELTAV.OPCEVENTSERVER.1 |
| |where DELTAV.OPCEVENTSERVER.1 is the name of the OPC AE Server as registered on that|
| |machine. |
| |If your server name has embedded spaces, enclose the name in double quote. For |
| |example: |
| |/SERVER="Server name with spaces" |
|/ST=tagname |Use this parameter to define a PI tag that will get the status of the OPC AE server.|
|Optional |This must be a digital state tag, set up for manual input as though it is a lab tag.|
|Default: none |Possible values are the following. |
| |0 = OPC_PLACE_HOLDER |
| |1 = OPC_STATUS_RUNNING |
| |2 = OPC_STATUS_FAILED |
| |3 = OPC_STATUS_NOCONFIG |
| |4 = OPC_STATUS_SUSPENDED |
| |5 = OPC_STATUS_TEST |
| |Note that if the server returns any value other than those listed above, a 0 is sent|
| |to PI. If you have defined only the values shown above for the states in the digital|
| |set, OPC_STATUS_RUNNING will be archived by default. Therefore define a state to |
| |represent the value of zero to handle this situation. |
|/STARTUP_DELAY=# |If your Interface is installed for autostart, but it hangs when the machine reboots,|
|Optional |you might need to give the network layer time to settle before trying to use it. |
| |This parameter causes the Interface to sleep for # seconds before trying to actually|
| |do anything. The syntax is the following. |
| |/STARTUP_DELAY=# |
| |where # is the number of seconds to wait. |
| |/STARTUP_DELAY=30 |
| |causes a 30-second delay. |
|/stopstat |If the /stopstat flag is present on the startup command line, then the digital state|
|or |I/O Timeout will be written to each PI Point when the interface is stopped. |
|/stopatat= |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|
|Default: |Server, digstate must be in the system digital state table. For a PI 2 Server, where|
|/stopstat= |there is only one digital state table available, digstate must simply be somewhere |
|”Intf shut” |in the table. 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. |
| |This interface suppresses the stopstat and no digital value will be written to the |
| |tag on interface exit. |
| |Examples: |
| |/stopstat=”Intf shut” |
| |The entire parameter is enclosed within double quotes when there is a space in |
| |digstate. |
|/SW=# |The number of seconds to wait for RUNNING status, before switching to the Backup OPC|
|Optional |AE Server. |
|Default: none | |
|/TS=c |Use this parameter to specify whether the Interface gets time stamps for the data |
|Optional |from the Interface, or whether it time stamps the data when it receives it. Some OPC|
|Default: /TS=N |AE servers are able to provide the time stamp for when they read the data from the |
| |device, while others are not. If your server is able to provide valid time stamps, |
| |use /TS=Y. Using /TS=A causes the interface to adjust the timestamps to match the |
| |time on the PI server. |
|/UST |For performance reasons, some users may wish to discard the sub-second portion of |
|Optional |the timestamps being passed to PI and only send whole integer seconds. This will |
|Default: (blank) |mean that PI will require less space, and possibly less CPU, to store the same |
| |amount of data. The fractional part of the second is simply truncated. |
| |Specify the /UST flag in order to archive sub-second portion of timestamps. |
| |Do not specify the /UST flag in order to discard subseconds. |
Sample piopcae.bat File
REM The following is an example of a start-up file, PIOPCAE.bat:
REM PIOPCAE.bat
REM ============================================================================
REM
REM Sample startup file for the PI OPC Alarm and Events interface.
REM
REM ============================================================================
REM Startup file for the OPC AE interface to PI
REM The ^ marks are continuation characters, they allow
REM you to have a command be split between multiple lines.
REM There must not be ANYTHING after the ^ on each line.
REM This is only a sample of the options available, the user
REM manual has the list and descriptions for them all.
REM
REM Required command-line parameters
REM ----------------------------------------------------------------------------
REM /host=mabel:5450 The PI server name and port
REM /ps=E The pointsource - this should match the pointsource for
REM your tags
REM /SERVER=DELTAV.OPCEVENTSERVER.1 The OPC server name; format servername
REM
REM Optional command-line parameters
REM ----------------------------------------------------------------------------
REM
REM /ai=x Specifies the index into the vendor specific array that
REM holds the Area name. (default = 4 for DeltaV system)
REM /backupnode The node name or IP address that the backup
REM OPC AE Server resides.
REM /bserver The name of the backup OPC AE Server to use.
REM /btm=# The buffer time is in milliseconds.
REM /cs The string tag into which should be written the
REM name of the current OPC AE Server.
REM /db=# Output interface debugging messages.
REM /dt=tagname The name of the tag to be used with /DB=4.
REM /ec=# The event counter number for IORATES.
REM /evc1= ... /evc32= Specify which event categories and
REM event attributes are to be supported
REM /ft The number of seconds to try to connect before
REM failing over.
REM /id=# The identifier string used in the pipc.log file for
REM messages from this interface -- it must match Location1
REM on the tags.
REM /mxe=# The max number of events sent in a single notification.
REM /node=OPAAEServ The node where the opc ae server resides.
REM /st=tagname Define a PI tag that will get the status of the OPC AE
REM server.
REM /stopstat=state State written when interface stops
REM /sw The number of seconds to try to wait for RUNNING
REM /ts=c Defines timestamp source, Y = AE server/N = Interface.
REM /ust=c Sub-second timestamps to be used - Y.
REM
REM Sample command line
REM
piopcae.exe /id=1 ^
/ps=E ^
/ts=y ^
/ec=1 ^
/db=127 ^
/node=dvinst ^
/server=DeltaV.OPCEventServer.1 ^
/st=opcaestat ^
/btm=10000 ^
/mxe=1000 ^
/evc1=1,1,2,3,4,5,6 ^
/evc2=2,1,2,3,4,5,6 ^
/evc3=7,1,2,3,4,5,6,7,8 ^
/evc4=8,1,2,3,4,5,6,7,8 ^
/evc5=9,1,2,3,4,5,6,7,8,9
Interface Node Clock
The correct settings for the time and time zone should be set in the Date/Time control panel. If local time participates in Daylight Savings, from the control panel, configure the time to be automatically adjusted for Daylight Savings Time. The correct local settings should be used even if the interface node runs in a different time zone than the PI Server node.
Make sure that the TZ environment variable is not defined. The currently defined environment variables can be listed by going to Start | Settings | Control Panel, double clicking on the system icon, and selecting the environment tab on the resulting dialog box. Also, make sure that the TZ variable is not defined in an autoexec.bat file. When the TZ variable is defined in an autoexec.bat file, the TZ variable may not appear as being defined in the System control panel even though the variable is defined. Admittedly, autoexec.bat files are not typically used on NT, but this does not prevent a rogue user from creating such a file and defining the TZ variable unbeknownst to the System Administrator.
Security
If the home node is a PI 3 Server, the PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Data Archive. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI 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 home node is a PI 2 Server, the read/write permissions should be set appropriately in the pisysdat:piserver.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the pibuild:piserver.txt file on the PI 2 home node.
If the interface cannot write data to a PI 3 Server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Serve, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.
Starting / Stopping the Interface
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.
Starting Interface as a Service
If the interface was installed a service, it can be started from the services control panel or with the command:
PIOPCAE.exe –start
A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. One is that the service may not be able to find the command-line arguments in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See "Appendix A:
Error and Informational Messages" for more information.
Stopping Interface Running as a Service
If the interface was installed a service, it can be stopped at any time from the services control panel or with the command:
PIOPCAE.exe –stop
The service can be removed by:
PIOPCAE.exe –remove
Buffering
For complete information on buffering, please refer to the UniInt End User Document.
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 XP as it was for NT4 and 2000.
Configuring Buffering with PI-ICU (NT-Intel)
Buffering is enabled through the PI-Interface Configuration Utility’s Tools>API Buffering… menu. Unless buffering is explicitly enabled, the PI-API will not buffer data, sending data directly to the home node.
The API Buffering… dialog allows the user to view and configure the parameters associated with the API Buffering (bufserv) process. The user can start and stop the API Buffering process from the Service tab:
[pic]
Service Tab
The Service tab allows for some API Buffering service configuration. For further configuration changes, use the Services applet.
Service Name
The Service name displays the name of the API Buffering Service.
Display Name
The Display name displays the full name associated with the API Buffering service.
Log On As
Log on as indicates the Windows user account under which the API Buffering service is setup to start automatically on reboot, or manually.
Password
Password is the name of the password for the Windows user account entered in the Log on as:above.
Confirm password
You must reenter the password again to verify you have typed it correctly both times.
Dependencies
The Dependencies lists the Windows services on which the 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 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 API Buffering service is setup to start automatically on reboot or manually on reboot, or is disabled.
• If the Auto option is selected, the service will be installed to start automatically when the machine reboots.
• If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.
• If the Disabled option is selected, the service will not start at all.
Generally, the API Buffering service is set to start automatically.
Create/Remove Service
The Create / Remove buttons allow for the creation or removal of the 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 API Buffering. Default values are used if no other value is provided.
[pic]
Enable Buffering
Enables the API Buffering feature.
Maximum File Size
Maximum buffer file size in kilobytes before buffering fails and discards events. Default value is 100,000. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Send Rate
Send rate is the time to wait between sending up to MAXTRANSFEROBJS to the server (milliseconds). Default value is 100. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Primary Memory Buffer Size
Primary memory buffer size is the size in bytes of the Primary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Secondary Memory Buffer Size
Secondary memory buffer size is the size in bytes of the Secondary memory buffer. Default value is 32768. Range is 64 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Transfer Objects
Max transfer objects is the maximum number of events to send between each SENDRATE pause. Default value is 500. Range is 1 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Pause Rate
When buffers are empty the buffering process will wait for this number of seconds before attempting to send more data to the home node. Default value is 2. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Retry Rate
When the buffering process discovers the home node is unavailable it will wait this number of seconds before attempting to reconnect. Default value is 120. Range is 0 to 2,000,000.
The Use Default button places the default value into the text box. To keep this value, click the Apply button.
Max Theoretical Send Rate
This is the theoretical max send rate 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 NT. This file follows the conventions of Microsoft Windows initialization files with sections, keywords within sections, and values for keywords. All buffering settings are entered in a section called [APIBUFFER]. To modify settings, simply edit the piclient.ini file in a text editor (Notepad on Windows) to the desired values.
The following settings are available for buffering configuration:
|Keywords |Values |Default |Description |
|BUFFERING |0,1 |0 |Turn off/on buffering. OFF = 0, ON = 1, |
|PAUSERATE |0 – 2,000,000 |2 |When buffers are empty the buffering process will wait for|
| | | |this long before attempting to send more data to the home |
| | | |node (seconds) |
|RETRYRATE |0 – 2,000,000 |120 |When the buffering process discovers the home node is |
| | | |unavailable it will wait this long before attempting to |
| | | |reconnect (seconds) |
|MAXFILESIZE |1 – 2,000,000 |100,000 |Maximum buffer file size before buffering fails and |
| | | |discards events. (Kbytes) |
|MAXTRANSFEROBJS |1 – 2,000,000 |500 |Maximum number of events to send between each SENDRATE |
| | | |pause. |
|BUF1SIZE |64 – 2,000,000 |32768 |Primary memory buffer size. (bytes) |
|BUF2SIZE |64 – 2,000,000 |32768 |Secondary memory buffer size. (bytes) |
|SENDRATE |0 – 2,000,000 |100 |The time to wait between sending up to MAXTRANSFEROBJS to |
| | | |the server (milliseconds) |
In addition to the [APIBUFFER] section, the [PISERVER] section may be used to define the default PI server and an optional time offset change that may occur between the client and server.
|Keywords |Values |Default |Description |
|PIHOMENODE |string |none |Windows default server is in pilogin.ini |
|DSTMISMATCH |0 – 2,000,000 |0 |The time that the server and client local time |
| | | |offset is allowed to jump. Typically, 3600 if the |
| | | |nodes are in time zones whose DST rules differ |
| | | |(seconds) |
Example piclient.ini File
NT
On Windows NT the default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds meaning wait 10 minutes after losing a connection before retrying.
On NT a piclient.ini file might look like:
[APIBUFFER]
BUFFERING=1
MAXFILESIZE=100000
; The PI-API connection routines have a 1 minute default timeout.
RETRYRATE=600
Debugging
The debugging flag is included to assist in understanding problematic or unexplained behavior, such as duplicate values or invalid timestamps. Use of the debugging flag should be limited to short periods of time, as the flag will generally cause the creation of large files (files larger than 200 Mb would not be unusual). The flag itself is actually a bit mask, which means you can set more than one option at the same time. A value of /DB=5 is the same as /DB=1 and /DB=4. Here are a few of the possible settings and what they do:
/DB=1
This is for internal testing only, and is not useful to users.
/DB=2
Log startup information, including InstrumentTag and ExDesc for each tag.
/DB=4
This setting will log the same items as /DB=32, but it will log them for only the tag specified as the debug tag (/DT=tagname). If there is no tag specified, the first tag for which a value is received will be declared the debug tag.
/DB=8
Logging for connections.
/DB=16
Logging for threads. This is internal and is not useful for users.
/DB=32
Logging for events that contain vendor specific array information.
/DB=64
Logging for internal data translation. This is internal and is not useful for users.
Appendix A:
Error and Informational Messages
General
A string NameID is pre-pended to error messages written to the message log. Name is a non-configurable identifier that is no longer than 9 characters. ID is a configurable identifier that is no longer than 9 characters and is specified using the /id flag on the startup command line.
PIPC.log File
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.
Troubleshooting
For interface-specific debugging, use the Debug Level to set the debug level of the interface between 1 and 127, inclusive. At a debug level of 127, the maximum number of debug messages is written to the output log file.
The command line equivalent is /db=x, where x is the setting between 1 and 127, inclusive. This parameter is optional.
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 NT, descriptions of system and PI errors can be obtained with the pidiag utility:
\PI\adm\pidiag –e error_number
Appendix B:
DeltaV OPC Alarm and Events Server ®
Introduction
This section will provide information specific to the DeltaV OPC AE server. This information is provided to aid in the understanding of the relation between the DeltaV OPC AE server and the PI-OPCAE interface. Additional information can be found in the DeltaV online help system.
The DeltaV OPC AE server does not create alarms and events; it only exposes alarms and events previously defined within the system. The exposing of the alarms and events can be performed by assigning the area to the alarm and events subsystem within the Exploring DeltaV application.
Area_A exposes all the system events and it is necessary to get these events from this area. To filter by area, the instrumenttag is set to “Area_A”, location5 must be set to 1 and userint1 needs to be set to 4. The AEConfig tool will generate the necessary data to filter on Area_A.
The PI-OPCAE PI Point Configuration Tool will aid in configuring the PI points from DeltaV OPC AE sources. After the configuration tool completes, it will have generated an SMT file with the source, event type, interface id, pointsource and pointtype specified. However, it does not configure the location2 attribute, but generates the information needed to complete the configuration.
Event Category
The DeltaV supports all 3 event types; Simple, Tracking and Conditional events. These event types are broke up into 9 Event Categories
|Event Category |Name |
|1 |GENERIC |
|2 |SIMPLE |
|3 |CHANGE |
|4 |DOWNLOAD |
|5 |SERVER ERROR |
|6 |PROCESS ALARM |
|7 |PROCESS EVENT |
|8 |DEVICE ALARM |
|9 |DEVICE EVENT |
These event categories can be filtered within the DeltaV OPC AE server using the command arguments /EVCx= to specify the event category. (See section Command Line Parameters). Only those events specified in the command line argument will receive alarms and events from the server. Event categories also be filtered by the interface on a tag by tag basis using Location2 (See section PI Point Configuration).
Vendor Specific Attributes
Other than the common attributes for that event type, each event category has attributes associated directly with that category. For all event categories, except for SERVER ERROR, the attributes 1 through 9 are common:
|Attribute |Name |
|1 |ORDINANCE |
|2 |DELTAV EVENT TYPE |
|3 |DELTAV EVENT CATEGORY |
|4 |AREA |
|5 |NODE |
|6 |ATTRIBUTE |
|7 |DELTAV STATE |
|8 |DESC1 |
|9 |DESC2 |
Event Categories 1, 2, 6 and 8 support the following additional attributes
|Event Category |Attribute |Name |
|1, 2, 6, 8 |10 |LEVEL |
|6, 8 |11 |ACKNOWLEDGEMENT COMMENT |
Event Category 5, SERVER ERROR, supports only attribute 1, ORDINANCE.
The attributes can be filtered within the DeltaV OPC AE server by using the command arguments /EVCx= to specify the attributes (See section Command Line Parameters). It is required that this filtering be accomplished for all event categories where events are expected and must include attribute 4 (Area), except for event category 5 (ServerError).
Buffer Times and Max Events
The default for the command arguments buffer time (/BTM) and maximum events (/MXE) is zero. This may not be sufficient in all cases for the DeltaV OPC AE server. These numbers are based on several factors, for example, the number of sources and the rate at which alarms and events occur on the server. It is recommended to test these parameters and make changes accordingly.
Appendix C:
DCOM Configuration Details
All OPC servers and clients are based on Microsoft’s DCOM technology. DCOM is the network connection protocol that allows communication between machines through the network. This type of communication requires proper DCOM configuration for all DCOM applications. Hence both OPC client and server machines must have proper DCOM settings permitting them to securely access one another remotely. This section describes DCOM configuration on both client and server machines.
There are two major steps that must be taken to properly configure DCOM permissions:
1. DCOM configuration for OPC Server application on an OPC Server machine;
2. DCOM configuration for default permissions on a PI-OPCAE Interface machine.
The general steps for DCOM configuration are similar. However depending on whether your machines are within the same domain or different domain, or even no domain, the sequence of steps will be different. In the following two sections it is assumed that your machines are within the same NT domain.
Using DCOM Configuration Instructions from Your OPC Server Vendor
Your server vendor may have provided you with instructions on how to configure DCOM for your OPC server. If so, please try to run the interface with those settings before you try to configure your system using the above instructions. Also, it is a good idea to write down the old settings or save their screen shots whenever you change something, so that you can change it back if you need to do so. That is particularly important if you already have another OPC client that works with your current setup. If your PI-OPCAE Interface is on a separate computer from your OPC AE Server, use these instructions just for the interface machine first, and only change the settings on the OPC Server machine if you are unable to collect data without changing them. If your server vendor gave you installation instructions for how to set up a client machine, try using those.
DCOM Configuration on Both Machines
If you are using two machines, both machines have to be configured to allow access. That is because the OPC Server makes calls to the interface, and the interface makes calls to the server, and if your configuration is not set up to give them both permission to communicate, the NT system will not allow communication.
DCOM Configuration on a Single Machine
You still have to configure DCOM, even if you're using one machine for both the OPC server and the PI-OPCAE Interface.
General Steps for DCOM Configuration
DCOM configuration can be done with the DCOM Configuration utility (dcomcnfg.exe) that comes with the Windows operating system. In order to use this utility, you must be logged in with administrator privileges. This utility allows you to define special security rules for all DCOM objects on the local computer. The DCOM Config utility may look slightly different, and setting options may differ, depending on your version of the Windows operating system. Therefore, procedures for DCOM configuration are described separately.
DCOM Configuration for Windows XP Systems
If the PI-OPCAE Interface is running on the same computer as the OPC AE server, both of these processes must be done on that computer, since both the client and the server permissions still need to be set.
On the Client Computer
Note: Be aware that the DCOM settings you make in the following procedure affect all DCOM applications on this computer. However, this is the only way to set DCOM client permissions. Since all data collection by the PI-OPCAE Interface is done asynchronously, the server must have permission to call into the client when it has data. This permission is granted by setting the default DCOM permissions for the client machine.
1. To run the DCOM Configuration utility, enter dcomcnfg in the Run dialog box (click Start and then click Run).
[pic]
2. In the Component Services window, which appears, expand the directory tree as shown below.
[pic]
3. Right click My Computer and select Properties. The My Computer Properties dialog box appears.
[pic]
4. On the Default Properties tab, make sure that Enable Distributed COM on this computer is selected, that Default Authentication Level is set to Connect, and that Default Impersonation Level is set to Identify.
[pic]
5. On the Default COM Security tab, click Edit Default for accessing permissions.
[pic]
6. In the Access Permission dialog box that appears, it is required that SYSTEM, NETWORK and INTERACTIVE groups be in the list. If they are not listed, add them by clicking Add and entering the name, or by selecting them from the list (Advanced Find Now). It can be useful to have the account Everyone in this list for connection testing purposes, since this gives access to all accounts that can log into the system. However, it is recommended that you restrict access to a specific account/user when testing is complete. At a minimum, you must give permission to the account under which the OPC server is running. When you are finished specifying the access permissions, click OK to close the Access Permissions dialog box.
[pic]
7. Follow the same general procedure for the Default Launch Permissions.
On the Server Computer
1. Run the DCOM Configuration utility as described in the "On the Client Computer" section. Click the DCOM Config folder and expand the directory tree as shown below.
[pic]
2. In the list of applications right-click your OPC Server and then click Properties. The Properties window for that specific application appears as shown below.
[pic]
Note: If the Authentication Level is set to Default as shown in the figure above, the default Authentication Level settings for the computer also apply to the OPC Server. It is recommended that you avoid changing this setting unless you have difficulty connecting to your server. In general, it is best to leave server settings as they were configured by the server vendor, and only add permissions to allow the client to connect.
3. On the Security tab, you can choose to use the system default security settings (select Use Default) or you can assign access to individual users (select Customize). Either choice is suitable, but be aware of security implications to changing the default permissions.
If you choose to customize one of the permission categories, click Edit. A dialog box appears as described in the previous section "On the Client Computer." Follow the procedure in that section to add the OPC user to the list. The userid that you add is the one under which the PI-OPCAE Interface will run, or the Everyone role account.
In the event the server is shutdown, you can prevent the interface from restarting it by denying launch permissions.
[pic]
4. It is recommended that you make no changes on the Identity tab unless you have difficulty connecting to the server. If you have difficulty receiving data from the server, make a note of the original settings. Then, select This User and specify an account under which the server will run. Servers that are tightly coupled to an underlying data system such as a DCS may only function if they run under an account that the underlying system recognizes.
[pic]
5. Click OK to save your changes and close the dialog box.
As part of the DCOM configuration for the server, you need to specify settings for the OPCEnum utility.
1. Follow the same procedure to run the DCOM Config utility as described in the "On the Server Computer" section.
2. When the Distributed COM Configuration Properties dialog box appears, click the Applications tab.
3. Select the OPCEnum utility and click Properties.
4. For the Authentication Level, select Default.
[pic]
5. On the Security tab, verify that both Launch Permissions and Access Permissions are set to Use Default as shown below.
[pic]
6. Click OK to save your changes and close the dialog box.
This completes the DCOM configuration on a server machine for a Windows XP system. It is recommended that you restart the computer to make sure all settings are read.
DCOM Configuration for Windows NT/2000 Systems
If the PI-OPCAE Interface is running on the same computer as the OPC AE server, you must follow both the procedures in this section on that computer since both the client and the server permissions still need to be set.
On the Client Computer
Note: Be aware that the DCOM settings you make in the following procedure affect all DCOM applications on this computer. However, this is the only way to set DCOM client permissions. Since all data collection by the PI-OPCAE Interface is done asynchronously, the server must have permission to call into the client when it has data. This permission is granted by setting the default DCOM permissions for the client machine.
1. To run the DCOM Config utility, enter dcomcnfg in the Run dialog box (click Start and then click Run.
[pic]
The Distributed COM Configuration Properties dialog box appears. Depending on your operating system version, it may differ in appearance from the figure below.
[pic]
2. On the Default Properties tab, make sure that Enable Distributed COM on this Computer is selected, that Default Authentication Level is set to Connect, and that Default Impersonation Level is set to Identify.
[pic]
3. On the Default Security tab, click Edit Default for accessing permissions.
[pic]
4. In the Registry Value Permissions dialog box that appears, make sure that the accounts shown in the figure below are present.
[pic]
5. It is required to have SYSTEM, NETWORK and INTERACTIVE groups in this list. If they are not listed, add them by clicking Add and entering the name, or by selecting them from the list (Advanced Find Now). It can be useful to have the account Everyone in this list for connection testing purposes, since this gives access to all accounts that can log into the system. However, it is recommended that you restrict access to a specific account/user when testing is complete. At a minimum, you must give permission to the account under which the OPC server is running. When you are finished specifying the access permissions, click OK to close the Registry Value Permissions dialog box.
6. Follow the same general procedure for the Default Launch Permissions. The Type of Access must be Allow Launch, as shown in the figure below.
[pic]
Note: You can set the default DCOM Protocols by adding them in the Default Protocols tab.
On the Server Computer
1. Run the DCOM Configuration utility as described in the "On the Client Computer" section. In the Distributed COM Configuration Properties dialog box that appears, click the Applications tab. Then select your OPC server and click Properties as shown below.
[pic]
2. If the OPC AE Server is on a node that is different from where the PI-OPCAE Interface is located, click the Location tab. Then select Run Application on the Following Computer and specify the node name. Do not specify more than one node. Otherwise, the connection will fail, generating error messages.
[pic]
The PI-OPCAE Interface launches the correct OPC Server if it is and has correct security settings.
3. On the Security tab, you can choose to use the system default security settings (select Use Default) or you can assign access to individual users (select Customize). Either choice is suitable, but be aware of security implications to changing the default permissions.
If you choose to customize one of the permission categories, click Edit. A dialog box appears as described in the "On the Client Computer" section. Follow the procedure in that section to add the OPC user to the list. The userid that you add is the one under which the PI-OPCAE Interface will run, or the Everyone role account.
In the event the server is shutdown, you can prevent the interface from restarting it by denying launch permissions.
[pic]
4. On the Identity tab select This User and specify an account with administrator privileges. You must also configure the PI-OPCAE Interface service in the Control Panel Services start-up dialog box to log on with that account. However, if you do not want to restrict the access to this application to a specific user select The Interactive User if the application is not installed as a Windows service. Otherwise, it will be the system account. This setting is only available if an application is implemented as a Windows service.
[pic]
5. In the Endpoints tab set the DCOM Protocols and endpoint to Default System Protocols as shown below.
[pic]
6. Click OK to save your changes and close the dialog box.
As part of the DCOM configuration for the server, you need to specify settings for the OPCEnum utility.
1. Follow the same procedure to run the DCOM Config utility as described in the "On the Server Computer" section.
2. When the Distributed COM Configuration Properties dialog box appears, click the Applications tab.
3. Select the OPCEnum utility and click Properties.
4. For the Authentication Level, select Default.
[pic]
5. On the Security tab, verify that both Launch Permissions and Access Permissions are set to Use Default as shown below.
[pic]
6. Click OK to save your changes and close the dialog box.
This completes the DCOM configuration on a server machine for a Windows NT/2000 system. It is recommended that you restart the computer to make sure all settings are read.
Using DCOM without a Windows NT Primary Domain Controller
If you do not have a primary domain controller, or if your OPC Server and your PI-OPCAE Interface computers are not within the same domain, DCOM cannot use Windows security to determine which machines can access each other. Therefore, the basic security models are used: the account(s) under which the client and server are running must be valid on both computers. The OPC Server must have a defined user account that is the same as the user account on the PI-OPCAE Interface computer under which the interface itself runs. The passwords for those two accounts must be identical. Otherwise, DCOM will not pass any communication between the client and the server, although it may launch the OPC Server. Note that this account must be a local account on each machine, not a domain account.
Using DCOM with an NT Primary Domain Controller
Do not use the Local System account to run applications that use DCOM. While the Local System account has local privileges, it has no authority outside its own system.
OPC Server Registration
If the DCOM Configuration utility running in list mode does not list your server when you run the tool on the same machine as the OPC Server, you need to register the OPC Server using a Command window. In a command window, enter the following:
servername.exe –regserver (to unregister use –unregserver)
This may not work for all servers, but it is recommended that you try it.
Search all hard drives for opcproxy.dll, which ships with the OPC server. Make sure there is only one copy on your computer. If there is more than one, it is unlikely that there will be difficulties if they are all same version. Otherwise, rename all but the latest version, which you need to copy to the \winnt\system32 directory. Then register the following DLLs. Make sure opcproxy.dll and opccomn_ps.dll exist in the winnt\system32 directory. In a Command window, enter the following:
C:>regsvr32 opcproxy.dll
Then enter the following:
C:>regsvr32 opccomn_ps.dll
Click on OK to complete this procedure.
Revision History
|Date |Author |Comments |
|03-Jan-2003 |BPayne |Rough draft |
|22–Jan-2003 |BPayne |Major rewrite from SL mtgs 1/16/03 |
|28-Feb-2003 |BPayne |Sandified and added documentation for loc3 |
|09-Apr-2003 |BPayne |Updated from Julie Z comments |
|15-Jun-2003 |BPayne |Updates from SL testing |
|31-Jul-2003 |BPayne |Updates from 2nd round of testing |
|26-Sep-2003 |BPayne |Update for support of string tag as an option for storing |
| | |conditional events. |
|27-Oct-2003 |BPayne |Added configuration tool documentation. |
|02-Dec-2003 |BPayne |Updated as per Julie Z comments/Appendix additions for DeltaV and |
| | |DCOM |
|5-Feb-04 |CGoodell |Standardized the checklist, digital states, installation, |
| | |performance points, and security sections; fixed the part number; |
| | |removed notes to developer; fixed typos; removed self-referencing |
| | |manual; added sample startup file; fixed headers & footers |
|2-Feb-04 |BPayne |Updated supported version 1.0.0.22 -1.0.0.23 |
|23-Apr-04 |BPayne |Updated for area filtering support - 1.0.0.24 |
|20-May-04 |BPayne |Added doc for command arg /ai, area filtering, location5 and |
| | |userint1. Updated AppendixB, DeltaV section for area filtering. |
|10-Jun-04 |BPayne /CH |Added ICU section under Startup Command File |
|10-Jun-04 |CGoodell |Version 1.0.0.31 Rev D: Fixed sections breaks; made all normal |
| | |text body text; fixed headers & footers; fixed page numbers |
|15-Jun-04 |BPayne |Corrected the term BCD to bit pattern for explanation of |
| | |location2. |
|15-Sep-04 |BPayne |Added entry explaining “Vendor Specific Attributes Identity” for |
| | |ExDesc |
|29-Oct-04 |BPayne |OPCstates were stated wrong – corrected |
| | |Enabled/Active/Acked/AckReqd. Added ‘APS Connector Currently |
| | |Available – No’ to the Supported Features Table. |
|13-Dec-04 |MPKelly/ BPayne|Version 1.0.0.33. Added new copyright page. Added Point Builder |
| | |Utility and ICU Control to the Supported Features Table. Added |
| | |section on Configuring Buffering Using PI-ICU and changed some |
| | |screenshots. Fixed headers and footers. Correct /ST and /AI in |
| | |sample .bat file. |
|06-Jun-05 |MMoore/ BPayne |Version 1.0.0.34. Updated for new uniint 4.0.0 |
|29-Jun-05 |MKelly |Fixed header and footers and Copyright date. Made Final. |
|05-Jun-05 |MMoore |Added information for new server-level failover feature. |
|04-Aug-05 |MMoore |General cleanup and clarification. |
|18-Oct-05 |MMoore |Updated /ust flag to match ICU control. |
|20-Oct-05 |Janelle |Version 1.1.0.65; Rev G: Alphabetized command line parameters; |
| | |added new screen shots of ICU control; added service id info; |
| | |added “2003” in supported platforms; minor formatting changes. |
|27-Oct-05 |MMoore |Modified the Point Configuration Tool for new filename, |
| | |“piopcae_config.csv”. |
-----------------------
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 download
- introduction who world health organization
- microsoft frontpage to expression web
- opc alarms and events interface to the pi system
- microsoft word specs
- real numbers ucla mathematics
- facilities management strategic plan
- things to know for exam on thursday jmu
- ada 9x compatibility guide version 6 0 letter
- compatibility home the site
Related searches
- historical events that changed the world
- why the school system is bad
- is the education system broken
- the school system is broken
- the education system is failing
- calculator with the pi button
- how to cleanse the lymphatic system naturally
- the planets of the solar system song
- parts of the respiratory system and functions
- the organs in the circulatory system include
- label the conduction system of the heart
- the lymphatic system of the human body