CiscoPhone Interface to the PI System
CiscoPhone
Interface to the PI System
Version 1.0.2.0
How to Contact Us
|OSIsoft, Inc. |Worldwide Offices |
|777 Davis St., Suite 250 |OSIsoft Australia |
|San Leandro, CA 94577 USA |Perth, Australia |
| |Auckland, New Zealand |
|Telephone |OSI Software GmbH |
|(01) 510-297-5800 (main phone) |Altenstadt, Germany |
|(01) 510-357-8136 (fax) |OSI Software Asia Pte Ltd. |
|(01) 510-297-5828 (support phone) |Singapore |
| |OSIsoft Canada ULC |
|techsupport@ |Montreal, Canada |
| |OSIsoft, Inc. Representative Office |
|Houston, TX |Shanghai, People’s Republic of China |
|Johnson City, TN |OSIsoft Japan KK |
|Mayfield Heights, OH |Tokyo, Japan |
|Phoenix, AZ |OSIsoft Mexico S. De R.L. De C.V. |
|Savannah, GA |Mexico City, Mexico |
|Seattle, WA | |
|Yardley, PA | |
|Sales Outlets and Distributors |
|Brazil |South America/Caribbean |
|Middle East/North Africa |Southeast Asia |
|Republic of South Africa |South Korea |
|Russia/Central Asia |Taiwan |
| |
|WWW. |
|OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI ProcessBook, Sequencia, |
|Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in this book that are known to be trademarks or service marks |
|have been appropriately capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the |
|property of its owner and use herein in no way indicates an endorsement, recommendation, or warranty of such party's |
|products or any affiliation with such party of any kind. |
| |
|RESTRICTED RIGHTS LEGEND |
|Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the |
|Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 |
| |
|Unpublished -- rights reserved under the copyright laws of the United States. |
| |
|© 2006-2007 OSIsoft, Inc. PI_CiscoPhone.doc |
Table of Contents
Introduction 1
Reference Manuals 1
Supported Features 1
Diagram of Hardware Connection 4
Principles of Operation 5
Installation Checklist 13
Interface Installation 15
Naming Conventions and Requirements 15
Interface Directories 16
The PIHOME Directory Tree 16
Interface Installation Directory 16
Interface Installation Procedure 16
Installing the Interface as a Windows Service 16
Installing the Interface Service with PI Interface Configuration Utility 17
Installing the Interface Service Manually 19
Connection Tool 21
Digital States 23
PointSource 25
PI Point Configuration 27
Point Attributes 27
Tag 27
PointSource 27
PointType 27
Location1 27
Location2 28
Location3 28
Location4 28
Location5 29
InstrumentTag 29
ExDesc 30
Scan 32
Shutdown 32
Performance Point Configuration 33
I/O Rate Tag Configuration 35
Monitoring I/O Rates on the Interface Node 35
Configuring I/O Rate Tags with PI ICU (Windows) 35
Configuring I/O Rate Tags Manually 37
Configuring the PI Point on the PI Server 37
Configuration on the Interface Node 37
Startup Command File 39
Configuring the Interface with PI-ICU 39
ciscophone Interface Tab 41
Command-Line Parameters 44
Sample PICiscoPhone.bat File 48
Interface Node Clock 49
Security 51
Windows 51
Starting / Stopping the Interface on Windows 53
Starting Interface as a Service 53
Stopping Interface Running as a Service 53
Buffering 55
Configuring Buffering with PI-ICU (Windows-Intel) 55
Configuring Buffering Manually 59
Example piclient.ini File 60
Appendix A: Error and Informational Messages 61
Log File Messages 61
System Errors and PI Errors 63
Appendix B: Acknowledgments 65
CURL 65
OpenSSL 65
Revision History 69
Introduction
The PI CiscoPhone interface is designed to read data from Cisco IP phones running Cisco Call Manager software. Each phone on a network can expose performance and network statistics in table format on a series of html pages. Each PI point loaded in the interface reads one value off a single phone and sends this value to a PI server.
The PI CiscoPhone interface runs on the Windows NT family (Windows NT 4.0 Service Pack 6 or greater, Windows 2000, Windows XP, and Windows Server 2003) on the Intel architecture.
Most of the functions of this interface are handled effectively by the PI HTML interface. However, in some cases, it may be more suitable to use the PI CiscoPhone interface instead. Both interfaces read an html file and select a value from this file to be sent to PI. The PI CiscoPhone differs from the PI HTML interface in that a single instance of the interface is capable of reading files from more than one address. The PI HTML interface however is a more richly featured interface that offers the user greater flexibility with locating the required data on a page.
Reference Manuals
OSIsoft
• PI Server manuals
• PI API manual
• UniInt Interface User Manual
Supported Features
|Feature |Support |
|Part Number |PI-IN-CISCO-PH-NTI |
|* Platforms |Windows NT 4.0 / 2000 / XP /2003 |
|APS Connector |No |
|Point Builder Utility |No |
|ICU Control |Yes |
|PI Point Types |Float64, Float32, Float16, Int16, Int32, Digital, |
| |String |
|Sub-second Timestamps |Yes |
|Sub-second Scan Classes |Yes |
|Automatically Incorporates PI Point Attribute Changes |Yes |
|Exception Reporting |Yes |
|Outputs from PI | No |
|Inputs to PI: Scan-based / Unsolicited / Event Tags |Scan based / Event tags |
|Supports Questionable Bit |No |
|Supports Multi-character PointSource |Yes |
|Maximum Point Count |Point count of the PI Server |
|* Uses PI SDK |No |
|* Source of Timestamps |PI server |
| History Recovery |No |
|* UniInt-based |Yes |
|* Disconnected Startup |Yes |
|* SetDeviceStatus |Yes |
|Failover |No |
|Vendor Software Required on PI Interface Node |No |
|Vendor Software Required on Foreign Device |No |
|Vendor Hardware Required |No |
|* Additional PI Software Included with Interface |Yes |
|Device Point Types |Not applicable |
|Serial-Based Interface |No |
* See paragraphs below for further explanation.
Platforms
The Interface is designed to run on the above mentioned Microsoft Windows operating systems and greater. Windows NT 4.0 requires Service Pack 6.
Please contact OSIsoft Technical Support for more information.
Uses PI SDK
The PI SDK and the PI API are bundled together and must be installed on each PI Interface node. This Interface does not specifically make PI SDK calls.
Source of Timestamps
The clock on the computer running the PI Server provides the source of timestamps for the values sent by the interface. The Interface writes a timestamp that reflects the time at which it requested the html page.
UniInt-based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by developers, and is integrated into many interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of OSIsoft’s interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.
The UniInt Interface User Manual is a supplement to this manual.
Disconnected Startup
The interface now supports startup without a connection to the PI server. Previously a PI server connection was required in order to obtain a list of which PI points belonged to an interface. Now this information is stored in a local cache. This cache is synchronized with the PI server point database. This not only reduces the time required for interface startup but also prevents data loss if starting the interface when the PI server is unavailable. Refer to the New Interface Features PR1 Manual for a more complete discussion on disconnected startup. Note this functionality requires PI API 1.6.1.x or later and is only supported for PI 3.x servers.
SetDeviceStatus
For a Health Tag whose Extended Descriptor attribute contains [UI_DEVSTAT], the Interface writes the following values:
a) "1 | Starting" - the interface has started.
b) "Good" - the Interface has successfully obtained the requested values for all its points.
c) "2 | Connected / No Data | Failed to read from (n) devices" - for at least one its points, the Interface was able to connect to the point's URL, but not able to obtain the requested value.
d) "3 | (n) devices in error" - for at least one its points, the Interface was unable to connect to the point's URL.
e) "4 | Intf Shutdown" - the interface has shut down.
Please refer to the UniInt Interface User Manual file for more information on how to configure Health Tags.
Additional PI Software
A utility for testing regular expressions (RegExpTester.exe) is included in the install of this interface. This utility is useful for testing the syntax of regular expressions before using them in a PI Point.
Diagram of Hardware Connection
[pic]
Principles of Operation
The PI CiscoPhone interface reads data presented in table format on html pages. Typically this interface is used to get data from Cisco IP Phones running Cisco Call Manager software. In this case each phone makes available a number of HTML pages that display operating statistics for the phone. A single instance of the interface can read any number of pages from any number of phones.
The interface is scan based; each PI point loaded in the interface will read a single value from a page on a phone at regular intervals according to its scan class. This interface does not support output points.
Interface Operation
PI points loaded in the interface are grouped by scan class. If multiple points in a scan class get their value from the same page (the URL is the same), then this page is read only once for each scan.
The interface works by representing any table it finds on an html page in an internal data table. By default this internal table should match table(s) found on the html page (see html parsing). Each PI point loads its values from this internal table. The point’s Location2 and ExDesc indicate the column number and row in this internal table of the value to send to PI.
Thread Pool
To perform a scan, the interface must read each page from each device required by the points in the scan class. In order to minimize the effect of one or more devices taking a long time to respond, the interface uses a thread pool to read and process each page. The interface groups all points that read pages from the same device (address) and submits this group as a single task to the thread pool. Tasks submitted to a thread pool are processed in turn, whenever a thread in the pool becomes available. The thread pool thread count determines how many tasks can be processed simultaneously (see /TC).
A thread pool task is performed in the following manner:
• A single html page (URL) in this task is read from the device. If the page is read without errors then the html is parsed into one or more data tables.
• A value is then written to each point that is configured for this URL. If an error was encountered either with reading the page or parsing the html data then the value written to the point will reflect this and an error message will be written to the PIPC.log file.
• The next page in this thread pool task is then processed in turn. When all the pages have been processed the thread pool task exits.
• The timestamp of the values written to PI is the time the page was requested from the device.
Each thread pool task requests pages from a single device. In cases where the device is unavailable, each request for a page will time out. When many devices are unavailable, all the threads in the thread pool may become busy waiting for each connection to timeout. This will result in a delay of the execution for other thread pool tasks. A reserve thread pool is available to alleviate this problem. The reserve thread pool operates in an identical manner to the main thread pool, however the interface submits to this thread pool any pool task that was not able to connect to a device during its last scan. Under normal operating conditions, the main thread pool has pool tasks only for devices that are connecting and reading values correctly. All failed connections are in the reserve thread pool.
Error Values
If the interface is unable to load a page from a device then the interface will write the system digital state I/O Timeout to each point configured with the URL of this page. If the interface is unable to find a value for a point or the value is the wrong type then the system state Failed is written to the PI Point. In either case a message will be written to the PIPC.log file indicating the nature of the error. If a PI point or page continues to be in error then the interface will suppress further identical error messages from being written to the log file. Editing a point in error will cause the interface to resume writing error messages for this point until it reaches 10 identical messages again.
Performance Counters
In addition to the normal UniInt performance counters the interface exposes three new counters to monitor the status of the interface. These are
• Write Queue Length: This counter monitors the length of the queue used to pass values for PI from the thread pools to the UniInt thread. If the counter’s value stays high for an extended period of time, the interface is overloaded.
• Main ThreadPool Queue Length: This is the number of pool tasks that have been submitted to the queue and are awaiting execution. If this queue stays large then scans will be late and may be skipped.
• Reserve ThreadPool Queue Length: This is the number of pool tasks that have been submitted to the reserve thread pool queue and are awaiting execution. This queue may be large without affecting the scan rate of good points. Points with values of I/OTimeout may have their scans delayed or skipped.
Pages are read using CURL. CURL is a freely available library for retrieving HTML pages from the internet. The CURL library is built into the PI CiscoPhone interface, therefore no external .dll is required.
CURL has the capability to access pages that require HTTP authentication and has the capability to go through proxy servers to access the required network.
Html parsing
This interface is designed to read html pages from CISCO IP Phones. However the interface is suitable to read data from any html page where the data is presented in a table and in many cases can be used to read values from xml files and html files where the data is not in a table.
After an html page is read, the interface parses the file so that data in tables in the html file is loaded into a single data table in the interface. The interface performs the following steps to parse the input file.
1. Read the input file for the first occurrence of the element tag opening tag ()
2. Search the input file for the matching closing tag for this element tag ()
3. If one or more elements are nested in this element, remove the nested elements. The remaining text is one element (one row)
4. Search this element for each ValueTag pair (…)
5. Remove from each ValueTag pair any nested ValueTag Values
6. Remove all addition tags and markup information
7. Remove “Special” characters (denoted by & and ;) and leading/ trailing white space. The resultant text is a “value” (if the text is empty the value replaced with the text “No Value.”)
8. Add each value to the appropriate column in the interface internal table
9. Repeat steps 1 to 8 for each subsequent element tag in the input file.
Thus the html page
Cisco Systems, Inc.
Carrier Events
1
Rx totalPkt
35058592
Would be represented internally by the interface as the table
|Key |Value |Value |
|Carrier Events |No Value |1 |
|Rx totalPkt |No Value |35058592 |
In most cases the interface table will match the table on the html page. However this table can be viewed by setting the debug level to 4 (see /db)
A PI point is configured to read its value from this table. For example a PI point with an ExDesc of Key= Rx totalPkt and Location2=2 will have the value 3505892 written to it, similarly a point with ExDesc= Carrier Events and Location2=2 will have 1 written to it.
The interface reads the text between the and tags as a single cell value, ignoring any further markup tags or attributes. If the content of the cell is not a string then the interface marks this cell as “No Value”. When a page has multiple tables, all tables are appended to the single table in the interface. This is true even when the tables in the html page are nested
PI documentation often uses the word “tag” to describe a PI point. In this document the word “tag” is mostly used to describe the markup information in html and xml files. When the PI point attribute Tag is written, it is used only in a context where the meaning is unambiguous.
Custom Parsing
In some cases the interface can be used to read data from XML files or HTML files where the data is not in a table. To do this, override the default tags ( and ) by setting the tags the interface uses to locate the data in the PI point’s ExDesc. The following Keywords are available to set rules used to parse the page.
• ElementTag= The tag that encapsulates the set of Value tags or Key/Value tags. The values within each ElementTag pair represent one row of data in the interface internal table
• KeyCol= When the “key” value is denoted by a ValueTag the KeyCol tells the interface which value (column) to use as the key value. That is, if KeyCol=0, the first value in each element is used as the key. When KeyCol=1 the second value is used as the key and so on. The key value is always placed in column 0 in the interface internal table.
• KeyTag= Use when the key value is denoted by a tag other than the value tag. The first occurrence of this tag (within the ElementTag scope) is put in column 0 of the interface internal table.
• ValueTag= The tag or tags that indicate the value to be sent to PI. Each occurrence of this tag (within the ElementTag scope) creates a new column in the interface’s internal table
• Sep= This defines a separator (or delimiter) to divide a single cell in the html page into multiple cells in the interface table. A point with this specified will override the command line parameter /SEP=char.
Example1
The text below is parsed where the ElementTag is “ET” and the ValueTag is “VT”. Note that the second and third element (row2 and row3) are nested in the first row.
Row2/Col1Value
Row2/Col2Value
Row2/Col3Value
Row2/Col0Value
Row3/Col1Value
Row3/Col2Value
Row3/Col3Value
Row3/Col0Value
Row1/Col1Value
Row1/Col2Value
Row1/Col3Value
Row1/Col0Value
Result Table
|Key (0) |Value (1) |Value (2) |Value (3) |
|Row1/Col0Value |Row1/Col1Value |Row1/Col2Value |Row1/Col3Value |
|Row2/Col0Value |Row2/Col1Value |Row2/Col2Value |Row2/Col3Value |
|Row3/Col0Value |Row3/Col1Value |Row3/Col2Value |Row3/Col3Value |
Example2
The XML formatted data below can be parsed using ElementTag=Book; KeyTag=title; ValueTag=Price.
The Autobiography of Benjamin Franklin
Benjamin
Franklin
8.99
The Confidence Man
Herman
Melville
11.99
The Gorgias
Plato
9.99
Result Table
|Key (title) |Value (price) |
|The Autobiography of Benjamin Franklin |8.99 |
|The Confidence Man |11.99 |
|The Gorgias |9.99 |
Thus a PI point with Key= The Autobiography of Benjamin Franklin will send the price of this book (8.99) to PI.
Each page read by the interface may be parsed into several tables, depending on the point’s ExDesc attribute. The interface will group all points with identical attributes ElementTag, KeyTag, KeyCol, ValueTag and Sep
Post Processing
The value read by the interface is the string between the start and end tags. This string can be further manipulated via regular expression syntax (see regexpTutorial.doc included with the interface install kit). When the PI PointType is numeric, the resultant string is converted to a number (a float64). If the interface is unable to convert the string to a number the system digital state Failed is written to the point. If the value read represents a counter value, the PI point can be configured to convert the counter value to a rate value (see Location3).
Installation Checklist
For those users who are familiar with running PI data collection interface programs, this checklist helps get the PI CiscoPhone interface running. Users who are not familiar with PI interfaces should return to this section after reading the rest of the manual in detail.
1. Install the PI Interface Configuration Utility (this also installs PI SDK and PI API)
2. Verify that PI API has been installed.
3. Install the interface.
4. Test the connection between the interface node and the phone devices using any XML/html browser, for example Microsoft Internet Explorer.
5. Choose a point source.
6. Configure PI points.
Location1 is the interface instance.
Location2 is the table column number.
Location3 is number format (0 is raw value).
Location4 is the scan class.
Location5 is not used.
ExDesc Key=TableRow
InstrumentTag is the URL of the page.
7. Configure the interface using the PI-ICU utility or edit startup command file manually. It is recommended to use PI-ICU whenever possible.
8. Configure I/O Rate tag.
9. Set interface node clock.
10. Set up security.
11. Start the interface without buffering.
12. Verify data.
13. 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. 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 PICiscoPhone.exe and that the startup command file is called PICiscoPhone.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 PICiscoPhone.exe and PICiscoPhone.bat for interface number 1, PICiscoPhone2.exe and PICiscoPhone2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line parameters in a file that has the same root name.
Interface Directories
The PIHOME Directory Tree
The PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the %windir% directory. A typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=c:\pipc
The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSIsoft recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
Place all copies of the interface into a single directory. The suggested directory is:
PIHOME\Interfaces\CiscoPhone\
Replace PIHOME with the corresponding entry in the pipc.ini file.
Interface Installation Procedure
The PI CiscoPhone interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000 or later operating systems. When running on Windows NT 4.0 systems, the PI- CiscoPhone setup program will install the Windows Installer itself if necessary. To install, run the
CISCOPhone _x.x.x.x.exe installation kit.
Installing the Interface as a Windows Service
OSIsoft recommends the PI CiscoPhone interface service be created with the PI Interface Configuration Utility; however it can also be created manually.
Installing the Interface Service with PI Interface Configuration Utility
The PI Interface Configuration Utility provides a user interface for creating, editing, and deleting the interface service:
[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 added to the beginning of the interface to indicate that the service is part of the OSIsoft suite of products.
Log on as
The Log on as text box shows the current “Log on as” Windows User Account of the interface service. If the service is configured to use the Local System account, the Log on as text box will show “LocalSystem”. Users may specify a different Windows User account for the service to use.
Password
If user specified a Windows User account in the Log on as text box that has a password, the password must be provided in the Password text box.
Confirm Password
If a password is specified in the Password text box, then repeat the password in the Confirm Password text box to confirm it.
Startup 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 dependent 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. Often interface services also depend on a vendor program, such as the Fisher-Rosemount chipservice. To remove a service from the list of dependencies, use the [pic] button, and the service name will be removed from the “Dependencies” list.
When the PI Interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the PI interface service will not run.
Note: Please see the PI Log and Operating System Event Logger for messages that may indicate the cause for any server not running as expected.
[pic] - Add Button
To add a dependency from the list of Installed services, select the dependency name, and click the Add button.
[pic] - Remove Button
To remove a selected dependency, highlight the service name in the Dependencies list, and click the Remove button.
The full name of the service selected in the Installed services list is displayed below the Installed services list box.
Create
The Create button adds the displayed service with the specified Dependencies and with the specified Startup Type.
Remove
The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out.
Start or Stop Service
To Start or Stop an interface service, use the Start button [pic] and a Stop button [pic] on the ICU toolbar. If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.
The status of the Interface service is indicated in the lower portion of the PI-ICU dialog.
[pic]
Installing the Interface Service Manually
One can get help for installing the interface as a service at any time with the command:
PICiscoPhone.exe –help
Change to the directory where the CiscoPhone.exe executable is located. Then, consult the following table to determine the appropriate service installation command.
|Windows Service Installation Commands on a PI Interface Node or a PI Server node |
|with Bufserv implemented |
|Manual service |PICiscoPhone.exe –install –depend “tcpip bufserv” |
|Automatic service |PICiscoPhone.exe –install –auto –depend “tcpip bufserv” |
|*Automatic service with service|PICiscoPhone.exe –serviceid X –install –auto –depend “tcpip bufserv” |
|id | |
|Windows Service Installation Commands on a PI Interface Node or a PI Server node |
|without Bufserv implemented |
|Manual service |PICiscoPhone.exe –install –depend tcpip |
|Automatic service |PICiscoPhone.exe –install –auto –depend tcpip |
|*Automatic service with service|PICiscoPhone.exe –serviceid X –install –auto –depend tcpip |
|id | |
*When specifying service id, the user must include an id number. It is suggested that this number correspond to the interface id (/id) parameter found in the interface .bat file.
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.
Connection Tool
Connection to any URL can be tested by using any XML/html browser, for example Microsoft Internet Explorer. The connection string from the browsers address bar can be copied to the point’s InstrumentTag.
Digital States
For more information regarding Digital States, refer to the PI Server documentation.
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.
A PI point of PointType Digital is associated with a Digital Set via its DigitalSet attribute. For this type of point, the value sent by the interface to PI must be an exact (case insensitive) match to a state in the point’s digital set.
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 cannot send a valid value to a point it will write the system digital state Failed to PI instead of a value.
This interface uses the state I/O Timeout to indicate it could not contact the device with the html page and Failed to indicate other errors in reading or parsing the html file.
PointSource
The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For example, one may choose the letter D to identify points that belong to the PI CiscoPhone interface. To implement this, one would set the PointSource attribute to D for every PI Point that is configured for the PI CiscoPhone interface. Then, if one uses /ps=D on the startup-command line of the PI CiscoPhone interface, the interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of D. Before an interface loads a point, the interface also checks the Location1 attribute to determine if this point belongs to this copy of the interface. For additional information, see the /ps argument.
Case-sensitivity for PointSource Attributes
In all cases, the point source character that is supplied with the /ps command-line argument is not case sensitive. That is, /ps=D and /ps=d are equivalent.
Reserved Point Sources
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 Server. 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
Tag
A tag is a label or name for a point. Any tag name can be used in accordance with the normal PI point naming conventions.
PI documentation uses the terms tag and point synonymously.
Length
The length of the Tag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below indicates the maximum length of this field for all the different combinations of PI API and PI Server versions.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |255 |
|Below 1.6 |3.4.370.x or higher |255 |
|Below 1.6 |Below 3.4.370.x |255 |
PointSource
The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps command-line argument and the “Point Source” section.
PointType
All numeric PointTypes are supported (float16, float32, float 64, int16, int32). The interface will attempt to convert the string value read to a number, if this is not successful Failed will be written to the point and an error logged in the PIPC.log file.
String and Digital PointTypes are also supported. The interface sends the string read to PI. For digital points, states in the digital point’s digital set should match the string values expected to be read from the page. For more information on the individual point types, see PI Server manuals. Strings are not supported on PI2 servers.
Location1
Location1 indicates to which copy of the interface the point belongs. The value of this attribute must match the /id startup parameter.
Location2
The interface reads the page and parses the html table into a data table in the interface’s memory. Location2 tells the interface which column in this table contains the value to send to PI.
|Column Number |0 (Key) |1 |2 |… |
|Location2 |0 |1 |2 |… |
| |Data |Data |Data |Data |
| |Data |Data |Data |Data |
Typically the columns in this data table will match the columns in html table. However, when KeyTag or KeyCol is specified in the point’s ExDesc attribute, the data table columns are rearranged so that the “Key” values are always in column 0. Also, some html code results in table columns that are not seen on the rendered html page. Start the interface with the debug flag db=4 to see the full data table as loaded by the interface.
Location3
Location3 is the format of the data written to PI (Numeric type points only)
|Location3 |Value |Comment |
|0 |Raw Data |The value is written as read from the page |
|1 |Rate |This is useful for counter data, The Rate is the difference/time |
| | |(seconds) between reads |
|2 |Difference |This is useful for counter data. The difference is the value read minus|
| | |the previous value read for this point |
|3 |IP Number |The value read is expected to be an IP address in dotted decimal |
| | |format. The interface will convert this to a number. Point type float64|
| | |is recommended for this type of point. |
|4 |Non-negative difference |The value is the current value minus the previous value, provided that |
| | |this difference is non-negative. If this difference is negative, then |
| | |the Interface writes the current value to the point. |
Points with a Point Type of String or Digital do not use Location3.
Location4
Scan-Based Inputs
Location4 defines the scan class for the PI point. The scan class determines the frequency at which points are scanned for new values. For more information, see the description of the /f flag in the section called “Startup Command File”.
Trigger-based Inputs
Location 4 should be set to zero for these points.
Location5
Location5 is not used by this interface.
InstrumentTag
Length
The length of the InstrumentTag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below indicates the maximum length of this field for all the different combinations of PI API and PI Server versions.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |32 |
|Below 1.6 |3.4.370.x or higher |32 |
|Below 1.6 |Below 3.4.370.x |32 |
Providing either the PI SDK is enabled or the PI API version 1.6 or greater is installed the maximum length of the InstrumentTag is 1023 characters. If the interface does not have the PI SDK enabled (see /PISDK), and an earlier version of the PI API is installed the maximum length of the instrument tag is 32 characters.
Thus, in order to effectively run the Interface, the user most likely will need to have PI API v1.6 (or higher) and PI Server 3.4.370.x (or higher) installed. For example,
contains 40 characters.
The instrument tag is the full URL of the target page.
For Example.
or
or
file://c:\myDirectory\myfile.txt
The “hostname” can be replaced with the IP address (in dotted decimal format).
If the given URL does not specify the protocol part ("http://" or "ftp://" etc) the CURL library will attempt to guess which protocol to use.
ExDesc
Length
The length of the Extended Descriptor field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below indicates the maximum length of this field for all the different combinations of PI API and PI Server versions.
|PI API |PI Server |Maximum Length |
|1.6 or higher |3.4.370.x or higher |1023 |
|1.6 or higher |Below 3.4.370.x |80 |
|Below 1.6 |3.4.370.x or higher |80 |
|Below 1.6 |Below 3.4.370.x |80 |
The extended descriptor is used to pass point specific parameters to the interface using the Keyword=Parameter syntax. Keywords / parameters are separated by a semicolon (“;”) character. Each PI point must have at minimum either the Key or KeyRow parameter defined in the ExDesc field
|Keyword |Parameter type |Usage Comment |
|Key= |string |Identifies the table row to read the data |
|KeyRow= |integer |Row number to read the data from. Use this in place |
| | |of Key= to specify the row by number rather than by |
| | |a name (see below) |
|*ElementTag= |string |The Tag that delimits a row for the results table. |
| |(default ) | |
|*KeyTag= |string |The Tag that delimits the Key Value. This is the |
| |(default - not used) |first column in the results table |
|*KeyCol= |integer |When no KeyTag is specified, the column in the |
| |(default 0) |results table to read the Key from |
|*ValueTag= |string |The Tag that denotes the Value |
| |(default ) | |
|*Sep= |string |This is used to divide a single cell in the html |
| |(default - not used) |page into multiple cells in the interface table. |
| | |Thus if the cell value on the html page is 123,456 |
| | |and Sep=, the interface will interpret this as two |
| | |cells, one with value 123 and the second with value |
| | |456. Use Sep if possible rather than RegExp as this |
| | |is more efficient. This also overrides the command |
| | |line parameter /SEP=char. |
|MaxCounter= |integer |Applies to points that reset to zero upon reaching a|
| |(default - not used) |maximum value. Applicable to Rate or Difference |
| | |point reads. MaxCounter tells the interface to |
| | |interpret a negative Rate or Difference result as a |
| | |counter reset. The interface then adds an offset to |
| | |the counter value so that the value of the PI point |
| | |represents the real counter value. |
|RegExp= |string |Regular expression to select the data to send to PI |
| |(default - not used) |(see below) |
|Sub |string |Substitution, used with RegExp (see below) |
| |(default not used) | |
*These keywords define the rules to parse the html page into the data table. A page may be parsed into more than one data table.
Examples
To send the value of the “Rcvr Lost Packets” to PI use the ExDesc
KEY=Rcvr Lost Packets
To use additional keywords separate each Keyword using the semicolon.
Key=Serial Number;RegExp=NM05(....);sub=$1
RegExp and Sub
Regular Expression syntax is available to manipulate the string read from the page before it is sent to PI. RegExp defines the searching pattern and Sub specifies what to extract out of the string found by RegExp. Sub and RegExp should both be defined if either is to be used. If Sub is not defined, whatever matches the searching pattern defined in RegExp is returned and written to the corresponding PI point. If an empty string is returned from the RegExp-Sub pair, then an empty string is written to PI.
For details about how to configure RegExp and Sub, refer to the Regular Expression Tutorial document.
KeyRow
Rather than selecting the row from the data table by matching the “Key” value we can select the row by row number. The data table is ordered alphabetically by row 0 so the row number in the data table may not match the row number as seen on the rendered html page. For example KeyRow=1 will give us the first row in the data table.
Trigger-based Inputs
A separate trigger point must be configured for trigger-based input points. An input point is associated with a trigger point by entering a case-insensitive string in the Extended Descriptor (ExDesc) PI point attribute of the input point in the form:
keyword=trigger_tag_name
where keyword is replaced by “event” or “trig” and trigger_tag_name is replaced by the name of the trigger point. There should be no spaces in the string. For UniInt to find this keyword correctly the event or trig keyword should be the last keyword in the point’s extended descriptor (ExDesc). Location4 must be zero for trigger based points.
An input is triggered when a new value is sent to the Snapshot of the trigger point. The new value does not need to be different than the previous Snapshot value to trigger an input, but the timestamp of the new value must be greater than (more recent than) or equal to the timestamp of the previous value. This is different than the trigger mechanism for output points. For output points, the timestamp of the trigger value must be greater than (not greater than or equal to) the timestamp of the previous value.
Scan
By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.
There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.
Shutdown
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 Server manuals.
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 Server manuals.
Bufserv
It is undesirable to write shutdown events when Bufserv is being used. Bufserv is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when the Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when PI is shut down, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.
Performance Point Configuration
A Performance Point is a UniInt feature that measures the time the interface takes to complete a scan. In this interface, the time to complete the scan is just the time the interface takes to submit tasks to the thread pool and has little bearing on load of the interface. Performance Points should not be created for this interface.
This is also the case for the performance counter values for Scan Time, Scheduled Scans: % Missed and Scheduled Scans: % Skipped.
I/O Rate Tag Configuration
An I/O Rate point can be configured to receive 10-minute averages of the total number of exceptions per minute that are sent to PI by the interface. An exception is a value that has passed the exception specifications for a given PI point. Since 10-minute averages are taken, the first average is not written to PI until 10 minutes after the interface has started. One I/O Rate tag can be configured for each copy of the interface that is in use.
Monitoring I/O Rates on the Interface Node
For Windows nodes, the 10-minute rate averages (in events/minute) can be monitored with a client application such as ProcessBook.
Configuring I/O Rate Tags with PI ICU (Windows)
The PI Interface Configuration Utility (PI ICU) provides a user interface for creating and managing IORates Tags.
[pic]
PI ICU currently allows for one I/O Rate tag to be configured for each copy of the interface that is in use. Some interfaces allow for multiple I/O Rates tags.
Enable IORates for this Interface
The Enable IORates for this interface check box enables or disables 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.
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.
Tag Status
The Tag Status column indicates whether the IORates tag exists in PI. The possible states are:
• Created – This status indicates that the tag exist in PI
• Not Created – This status indicates that the tag does not yet exist in PI
• Deleted – This status indicates that the tag has just been deleted
• Unknown – This status indicates that the ICU is not able to access the PI Server
In File
The In File column indicates whether the 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
Snapshot
The Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists in PI. The Snapshot column is updated when the IORates/Status Tags tab is clicked, and when the Interface is first loaded.
Button Options
Create
Create the suggested IORates tag with the tag name indicated in the Tagname column.
Delete
Delete the IORates tag listed in the Tagname column.
Reset
Resets the IO Rate configuration as PI ICU suggests.
Rename
Allows the user to specify a new name for the IORates tag listed in the Tagname column.
Add to File
Adds the tag to the IORates.dat file with the event counter listed in the Event Counter Column.
Search [pic]
Allows the user to search the PI Server for a previously defined IORates tag.
Refresh Snapshots [pic]
Used to update the snapshot values.
Configuring I/O Rate Tags Manually
There are two configuration steps.
1. Configuring the PI Point on the PI Server
2. Configuration on the Interface Node
Configuring the PI Point on the PI Server
Create an I/O Rate Tag with the following point attribute values.
|Attribute |Value |
|PointSource |L |
|PointType |float32 |
|Compressing |0 |
|ExcDev |0 |
Configuration on the Interface Node
For the following examples, assume that the name of the PI tag is PIPerfMon001, and that the name of the I/O Rate on the home node is PIPerfMon001.
1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PIHOME entry in the pipc.ini file, which is located in the %windir% directory. If both are specified, the PIPCSHARE entry takes precedence.
Since the PIHOME directory is typically C:\PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.
Add a line in the iorates.dat file of the form:
PIPerfMon001, x
where PIPerfMon001 is the name of the I/O Rate Tag and x corresponds to the first instance of the /ec=x parameter in the startup command file. x can be any number between 2 and 34 or between 51 and 200, inclusive. To specify additional rate counters for additional copies of the interface, create additional I/O Rate tags and additional entries in the iorates.dat file. The event counter, /ec=x, should be unique for each copy of the interface.
2. Set the /ec=x parameter on the startup command file of the interface to match the event counter in the iorates.dat file.
The interface must be stopped and restarted in order for the I/O Rate tag to take effect. I/O Rates will not be written to the tag until 10 minutes after the interface is started.
Startup Command File
Command-line parameters can begin with a / or with a -. For example, the /ps=M and –ps=M command-line parameters are equivalent.
For Windows, command file names have a .bat extension. The Windows continuation character (^) allows one to use multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of command-line parameters is unlimited, and the maximum length of each flag is 1024 characters.
Configuring the Interface with PI-ICU
Note: PI-ICU requires PI 3.3 or greater.
The PI Interface Configuration Utility provides a graphical user interface for configuring PI interfaces. If the interface is configured by the PI-ICU, the batch file of the interface (PICiscoPhone.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 CiscoPhone Interface.
From the PI-ICU menu, select Interface, New, and then Browse to the PICiscoPhone.exe executable file. Then, enter values for Point Source and Interface ID#. A window such as the following results:
[pic]
“Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name and it will be the display name in the services menu.
Click on Add.
The following display appears:
[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. To configure the interface to communicate with a remote PI Server, select ‘Connections…’ from the PI-ICU menu and make it the default server. If the remote node is not in the list of servers, it can be added in.
Once the interface is added to PI-ICU, near the top of the main PI-ICU screen the Interface Type should be CiscoPhone. If not, use the drop-down box to change the Interface Type to be CiscoPhone.
Click on Apply to enable the PI-ICU to manage this copy of the PI CiscoPhone Interface.
[pic]
The next step is to make selections in the interface-specific tab (i.e. “ciscophone”) that allow configuration of the startup parameters that are specific to the PI CiscoPhone Interface.
[pic]
Since the PI CiscoPhone Interface is a UniInt-based interface, in some cases the user will need to make appropriate selections in the UniInt tab. This tab allows the user to access UniInt features through the PI-ICU and to make changes to the behavior of the interface.
To set up the interface as a Windows Service, use the Service tab. This tab allows configuration of the interface to run as a service as well as starting and stopping of the interface. The interface can also be run interactively from the PI-ICU. To do that, go to menu, select the Interface item and then Start Interactive.
For more detailed information on how to use the above-mentioned and other PI-ICU tabs and selections, please refer to the PI Interface Configuration Utility User Manual. The next section describes the selections that are available from the ciscophone tab. After selections have been made on the PI-ICU GUI, press the Apply button in order for PI-ICU to make these changes to the interface’s startup file.
ciscophone Interface Tab
Since the startup file of the PI CiscoPhone Interface is maintained automatically by the PI-ICU, use the ciscophone tab to configure the startup parameters instead of making changes in the file manually. The following is the description of interface configuration parameters used in the PI-ICU Control and corresponding manual parameters.
CiscoPhone
[pic]
Configuration
• Proxy Address or Hostname: - Checking this box enables the user to enter either an IP Address or Hostname in the text box provided for the HTTP proxy server to use. (/PROXY= xxx.xxx.xxx.xxx[:port] or Hostname)
• Proxy Username : Password: - Checking this box enables the user to enter a proxy username and/or password for the proxy server. (/PROXYUSERPWD=username[:password])
• Host Username : Password: - Checking this box enables the user to enter a host username and/or password for the connection. (/USERPWD=username[:password])
• User Agent String: - Checking this box enables the user to enter a user agent string to identify itself to the remote web server as a different web browser. Some web sites will return a different page for different browsers. A common user-agent string to use to mimic Internet Explorer 5.5 on Windows 2000 is “Mozilla/4.0” (compatible; MSIE 5.5; Windows NT 5.0)”. (/USERAGENT=string)
• Enforce Case Matching: - Checking this box forces the interface to perform case sensitive matching between tags. (/CASE)
• Use Separator: - Checking this box enables the user to enter a separator used to divide a single cell in the html page into multiple cells in the interface table. See the ExDesc for more details. (/SEP=s)
• Download Timeout: - This parameter is used to indicate how long (in seconds) the interface should wait for a page to download before timing out. (/DLTIMEOUT=#, default=60)
• Connection Timeout: - This parameter is used to indicate how long (in seconds) the interface should wait to get a successful connection before timing out. (CNXTIMEOUT=#, default=60)
• Thread Count: - This parameter indicates the number of available threads in each thread pool. (/TC=#, default=10)
• Additional Parameters – This field is available to enter any command-line parameters not currently supported by the ICU control. Command-Line parameters entered in this text box must be separated by a space. Any argument which has embedded spaces must be enclosed in double quotes.
Debug
[pic]
• Maximum Debug: - Checking this box will turn on all debugging message possible.
• Log the Loading of Points: - This will log additional information on point loading. (/DB=1)
• Log the Scanning and Reading of Values: - This will log additional information during interface operation concerning scanning and reading of values. (/DB=2)
• Log the Writing to a File: - The interface will write to a directory the html file as received from the device and a comma separated text file for each data table generated. The interface will place these files in the \Data directory, below the interface executable directory. Do not use this debug level for a long period of time as many files may be written to the drive. (/DB=4)
Note: The UniInt End User Document includes details about other command line parameters, which may be useful.
Command-Line Parameters
|Parameter |Description |
|/case |If specified, the interface will enforce case sensitive matching between tags. |
|Optional | |
|/cnxtimeout=# |The /cnxtimeout flag is used to indicate how long (in seconds) the interface should |
|Optional |wait to get a successful connection before timing out. The default is 60 seconds. |
|/dltimeout=# |The /dltimeout flag is used to indicate how long (in seconds) the interface should |
|Optional |wait for a page to download before timing out. The default is 60 seconds. |
|/db=# |The value of this flag sets the type of debug messages to be written to the log file.|
|Optional |The debug levels are as follows. |
| |1 – Loading Points: Additional information on point load |
| |2 – Scanning and Reading Values: Additional information during interface operation |
| |4 –Write File- The interface will write to a directory the html file as received from|
| |the device and a comma separated text file for each data table generated. The |
| |interface will place these files in the \Data directory, below the interface |
| |executable directory. The interface will write each page on its first scan and when |
| |there is an error for any point associated with a page. Do not use this debug level |
| |for a long period of time as many files may be written to the drive |
|/ec=# |The first instance of the /ec flag on the command line is used to specify a counter |
|Optional |number, #, for an I/O Rate point. If # is not specified, then the default event |
| |counter is 1. Also, if the /ec 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=# 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.” |
|/f=SS |The /f flag defines the time period between scans in terms of hours (HH), minutes |
|or |(MM), and seconds (SS). The scans can be scheduled to occur at discrete moments in |
|/f=SS,SS |time with an optional time offset specified in terms of hours (hh), minutes (mm), and|
|or |seconds (ss). If HH and MM are omitted, then the time period that is specified is |
|/f=HH:MM:SS |assumed to be in seconds. |
|or |Each instance of the /f flag on the command line defines a scan class for the |
|/f=HH:MM:SS,hh:mm:ss |interface. There is no limit to the number of scan classes that can be defined. The |
| |first occurrence of the /f flag on the command line defines the first scan class of |
|Required for reading scan-based |the interface; the second occurrence defines the second scan class, and so on. PI |
|inputs |Points are associated with a particular scan class via the Location4 PI Point |
| |attribute. For example, all PI Points that have Location4 set to 1 will receive input|
| |values at the frequency defined by the first scan class. Similarly, all points that |
| |have Location4 set to 2 will receive input values at the frequency specified by the |
| |second scan class, and so on. |
| |Two scan classes are defined in the following example: |
| |/f=00:01:00,00:00:05 /f=00:00:07 |
| |or, equivalently: |
| |/f=60,5 /f=7 |
| |The first scan class has a scanning frequency of 1 minute with an offset of |
| |5 seconds, and the second scan class has a scanning frequency of 7 seconds. When an |
| |offset is specified, the scans occur at discrete moments in time according to the |
| |formula: |
| |scan times = (reference time) + n(frequency) + offset |
| |where n is an integer and the reference time is midnight on the day that the |
| |interface was started. In the above example, frequency is 60 seconds and offset is 5 |
| |seconds for the first scan class. This means that if the interface was started at |
| |05:06:06, the first scan would be at 05:06:10, the second scan would be at 05:07:10, |
| |and so on. Since no offset is specified for the second scan class, the absolute scan |
| |times are undefined. |
| |The definition of a scan class does not guarantee that the associated points will be |
| |scanned at the given frequency. If the interface is under a large load, then some |
| |scans may occur late or be skipped entirely. See the section called “Principals of |
| |Operation” for more information on skipped or missed scans. |
| |Sub-second Scan Classes |
| |One can also specify sub-second scan classes on the command line such as |
| |/f=0.5 /f=00:00:00.1 |
| |where the scanning frequency associated with the first scan class is 0.5 seconds and |
| |the scanning frequency associated with the second scan class is 0.1 of a second. |
| |Similarly, sub-second scan classes with sub-second offsets can be defined, such as |
| |/f=0.5,0.2 /f=1,0 |
| |Wall Clock Scheduling |
| |Scan classes that strictly adhere to wall clock scheduling are now possible. This |
| |feature is available for interfaces that run on NT and/or UNIX. Previously, wall |
| |clock scheduling was possible, but not across daylight savings time. For example, |
| |/f=24:00:00,08:00:00 corresponds to 1 scan a day starting at 8 AM. However, after a |
| |Daylight Savings Time change, the scan would occur either at 7 AM or 9 AM, depending |
| |upon the direction of the time shift. To schedule a scan once a day at 8 AM (even |
| |across daylight savings time), one should use /f=24:00:00,00:08:00,L. The ,L at the |
| |end of the scan class tells UniInt to use the new wall clock scheduling algorithm. |
|/host=host:port |The /host flag is used to specify the PI Home node. Host is the IP address of the PI|
|Required |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. 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 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 |
| |command-line parameters would be: |
| |/host=marvin |
| |/host=marvin:5450 |
| |/host=206.79.198.30 |
| |/host=206.79.198.30:5450 |
|/id=x |The /id flag is used to specify the interface identifier. |
|required |This interface uses the /id flag to identify a particular interface copy number that |
| |corresponds to an integer value that is assigned to Location1 in the tag |
| |configuration. For this interface, one should use only numeric characters in the |
| |identifier. For example, /id=1 |
|/PISDK=# |The /pisdk flag can be used to enable or disable the PI SDK. Use /pisdk=1 to enable |
| |the PI SDK. Use /pisdk=0 to disable the PI SDK. If /pisdk is not found then the |
| |interface will not use the PI SDK. It is recommended the PI SDK is enabled when the |
| |version of the PI API is 1.3.x or lower. |
|/Proxy=host[:port] |The /Proxy flag is used to specify the name of an http proxy server. This parameter |
|Optional |should be a string holding the host name or dotted IP address of the proxy server. |
|/PROXYUSERPWD=username[:password] |The /PROXYUSERPWD flag is used to pass a username and password to the http proxy |
|Optional |server. |
|/ps=x |The /ps flag specifies the point source for the interface. X is not case sensitive |
|Required |and can be any single or multi-character string. For example, /ps=P and /ps=p are |
| |equivalent. |
| |The point source that is assigned with the /ps 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. |
|/q |When the /q flag is present, Snapshots and exceptions are queued before they are sent|
|Optional |to the PI Server node. |
| |Extended API mode behavior: |
| |The maximum queue size is close to 4000 bytes. The queue is flushed between scans if |
| |it is not filled. |
|/Sep=x |This defines a separator (or delimiter) to divide a single cell in the html page into|
|Optional |multiple cells in the interface table. Using this flag in the startup command line |
| |is equivalent to specifying sep=x in each points ExDesc attribute. A point with sep= |
| |specified in its ExDesc attribute will override the separator specified here. See |
| |ExDesc for more details. |
|/stopstat |If the /stopstat flag is present on the startup command line, then the digital state”|
|or |Intf shut” will be written to each PI Point when the interface is stopped. |
|/stopstat= |If /stopstat=digstate is present on the command line, then the digital state, |
|digstate |digstate, will be written to each PI Point when the interface is stopped. Digstate |
|Default: |must be in the system digital state table. UniInt uses the first occurrence in the |
|/stopstat= |table. |
|”Intf shut” |If neither /stopstat nor /stopstat=digstate is specified on the command line, then no|
|Optional |digital states will be written when the interface is shut down. |
| |Examples: |
| |/stopstat=”Intf shut” |
| |The entire parameter is enclosed within double quotes when there is a space in |
| |digstate. |
|/TC=# |The number of threads available in each thread pool. Default 10 |
|Optional | |
|/useragent=string |The /useragent flag is used to allow the interface to identify itself to the remote |
|Optional |web server as a different web browser. Some web sites will return a different page |
| |for different browsers. A common user-agent string to use to mimic Internet Explorer |
| |5.5 on Windows 2000 is "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)". |
|/USERPWD=username[:password] |The /USERPWD flag is used to pass a username and password to the device. |
|Optional | |
Sample PICiscoPhone.bat File
The following is an example startup command file:
REM ==========================================================================
REM
REM PICiscoPhone.bat
REM
REM Sample startup file for the CiscoPhone Interface to the PI System
REM
REM ==========================================================================
REM
REM OSIsoft strongly recommends using PI ICU to modify startup files.
REM
REM Sample command line
REM
.\PICiscoPhone.exe /ps=CiscoPhone /id=1 /host=XXXXXX:5450 ^
/stopstat="Intf Shut" /sep=, /f=60
REM
REM End of PICiscoPhone.bat File
Interface Node Clock
Make sure that the time and time zone settings on the computer are correct. To confirm, run the Date/Time applet located in the Windows Control Panel. If the locale where the interface node resides observes Daylight Saving Time, check the box marked “Automatically adjust clock for daylight saving changes”. For example,
[pic]
In addition, make sure that the TZ environment variable is not defined. All of the currently defined environment variables can be viewed by opening a Command Prompt window and typing set. That is,
C:> set
Confirm that TZ is not in the resulting list. If it is, run the System applet of the Control Panel, click the Environment tab, and remove TZ from the list of environment variables.
Security
Windows
The PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Server. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Server manuals.
Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy Database used prior to PI version 3.3. The Trust Database maintains all the functionality of the proxy mechanism while being more secure.
See “Trust Login Security” in the chapter “PI System Management” of the PI Universal Data Server System Management Guide.
If the interface cannot write data to 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 Server, it writes a –999 error. See the section “Appendix A: Error and Informational Messages” for additional information on error messaging.
PI Server v3.3 and Higher
Security configuration using piconfig
For PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust table:
C:\PI\adm> piconfig
@table pitrust
@mode create
@istr Trust,IPAddr,NetMask,PIUser
a_trust_name,192.168.100.11,255.255.255.255,piadmin
@quit
For the above,
Trust: An arbitrary name for the trust table entry; in the above example,
a_trust_name
IPAddr: the IP Address of the computer running the Interface; in the above example,
192.168.100.11
NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr
PIUser: the PI user the Interface to be entrusted as; piadmin is usually an appropriate user
Security Configuring using Trust Editor
The Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI Trust table.
See the PI System Management chapter in the PI Server manual for more details on security configuration.
PI Server v3.2
For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:
C:\PI\adm> piconfig
@table pi_gen,piproxy
@mode create
@istr host,proxyaccount
piapimachine,piadmin
@quit
In place of piapimachine, put the name of the PI Interface node as it is seen by PI Server.
Starting / Stopping the Interface on Windows
This section describes starting and stopping the interface once it has been installed as a service. See the UniInt End User Document to run the interface interactively.
[pic]
Starting Interface as a Service
If the interface was installed a service, it can be started from PI-ICU, the services control panel or with the command:
PICiscoPhone.exe –start
To start the interface service with PI-ICU, use the [pic] button on the PI-ICU toolbar.
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 parameters in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See the section “Appendix A: Error and Informational Messages,” for additional information.
Stopping Interface Running as a Service
If the interface was installed a service, it can be stopped at any time from PI-ICU, the services control panel or with the command:
PICiscoPhone.exe –stop
The service can be removed by:
PICiscoPhone.exe –remove
To stop the interface service with PI-ICU, use the [pic] button on the PI-ICU toolbar.
Buffering
For complete information on buffering, please refer to the PI API Installation Instruction.
PI Interface Node buffering consists of a buffering process which runs continuously on the local node, a PI API library whose calls can send data to this buffering process, and a utility program for examining the state of buffering and controlling the buffering process.
Note: Change the Local Security Policy on Windows XP.
1. Open "Administrative Tools" from the control panel.
2. Open "Local Security Policy" from administrative tools.
3. Browse to "Security Options" under "Local Policies."
4. Double click on "System Objects: Default owner for objects created by members of the Administrators group."
5. Change the dropdown from "Object Creator" to "Administrators group."
The behavior of Bufserv should now be the same on XP as it was for NT4 and 2000.
Configuring Buffering with PI-ICU (Windows-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
The user must reenter the password again to verify that he has 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 |Default server for UNIX. 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
The default server information is stored in the pilogin.ini file so the piclient.ini would only have the [APIBUFFER] section. The BUFFERING=1 indicates that buffering is on. The MAXFILESIZE entry in Kbytes of 100000 allows up to 100 Megabytes of data storage. Do not use commas or other separators in the numeric entries. The retry rate is set to 600 seconds, meaning “Wait 10 minutes after losing a connection before retrying”.
On NT a piclient.ini file might look like:
[APIBUFFER]
BUFFERING=1
MAXFILESIZE=100000
; The PI API connection routines have a 1 minute default timeout.
RETRYRATE=600
Appendix A:
Error and Informational Messages
Messages from this interface are written to the PIPC.log file on the machine the interface is running. Messages from this interface are identified by the header PI-CiscoPhone N> where N is the interface instance (/ID command line parameter).
Log File Messages
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 listing points loaded by the interface and 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.
Points that continue to be in error will have their error messages suppressed after 10 identical messages; this is to prevent the log file from being flooded with repeated messages. If a point is in error and no messages are seen in the log, the user can make a point edit to this point and messages will again be sent to the log until the limit of 10 identical messages is again reached..
There are four main places the interface encounter an error
Point Loading
If the interface is unable to load a PI point that belongs to this interface then an error message is written to the log and the digital state “Configure” is written to the point.
For Example, the message:
PI-CiscoPhone 2> Load Tag> CiscoDevice1_P1_01(245) Rejected: URL not found in instrumentTag
Tells us the point, CiscoDevice1_P1_01 (pointID 245), was not loaded because the interface did not find a URL in the instrument tag.
Reading the URL
The interface groups points in the same scan class that read an identical URL. Reading is done via a third party library (CURL). If the read returns an error I/O Timeout is written to all the points that use this URL. The error string returned from the library is written to the log for each point affected. For Example:
Tag CiscoDevice1_P1_01(245) Load Value Failed: Page '' not loaded. Error: couldn't connect to host
In this case the URL should be tested using Microsoft Internet Explorer, or some other XML/html browser..
Loading Value from Page
Once a page has been loaded from a URL the page is parsed into one or more result tables. Each point that uses this URL will then attempt to load its value from the appropriate result table. If the point is unable to load a value from the result table or the value is a type that is not appropriate for the point type the digital state Failed is written to the point and the reason written to the log. For Example:
PI-CiscoPhone 2> Tag CiscoDevice1_P1_01(245) Load Value Failed: Key (NAC Address) not found in table
If it is not clear why a point has failed to load its value it may be useful to run the interface with the command line parameter db=4. This will write the downloaded Page and the resulting data table to the “data” directory under the interface directory (usually PIHome\interface\CiscoPhone\data). A message will be written to the log indicting the file name to review for any broken points. For example:
PI-CiscoPhone 2> Tag CiscoDevice1_P1_01(245) Load Value Failed: Key (NAC Address) not found in table: Table is written to file C:\PIPC\Interfaces\CiscoPhone\Debug_File_2009_1.csv loaded from file C:\PIPC\Interfaces\CiscoPhone\Debug_File_2009.htm
The downloaded page is saved in the .htm file and the result table is in the .csv file (in comma separated format). The header of this file (see below) contains the name of the URL the file was downloaded from, the table name (this is compiled from the attributes that determine the way the page is parsed into a table) and the points that use this table. The table itself (everything beyond the Table Starts Here line) lists the available Keys in the first column and the values in the subsequent columns. Note here that the Key “Nac Address” is not in this table at this time, thus triggering the error, possibly the user should have configured Key=Mac Address in this point’s ExDesc.
Example CSV file
This File is generated by the CiscoPhone Interface
From:
Saved in file: C:\PIPC\Interfaces\CiscoPhone\Debug_File_2009.html
Table Name is: Element(TR)Col(0)Value(TD)Sep(,)
This Table is used by the following PI points
CiscoDevice1_P1_01 (245)
CiscoDevice1_P1_01_b (246)
**********************Table Starts Here********************
Column 0,Column 1,Column 2,Column 3,...
Amps,No Value,5V Amp
App Load ID,No Value,P00303010413
Boot Load ID,No Value,PC03A300
C3PO Revision,No Value,2
Codec,No Value,ADLCodec
Debug Display
Device Information
Device Logs
Ethernet
Expansion Module 1,No Value,No Value
Expansion Module 2,No Value,No Value
Hardware Revision,No Value,2.0
Host Name,No Value,SEP0006D79C2E29
MAC Address,No Value,0006D79C2E29
Network Configuration
Network Statistics
No Value,Device InformationCisco IP Phone 7960 ( SEP0006D79C2E29 )
No Value_1,No Value
Phone DN,No Value,3808
Port 1 (Network)
Port 2 (Access)
Port 3 (Phone)
Serial Number,No Value,INM0530B1LK
Stack Statistics
Status Messages
Stream 1
Streaming Statistics
Version,No Value,3.1(4.13)
When db=4 is set the interface writes, the first time a page is read, a single .htm file for each page downloaded and single .csv file for each result table generated. If any point is in error, these debug files will be written for this point on each scan. Typically this debug level will only be used for testing the interface. If the interface is run continuously with db=4 set then there is a risk the interface drive could become full.
Processing the Value
After a value is loaded from the result table the interface may still fail to write this value to PI. Typically this is because the value loaded from the result table is not suitable to be processed. For example
PI-CiscoPhone 2> Tag Cisco04_FLOAT64(24597) WritePoint Failed, Unable to convert IP(NotAnIP Address) to number.
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
On NT, descriptions of system and PI errors can be obtained with the pidiag utility:
NT: \PI\adm\pidiag –e error_number
Appendix B:
Acknowledgments
PI CiscoPhone contains components from the CURL and OpenSSL projects. Copyright notices and acknowledgments follow.
CURL
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1996 - 2004, Daniel Stenberg, .
All rights reserved.
Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not
be used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization of the copyright holder.
OpenSSL
Portions of this program are Copyright (c) 1998-2006 The OpenSSL Project. All rights reserved.
Copyright (c) 1998-2006 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgment:"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. ()"
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@.
5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ()"
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
===============================================================
This product includes cryptographic software written by Eric Young (eay@). This product includes software written by Tim Hudson (tjh@).
Original SSLeay License
-------------------------------
Copyright (C) 1995-1998 Eric Young (eay@)
All rights reserved.
This package is an SSL implementation written by Eric Young (eay@).
The implementation was written so as to conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms
except that the holder is Tim Hudson (tjh@).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed.
If this package is used in a product, Eric Young should be given attribution
as the author of the parts of the library used.
This can be in the form of a textual message at program startup or
in documentation (online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:"This product includes cryptographic software written by Eric Young (eay@)"
The word 'cryptographic' can be left out if the rouines from the library being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement:"This product includes software written by Tim Hudson (tjh@)"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]
Revision History
|Date |Author |Comments |
|4-Aug-2005 |MDymond |Created from Skeleton Version 1.15 |
|9-Nov-2005 |MKelly |Rev A. Added section on configuring the interface with the ICU.|
| | |Fixed section break, headers and footers, TOC. |
|16-Nov-2005 |MDymond |Rev B included Appendix B (Acknowledgments) |
|28-Dec-05 |MDymond |Rev C clarified ExDesc, KeyRow |
|20-Jan-06 |Janelle |Version 1.0.0.0 Rev D: Fixed formatting, reworded some |
| | |sentences, added many comments for developer’s review; fixed |
| | |headers and footers; updated how to contact us page, and |
| | |removed PI2 references. |
|27-Jan-06 |MDymond |Version 1.0.0.0 Rev E: changed wording of Introduction and |
| | |Principals of Operation |
|31-Jan-06 |Janelle |Version 1.0.0.0 Rev F: fixed the sample command line file to be|
| | |the same as the file included with the install kit; fixed a few|
| | |typo’s. |
|14-Feb-2006 |MKelly |Version 1.0.0.0 Rev G: Fixed header and footer on copyright |
| | |page, page numbering in TOC, fixed various formatting. |
|15-Feb-2006 |MDymond |Version 1.0.0.0 Rev H: Clarified some parts of Principals of |
| | |Operations and PI Point Configuration |
|17-Feb-2006 |MKelly |Version 1.0.0.0 Rev I: Changed copyright date to 2006 only, |
| | |modified sample batch file to match distributed copy. |
|9-May-2007 |ETam |Version 1.0.1.0 |
|8-Jun-2007 |MKelly |Version 1.0.1.0, Rev A: Attached current interface manual |
| | |template, fixed headers and footers, updated screenshot for ICU|
| | |and other sections. Updated the OpenSSL copyright information. |
|11-Jun-2007 |Janelle |Version 1.0.1.0, Revision B: made minor corrections in |
| | |interface installation section, table formatting changes; fixed|
| | |headers |
|29-Jun-2007 |ETam |Version 1.0.2.0 |
| | | |
| | | |
-----------------------
Service installed or uninstalled
Status of the Interface Service
Status of the ICU
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- why the school system is bad
- is the education system broken
- the school system is broken
- the education system is failing
- why the education system is good
- changing the school system essay
- the college system is broken
- calculator with the pi button
- how to cleanse the lymphatic system naturally
- the planets of the solar system song
- the organs in the circulatory system include
- label the conduction system of the heart