Output points control the flow of data from the PI Data Archive to any destination that is external to the PI Data Archive, such as a PLC or a third-party database. For example, to write a value to a register in a PLC, one would use an output point. Each interface has its own rules for determining whether a given point is an input point or an output point. There is no de facto PI point attribute that distinguishes a point as an input point or an output point.
Outputs are triggered for UniInt-based interfaces. That is, outputs are typically not scheduled to occur on a periodic basis. There are two mechanisms for triggering an output.
Trigger Method 1 (Recommended)
For trigger method 1, a separate trigger point must be configured. The output point must have the same point source as the interface. The trigger point can be associated with any point source, including the point source of the interface. Also, the point type of the trigger point does not need to be the same as the point type of the output point.
The output point is associated with the trigger point by setting the SourceTag attribute of the output point equal to the tag name of the trigger point. An output 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 value that was sent to the Snapshot to trigger an output, but the timestamp of the new value needs to be more recent than the previous value. If no error is indicated, then the value that was sent to the trigger point is also written to the output point. If the output is unsuccessful, then an appropriate digital state that is indicative of the failure is usually written to the output point. If an error is not indicated, the output still may not have succeeded because the interface may not be able to tell with certainty that an output has failed.
Trigger Method 2
For trigger method 2, a separate trigger point is not configured. To trigger an output, write a new value to the Snapshot of the output point itself. The new value does not need to be different than the previous value to trigger an output, but the timestamp of the new value must be more recent than the previous value.
Trigger method 2 may be easier to configure than trigger method 1, but trigger method 2 has a significant disadvantage. If the output is unsuccessful, there is no tag to receive a digital state that is indicative of the failure, which is very important for troubleshooting.
Bailey Point Types
Analog data from Bailey should be defined in the PI system as a float. If the Quality of the value is good, the floating-point value from Bailey is stored in the PI System. If the passed Quality is bad, the digital code for Bad Input is stored for that tag. Other Bailey status information such as alarm fields are not used by the interface except in the case of extended attributes specified in the extended descriptor.
If a Bailey analog point is defined as a digital point in the PI system, the value is interpreted as the offset from the digital starting code of the point. Any value out of the range of 0 and the number of digital states minus one is stored as Bad Input.
For most point types, the interface supports the retrieval of additional attributes from the exception reports. Thus, the user can define more than one PI tag pointing to the same Bailey block and extract different pieces of information from the same exception report.
For all Bailey data, the interface always checks the Quality of the Bailey value. If the Quality is bad, no further processing is done and the digital state Bad Input is put into the PI value. This Quality check also applies to PI tags retrieving extended attributes from the Bailey values.
Note: If the Bailey Quality is bad, the interface will not retrieve other fields or fields within the Bailey Exception Report.
The supported input Bailey point types are listed in the following tables and further described below.
Supported Input Point Types (Bailey Data to PI) -
Bailey
Point Type
|
Description
|
Data Type
|
Bailey
Function Code
|
OIS Type Name
|
Extended Attribute
|
1
|
Process Variable
|
A
|
Note 1
|
Station
|
No
|
2
|
Set Point Read
|
A
|
Note 1
|
Station
|
No
|
3
|
Control Output Read
|
A
|
Note 1
|
Station
|
No
|
4
|
Ratio Index Read
|
A
|
80, 23
|
Station
|
No
|
5
|
Analog Read
|
A
|
30
|
Analog
|
Yes
|
6
|
Station Status
|
D
|
Note 1
|
Station
|
Yes
|
7
|
Digital Read
|
D
|
45
|
Digital
|
No
|
14
|
Module Status
|
D
|
|
|
No
|
15
|
RCM Read
|
D
|
62, Note 3
|
RCM
|
Yes
|
19
|
RMSC Read
|
A
|
68
|
RMSC
|
Yes
|
21
|
4-byte Analog Read
|
A
|
|
|
Yes
|
29
|
DAANG
|
A
|
|
|
Yes
|
30
|
ASCII string
|
S
|
|
|
No
|
51
|
MSDD
|
D
|
129
|
|
Yes
|
52
|
DD
|
D
|
123
|
|
Yes
|
53
|
RMC
|
D
|
|
|
Yes
|
54
|
DADIG
|
D
|
|
|
Yes
|
60
|
Text Selector
|
I
|
|
|
No
|
70
|
Harmony Analog Input
|
A
|
Note 2
|
|
Yes
|
71
|
Harmony Analog Output
|
A
|
Note 2
|
|
Yes
|
72
|
Harmony Digital Input
|
D
|
Note 2
|
|
Yes
|
73
|
Harmony Digital Output
|
D
|
Note 2
|
|
Yes
|
Note 1: For Station points, the Bailey function code can be 80, 21, 22 or 23. Use the same Bailey address for the PV, SP and CO of the station point.
Note 2: The Harmony point types (70-73) are supported only for interface version 1.3 and greater running on Windows.
Note 3: The Bailey point type specifications for this interface are almost the same as those in the PI BA-I90, the serial communication based interface. For those customers who will convert from the serial based Infi90 interface to the semAPI, NO changes to the location parameters are required except for Bailey point type 15. The serial based interface uses a point type of 15 to get data from RCM, MSDD, and DD point types. The semAPI interface uses 15 for RCM, 51 for MSDD, and 52 for DD point types.
Share with your friends: |