PointSource
The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For example, the string Bailey may be used to identify points that belong to the Bailey semAPI Interface. To implement this, the PointSource attribute would be set to Bailey for every PI Point that is configured for the Bailey semAPI Interface. Then, if /ps=Bailey is used on the startup command-line of the Bailey semAPI Interface, the Interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of Bailey. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps parameter.
In all cases, the point source character that is supplied with the /ps command-line parameter is not case sensitive. That is, /ps=B and /ps=B are equivalent. One only needs to be careful with the case of the PointSource during point definition, and only if the interface will be running on a PINet node communicating to a PI 3 Server.
Reserved Point Sources
Several subsystems and applications that ship with PI are associated with default PointSource characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Do not use these PointSource characters or change the default point source characters for these applications. Also, if a PointSource character is not explicitly defined when creating a PI point; the point is assigned a default PointSource character of Lab (PI 3). Therefore, it would be confusing to use Lab as the PointSource character for an interface.
Note: Do not use a point source character that is already associated with another interface program. However it is acceptable to use the same point source for multiple instances of an interface.
PI Point Configuration
The PI point is the basic building block for controlling data flow to and from the PI Server. A single point is configured for each measurement value that needs to be archived.
Point Attributes
Use the point attributes below to define the PI Point configuration for the Interface, including specifically what data to transfer.
Tag
A tag is a label or name for a point. Any tag name can be used in accordance to the normal PI point naming conventions.
Length
The length of the Tag field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
PI API
|
PI Server
|
Maximum Length
|
1.6 or higher
|
3.4.370.x or higher
|
24
|
1.6 or higher
|
Below 3.4.370.x
|
24
|
Below 1.6
|
3.4.370.x or higher
|
24
|
Below 1.6
|
Below 3.4.370.x
|
24
|
PointSource
The PointSource is a unique single or multiple character string that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps=x command-line parameter and the PointSource section.
PointType
Typically, device point types do not need to correspond to PI point types. For example, integer values from a device can be sent to floating point or digital PI tags. Similarly, a floating-point value from the device can be sent to integer or digital PI tags, although the values will be truncated.
Float16, float32, int16, int32, digital, and string are supported on PI 3 Servers. For more information on the individual point types, see PI Data Archive for NT and UNIX.
Location1
Location 1 is the interface number.
It is common for the interface number to match the logical ICI Number used by the Bailey semAPI software; where the logical ICI Number is configured via the utility: [ICI.EXE]ICICONF.
Location2 Input Points
Location 2 is the Infi90 Loop Number * 256 + the Infi90 PCU (Node) Number.
Output Points
Location 2 is the CIU index where the interface writes data. Assign a unique CIU index for each output point. This index is used to compute the block number when configuring Infi90 PCU modules to read the output:
Block = index
Module = 2
PCU (Node) = node address of the ICI
For example, a PI tag with CIU index number 49 connecting to an ICI whose node address is 25 could be read from another node on the Bailey Loop with an analog input block (FC26) by:
PCU-Module-Block = 25-2-49
Index 2049 can be read as PCU-Module-Block of 25-2-2049.
Location3 Input Points
Location3 is the Infi90 Module Number for inputs.
Output Points
For outputs, Location3 must be 1.
Location4 Input Points
Location4 is the Infi90 Block Number for inputs.
For Station Blocks, use the block number of the Station block for all parameters for that block. A process variable, setpoint, mode, and control output would all have the same block number as far as the ICI is concerned. They would have different Infi90 point types (Location 5).
Output Points
For outputs, Location4 must be 1.
Location5
Location5 is the Bailey point type. This defines the kind of Bailey point sending or receiving the data. See list of available types in the Bailey Point Types section.
InstrumentTag
The PI Bailey SemAPI interface does not use the InstrumentTag attribute.
ExDesc Length
The length of the Extended Descriptor field is limited by the version of the PI API, the version of the PI Server, and sometimes by a specific Interface. The table below explains this in more detail. When the maximum possible lengths differ for the software installed on site, the shortest length applies.
-
PI API
|
PI Server
|
Maximum Length
|
1.6 or higher
|
3.4.370.x or higher
|
1023
|
1.6 or higher
|
Below 3.4.370.x
|
80
|
Below 1.6
|
3.4.370.x or higher
|
80
|
Below 1.6
|
Below 3.4.370.x
|
80
|
This is the extended descriptor attribute, which is limited to 80 characters.
Some Bailey function types provide multiple fields of information (e.g. RCMs, Device Drivers). It is possible to retrieve any subset or all of these fields of information into a single PI tag or into multiple PI tags. The fields can be retrieved into a single PI tag in any order. The user specifies the field number and the extraction order by using the keyword /BLY=# or /BLY=#,#,# in the Extended Descriptor of the PI tag. Data retrieved in this manner are referred to as extended attributes in the rest of this manual. Here are a few examples:
Case 1: Single PI Tag Retrieving Multiple Fields from a DAANG Block
To get the fields in this specific order, Auto/Manual, Alarm Level, High Alarm, Low Alarm, High Deviation Alarm, Location5 would be 29 and the following configuration would be added to the extended descriptor: /BLY=7,4,2,3,17 where the field definitions are as follows:
-
Data Field
|
Definition
|
7
|
Auto/Manual
|
4
|
Alarm Level
|
2
|
High Alarm
|
3
|
Low Alarm
|
17
|
High Deviation Alarm
|
The resultant value would be built from the value in the data field or fields. Additionally, the place value assigned to each data piece depends upon its position in the extended descriptor parameter list. Thus, assuming that the Alarm Level has a value of 3, and the High Deviation Alarm is ON, the value sent to the PI tag would be as follows:
-
Data Field
|
Field Length
|
Bailey Value
|
Position in PI Value
|
PI Value
|
Auto/Manual
|
1
|
0
|
bit 0
|
0
|
AlarmLeve1
|
2
|
3
|
bits 1, 2
|
6
|
High Alarm
|
1
|
0
|
bit 3
|
0
|
Low Alarm
|
1
|
0
|
bit 4
|
0
|
High Deviation Alarm
|
1
|
1
|
bit 5
|
32
|
Value for this PI Tag
|
|
|
00100110
|
38
|
The sum of the bit length for all the extracted fields cannot exceed 15 for each tag. An error will be printed in the log file if more than that is specified. Specific data fields may be duplicated within a single tag.
Case 2: Multiple PI Tags for this Bailey Block Address and Point Type
Each tag retrieves single or multiple fields from a DAANG block. The location parameters for each of these tags will be the same; however, they will have different extended descriptors. For example, tag 1 might have an extended descriptor /BLY=7,17, and tag 2 might have an extended descriptor, /BLY=4,2,3.
Note: Even though there are multiple PI tags, the interface will only retrieve the data once from Bailey and push the correct values into the correct tags.
Performance Points
Performance Points are not supported by this interface.
Scan
By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, SCAN OFF will be written to the PI point. If the scan attribute is changed from 1 to 0 while the interface is running, SCAN OFF will also be written to the PI point after the point edit is detected by the interface.
There is one other situation, which is independent of the Scan attribute, where UniInt will write SCAN OFF to a PI point. If a point that is currently loaded by the interface is edited so that the point is no longer valid for the interface, the point will be removed from the interface, and SCAN OFF will be written to the point. For example, if the PointSource of a PI point that is currently loaded by the interface is changed, the point will be removed from the interface and SCAN OFF will be written to the point.
SourceTag
Source Tag is used only for the output points. It is the PI tag from which the output points get the values to send to Infi90. For example, the source tag can be a performance equation calculation tag or a lab (manual input) tag.
When the source tag is not defined for an output point, the interface will get the output value from the output tag snapshot. In this case, the user is responsible for updating the value directly.
Note: The source tag should have the same PI point type as the output tag in order to assure that the correct value is sent to Bailey. However, it is not necessary that the tag be a real (integer or digital) type in order to send analog or digital data to Bailey, respectively.
Shutdown
The shutdown attribute is used only if the server node is a PI 3 system.
The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of a power failure. For additional information on shutdown events, refer to PI Data Archive for NT and UNIX.
Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat command-line parameter is specified.
One can disable SHUTDOWN events from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, one can change the default behavior of the PI Shutdown Subsystem to write SHUTDOWN events only for PI points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Data Archive for NT and UNIX.
Bufserv
It is undesirable to write shutdown events when Bufserv is being used. Bufserv is a utility program that provides the capability to store and forward events to a PI Server, allowing continuous data collection when the Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when PI is shutdown, Bufserv will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface.
Share with your friends: |