Beispiel 1: Funktion MUL_01 mit konkretem Datentyp

Die folgende Schnittstelle deklariert eine Funktion mit 2 Eingängen mit dem Datentyp INT.

Die Anwendung Test_01 ruft den angegebenen Vendor-Baustein MUL_01 auf und weist dessen Ergebniswert der Variablen Var2 zu.

Die folgenden Zeilen werden in der H-Datei lcfu___MUL_01.h benötigt, damit logi.CAD 3 in der Lage ist, die Anwendung für Test_01 zu erstellen. Die Zeilen /* ... */ sind lediglich Kommentare, die zur Erläuterung der Struktur hinzugefügt wurden.

Hier einige grundlegende Erklärungen zu diesem Inhalt:

• Die Standard-Header-Datei muss enthalten sein, weil der Standard-Datentyp INT verwendet wird.

• Die Typdefinition muss die folgenden Elemente der POE und deren Datentyp deklarieren:

  	Funktionsbausteine	Funktionen
  →Eingangsvariablen der POE		–
  →Ein-/Ausgangsvariablen der POE
  Ausgang ENO (dessen Datentyp ist immer BOOL)
  →Ausgangsvariablen der POE
  lokale →Variablen der POE		–
  Ergebniswert der Funktion	–
  Hilfsvariablen, die für den Benutzer nicht sichtbar sind Diese Hilfsvariablen sind notwendig, um ihre Werte von einer Ausführung der Anwendung bis zur nächsten behalten wird.		–

  Der Datentyp der Variablen und des Ergebniswerts hängt von der angegebenen Schnittstelle ab. Für das obige Beispiel muss für den Ergebniswert LC_VD_MUL_01 der Datentyp INT angegeben werden.
  Deklarieren Sie die Variablen in der Reihenfolge wie in der Tabelle angegeben. Die Reihenfolge kann relevant werden, wenn eine Anwendung mit Hilfe des Ressourcenmanagers aktualisiert (= neu geladen) wird.
  Dies bedeutet:

  • Die erforderliche Reihenfolge für Variablen in einer Herstellerfunktion ist: VAR_IN_OUT – ENO – VAR_OUTPUT – Ergebniswert

  • Die erforderliche Reihenfolge für Variablen in einem Vendor-Funktionsbausteins ist: VAR_INPUT – VAR_IN_OUT – ENO – VAR_OUTPUT – VAR – Hilfsvariablen, die für den Benutzer nicht sichtbar sind

• Das Initialisierungsmakro ist für jedes Element erforderlich, das innerhalb der Typdefinition deklariert ist, nicht aber für den Ausgang ENO. Das Initialisierungsmakro ist eine typspezifische Initialisierung.

• Die Implementierung spezifiziert eine "C-Funktion", die angibt, was die POE tun soll, wenn sie aufgerufen wird. Im obigen Beispiel führt MUL_01 die Berechnung 2*IN1*IN2 durch und weist das Ergebnis dem Ergebniswert LC_VD_MUL_01 zu.
  Alternativ kann die Implementierung auch mit Hilfe einer C-Datei erfolgen. In diesem Fall ist im Vendor-Baustein die Definition functionHasCFile innerhalb der Anweisung { ImplementationProperties ( ) } erforderlich. Informationen über die Struktur einer C-Datei erhalten Sie bei logi.cals .

Wenn Sie die Anwendung für Test_01 erstellen, erzeugt logi.CAD 3 automatisch die folgenden Zeilen in der Datei lcpu___test_01.c für die Zeile Var2:=MUL_01(IN1:=2, IN2:=Var1);:

(Diese Datei befindet sich im Unterordner src-gen des Projekts. Dieser Unterordner ist standardmäßig nicht sichtbar.)

Hier sind einige grundlegende Erklärungen zu diesem Code (wenn Sie an Details interessiert sind, wenden Sie sich bitte an logi.cals):

• Zeile LC_TD_Function_MUL_01 lFunction_MUL_01; = Verwendung der Typdefinition (in der H-Datei angegeben); Außerdem wird die Variable lFunction_MUL_01 erstellt.

• Zeile LC_INIT_Function_MUL_01(&lFunction_MUL_01); = Initialisierung der erzeugten Variablen mit dem Initialisierungsmakro (in der H-Datei angegeben)

• Zeile lcfu___MUL_01(&lFunction_MUL_01, (LC_TD_INT)2, LC_this->LC_VD_VAR1, pEPDB); = Aufruf der Funktion MUL_01 mit zugewiesenen Parametern; Zunächst wird dem Ergebniswert eine Variable zugewiesen, dann werden die Werte bzw. Variablen den Eingangsvariablen zugewiesen (hier: Literal 2 und Variable VAR1. Zuletzt ird immer der interne Parameter pEPDB aufgeführt.
  Wären Eingangsvariablen der Funktion beim Aufruf der Funktion weggelassen worden, so würde der Initialisierungswert des Datentyps diesen Eingangsvariablen zugewiesen werden.
  Normalerweise wird der Parameter pEPDB (pointer Entry Point Description Block) nicht benötigt, um einen C-Baustein zu implementieren. Daher können Sie diesen internen Parameter ignorieren. Wenn Sie jedoch bestimmte RTS-APIs verwenden, muss der Parameter pEPDB übergeben werden.
  

• Zeile LC_this->LC_VD_VAR2 = lFunction_MUL_01.LC_VD_MUL_01; = Zuweisung der Ergebnisse an die Variable VAR2.

Ergebnis der obigen Implementierung: Wenn Sie die Anwendung auf die integrierte SPS laden, wird die Sicht Variablenwerte den Wert 20 für die Variable Var2 anzeigen.

Beispiel 2: Funktion MUL_02 mit allgemeinem Datentyp

Die folgende Schnittstelle deklariert eine Funktion mit 2 Eingängen, nun mit dem allgemeinen Datentyp ANY.

Die Anwendung Test_02 ruft den angegebenen Vendor-Baustein MUL_02 auf (ein mit INT typisierter Aufruf und ein anderer mit SINT typisierter Aufruf) und weist dessen Ergebniswert der jeweiligen Variablen zu.

Als Folge davon werden die folgenden Zeilen in der H-Datei lcfu___MUL_02.h benötigt.
Wenn Sie den Aufruf mit mehr Datentypen als INT und SINT verwenden würden, würde die H-Datei auch die entsprechenden Zeilen für diese Datentypen erfordern.

Ergebnis der obigen Implementierung: Wenn Sie die Anwendung auf die integrierte SPS laden, wird die Sicht Variablenwerte den Wert 60 für die Variable Var3 und den Wert 12 für die Variable Var5 anzeigen.

Beispiel 3: Funktionsbaustein FB_MUL_01 mit konkretem Datentyp

Die folgende Schnittstelle deklariert einen Funktionsbaustein mit 2 Eingängen mit dem Datentyp ANY. und 1 Ausgang mit dem Datentyp INT.

Die Anwendung Test_01 ruft den angegebenen Vendor-Baustein FB_MUL_01 auf und weist dessen Ausgang der Variablen Var2 zu.

Die folgenden Zeilen werden in der H-Datei lcfu___fb_mul_01.h benötigt, damit logi.CAD 3 in der Lage ist, die Anwendung für Test_01 zu erstellen. Die Zeilen /* ... */ sind lediglich Kommentare, die zur Erläuterung der Struktur hinzugefügt wurden.

Hier die grundlegenden Unterschiede zum Beispiel für Funktionen:

• In der Typdefinition müssen die Eingänge des Funktionsbausteins und deren Datentyp deklariert werden.
  Lokale Variablen müssten ebenfalls in der Typdefinition deklariert werden. Dieser Funktionsbaustein hat aber keine lokalen Variablen.

• Daher werden die Eingänge des Funktionsbausteins auch innerhalb des Initialisierungsmakros benötigt.

• Das Initialisierungsmakro für den Warmstart (= WINIT-Makro) wird benötigt. Das WINIT-Makro definiert das Verhalten des Funktionsbausteins bei einem Warmstart, während das INIT-Makro das Verhalten bei einem Kaltstart definiert.
  Das WINIT-Makro ist dem INIT-Makro ähnlich, hat aber zusätzlich das Retain-Flag RF.
  Die Zeile #define LC_WINIT_FunctionBlock_FB_MUL_01(p,RF) { if (RF==0) LC_INIT_FunctionBlock_FB_MUL_01(p) } reicht aus, um eine korrekte Codegenerierung zu gewährleisten, wenn eine Instanz des Funktionsbausteins in einem Abschnitt VAR ... END_VAR mit dem Schlüsselwort RETAIN deklariert werden würde.
  Obwohl in diesem Beispiel der Funktionsbaustein in einem Abschnitt VAR ... END_VAR ohne das Schlüsselwort RETAIN deklariert wird, ist es sinnvoll, diese Zeile für das WINIT-Makro zu integrieren. Sie – als Hersteller des Funktionsbausteins – können nicht sicher sein, ob der Funktionsbaustein mit oder ohne das Schlüsselwort RETAIN verwendet werden wird.
  Wenn der Funktionsbaustein selbst einen Abschnitt mit dem Schlüsselwort RETAIN enthält, muss der Inhalt des WINIT-Makros anders aussehen. Bitte kontaktieren Sie logi.cals für Details zu diesem Inhalt.

• Die Nameserver-Datenstruktur wird ebenfalls benötigt.
  Die Zeile #define LCNS_EL_CNT___FB_MUL_01 0 ist ausreichend, um eine korrekte Codegenerierung zu gewährleisten. Wenn die H-Datei jedoch automatisch generiert wird, sieht der Inhalt anders aus. In diesem Fall müssen Sie den automatisch generierten Inhalt nicht ändern.

• Die Implementierung gibt die "C-Funktion" für den Funktionsbaustein an, ohne die Eingänge zu spezifizieren. Grund dafür: Die Eingänge werden bereits von der Datenstruktur (LC_this) bereitgestellt.

Ergebnis der obigen Implementierung: Wenn Sie die Anwendung auf die integrierte SPS laden, wird die Sicht Variablenwerte den Wert 30 für die Variable Var2 anzeigen.