Opc interface to the pi system

Connections - Creating, Losing, and Recreating

The interface is designed to be very persistent about creating and maintaining a connection with both the OPC Server and the PI Server. If either or both of them are not available on startup, the interface will indicate that fact in the pipc.log file and retry the connection every 5 seconds until it is successful. If it loses the connection to the PI Server after the initial connection, it will continue to gather data from the OPC Server and try to send it to the PI Server by trying to re-establish the connection. To avoid losing data in this situation, the use of the PI API buffering program (bufserv) that buffers data on the interface node is strongly recommended. If the connection to the PI Server is lost, it will be apparent on the PI Server side that no data is coming in if /ST command-line parameter was used in the interface configuration, which will be discussed in more detail later. When the interface loses the connection to the OPC Server, it will also try to re-establish that connection (see OPC DA Interface Failover Manual for alternative strategies). The interface also monitors the server status reported by the OPC Server. On startup, it will wait for the OPC Server to report that it is in the RUNNING state. This will happen before beginning the process of creating Groups and adding items. To accommodate servers that do not return the proper state code, use the /IS command-line parameter in the interface startup file.

A simple OPC client, PI OPCClient, is provided with the interface. The PI OPCClient comes with a manual (User’s Guide) that provides more information about its usage and supported functionality. The general purpose of PI OPCClient is to verify that we can connect to the OPC Server and read (and optionally write) data. If the OPC Server is on a different machine than the OPC Interface and the PI OPCClient, this requires having OPCEnum (see the next section) installed on both machines. If the user cannot establish connection using the PI OPCClient, then the PI OPC Interface will also fail to connect to that OPC Server.

The PI OPCClient can also be used to read from and write data to the OPC Server. If the user succeeds in reading data from the OPC Server by using the Poll and Advise operations in the PI OPCClient, the PI OPC Interface should also be able to read and write data. More details on these issues are described in the PI OPCClient User’s Guide.

The OPCEnum Tool

The OPC Foundation has provided a tool to allow OPC clients to locate servers on remote nodes, without having information about those servers in the local registry. This tool is called OPCEnum and is freely distributed by the OPC Foundation. The PI OPC Interface installation will automatically install OPCEnum as well. The primary function of OPCEnum is to inform or request information from other instances of OPCEnum about existing OPC Servers on the local system. When OPCEnum is installed, it grants Launch and Access DCOM permission to Everyone, and sets the Authentication level to NONE. This allows access to any user who can log on to the system. Permissions can be changed using dcomcnfg.exe (see DCOM Configuration Details section for more information on DCOM settings).

If the OPC Server is on a different node which does not have the OPCEnum tool (OPCEnum.exe), it is allowed to manually copy it from the Windows\System32 directory of the interface node and place it in the Windows\System32 directory of the OPC Server node. This application can be registered as a service on the OPC Server node by entering the command OPCEnum.exe –service from the Windows\System32 directory in a Command Prompt window. Administrative privileges are required for the login UserId on the OPC Server system.

Timestamps

The interface is designed to get timestamps from the OPC Server along with the data. The interface will then adjust those timestamps to match the time on the PI Server. This is done because system clock settings can be different for different systems or the clocks may drift. The interface calculates the difference of the timestamps from the PI Server and the OPC Server every 30 seconds.

If the OPC Server provides timestamps it is possible to use the /TS command-line parameter to adjust the behavior of the interface.  With the /TS=Y setting, the interface expects the OPC Server to provide timestamps, and will only adjust them to compensate for the offset between OPC Server time and PI Server time.

/TS=N is used if the OPC Server cannot provide any timestamps or if the user doesn’t want to get them from the OPC Server.  In this case, the interface will timestamp each value as it receives it and adjusts that to compensate for the offset between interface node time and PI Server time.  This is the default setting.

/TS=A is used if the OPC Server will provide timestamps for Advise tags. Some servers will return correct values for Advise items, but for Polled reads they will return the time that the value last changed, rather than the time of the read. This option has the interface use the Advise timestamps, but provide timestamps for the Polled values, just as it would with /TS=N.

/TS=U is an option that needs to be selected with caution. With this option, the timestamps received from the OPC Server will be sent to the PI Server directly without any adjustments. If the OPC Server time is ahead of the PI Server time, this option will result in the PI Server receiving timestamps that are in the future. Consequently, the data will not be written to the PI Server. The user should select this option only if the clock settings on both servers are appropriate (i.e. either the same or the PI Server clock is ahead) and the clocks are either automatically synchronized or clock checks are made frequently. If the user is getting error  11049 in the pipc.log file, the clocks on the PI Server and on the interface node need to be checked. This error will occur when the interface has sent a timestamp that is outside of the range for the PI archives.

For more details on Advise and Polled tags, see the section below on Polling, Advising and Event Tags.

Writing Timestamps to the Device

Timestamps may be written to or read from the device as data. To read and write timestamps from a PI tag, where the timestamp is the value of the tag, see the section on Data Types.

For the special case where the user needs to write the timestamp of an output value to one ItemID and the output value itself to another, it is possible to get the timestamp by specifying the ItemID in the ExDesc field. In this case it is required to specify whether the ItemID is to be written as a VT_DATE or as a VT_BSTR (string value). If it is to be written as a string value, the /TF parameter in the startup file must be defined, so the interface knows what format to use to create the string. See the sections on ExDesc and Command-line Parameters for more details on settings.