POINTS

[POINTS]

The data point (register) is defined using the following fields (strictly in this order).

Modbus Point Data

 

Description

ParentConnectionName1)

Name of the Modbus connection instance.
NOTE: The Importer will reject this connection entry if this field is empty.

ParentDeviceName1)

Name of the device to which this point is connected. It must match the DeviceName of the device to which this point will be connected.
NOTE: The Importer will reject this point entry if this field is empty or duplicated in the same CSV file.

PointName1)

Name of the Modbus point. The naming rules are similar to that of InterfaceName; there must be no spaces or special characters.
NOTE: The Importer will reject this point entry if this field is empty or duplicated in the same CSV file.

PointDescription1)

Description of the Modbus point instance as it will appear in System Browser in Management View.
NOTE: The Importer will reject this point entry if this field is empty.

FunctionCode1)

Modbus function code for accessing Modbus data points. It should be numeric and must be from the set of FunctionCodes mentioned in the Import Rules. It is mandatory for system-defined points, but optional for custom points.

Offset1)

Offset number defines the address of point in the set of data points. For example, the offset 0 indicates address 1. The Offset must contain numbers greater than or equal to 0.
In case of Blob data type, the syntax of the Offset will be <OffsetValue>:<Size>.

For example, if your blob property has an offset value of 64 and size of 16 bytes then in the Offset field, specify the value as 64:16.

SubIndex1)

Subindex value specifies the starting bit from which to read or access a part of the retrieved data point value. Composed of byte streams, the Modbus data is an array of untyped values. Subindex value defines the position within that array. Using Subindex and its transformation type, the Modbus data point calculates the number of bytes to be taken from that position.

DataType1)

Transformation type. Data format required by the Modbus device.
For details about the allowed values, see the table showing the mapping between the data point element type – direction – function code – transformation in the Data Type section.

Direction1)

This defines the address/response mode used for accessing the value on the Modbus server:
Input: Data must be read from the Modbus server
Output: Data must be written to the Modbus server
NOTE:
For reading back an output item, you must create a Modbus InOut point.

LowLevelComparison

Low Level Comparison is applicable for only those properties with Direction as Input. The default value of this field is False.

If set to True, the driver sends the data only in case of changes.

ObjectModel

Object model of the point if this is a custom point.
NOTE: You need to define and import an object model in the system before you can use this field. For details, see the table that illustrates mapping between DPE type – direction – function code – transformation in the Data Type section. The Importer rejects the point entry only when this field is invalid; not when the field is empty.

Property

Name of the object model property.

AddressProfile

Address profile associated with the object model.

Alias

Alias to be assigned to the Modbus data point.

FunctionName

User-defined function.

DisciplineID

Discipline to which the Modbus data point should be associated with.

SubdisciplineID

Subdiscipline to which the Modbus data point should be associated with.

TypeID

Type of Modbus data point.

SubtypeID

Subtype of the Modbus data point.

Min

Minimum value set for a field point. The syntax depends on the mentioned data type. If it not present, then it is taken from the object model.

Max

Maximum value set for the field point. The syntax depends on the mentioned data type. If it is not present, then it is taken from the object model.

MinRaw

Lower end of the raw value scale.

MaxRaw

Upper end of the raw value scale.

MinEng

Lower end of your engineering value scale.

MaxEng

Upper end of your engineering value scale.

Resolution

The number of digits that display after the decimal point (resolution value).
For example, if the resolution value is 1, then the value displays as 20.0. If this field is empty, then it is taken from the object model.

Unit

Selection list for a unit from the selected text group. (For example, %, min, °C, and so on). If it is blank, then no unit is set for this point.

StateText

Name of the text group. This text group could be either from the list of text groups defined in the Texts section or from the text groups present in the system.

This field applies only for BOOL and ENUM data types.

PollGroup

Name of the poll group to be associated with the point.

AlarmClass

Generic Alarm class.
Defines the Alarm Class to be enabled for an event (for example, Alarm, Anomaly, Blocked$Fault,) For multiple alarms or alarm classes, separate the alarm class by the $ characters.
Syntax: [AlarmClass]=<AlarmClass1>$<AlarmClass2>$ <AlarmClass3>…
Example
Alarm$Fault$Anomaly

AlarmType

Workstation Alarm Type
Valid Alarm Types:
-EQ: equality (=)
-NE: not equal to (!=)
-LT: less then (<)
-LE: less than or equal to (<=)
-GT: greater then (>)
-GE: greater than or equal to (>=)
-BET: between
-NBET: not between
Syntax: [AlarmTypes]=<AlarmTypes1>$<AlarmTypes2>$ <AlarmTypes3>
NOTE: The point will be imported without alarming if this field is not present.

AlarmValue

Defines the value for which an alarm is reported. The range is indicated by the $ character. For example, if the Alarm Value is 40$50, it means that alarm values are between 40 and 50.
Syntax: [AlarmValues]=<AlarmValue1>$<AlarmValue2>$ <AlarmValue3>
The syntax of Between (-BET) and Not Between (-NBET) operators are as follows: [Value1$Value2]
For multiple alarms containing both Equals and Range alarms, the syntax should be like this: “10$[40$50]”
NOTE: If the StateText field is defined, then the AlarmValue field will use it. The point will be imported without alarming if this field is not present.

EventText

Alarm text for incoming event. For multiple alarms, multiple event texts can be defined.
Syntax: [EventText]=<EventTexts1>$<EventText2>$ <EventText3>
Examples: "Error", "Error$Warning", "Error$Warning$DangerLevel” …

NormalText

Alarm text for outgoing event. For multiple alarms, multiple normal texts can be defined.
Syntax: [NormalText]=<NormalText1>$<NormalText2>$ <NormalText3>
Examples: “Normal”, “OK$Normal”, “Normal$OK$Normal” …

UpperHysteresis

Defines the upper range for the alarm value; beyond which alarms will be generated. For example, if the alarm set for the value is greater than 50 and the UpperHysteresis is set to 2, then the alarm is only generated when the alarm value reaches 52.

LowerHysteresis

Defines the lower range for the alarm value below which alarms will be generated. This value is always specified as a negative. For example, if the alarm set for the value is less than 50 and the LowerHysterisis is set to -2, then the alarm is only generated when the alarm value falls to less than 48.

NoAlarmOn

Defines whether or not an alarm is triggered whenever the connection to the device is lost. This field can have either of the following values:
None or Blank: If None is specified or if no value is specified in this field, then on importing the CSV file, the No alarm on driver invalid check box in Alarm Configuration section of the Object Configurator is not selected. In this case, if alarm is configured on default value then that alarm will be raised whenever the connection to the device is lost.
DriverFail: If the value specified is DriverFail, then on importing the CSV file, the No alarm on driver invalid check box in Alarm Configuration section of the Object Configurator is selected. In this case, if alarm is configured on default value then that alarm will not be raised even if the connection to the device is lost.

Logical Hierarchy

Logical Hierarchy of the data point in the logical view. The logical hierarchy path in the CSV file must start and end with a backslash (\).
Syntax: [Delimiter]<Level1>[Delimiter]<Level2> [Delimiter]…[Delimiter]<Level-n>[Delimiter]
Example: \BuildingA\Floor3\Room403\
The importer automatically adds the data point to the logical hierarchy path after the last delimiter and thereafter adds this hierarchy to the root node of the Logical View in the System Browser.
So, for example, for a data point “Light403_11” associated with the hierarchy path “\BuildingA\Floor3\Room403\”, the logical hierarchy as displayed in the System Browser will be the following:
<Logical Hierarchy Root Node>\BuildingA\Floor3\Room403\Light403_11

User Hierarchy

User hierarchy of the data point in the user-defined view. The user hierarchy path in the CSV file must start and end with a backslash (\).
Syntax: [Delimiter]<Level1>[Delimiter]<Level2> [Delimiter]…[Delimiter]<Level-n>[Delimiter]
Example: \BuildingA\Floor3\Room403\
The importer automatically adds the data point to the user hierarchy path after the last delimiter and thereafter adds this hierarchy to the root node of the user hierarchy in the System Browser.
So, for example, for a data point “Light403_11” associated with the hierarchy path “\BuildingA\Floor3\Room403\”, the user hierarchy as displayed in the System Browser will be the following:
<User Hierarchy Root Node>\BuildingA\Floor3\Room403\Light403_11

1)

Indicates Mandatory Field

NOTE 1:
If any of the alarm fields contains an error, the point is imported, but no alarm is configured.
NOTE 2:

If multiple alarm configurations are listed in one field, the delimiter is $.
NOTE 3:
The following data point fields are ignored from the CSV file if the object model is present or it is not empty because the Importer interprets this point as an instance of a custom object model and expects that all these settings are already configured in the object model.
- Function Code
- DataType
- Direction