On Windows 2000 and earlier platforms, PI-Ping has a resolution lower limit of 10 milliseconds. This restriction can limit its applicability with respect to very fast networks. Therefore, PI Ping should be viewed as a tool that records automated attempts that quantify the quality of troublesome client-server connections.
PI-Ping measures ping response times only between the computer on which it runs and a remote machine. For example, in the following configuration, PI-Ping cannot determine the ping time between Machine1 and Machine2.
For those users who are familiar with running PI data collection interface programs, the following checklist provides assistance for getting the PI-Ping Interface running. Those who are not familiar with PI interfaces should return to this section after reading the rest of the manual in detail.
Install the PI ICU. This installation automatically installs the PI-SDK and the PI API.
Confirm PI-API connectivity by running the apisnap program.
Run the PI-Ping installation program.
Choose a point source for use by the Interface.
Use the PI ICU to configure startup parameters. Alternatively, manually edit the startup command file.
Configure PI points to be used by the Interface.
The InstrumentTag specifies the IP address or name of the machine to be “ping”ed.
Location1 is the interface identification number.
Location2 is the number of pings to send.
Location3 is the required number of ping replies.
Location4 specifies the scan class (and hence the measurement frequency).
Location5 enables point-level debugging.
If desired, configure performance points.
If desired, configure an I/O Rate point.
Modify the security of the PI Server. For PI 3.3 and above, use the Trusts plug-in of PI-SMT to edit the PI Trust table. For PI 3.2, use PIConfig to edit the PI Proxy table.
Stop the PI Buffer Server.
Interactively start the Interface.
Verify that the Interface writes correct data to the PI Server.
Stop the Interface and start the PI Buffer Server.
Start the Interface as a Windows service.
Confirm that the Interface re-starts after a complete machine shutdown and restart.
Interface Installation on Windows
OSIsoft recommends that interfaces be installed on PI Interface Nodes instead of directly on the PI Server node. A PI Interface Node is any node other than the PI Server node where the PI Application Programming Interface (PI API) has been installed (see the PI API manual). With this approach, the PI Server need not compete with interfaces for the machine’s resources. The primary function of the PI Server is to archive data and to service clients that request data.
After the interface has been installed and tested, Bufserv should be enabled on the PI Interface Node (once again, see the PI API manual). Bufserv is distributed with the
PI API. It is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when communication to the PI Server is lost. Communication will be lost when there are network problems or when the PI Server is shut down for maintenance, upgrades, backups, or unexpected failures.
In most cases, interfaces on PI Interface Nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of an interruption in electrical power.
The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and install the interface as an automatic service that depends on the PI Update Manager and PI Network Manager services. 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
When Configuring the Interface Manually
When an interface is configured as a Windows service, the executable file name (i.e., PIPing.exe) and the command file (i.e., PIPing.bat) must have the same root name (i.e., piping). The reason is that at service startup, the interface executable (i.e., PIPing.exe) looks specifically for startup parameters in a .bat file (i.e., PIPing.bat) that has the same root name (i.e., PIPing) as the executable.
Thus, when manually configuring the interface and running multiple copies, the user needs to copy and rename both the executable and the startup command file. For example, copy PIPing.exe so that PIPing1.exe results and copy PIPing.bat so that PIPing1.bat results. Subsequently, PIPing1.exe and PIPing1.bat are typically used for interface instance number 1. Repeat the process so that PIPing2.exe and PIPing2.bat are used for interface instance number 2, and so on.
PIHOME Directory Tree
The PIHOME directory tree is defined by the PIHOMEentry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file; it is located in the directory where Windows itself is installed.
A typical pipc.ini file contains the following lines:
[PIPC] PIHOME=c:\Program Files\pipc
The above lines define the c:\Program Files\pipc directory as the root of the PIHOME directory tree on the C: drive.
OSIsoft recommends using \Program Files\pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.
Interface Installation Directory
If installing the interface manually, place all copies of the interface into a single directory. The suggested directory is:
Replace PIHOME with the corresponding entry in the pipc.ini file.