Module Declaration

A header of the form MODULE<name> begins the declaration. This is followed by a list of "sections".

Each section is introduced by the keyword SEC (for "section") and a unique name. The keyword END_SEC closes the section. The contents of a section contain a list of entries consisting of further sections or so-called definitions.

A definition consists of a name and an optional value and ends with a semicolon.

Comments can be used as in ST code: "//"" for a single line comment and "(*" and "*)" for multiline comments. Whitespace (tabs and spaces) and newline/linefeed can be used to separate the parts of a declaration. Otherwise they are ignored during further processing.

As with ST code, case sensitivity makes no difference.

01    MODULE Persistence IMPLEMENTED_BY PersistenceFB
02    SEC MetaData
03        NAME       := TL.ChannelName ;
04        DESC       := TL.ChannelDesc ;
05        COLLECTION CATEGORY := ’Persistence’TL.Collection  ;
06        ICON_16    := IP.Channel16 ;
07        ICON_32    := IP.Channel32 ;
08    END_SEC
09    SEC Toplevel
10              SEC STANDARD_TASK : LOW
11                      NAME  := LOW ;
12                      DESC  := TL.TaskLow ;
13                      FLAGS := CREATE_IF_MISSING | READONLY ;
14              END_SEC
15              GVL_NAME := 'GVL_%InstanceName%' ;
16     END_SEC

In this section the syntax and the allowed syntactic structure of a module declaration will be explained.

In the following scanner tokens will be written in capitals (example: ID). Non-terminals of the grammar will be written in curly brackets (example: {Entry}).

Lexical analysis (scanner)

In the first step so-called tokens (or lexemes) will be created from the characters of the module declaration (example: keywords, constants, identifiers).

Whitespace as well as newline/linefeed characters separate tokens, but will be ignored otherwise. Comments will also be ignored for the further treatment of the declaration. (Comments can be written in a single line (//") or multiline comments ((* and *)) as in to ST language. Multiline comments can be nested.

Basically a token has always a maximal length. For example a123 will be interpreted as an identifier and not as an identifier a followed by a literal 123.

The order of the tokens in the list below shows their priority. For example the input MODULE will be understood as keyword and not as identifier.

Syntax (parser)

The syntax of the module declaration is defined by the following grammar. µ is an empty sequence.

{MDecl}        ::= MODULE {QID} {ImplSpec} {ImportsSpec} {MBody}
{ImplSpec}     ::= IMPLEMENTED_BY {QID} | µ
{ImportsSpec}  ::= IMPORTS {QID} | µ
{MBody}        ::= {SecList}
{SecList}      ::= {Modifiers} {Sec} {SecList} | µ
{Sec}          ::= SEC {QID} {SecTarget} {EntryList} END_SEC
{SecTarget}    ::= OP(":") {QID} | µ
{Modifiers}    ::= OP("[") {ModifierList} OP("]") | µ
{ModifierList} ::= {QID} OP(",") {ModifierList} | {QID}
{EntryList}    ::= {Modifiers} {Entry} {EntryList}
{Entry}        ::= {Sec} | {Def}
{Def}          ::= {QID} OP(":=") {ValList} SEMICOLON |
                   {QID} SEMICOLON
{ValList}      ::= {Val} {ValList} | {Val}
{Val}          ::= ID | LIT | OP
{QID}          ::= ID | ID OP(".") {QID}

The list of definition values ({ValList}) must be completed with a semicolon. This simplifies the grammar and avoids ambiguities, because the semicolon cannot be part of a value ({VAL}), except within a string literal.

The assignment operator (:=) of definitions ({Def}) also serves to avoid ambiguities ({QID}) of definition names and values.

Defined types for definitions

At some positions in the module declaration instance paths can be defined to address a variable of a function block: For parameters, slots, I/Os, arrays with variable size and instance references.

An instance path is defined as a non empty sequence of components, separated by dots: C1.C2…CN. A component must either be a IEC identifier or a component followed by an index expression [i1, …, iN], where i1 to iN are integer values.

Instance paths are always relative to the function block which implements the module logic. The first component of the instance path is a member (VAR_INPUT or VAR_OUTPUT, depending on the use case) of the function block. In case of additional components in the instance path these components address the variable within the member. Otherwise the member itself is addressed. Instance paths can be restricted to input or output variables (example: for I/Os). For structures these restrictions are not valid. These kind of instance paths are called input instance paths resp. output instance paths.

Texts in modules (example: description of module, name, description of parameter) can be displayed in different languages. These texts are managed in text lists.

Analogously to the object oriented inheritance of a function block A from a function block B ("EXTENDS") there is the possibility of deriving module declarations by use of the IMPORTS keyword. The modifiers UPDATE and HIDE are treated specially.

MODULE MBase IMPLEMENTED_BY FBBase
SEC MetaData
        DESC := TL.Desc_Base ;
END_SEC
SEC Parameters
        SEC Param : paramxIn
                Variable := xIn ;
                Name     := TL.Param1_Name ;
                Desc     := TL.Param1_Desc ;
        END_SEC
END_SEC

MODULE MDerived IMPORTS MBase
[UPDATE] SEC MetaData
        DESC := TL.Desc_Derived ;
END_SEC
[UPDATE] SEC Parameters
        [UPDATE,HIDE] SEC Param : paramIn
                Variable := xIn ;
                DEFAULT := TRUE ;
        END_SEC
END_SEC

In the example above the parameter paramIn of the module MBase is hidden in the derived module MDerived (by use of the HIDE modifier), and at the same time a new default value (TRUE) is set.

The order of the sections directly after the module header is irrelevant. Within the sections the order may be very important. For example the order of the slot declarations defines the order of the modules in the module tree.

The order of the definitions is always irrelevant.

When start typing in the module editor all available/possible section definitions are shown in an "list components" menu. Only meaningful sections and definitions for the current position are shown. Even if some subsection entries have the same name as subsection entries of other sections, it will try to display only the matching section definitions.

If Return is pressed after completing the first line of a section, then the section will be completed with all necessary definitions/sections and the END_SEC .

After variable definitions input/output variables are presented by "list components" definitions. Flags or predefined values are also presented in a "list components" selection, which shows the possible flags/values.

After definitions, which use text list entries or image pool entries (example: most times Desc :=), a "list components" menu including all available and visible text lists or image pools and their entries is presented.

By pressing F2, the corresponding input support can be opened.

Section: MetaData

Section: Toplevel

Section: IO

Section: Parameters

Section: Slots

Section: Visu

Section: Proxies

Section: VarArrays

Section: Constraints

Section: InstRefs

Section: mse.Sequence

Device Generator

alg.Alarm