Moduldeklaration

Ein Header der Form MODULE <Name> leitet die Deklaration ein. Es folgt eine Liste von sogenannten Abschnitten.

Jeder Abschnitt wird durch das Schlüsselwort SEC (für „Section“) eingeleitet und hat einen eindeutigen Namen. Ein Abschnitt wird mit dem Schlüsselwort END_SEC abgeschlossen. Der Inhalt eines Abschnitts ist eine Liste von Einträgen, die entweder wiederum Abschnitte oder aber sogenannte Definitionen sein können.

Eine Definition besteht aus einem Namen und einem (optionalen) Wert und wird mit einem Semikolon abgeschlossen.

Kommentare können wie in ST verwendet werden: „//“ für einzeilige Kommentare und „(*“ and „*)“ für mehrzeilige Kommentare, die auch verschachtelt sein dürfen. Whitespace (Tabulatoren und Leerzeichen) und Newline/Linefeed-Zeichen spielen nur insofern eine Rolle, als sie die einzelnen Bestandteile einer Deklaration trennen. Ansonsten werden sie bei der weiteren Bearbeitung ignoriert.

Groß- und Kleinschreibung spielt, wie bei ST, keine Rolle.

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 diesem Abschnitt werden die Syntax und die zulässige syntaktische Struktur einer Moduldeklaration erklärt.

Im Folgenden werden Scanner-Token in Großbuchstaben gesetzt (beispielsweise ID). Nichtterminale der Grammatik werden in geschweifte Klammern gesetzt (beispielsweise {Entry}).

Lexikalische Analyse (Scanner)

In der ersten Phase werden aus den einzelnen Zeichen der Moduldeklaration sogenannte Token (oder Lexeme) gebildet, zum Beispiel Schlüsselwörter, Konstanten, Identifier.

Whitespace sowie Newline/Linefeed-Zeichen trennen Token, werden aber ansonsten ignoriert. Kommentare werden für die weitere Verarbeitung der Deklaration ebenfalls ignoriert. (Kommentare können, wie oben schon gesagt, wie in ST als einzeilige (//“) oder mehrzeilige Kommentare ((* und *)) auftreten, letztere auch verschachtelt.)

Grundsätzlich gilt die Regel, dass ein Token immer die maximal mögliche Länge hat. Zum Beispiel wird a123 als ein Identifier und nicht als Identifier a gefolgt von einem Literal 123 eingelesen.

Außerdem gibt die Reihenfolge, in der die Token unten beschrieben sind, ihre Priorität vor. Die Eingabe MODULE wird beispielsweise als Schlüsselwort erkannt und nicht als Identifier.

Syntax (parser)

Die Syntax der Moduldeklaration wird durch folgende Grammatik definiert. µ ist die leere Sequenz.

{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}

Die Liste der Werte einer Definition ({ValList}) muss mit einem Semikolon abgeschlossen werden. Dies vereinfacht die Grammatik und verhindert Mehrdeutigkeiten, da das Semikolon innerhalb eines Wertes ({VAL}) nicht vorkommen kann (außer innerhalb eines String-Literals).

Ebenso dient der Zuweisungsoperator (:=) bei Definitionen ({Def}) dazu, Mehrdeutigkeiten zwischen dem Namen der Definition ({QID}) und den Werten zu vermeiden.

Definierte Typen für Definitionen

An einigen Stellen der Moduldeklaration können Instanzpfade angegeben werden, die eine Variable des Module-Funktionsbausteins adressieren: Bei Parametern, Slots, E/As, Arrays konfigurierbarer Größe und bei Instanzreferenzen.

Ein Instanzpfad besteht aus einer nichtleeren, durch Punkte getrennten Folge von Komponenten: C1.C2…CN. Eine Komponente ist entweder ein IEC-Bezeichner oder eine Komponente gefolgt von einem Index-Ausdruck [i1, …, iN] wobei i1 bis iN ganzzahlige Literale sind.

Instanzpfade sind immer relativ zum Funktionsbaustein, der die Modullogik implementiert. Die erste Komponente des Instanzpfads ist ein Member (VAR_INPUT oder VAR_OUTPUT, je nach Anwendungsfall) des Funktionsbausteins. Hat der Instanzpfad weitere Komponenten, dann adressieren diese die Variable innerhalb des Members. Ansonsten ist das Member selbst adressiert. Instanzpfade können auf Eingangs- oder Ausgangsvariablen eingeschränkt werden (zum Beispiel bei I/Os). Für Strukturen gelten diese Einschränkungen nicht. Solche Instanzpfade werden als Eingangs-Instanzpfad bzw. Ausgangs-Instanzpfad bezeichnet

Texte, die lokalisiert werden sollen (beispielsweise Beschreibungen von Modulen, Name, Beschreibung von Parametern), werden in Textlisten verwaltet.

Analog zum objektorientierten Ableiten eines Funktionsbausteins A von einem Funktionsbaustein B („EXTENDS“) ist auch das Ableiten von Moduldeklarationen über IMPORTS möglich. Die beiden Modifier UPDATE und HIDE werden gesondert behandelt.

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 diesem Beispiel wird der Parameter paramIn des Modules MBase im abgeleiteten Modul MDerived mit HIDE verborgen und gleichzeitig mit einem neuen Defaultwert (TRUE) versehen.

Die Reihenfolge der Abschnitte direkt nach dem Modul-Header spielt keine Rolle. Innerhalb der Abschnitte kann die Reihenfolge allerdings sehr wohl eine Rolle spielen. Zum Beispiel bestimmt die Reihenfolge der Slot-Deklarationen die Reihenfolge, in der die Slots im Modulbaum angezeigt werden.

Die Reihenfolge von Definitionen spielt nie eine Rolle.

Beim Schreiben im Moduleditor werden alle möglichen verfügbaren Sekionsdefinitionen in einem „Komponenten auflisten“-Menü angezeigt. Dabei werden nur sinnvolle Sektionen und Definitionen für die aktuelle Position gezeigt. Selbst wenn einige Untersektionseinträge den gleichen Namen wie Untersektionseinträge anderer Sektionen haben, wird versucht, nur die passenden Sektionsdefinitionen anzuzeigen.

Wenn nach der Fertigstellung der ersten Zeile einer Sektion Return gedrückt wird, wird die Sektion mit allen notwendigen Definitionen/Sektionen und dem END_SEC vervollständigt.

Nach den Variablendefinitionen werden Eingangs- und Ausgangsvariablen durch eine „Komponenten auflisten“-Menü angeboten. Flags oder vordefinierte Werte werden ebenfalls in einer „Komponenten auflisten“-Auswahl, die die möglichen Flags/Werte anzeigt, angeboten.

Nach Definitionen, welche Textlisteneinträge oder Einträge von Bildersammlungen verwenden (in den meisten Fällen Desc :=), wird ein „Komponenten auflisten“-Menü mit allen verfügbaren und sichtbaren Textlisten/Bildersammlungen und deren Einträgen angezeigt.

Durch Drücken von F2 kann die entsprechende Eingabeunterstützung geöffnet werden.

Sektion MetaData

Sektion Toplevel

Sektion IO

Sektion Parameters

Sektion Slots

Sektion Visu

Sektion Proxies

Sektion VarArrays

Sektion Constraints

Sektion InstRefs

Sektion mse.Sequence

DeviceGenerator

Sektion alg.Alarm