Interface to the pi system



Download 0.56 Mb.
Page7/14
Date31.07.2017
Size0.56 Mb.
#24976
1   2   3   4   5   6   7   8   9   10   ...   14

Output Points


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.


Download 0.56 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   10   ...   14




The database is protected by copyright ©ininet.org 2024
send message

    Main page