Befehl: Erzeugen

Symbol:

Dieser Befehl (Kategorie "Composer“) startet einen Build-Prozess, welcher automatisch die CODESYS-Applikation aus dem Modulbaum und den Einstellungen der Generatorkonfiguration erzeugt.

Meldungen und Fehler werden im Meldungsfenster ausgegeben.

Alle Objekte, welche mit dem Standard-Generator erzeugt werden (ausgenommen die Task-Objekte und Applikationen) werden im Unterordner der Applikation oder im POUs-Pool mit dem Namen AC_Std und AC_FBs gespeichert. Wenn bereits ein Ordner mit diesem Namen vorhanden ist, wird ein eindeutiger Name durch Hinzufügen eines Suffix _0 erzeugt.

Abbildung 39. Erzeugte Funktionsbausteine

Alle Objekte, welche durch den Befehl Erzeugen angelegt werden, sind mit einem kleinen blauen Icon versehen. Versucht der Anwender eines dieser Objekte zu löschen, zu verschieben oder zu editieren, dann erscheint ein Dialog mit dem Hinweis, dass diese Aktion zu Übersetzungsfehlern führen könnte. Wenn der Vorgang fortgesetzt wird, wechselt die Farbe die Icons auf rot (siehe Funktionsbaustein AC_PRG_RMP (PRG) im obigen Screenshot).

Tipp

Wenn Sie den Application Composer zusammen mit CODESYS SVN verwenden:

Alle Composer-generierten Objekte werden mit einem Ignore on Commit für SVN versehen. Zusätzlich wird beim Erzeugen in den SVN-Offlinebetrieb geschaltet, um SVN-Locks zu vermeiden und zu umgehen.

Erzeugung von Funktionsbaustein-Instanzen durch den Standard-Generator

Für jede Modulinstanz wird ein Funktionsbaustein im Ordner AC_FBs erzeugt. Dieser Funktionsbaustein leitet vom Modulfunktionsbaistein ab.

Der Funktionsbaustein enthält (Eingangs-)Variablen für

Submodulinstanzen
Arrays konfigurierbarer Größe
Puffervariablen von direkten E/A-Verbindungen
Arrays von Mehrfach-Steckplätzen und der Instanzreferenzen

Die Namen der entsprechenden Array-Variablen bilden sich aus einem Präfix AC_ARRAY_ gefolgt vom Variablennamen der entsprechenden Pointer-Variable. Für Arrays konfigurierbarer Größe kann der Name durch die Definition VarArray.InstName optional überschrieben werden.

Der Implementierungsteil des Funktionsbausteins enthält die Anweisung SUPER^();, durch die der Implementierungsteil des Modul-FBs aufgerufen wird.

Beispiel 11. Beispiel

Die Modulinstanz ModuleInstanceA ist vom Typ ModuleA mit zugehörigem Funktionsbaustein ModuleA_FB. Sie hat eine Submodulinstanz vom Typ ModuleB.

Die Modulinstanz ModuleInstanceA ist vom Typ ModuleA mit zugehörigem Funktionsbaustein ModuleA_FB. Sie hat eine Submodulinstanz vom Typ ModuleB

FUNCTION_BLOCK AC_ModuleInstanceA EXTENDS ModuleA_FB

VAR_INPUT
        Inst_Sub1 : AC_ModuleInstanceB ;
END_VAR

Der Name des Funktionsbausteins wird aus dem Modulinstanzpfad und dem Präfix AC_ gebildet.

Der Name der Variablen für die Submodulinstanzen bildet sich aus einem Präfix gefolgt vom Namen der jeweiligen Submodulinstanz.

Jeder FB wird einmal instanziiert, die FB-Instanzen von Toplevelmodulen direkt in den GVLs, die übrigen entsprechend in den FBs der Vater-Instanz.

Für jede referenzierte Modulinstanz, die in einer anderen Applikation liegt, wird genau eine FB-Instanz des Proxy-FBs angelegt, und zwar in einer der GVLs der referenzierenden Modulinstanzen. Der Name der Proxy-Instanz ist AC_PROXY_<InstanceName> wobei <InstanceName> der Name der Zielinstanz in der anderen Applikation ist.

Für alle Modul-FB-Instanzen werden eindeutige Adressen vergeben. Die Proxy-FB-Instanzen erhalten die Adresse der Modulinstanz der anderen Applikation.

Die Methode IBaseInstance.Main der Proxy-FB-Instanzen wird zyklisch in der Kommunikationstask aufgerufen.

Erzeugung der Applikation und der Task-Aufrufe

Wenn ein Modul einer Applikation zugeordnet ist, die noch nicht existiert, wird die Applikation angelegt.
Anlegen von nicht existierenden Standard-Tasks:
- TASK_MODULE_HIGH
- TASK_MODULE_MEDIUM
- TASK_MODULE_LOW
Die Priorität und Zykluszeit der Tasks wird gemäß den Generatoreinstellungen gesetzt. Außerdem werden modulspezifische Tasks mit den gegebenen Einstellungen angelegt.
Erzeugung einer globalen Variablenliste pro Toplevel-Instanz, in welcher die Modulinstanzen, die unter Toplevel-Modulen hängen, die dieser Applikation angehören, angelegt werden. Die globale Variablenliste trägt den im Modul festgelegten Namen oder, falls keine Festlegung getroffen wurde, den Namen GVL_MODULE. Die GVL hängt unter der gewählten Applikation oder im globalen POU-Baum
Pro Applikation wird eine GVL mit dem Namen GVL_ MODULE_TREE deklariert. In ihr werden die zur Verwaltung des Modulbaums nötigen Variablen deklariert. Die GVLs werden in einen Ordner mit Namen AC_Std angelegt.
Erzeugung von Initialisierungscode, der mittels Pragmas automatisch bei Download und Online-Change aufgerufen wird:
- Die Baumstruktur wird abgebildet.
- Parametersätze werden gesetzt.
- Referenzen und Submodulinstanzen werden zugewiesen.
- Felder konfigurierbarer Größe werden befüllt.
- Instanzreferenzen werden gesetzt.
Beim Download werden nur die Parameter gesetzt, die nicht auf dem Defaultwert stehen (es sei denn der Default-Wert wurde in der Moduldeklaration überschrieben), beim Online-Change alle, da hier nicht bekannt ist, auf welchem Wert der Parameter zuvor stand. Die POUs werden in einen Ordner mit Namen AC_Std angelegt.
Für jeden definierten Einsprungspunkt aus einer Task wird eine PROGRAM-POU (Implementierungssprache ST) angelegt, welche die Aufrufe der Toplevelnodule enthält. Der Aufruf dieser neuen POU wird dann unterhalb der Task eingehängt. Im Fall der Standardtasks heißen die POUs:
- MODULE_CALL_<TASKNAME>_START
- MODULE_CALL_<TASKNAME>_END
Die POUs werden in einen Ordner mit Namen AC_Std angelegt.
Für Toplevel Modulinstanzen im POUs-Pool werden die Taskaufrufe in jeder Applikation angelegt.

Erzeugung der E/A-Zuordnung

Je nach Typ der E/A-Zuordnung führt der Standardgenerator folgende Änderungen durch:

[E/A-Kanal]: Im entsprechenden Gerätekanal wird der Instanzname des E/As der Modulinstanz eingetragen.
[ST-Ausdruck]: Die Zuweisungen der Ausdrücke auf die Eingänge oder von den Ausgängen auf die Ausdrücke werden über den gesamten Teilbaum jeder Toplevel-Instanz gesammelt. Falls es entsprechende Zuweisungen gibt, wird pro Toplevel-Instanz eine Funktion mit Namen
- AC_Io_SetInputs_<Instanzname> oder
- AC_Io_SetOutputs_<Instanzname>
erzeugt, die alle Zuweisungen enthält.
Die Task, in der Ein- und Ausgänge beschrieben werden, wird durch das Flag UPDATE-IOS in der Modulbeschreibung gekennzeichnet. Diese Task wird im Folgenden "I/O-Task" genannt.
Die Funktion für die Eingänge wird in der I/IO-Task vor der Task-Methode der Modulinstanz aufgerufen. (Wenn die I/O-Task eine Standard-Task ist: vor der Start-Methode.) Die Funktion für die Ausgänge wird in der IO-Task nach Task–Methode der Modulinstanz aufgerufen. (Wenn die I/O-Task eine Standard-Task ist: nach der End-Methode.)
[Direktverbindung mit Modul-E/A, lokal]: lm Funktionsbaustein, der für die Instanz des Eingangs erzeugt wird, wird eine Puffer-Variable passenden Typs angelegt. Der Name der Puffer-Variablen beginnt mit dem Präfix AC_Io_Buffer_.
Die Puffer-Variablen werden während der Initialisierung der Applikation auf die aktuellen Werte der verbundenen Ausgänge initialisiert. Der Generator behandelt die Eingangs- und Ausgangszuweisungen wie eine Zuweisung von/auf diese(r) Puffer-Variable (siehe [ST-Ausdruck])
[Direktverbindung mit Modul-E/A, remote]: Es wird für jeden Ausgang, der mit dem Eingang einer Modulinstanz verbunden ist, die in einer anderen Applikation liegt, eine Puffer-Variable passenden Typs in der entsprechenden Sende-Netzwerk-GVL angelegt. Der Name der Puffer-Variablen beginnt mit dem Präfix AC_RemoteIo_Buffer_ und wird aus dem Instanzpfad und dem Variablenpfad des Ausgangs gebildet. Die Puffer-Variablen werden mit dem Initialisierungsausdruck der Ausgangsvariable initialisiert, falls einer existiert. Falls der Wert dieses Initialisierungsausdrucks nicht in den Precompile-Informationen enthalten ist (weil der Ausdruck z.B. Variablen, Funktionen oder Konstanten verwendet), wird ein Fehler erzeugt
Der Generator behandelt die Ausgangszuweisung wie eine Zuweisung auf diese Puffer-Variable und die Eingangszuweisung in der anderen Applikation wie eine Zuweisung von der entsprechenden Variable in der Empfänger NVL, siehe oben unter [ST-Ausdruck].
Anmerkung: die Synchronisierung zwischen der Task, in der die Netzwerkvariablen aktualisiert werden und der I/O-Task des Moduls ist noch nicht gelöst. Es kann daher sein, dass Werte nicht komplett geschrieben wurden, wenn die I/O-Task diese liest.

Erzeugung von Kommunikationsinfrastruktur

Festlegung: Im folgenden wird gesagt, dass Applikationen A1 an Applikation A2 sendet (oder äquivalent, dass A2 von A1 empfängt), wenn eine der folgenden Bedingungen gegeben ist:

Eine Modulinstanz, die der Applikation A1 zugeordnet ist, referenziert eine Modulinstanz, die der Applikation A2 zugeordnet ist oder umgekehrt.
Ein Ausgang einer Modulinstanz, die A1 zugeordnet ist, ist über eine direkte Modul-E/A-Verbindung mit einem Eingang einer Modulinstanz verbunden, die A2 zugeordnet ist.

Die folgenden Objekte werden für jede vom Generator erzeugten Applikation im Ordner AC_RMP unter der Applikation erzeugt:

Es wird eine Kommunikationstask angelegt. (Zykluszeit und Priorität gemäß Einstellung in der Generatorkonfiguration.). In dieser Task erfolgen auch die Aufrufe der Proxy-Instanzen und Setzen/Lesen der gespiegelten Modul-Proxy-FB-Variablen.
Für jede Applikation, die an die aktuelle Applikation sendet, wird eine (Sende)-GVL angelegt und deren Netzwerkeinstellungen gesetzt. (Protokoll "UDP“, zyklische Übertragung, Prüfsummen, Zykluszeit gemäß Einstellung in der Generatorkonfiguration, Kommunikationstask. Der "List Identifier“, der eine ganze Zahl zwischen 1 und 2^15-1 sein muss, wird zu Beginn der Generierung mittels Zufallsgenerator ermittelt und dann nach jeder Sende-GVL um 1 erhöht. Der Zufallswert wird so ermittelt, dass er mindestens 128 ist und dass der gültige Wertebereich nicht überschritten wird. Falls es Modulinstanz-Referenzen zwischen den Applikationen gibt, wird eine Variable vom Typ RMPExchangeData in der GVL angelegt. Der Name der Variable enthält die Namen der Quell- und der Zielapplikation. Falls diese Modulinstanz-Referenz in ihrer (nötigen) Proxy-Definition zusätzlich zu spiegelnde Variablen (MirrorVar) angibt, wird in der (Sende)-GVL, der referenzierten Modulinstan, für jede "MirrorVar“ eine Variable in der GVL angelegt. Ihr Name enthält den Instanzpfad der Modulinstanz und die TargetId, der Definition der jeweiligen "MirrorVar“.
Für jede Applikation A2, an die die aktuelle Applikation sendet, wird eine (Empfangs)-NVL (Netzwerkvariablenliste) angelegt und mit der entsprechenden Sende-GVL von A2 und der Kommunikationstask verknüpft.
In der GVL AC_RMP wird ein Funktionsbaustein vom Typ RMPService instanziiert und in der Deklaration initialisiert (mit Attribut init_on_onlchange). Dazu werden zwei Arrays vom Typ RMPConnection angelegt, die auf die oben erzeugten Variablen vom Typ RMPExchangeData in den GVLs und NVLs verweisen.
Es wird ein Programm AC_PRG_RMP erzeugt, das den Baustein vom Typ RMPService aufruft. Dieses Programm wird in die Kommunikationstask eingetragen. Zusätzlich wird in dem Program AC_PRG_RMP der Inhalt der zu spiegelnden Variablen ("MirrorVars“) gesetzt und gelesen. Es werden somit jeweils die Proxy-"MirrorVars“ den entsprechende Variablen der (Empfänger)-GVL zugewiesen. Anschließend wird die Main“-Methode der Proxy-Instanz aufgerufen und schließlich die entsprechenden Variablen der (Sender)-GVL den Modul-"MirrorVars“. Dies geschieht entsprechend der Senderichtung von Modulinstanz zu Proxies.

In diesem Abschnitt: