Eigenschaften für das Implementieren von Vendor-Bausteinen
Dieser Artikel enthält Anweisungen, die bei der Erstellung von Vendor-Bausteinen verwendet werden können – insbesondere die Anweisungen zur Erstellung der Schnittstelle des Vendor-Bausteins. Außerdem gibt es einige Beispiele, die einige der Möglichkeiten für die Schnittstelle illustrieren.
Information zum Vendor-Baustein |
---|
Die Schnittstelle eines Vendor-Bausteins (= Vendor-→Funktionsbaustein oder Vendor-→Funktion) wird in einem ST-Objekt erstellt, während die Implementierung eines Vendor-Bausteins in →C erstellt wird. Einschränkungen: Die folgenden Variablen werden in der Schnittstelle eines Vendor-Bausteins nicht unterstützt:
|
Beachten Sie:
-
Dieser Artikel enthält eine Referenzdokumentation der Anweisungen, die für die Erstellung der Schnittstelle von Vendor-Bausteinen vorgesehen sind. Natürlich werden Sie auch andere Anweisungen verwenden müssen – zum Beispiel die Abschnitte
VAR_INPUT ... END_VAR
,VAR_OUTPUT ... END_VAR
,VAR_IN_OUT ... END_VAR
. Informationen zu diesen Möglichkeiten (oder zu anderen, hier nicht aufgeführten Anweisungen) finden Sie unter "Unterstützte ST-Syntax". -
Die folgenden Dateien werden für die Implementierung benötigt:
Datei
Inhalt
die H-Datei
Datentyp für den Vendor-Baustein, Initialisierungsmakros (
INIT
,WINIT
) und – falls keine C-Datei verwendet wird – die Implementierung (in der Regel durch ein Makro)
Siehe "Die Struktur der benötigten H-Datei" für den grundlegenden Aufbau einer H-Datei.eine optionale C-Datei
die Implementierung (falls die Implementierung nicht in der H-Datei realisiert ist)
Alle C-Dateien werden beim Erstellen der Anwendung angehängt, so dass eine C-Datei zum Kompilieren verwendet wird. Daher können die einzelnen C-Dateien auch Auswirkungen auf andere C-Dateien haben. Neuron empfiehlt, einen Define am Ende der C-Datei zurückzusetzen, falls der Define nur für eine C-Datei gültig ist.Die Tatsache, ob eine C-Datei verwendet wird, wird durch die Definition
functionHasCFile
innerhalb der Anweisung{ ImplementationProperties ( ) }
gesteuert. Weitere Informationen finden Sie weiter unten.optionale O-Dateien und/oder lib-Dateien
Die Tatsache, ob Dateien für zusätzliche Objekte und/oder Bibliotheken verwendet werden, wird durch die Definitionen
additionalObjects
undadditionalLibraries
innerhalb der Anweisung{ ImplementationProperties ( ) }
gesteuert. Weitere Informationen finden Sie weiter unten.Die Erstellung des Inhalts der H-Datei und der C-Datei geht über den Rahmen dieses Artikels hinaus. Im Artikel "Details: Vendor-Baustein erstellen" finden Sie eine Anleitung zur Erstellung der Implementierungs-Stubs in der C-/H-Datei.
-
Die Anweisungen
{...}
werden in der IEC-Norm auch als →Pragma bezeichnet. Die folgenden Anweisungen können Ganzzahlliterale oder →Zeichenfolge-Literale in Pragmas enthalten. Zeichenfolge-Literale in Pragmas können sowohl in das doppelte Anführungszeichen"
als auch in das einfache Anführungszeichen'
eingeschlossen werden. Der Einfachheit halber wird in diesem Artikel für die meisten Zeichenfolge-Literale in Pragmas das doppelte Anführungszeichen"
verwendet.
In diesem Artikel: |
---|
Allgemeine Anweisungen
Sie müssen eine der folgenden Anweisungen als erste Zeile des ST-Objekts einfügen, das die Schnittstelle des gewünschten Vendor-Bausteins enthält.
Anweisung |
Zweck |
---|---|
|
Diese Anweisung macht den Baustein zum Vendor-Baustein, der für eine Bibliothek verwendet werden soll. Diese Anweisung hat die folgenden Auswirkungen:
Falls Sie eine C-Datei verwenden wollen, geben Sie in der Anweisung |
|
Beachten Sie: Neuron empfiehlt die Verwendung der
Der Name, der bei der optionalen Definition |
Schnittstellen-Anweisungen
Geben Sie die Schnittstellen-Anweisungen an, um die Bausteinschnittstelle zu bestimmen (z. B. Hintergrundfarbe, Höhe/Breite).
Speichern Sie keine Änderungen, die Sie im Schnittstelleneditor durchgeführt haben. Normalerweise verwenden Sie den Schnittstellen-Editor, um die Bausteinschnittstelle zu erstellen. Bei der Erstellung von Vendor-Bausteinen sollten Sie den Schnittstellen-Editor jedoch nur zur Überprüfung der Schnittstelle verwenden. |
Syntax |
---|
|
Die Definitionen für EA { IO_definition_1, IO_definition_2, IO_definition_3 }
werden auf die angegebene Variable des Vendor-Bausteins angewendet, z. B. IO-name_1
. Neuron Power Engineer unterstützt die Definitionen für EA für
-
den Ergebniswert einer Funktion.
In der folgenden Beschreibung wird der allgemeine Begriff "Variable" verwendet.
EA-Definition |
Zweck |
---|---|
|
bestimmt die Ausrichtung der angegebenen Variablen
|
|
bestimmt die Position der angegebenen Variablen
Befindet sich die Variable außerhalb von |
|
bestimmt den alternativen Namen der angegebenen Variablen |
Die Schnittstellen-Definitionen, z. B. Interface_definition_1
, werden auf den Vendor-Baustein angewendet.
Schnittstellen-Definition |
Zweck |
---|---|
|
bestimmt die Höhe des Bausteins, falls der Baustein in den FBS-Editor eingefügt wird |
smartWidth := #
|
bestimmt die Breite des Bausteins, wenn der Bausteins in den FBS-Editor eingefügt wird |
|
wie |
|
bestimmt die Minimumhöhe des Bausteins – Nach dem Einfügen des Bausteins in den FBS-Editor kann der Baustein bis zu der angegebenen Minimumhöhe verkleinert werden. |
|
bestimmt die Maximumhöhe des Bausteins – Nach dem Einfügen des Bausteins in den FBS-Editor kann der Baustein bis zu der angegebenen Maximumhöhe vergrößert werden. |
|
bestimmt die Minimumbreite des Bausteins – Nach dem Einfügen des Bausteins in den FBS-Editor kann der Baustein bis zu der angegebenen Minimumbreite verkleinert werden. |
|
bestimmt die Maximumbreite des Bausteins – Nach dem Einfügen des Bausteins in den FBS-Editor kann der Baustein bis zu der angegebenen Maximumbreite vergrößert werden. |
|
bestimmt die Anzahl der Eingänge, die für die ordnungsgemäße Funktion des Vendor-Bausteins erforderlich sind Eine Warnung wird ausgegeben, falls ein Bausteinaufruf in einen Editor eingefügt wird und im FBS-Editor zu wenig Eingänge des Bausteinaufrufs beschaltet sind oder im ST-Editor zu wenig Parameter für den Bausteinaufruf angegeben sind. Um die Warnung zu vermeiden, müssen Sie die erforderliche Anzahl von Eingängen oder zumindest den letzten Eingang beschalten oder angeben.
Falls Sie diese Definition angeben, fügen Sie am besten die Definition |
|
bewirkt, dass der Baustein eine feste Größe hat In der Folge werden die Angaben für |
|
verbirgt die Namen der Eingänge, Ausgänge, Ein-/Ausgänge und den Ergebniswert einer Funktion |
|
für Ein-/Ausgangsvariablen (= Neuron Power Engineer zeigt die Schnittstelle des Bausteins wie in logi.CAD/32 an. Das bedeutet, dass nur der Eingangsanschlusspunkt der Ein-/Ausgangsvariablen in Neuron Power Engineer angezeigt wird. Außerdem ist es möglich, dass andere Variablen auf der gegenüberliegenden Position des Eingangsanschlusspunkt angezeigt werden. Diese Einstellung wird automatisch übernommen, falls ein Baustein mit Ein-/Ausgangsvariablen von logi.CAD/32 nach Neuron Power Engineer migriert wird. Der Schnittstellen-Editor bietet für diese Schnittstellenanweisung kein passendes GUI-Element. |
|
bestimmt den alternativen Namen für den Baustein |
|
bestimmt die vertikale Ausrichtung des Bausteinnamens (oder des alternativen Namens für den Baustein)
Siehe die folgenden Beispiele für die Ausrichtung. |
|
bestimmt die Hintergrundfarbe des Bausteins Neuron empfiehlt, dass Sie und/oder Ihr Systemintegrator keine Gelb-Farbtöne bei der Gestaltung von FBS-Elementen verwenden, da "Gelb" für die Verfolgung von sicheren Signale beim Entwickeln von sicherheitsrelevanten Anwendungen verwendet wird. Diese Empfehlung gilt insbesondere dann, wenn Sie das Legacy-Styling verwenden. Neuron Power Engineer prüft nicht, ob Farben bereits anderweitig verwendet werden. Die Verwendung von Gelb-Farbtönen durch Sie und/oder Ihren Systemintegrator könnte also zur Folge haben, dass "Gelb" dann auch eine nicht-sichere Logik kennzeichnet. |
|
bestimmt die Farbe des Bausteintextes; Mögliche Werte: siehe die Hintergrundfarbe des Bausteins |
|
bestimmt die Farbe der Eingänge, Ausgänge, Ein-/Ausgänge und des Ergebniswertes einer Funktion; Mögliche Werte: siehe Hintergrundfarbe des Bausteins |
safeStyle
|
ähnlich wie bgColor , aber ohne Wert, da die Hintergrundfarbe des Bausteins automatisch auf "Gold" eingestellt wirdNeuron empfiehlt, die Eigenschaft safeStyle nur dann zu verwenden, wenn ein Baustein sichere Signale bei der Entwicklung von sicherheitsrelevanter Anwendungen verfolgt und der Baustein im Smart-Styling mit dieser goldenen Hintergrundfarbe dargestellt werden soll. Die Eigenschaft safeStyle darf nicht für andere Bausteine missbraucht werden, da die Farbe "Gelb" für die Verfolgung von sicheren Signalen bei der Entwicklung von sicherheitsrelevanten Anwendungen verwendet wird. Die Fehlgebrauch der Eigenschaft safeStyle könnte zur Folge haben, dass die Farbe "Gold" auch eine nicht-sichere Logik kennzeichnet. |
|
bestimmt, dass der Vendor-Baustein ein erweiterbarer Baustein ist, d.h. er kann um zusätzliche Ein-/Ausgänge erweitert werden (falls der Baustein vergrößert wird) |
|
bestimmt die Seitengröße, falls die FBS-Logik im grafischen FBS-Editor angezeigt wird. |
|
bestimmt das Layout des Instanznamens für eine Funktionsbaustein-Instanz
|
|
fügt Wertfelder für Eingänge innerhalb der Schnittstelle hinzu und bestimmt das Layout dieser Wertfelder
|
|
fügt Kommentarfelder innerhalb der Schnittstelle hinzu und bestimmt das Layout dieser Kommentarfelder
|
Beispiele mit Schnittstellen-Anweisungen
Die Schnittstelle der folgenden Beispiele... |
sieht so aus: |
||||||||
---|---|---|---|---|---|---|---|---|---|
|
Beachten Sie die Warnsymbole aufgrund von |
||||||||
|
Beachten Sie die Warnsymbole aufgrund der deklarierten Ein-/Ausgänge (= VAR_IN_OUT). |
Anweisung 'ImplementationProperties' und dessen Definitionen
Die Anweisung { ImplementationProperties ( ) }
ist ein Behälter für Definitionen zum Steuern der Codegenerierung für die Vendor-Bausteine – sowohl innerhalb der Anwendung, in der der Vendor-Baustein erstellt wird, als auch innerhalb einer Bibliothek, in die der Vendor-Baustein integriert wird.
Syntax |
---|
|
Definition |
Zweck |
---|---|
Definitionen, die sich auf die Struktur von Dateien auswirken |
|
|
bestimmt zusätzliche Objekte und/oder zusätzliche Bibliotheken, die integriert werden müssen, wenn die Anwendung für das Zielsystem erstellt wird Beachten Sie: Falls die Bibliothek mit dem Vendor-Baustein generiert wird, können Sie in der Bibliothekskonfiguration die folgenden Anweisungen angeben (siehe "Beispiel für die Bibliothekskonfiguration" unten):
Weitere Informationen finden Sie in einem der nachfolgenden Beispiele. |
|
bestimmt eine oder mehrere zusätzlich benötigte H-Files Standardmäßig müssen sich die zusätzlichen Dateien im Unterordner |
|
bestimmt, dass neben der H-Datei auch eine C-Datei verwendet werden soll |
|
bestimmt, dass ein anderer Bausteinnamen als Bestandteil des Dateinamens verwendet wird – sowohl für die H-Datei als auch für die C-Datei (falls die Definition |
Definitionen, die sich auf den Inhalt der H-Datei auswirken |
|
|
Diese Definition ist für die korrekte Codegenerierung eines erweiterbaren Bausteins notwendig (siehe Schnittstellen-Definition Bei Vendor-Bausteinen reicht es aus, nur die Definition |
|
bestimmt, dass das Argument |
|
mappt den Vendor-Baustein – Auswirkung: Eine Liste der konkreten Datentypen wird auf der Grundlage der angegebenen Werte erstellt. Für jeden dieser konkreten Datentypen muss
Erlaubte Werte für beide Definitionen (als kommagetrennte Liste):
|
|
bestimmt, dass der konkrete Datentyp nicht dem Namen der |
Definitionen, die sich auf die Validierung auswirken, falls der Vendor-Baustein aufgerufen wird |
|
|
bestimmt, welche Datentypen unterstützt werden, falls die Eingänge/Ausgänge des Vendor-Baustein-Aufrufs beschaltet sind
Erlaubte Werte für beide Definitionen (als kommagetrennte Liste):
Kontaktieren Sie Neuron, falls Ihr Vendor-Baustein oder die elementaren Datentypen |
|
legt fest, dass im Falle eines Funktionsaufrufs der Ergebniswert einer konkreten Variablen zugewiesen werden muss |
|
legt fest, dass ein Fehler gemeldet wird, wenn der Ausgang des Vendor-Bausteins (oder des Ergebniswertes im Fall einer Vendor-Funktion) mit dem Baustein-Eingang eines allgemeinen Datentyps (z.B. dem Eingang eines TO_INT -Bausteins) verbunden istDiese Definition ist für Bausteine mit Ausgängen oder Ergebniswerten allgemeiner Datentypen und für alle Baustein-Eingänge eines expliziten Datentyps nützlich. Ohne dieser Anweisung könnte Neuron Power Engineer den Ausgang oder den Ergebniswert und den verbundenen Eingang des folgenden Bausteins mit dem niedrigsten gemeinsamen Datentyp des allgemeinen Datentyps typisieren, was kein vernünftiges Verhalten darstellen würde. Der PACK -Baustein ist ein Systembaustein, der diese Anweisung ab Version 3.25.0 verwendet. |
Was ist ein generischer Datentyp? Welches sind die geeigneten elementaren Datentypen? Siehe →allgemeiner Datentyp
Beispiele mit Implementierungseigenschaften
Die folgenden Beispiele verwenden hauptsächlich die Systembausteine von Neuron Power Engineer, um die Verwendung der obigen Definitionen zu veranschaulichen. Beachten Sie, dass die Systembausteine aus internen Gründen den Teil CustomNameSpace := Name
anstelle der empfohlenen Anweisungen NAMESPACE ... END_NAMESPACE
verwenden.
Falls Sie sich dafür interessieren, wie Neuron die Systembausteine implementiert hat und Sie sich die entsprechenden H- und C-Dateien im Detail ansehen wollen: Kontaktieren Sie Neuron, um die Quellen mit der entsprechenden Systembibliothek zu erhalten.
In der Regel handelt es sich bei den Quellen um ein Neuron Power Engineer-Projekt, das die Systembausteine und eine Bibliothekskonfiguration enthält.
Beispiele, die sich auf die Dateistruktur auswirken
Beispiel mit 'additionalLibraries' und 'additionalObjects'
Beispiel 1 für Schnittstelle |
---|
|
Die Erzeugung der Bibliothek MyLibWithVendorBlocks
(siehe nächstes Beispiel) erfordert die zusätzlichen Bibliotheksdateien additionalLibrary1
und additionalLibrary2
sowie die zusätzlichen Objektdateien additionalObject
und additionalObject2
.
Beachten Sie:
-
Der Speicherort dieser Dateien ist abhängig von den Anweisungen
COMMON_SOURCE
undSUPPORTED_PTKS
, die in der Bibliothekskonfiguration angegeben sind. Bei der folgenden Bibliothekskonfiguration werden die Dateien im Pfadproject/MoreFiles/src-code/WindowsX86
gesucht. Ohne die AnweisungCOMMON_SOURCE
werden die Dateien in dem Pfadproject/src-code/WindowsX86
gesucht. -
Die Erweiterung dieser Dateien hängt ebenfalls von der Anweisung
SUPPORTED_PTKS
ab. Bei der folgenden Bibliothekskonfiguration werden die DateienadditionalLibrary1.lib
undadditionalLibrary2.lib
,additionalObject.o
undadditionalObject2.o
durchsucht.
Beispiel für Bibliothekskonfiguration |
---|
|
Spezielles Verhalten:
-
Falls Sie in der Bibliothekskonfiguration die Plattform
BuiltInPlc
(anstelle vonWindowsX86
) definieren, hängt der Speicherort der Datei vom Betriebssystem ab, unter dem die Bibliothek verwendet wird. Für Windows ist der UnterordnerWindowsX86
(wie bereits oben angegeben), für Linux ist der UnterordnerLinuxX86
. -
Falls Sie den Vendor-Baustein direkt innerhalb des Projekts verwenden (in dem Sie den Vendor-Baustein erstellt haben), werden die zusätzlichen Dateien beginnend mit der Zielplattform gesucht. Das heißt, falls die Plattform
BuiltInPlc
in der Ressource für das Projekt angegeben ist, werden die zusätzlichen Dateien im Pfadproject/src-code/BuiltInPlc
gesucht.
Beispiel mit/ohne 'extraIncludes'
Beispiel für Schnittstelle |
---|
|
Die Codegenerierung benötigt die H-Datei lcfu_iec61131__GET_TYPE_FROM_VARNAME.h
, die C-Datei lcfu_iec61131__GET_TYPE_FROM_VARNAME.c
sowie die zusätzlichen H-Dateien RTSSNS.h
, RTSSNSUtil.h
.
Falls in der Bibliothekskonfiguration nichts anderes angegeben ist, sucht Neuron Power Engineer nach den zusätzlichen Dateien im Pfad project/src-code
.
Beispiel mit/ohne 'functionHasCFile'
Beispiel 1 für Schnittstelle |
---|
|
Die Codegenerierung benötigt die H-Datei lcfu_iec61131__FIND.h
als auch die C-Datei mit dem Namen lcfu_iec61131__FIND.c
.
Vergleichen Sie die folgende Kopie des Systembausteins, die leicht verändert wurde:
Beispiel 2 für Schnittstelle |
---|
|
Die Codegenerierung benötigt nur die H-Datei lcfu___copies.FIND_COPY.h
. Aufgrund der fehlenden Definition functionHasCFile
ist keine C-Datei erforderlich.
Beispiel mit/ohne 'implementationName'
Beispiel für Schnittstelle |
---|
|
Die Codegenerierung benötigt die H-Datei lcfu_iec61131__CONVERT.h
und die C-Datei lcfu_iec61131__CONVERT.c
– statt den H-Dateien lcfu_iec61131__TO_SINT.h
, lcfu_iec61131__TO_INT.h
und den C-Dateien lcfu_iec61131__TO_SINT.c
, lcfu_iec61131__TO_INT.c
.
Beachten Sie:
-
Falls das erste ST-Objekt mit der Funktion
TO_SINT
gespeichert wird, generiert Neuron Power Engineer automatisch die Dateienlcfu_iec61131__CONVERT.h
und die C-Dateilcfu_iec61131__CONVERT.c
mit den Implementierungs-Stubs fürTO_SINT
. -
Falls das zweite ST-Objekt, das die Funktion
TO_INT
enthält, später gespeichert wird, aktualisiert Neuron Power Engineer die Dateienlcfu_iec61131__CONVERT.h
und die C-Dateilcfu_iec61131__CONVERT.c
nicht, um die Implementierungsstubs fürTO_INT
darin aufzunehmen.
Falls Sie unterschiedliche Implementierungs-Stubs für TO_SINT
und TO_INT
benötigen, ist es am besten, die Definition implementationName
nicht zu verwenden. Verwenden Sie die Definition implementationName
nur, falls die gleiche Implementierung in der gleichen Datei benötigt wird.
Beispiele, die sich auf den Inhalt der H-Datei auswirken
Beispiel mit/ohne 'expandable'
Beispiel 1 für Schnittstelle |
---|
|
Code, der für die Codegenerierung erforderlich ist |
---|
|
Beispiel 2 für Schnittstelle |
---|
|
Code, der für die Codegenerierung erforderlich ist |
---|
|
Beispiel mit/ohne 'passConcreteTypeParameter'
Beispiel für Schnittstelle |
---|
|
Code, der für die Codegenerierung erforderlich ist |
---|
|
Beispiel mit 'untypedCFunctionNameWhitelist' und ohne 'untypedCFunctionNameBlacklist' und ohne beide
Beispiel 1 für Schnittstelle |
---|
|
Für SUB
ergibt sich die folgende Liste konkreter Datentypen:
Konkrete Datentypen wegen der "White-List" |
Konkrete Datentypen nach der "Black-List" |
---|---|
|
identisch, weil es keine "Black-List" gibt |
Die Codegenerierung setzt voraus, dass __ANY
(anstelle von __REAL
, __LREAL
, __USINT
usw.) innerhalb der Implementierung (z.B. in der H-Datei) verwendet wird.
Code, der für die Codegenerierung erforderlich ist |
---|
|
Vergleichen Sie den folgenden Systembaustein, der die "White-Liste" und "Black-List" verwendet:
Beispiel 2 für Schnittstelle |
---|
|
Für OR
ergibt sich die folgende Liste konkreter Datentypen:
Konkrete Datentypen wegen der "White-List" |
Konkrete Datentypen nach der "Black-List" |
---|---|
|
|
Die Codegenerierung setzt voraus, dass __ANY
(anstelle von __BYTE
, __WORD
, __DWORD
und __LWORD
) innerhalb der Implementierung (z.B. in der H-Datei) verwendet wird, aber nicht der konkrete Datentyp BOOL
.
Code, der für die Codegenerierung erforderlich ist (Auszug) |
---|
|
Beispiel mit 'useUntypedTypeStructure'
Beispiel 1 für Schnittstelle |
---|
|
Normalerweise würde der allgemeine Datentyp ANY_NUM
des 2. Eingangs erfordern, dass die konkreten Datentypen beim Namen der typedef
-Struktur hinzugefügt werden. Dies ist aufgrund der Implementierung selbst nicht notwendig. Daher wird useUntypedTypeStructure
in der Schnittstelle verwendet.
Code, der für die Codegenerierung erforderlich ist |
---|
|
Vergleichen Sie die folgende Kopie des Systembausteins, die leicht verändert wurde: MUL_TIME_Copy
wird ohne useUntypedTypeStructure
angegeben.
Beispiel 2 für Schnittstelle |
---|
|
Die Codegenerierung erfordert, dass die konkreten Datentypen beim Namen der typedef
hinzugefügt werden. Daher lauten die Namen für die Strukturen:
-
MUL_TIME_REAL
-
MUL_TIME_LREAL
-
MUL_TIME_USINT
-
MUL_TIME_UINT
-
MUL_TIME_UDINT
-
MUL_TIME_ULINT
-
MUL_TIME_SINT
-
MUL_TIME_INT
-
MUL_TIME_DINT
-
MUL_TIME_LINT
Code, der für die Codegenerierung erforderlich ist |
---|
|
Beispiele, die sich auf die Validierung beim Aufruf des Vendor-Bausteins auswirken
Beispiel mit 'allowedTypeWhitelist' und ohne 'allowedTypeBlacklist' und ohne beide
Beispiel 1 für Schnittstelle |
---|
|
Für SHL
ergibt sich die folgende Liste konkreter Datentypen:
Konkrete Datentypen wegen der "White-List" |
Konkrete Datentypen nach der "Black-List" |
---|---|
|
identisch, weil es keine "Black-List" gibt |
Diese konkreten Datentypen werden unterstützt, wenn der Eingang IN
eines SHL
-Bausteins angeschlossen ist.
Beispiel für Aufrufe dieser Funktion |
---|
|
Vergleichen Sie den folgenden Systembaustein, der die "White-Liste" und "Black-List" verwendet:
Beispiel 2 für Schnittstelle |
---|
|
Für LIMIT
ergibt sich die folgende Liste konkreter Datentypen:
Konkrete Datentypen wegen der "White-List" - aufgrund von |
Konkrete Datentypen nach der "Black-List" - aufgrund von |
---|---|
|
|
Diese konkreten Datentypen werden unterstützt, wenn der Eingang des LIMIT
-Bausteins angeschlossen ist. Dies gilt für alle 3 Eingänge MN
, IN
und MX
.
Beachten Sie: Neuron Power Engineer unterstützt einige der konkreten Datentypen (z.B. LTIME
) nicht. Andernfalls wären diese Datentypen aufgrund von ANY_ELEMENTARY
enthalten.
Beispiel für Aufrufe dieser Funktion |
---|
|
Beispiel mit/ohne 'returnValueMustBeAssigned'
Beispiel 1 für Schnittstelle |
---|
|
Vergleichen Sie die folgende Kopie des Systembausteins, die leicht verändert wurde:
Beispiel 2 für Schnittstelle |
---|
|
Beispiel für Aufrufe dieser Funktion |
---|
|
Beispiel mit 'anyOutputMustBeConcreteResolved'
Beispiel für Schnittstelle |
---|
VAR_INPUT
|
Beispiel für Aufrufe dieser Funktion |
---|
|
Funktionsreferenzen
Das Pragma { FunctionReferences }
muss in einem Vendor-Baustein verwendet werden, wenn Funktionen einer Bibliothek im C-Code des Vendor-Bausteins aufgerufen werden. Dieses Pragma wird benötigt, damit Neuron Power Engineer beim Erstellen der Anwendung, die den Vendor-Baustein verwendet, ausreichende Informationen über die aufgerufenen Funktionen erhält.
Im Vergleich:
-
Sie müssen dieses Pragma nicht einfügen, wenn im C-Code des Vendor-Bausteins nur Funktionsbausteine aufgerufen werden.
-
Sie müssen dieses Pragma bei ST-/FBS-/KOP-POE, die Funktionen aufrufen, nicht einfügen. Dieses Pragma wird von Neuron Power Engineer automatisch eingefügt, wenn Sie diese POE mit dem Wert
INTERFACE
oderDEPLOY
als Teil einer Bibliothek angeben.
Ergänzen Sie das Pragma { FunctionReferences }
durch die Namen der aufgerufenen Funktionen. Trennen Sie die Funktionsnamen durch das Zeichen ",
".
Beispiel für Funktionsreferenzen |
---|
|
Definitionen für Variablen
Es ist möglich, einige spezielle Definitionen für deklarierte Variablen einzuzufügen – zusätzlich zu den Anweisungen/Definitionen, die unterhalb von "Unterstützte ST-Syntax" angeführt sind.
Syntax |
---|
|
Definition für Variable |
Zweck |
---|---|
|
definiert, dass temporäre Werte nicht mit der entsprechenden Ein-/Ausgangsvariable (VAR_IN_OUT) verbunden werden dürfen. |
{ |
gibt die folgenden zusätzlichen Daten (= Datenelemente) für die Variable an:
Siehe "Beschreibung, Kommentar, JSON-String oder Typ für Variablen oder Datentypen angeben" für Details. |
Beispiele mit '{REQUIRES_NON_TEMP_VALUE}'
Beispiel für Schnittstelle des Vendor-Bausteins |
---|
|
Beispiel für den Aufruf des Vendor-Bausteins (in der Bibliothek integriert) |
---|
|
Zusätzliche Anweisungen, die nicht verwendet werden dürfen
Die folgenden Anweisungen sind nur als Referenz enthalten. Verwenden Sie diese Anweisungen nicht für Ihre manuell erstellten Schnittstellen.
Syntax |
---|
|
Anweisung |
Zweck |
---|---|
|
ignoriert den gesamten Inhalt des aktuellen ST-Objekts Siehe "Anweisung zum Ignorieren von ST-Objekten" für Details zu dieser Anweisung. |
|
Derzeit wird diese Anweisung nicht für die Verwendung innerhalb von Vendor-Bausteinen unterstützt. |
|
Derzeit wird diese Anweisung nicht für die Verwendung innerhalb von Vendor-Bausteinen unterstützt. Siehe "Anweisung zum Unterdrücken von Warnungen" für Details zu dieser Anweisung. |