Event points

Event points are read by the PI OPC interface when it receives notification that a trigger point has a new event. Event PI points are configured with a trigger PI point. When the trigger point receives a value, the event point is read.

Note: Data loss can occur for Event Points ( ExDesc contains event='trigger_tag_name' condition) if the connection to the PI Server is lost. The interface signs up for events from Update Manager for the source points configured for the Event Points. When there is no connection, the source point data cannot be sent to PI, nor can updates be received from the Update Manager for the Event Points. Thus, Event Points will not be updated during the time period when connectivity is lost, nor can data be recovered during the period of lost connectivity

Frequent device reads can impair the performance of the OPC server. By default, the server is requested to update its cache every second for every event point defined. You can set reads to different update rates depending on the OPC server version:

• OPC v2.0 servers always read event points from the device, not the cache. To reduce system resource overhead from cache updates to the OPC server, set the event rate (er) parameter to a high value, such as eight hours.

• For OPC v1.0a servers, asynchronous reads come from the cache. The internal cache update interval needs to be fast enough to ensure that data in the cache is not stale.

For any asynchronous read, the OPC server is required to return all of the values together, which can delay the return of new values to Data Archive if the OPC server encounters a delay in reading the values. To improve performance in this case, group points according to the device where the data originates.

Configure the following PI Point attributes to create event points.

• location3

  Set to 0 for event points.

• location4

  Assigns the scan class for a point. Set to 0 for event points.

• userint2

  For each OPC event group, configure this attribute as the same integer for each PI point in the group. Assigning PI points to OPC event groups ensures that the points are read together. For example, a plug-in DLL that post-processes data might require the data to be sent in a single group.

• exdesc

  For each OPC event group, configure the exdesc attribute using the same name of the triggering point. Use the syntax TRIG='trigger_point_name’ event_condition. Use single quotes. To treat all changes as triggering events, omit event_condition.

  See the following table for a list of event descriptions:

  Event Condition	Description
  Anychange	Trigger on any change as long as the value of the current event is different than the value of the previous event. System digital states also trigger events. For example, an event will be triggered on a value change from 0 to "Bad Input," and an event will be triggered on a value change from "Bad Input" to 0.
  Increment	Trigger on any increase in value. System digital states do not trigger events. For example, an event will be triggered on a value change from 0 to 1, but an event will not be triggered on a value change from "Pt Created" to 0. Likewise, an event will not be triggered on a value change from 0 to "Bad Input."
  Decrement	Trigger on any decrease in value. System digital states do not trigger events. For example, an event will be triggered on a value change from 1 to 0, but an event will not be triggered on a value change from "Pt Created" to 0. Likewise, an event will not be triggered on a value change from 0 to "Bad Input."
  Nonzero	Trigger on any non-zero value. Events are not triggered when a system digital state is written to the trigger tag. For example, an event is triggered on a value change from "Pt Created" to 1, but an event is not triggered on a value change from 1 to "Bad Input."

  The PI point that triggers the read is a separate input point than the event points. When a new event for a trigger point is sent to the PI Snapshot, the PI System notifies the interface, which then reads the values for all the associated event points from the OPC server.

  For v1.0a servers, an asynchronous read is sent to the server’s cache. For v2.0 servers, the interface performs an asynchronous read from the device.

For more information about configuring input trigger points, see the PI Universal Interface (UniInt) User Guide.

For efficiency with v1.0a servers, separate event points into groups based on the triggering event. For OPC v2.0 servers, separate event points according to the data source. The OPC v2.0 standard requires that all asynchronous reads originate from the device rather than from the server’s cache, so set the cache update rate high and do not group values that come from different devices.

The following table illustrates PI points configured for separate event points.

In the preceding example, PM1_Trigger and PM2_Trigger are points that are updated either by this interface instance, another interface, or by manual entry. When PM1_Trigger gets a new event in the snapshot, the interface sends the OPC server a read command that requests data for both PM1_Temp.PV and PM1_Rate.PV. Both values are returned in a single call. Likewise, when PM2_Trigger gets an event in the snapshot, the interface requests a value for PM2_Temp.PV.