Generic generation

During the generic generation of the DPAD, the texts of the levels of the base framework are automatically concatenated together.

Complete object names and object descriptions are created from the names and descriptions of the objects and folders from the project structure.

Here is an example to explain the mechanism:

The illustration shows the measured value (MV) of the return temperature sensor (TRt) from heating circuit 01 HTC01.

An instance of the function block FB_FB_BA_CarelessDPAD is required for the generic generation of the DPAD. It is recommended to call the function block right at the beginning in MAIN.

The number of levels, the type of separators and the character width of the indexes are defined in the initialization of the DPAD function block. It is important that the number of initialized levels of the DPAD matches those of the project structure.

The indexes are mostly used for naming the aggregate and function levels of the data point. In the initialization sample, two digits (00 to 99) are provided for each index.

The concatenation algorithm of the DPAD function block only recognizes the texts that are to be concatenated if they are defined as placeholders {} within the curly brackets.

Placeholders are very variable and versatile. A more detailed description of the placeholders can be found in the chapter: Object description texts

There are two methods for specifying the initialization texts for the object name and the description:

Direct writing of name and description

Sample:

sObjectname := 'Sample name';

sDescription := 'Sample description';

Use of placeholders

One variant for initializing these texts is the use of placeholders.

These are usually defined in the FB_init of the template (in this sample FB_BA_H_HtgCir01).

Only texts initialized in placeholders {} are concatenated to the other levels of the project structure by the DPAD algorithm.

The following samples show how the concatenation of texts can be influenced by placeholders.

All of the following DPAD initialization samples refer to the name of the pump in the heating circuit.

Object names and descriptions are described directly in these samples without the use of labels.

Name concatenated and fixed index

Pu.sObjectName := '{Pu{Idx=99}}';

Description text with object index

Pu.sDescription := '{Pump{Idx}}';

Name concatenated and automatic index

Pu.sObjectName := '{Pu} ';

Entry point for concatenation defined by !{} and ObjectIndex {Idx} activated

Pu.sDescription := '!{Pump{Idx}}';

Name concatenated without index

Pu.sObjectName := '{Pu01{!Idx}}';

Pu.sDescription:= '{Pump01}';

User-defined name

Pu.sObjectName := '{123M1{!Idx}}';

Pu.sDescription:= '{Pump 123M1}';

Name not concatenated and fixed index

Pu.sObjectName := Pu{Idx=99}';

Transfer of the object index to the description text

Pu.sDescription:='Pump{Idx}';

Name not concatenated and fixed index

Pu.sObjectName :='Pu{Idx=99}';

Defined own index in the description text

Pu.sDescription :='Pumpe{Idx=123}';

Name not concatenated and InstanceID of object

Pu.sObjectName :='Pu{InstID}';

Pu.sDescription:='Pump{InstID}';

Name not concatenated and automatic

Pu.sObjectName:='Pu';

Pu.sDescription:='Pump{Idx}';

Name not concatenated without index

Pu.sObjectName := 'Pu{!Idx}';

Pu.sDescription := 'Pump';

Labels for defining names and descriptions

Labels are another option for initializing the texts of names and descriptions of objects.

A label is the paired summary of the texts for the name and description of an object. Initialization is carried out with the function block FB_BA_Label.

The function block FB_BA_Label2x is to be used if the texts of the levels aggregate and function of the data point are to be initialized together.

In TwinCAT 3 Building Automation, the labels are stored in a list of global variables.

Within the TwinCAT 3 Building Automation templates, they are used to initialize the text variables sObjectname and sDescription.

The label lists are available for naming aggregates (LblAggregates_xx), general control functions (LblControll_xx) and function names (LblFunction_xx).

The lists with the ending _EN contain labels in English and the lists with the ending _DE contain labels in German. For the choice of language, the language that is not desired must be commented out before compiling the controller for the first time.

DPAD mode

For each level of the project structure, the DPAD mode can be used to determine whether and which texts are to be taken into account in the concatenation.

In the following sample, the explanation is based on a ventilation system from the TwinCAT 3 Building Automation template repository.

The main aggregates of the ventilation system, the heater (PreHtr), the energy recovery (ERC) and the cooler (Col), each have their own function block, within which all components or sub-aggregates are called. The main aggregates are not part of the levels in the DPAD. In the definition of the DPAD, the levels for the sub-aggregates and functions are defined directly after the Plant level.

This means that there is one more level in the PLC than there is in the DPAD.

The heater level must therefore be excluded when generating the object names.

This is done with the DPAD mode and the following initialization.

The eIncludeDescription setting is selected for the heater. The description text of the heater is thus concatenated and the name of the heater is excluded when generating the object names.

The result of this parameterization can be seen in the Site Explorer.

The symbol path (1) has 7 levels, which means that the description text (2) and the object name (3) also have 7 levels, whereby one level is not displayed for the object name.

In the description text (2) of the flow temperature sensor of the air heater, the description text 'PreHeater' is included and excluded in the object name (3).