Skip to main content

Sektion: Toplevel

Module, die in der ersten Ebene des Baumes zu finden sind, heißen Toplevel-Module. Sie zeichnen sich dadurch von den anderen Modulen aus, dass sie über Methoden verfügen, die direkt von einer/mehreren Tasks aufgerufen werden. Toplevel-Module enthalten die Sektion Toplevel.

SEC Toplevel                                        //optional: yes, modifier: [UPDATE]
    GVL_Name := <GVL name>;                         //optional: yes, type: literal
    Default_Application := <default application>;   //optional: yes, type: QID
    Default_POUPool := <TRUE/FALSE>;                //optional: yes, type: BoolFlag
    Pragmas := [<pragma1>, <pragma2>,...];          //optional: yes, type: Pragmalist
    SEC Standard_Task : <task name>                 //optional: yes, modifier: [HIDE,UPDATE]
            Name := <task name>;                        //optional: no, type: ID
            Desc := <task description>;                 //(optional: no, type: Text)
            Flags:= <flag>;                             //(optional: no, type: StdTaskFlags)
    END_SEC
    SEC Custom_Task : <task name>                    //optional: yes, modifier: [UPDATE]
            Priority := <priority>;                     //optional: no, type: Subrange(0 .. 31)
            Interval :=  <interval>;                    //optional: no, type: TimeLiteral)
            Flags:= <flag>;                             //optional: no, type: CustomTaskFlags)
    END_SEC
END_SEC

Details über die Syntax der Definitionstypen sind im Kapitel Syntax der Moduldeklaration beschrieben.

. Spezifikation:

  • GVL_Name legt die globale Variablenliste fest, in der die Instanz für das Modul und alle seine Unterinstanzen angelegt werden. Der Platzhalter %Instancename% (Groß-/Kleinschreibung spielt keine Rolle) wird dabei durch den Instanznamen der Modulinstanz ersetzt.

  • Default_Application definiert die Vorbelegung der Applikationszuordnung auf eine bestimmte Applikation für alle Instanzen dieses Moduls. Wenn eine Default-Applikation definiert ist, kann der Parameter Default_POUPool nicht mehr verwendet werden.

  • Default_POUPool definiert die Vorbelegung der Applikationszuordnung auf einen POU-Pool für alle Instanzen dieses Moduls. Wenn eine Default-POU-Pool definiert ist, kann der Parameter Default_Application nicht mehr verwendet werden.

  • Der Parameter Pragmas enthält eine in eckige Klammern gefasste, Komma-separierte Liste von Compiler-Pragmas, die vor FB-Instanzen des Moduls eingefügt werden.

Über den Abschnitt Standard_Task wird festgelegt, aus welcher/n Task(s) Aufrufe erwartet werden. Dazu sind drei Standardtasks vorgesehen: LOW, MEDIUM und HIGH, die als Target des Abschnitts verwendet werden. Die Definitionen von Standard_Task haben folgende Bedeutung:

  • Name: Der Default-Taskname, der nach dem Erzeugen der Modulinstanz als Taskzuordnung eingetragen wird.

  • Desc: Bezeichner für den Taskaufruf. Dieser sollte kurz und aussagekräftig sein, beispielsweise I/O-Task)

  • Flags: Folgende Werte können mit | kombiniert werden:

    • CREATE_IF_MISSING: Die Task wird neu angelegt, wenn sie nicht existiert.

    • READONLY: Der Anwender kann die Taskzuordnung nicht ändern.

    • UPDATE_IOS: Die Task wird zum Aktualisieren von E/As verwendet. Jeder E/A kann durch den Parameter UpdateInTask in der Sektion IO überschrieben werden.

    • NONE: Kein Flag gesetzt.

Beispiel 17. Beispiel
SEC Standard_Task : MEDIUM
        Name  := MainTask ;
        Desc  := TL.TaskMedium_Desc ;
        Flags := READONLY | CREATE_IF_MISSING ;
END_SEC


Über den Unterabschnitt Custom_Task kann ein Modul eine oder mehrere eigene Tasks definieren. Das Target des Abschnitts muss der Name einer Methode des Modul-Funktionsbausteins sein. Die Methode darf keine Argumente haben (weder INPUT noch OUTPUT noch INOUT).

  • Priority: Die Task-Priorität

  • Interval: Das Task-Intervall (TIME- oder LTIME-Konstante).

  • Flags: Folgende Werte können mit | kombiniert werden:

    • SHARED: Dieses Flag ist aus Kompatibilitätsgründen noch vorhanden, wird jedoch implizit immer als gesetzt angenommen. Dies bedeutet grundsätzlich, dass wenn eine Task mit den in der Sektion Custom_Task festgelegten Eigenschaften existiert, diese Task verwendet wird. Da eine neue Task erzeugt wird wenn keine bestehende Task mit den passenden Eigenschaften existiert, ist dieses Flag veraltet. Der Name der erzeugten Task ist TASK_<Modulinstanzname>_<MethodenName>.

    • UPDATE_IOS: Der Task wird zum Update von E/As verwendet, die mit ST-Ausdrücken oder direkt mit Modul-E/As verbunden sind.

    • NONE: Kein Flag gesetzt.

Für die angegebene Methode gibt es keine Standard-Implementierung in der Modulklasse.

Beispiel 18. Beispiel
SEC Custom_Task : Method1
        Priority := 7 ;
        CycleTime := t#14ms ;
        Flags := NONE ;
END_SEC


Tipp

Es muss genau eine Standardtask oder spezifische Task das Flag UPDATE_IOS gesetzt haben.

. Hier einige grundlegende Regeln, wie Tasks erzeugt werden:

  • Wenn Standardtasks existieren, die das Flag CREATE_IF_MISSING nicht gesetzt haben, sollte eine Task mit dem festgelegten Namen und den Eigenschaften der Generatoreinstellungen existieren. Wenn die Eigenschaften nicht mit den spezifizierten Eigenschaften übereinstimmen, wird eine Warnung ausgegeben.

  • Wenn Standardtasks existieren, die das Flag CREATE_IF_MISSING gesetzt haben, wird zuerst eine Task mit den spezifizierten Eigenschaften erzeugt. Wenn nun die Generatoreinstellungen für diese Task geändert werden, wird die Task entsprechend angepasst, ohne eine Warnung auszugeben.

  • Standardtasks unterschiedlichen Typs, die den gleichen Tasknamen referenzieren, sind nicht erlaubt. In diesem Fall wird eine Fehlermeldung ausgegeben.

In Abhängigkeit von den geforderten Taskaufrufen muss ein Toplevel-Modul über folgende Methoden verfügen, die aus der definierten Task heraus am Taskanfang und –ende aufgerufen werden:

METHOD CallPrioHighStart: BOOL
METHOD CallPrioHighEnd: BOOL
METHOD CallPrioMediumStart: BOOL
METHOD CallPrioMediumEnd: BOOL
METHOD CallPrioLowStart: BOOL
METHOD CallPrioLowEnd: BOOL

Das Toplevel-Modul muss für den Aufruf seiner Untermodulinstanzen selbst Sorge tragen. Untermodulreferenzen sollen nicht aufgerufen werden. Die Default-Implementierung im FB Module ruft die jeweiligen Methoden aller Untermodulinstanzen in Reihenfolge des Baumes auf.

Tipp

Der Super-Pointer bietet einen Zugriff auf die Instanz des Basisfunktionsbausteines. Deshalb kann zum Beispiel der Aufruf SUPER^.CallPrioHighStart() verwendet werden, um die Methode Module.CallPrioHighStart() aufzurufen, falls der Funktionsbaustein von Module abgeleitet wurde. In diesem Fall stellt die Implementierung in Module sicher, dass alle Untermodule aufgerufen werden.

In diesem Abschnitt: