Implementierung von Funktionsbausteinen

1. Online-Change-Fähigkeit sicherstellen [++]
2. Einheitliche Schnittstelle bei einmaliger asynchroner Abarbeitung [+]
3. Einheitliche Schnittstelle bei kontinuierlicher asynchroner Abarbeitung [+]
4. Alle Parameter eines Funktionsbausteins intern verwenden [+]
5. Gruppierung von Parametern als Struktur [+]

Online-Change-Fähigkeit sicherstellen

Die Möglichkeit zum Online-Change ist ein wichtiges grundlegendes Feature von SPS-Anwendungen. Ein SPS-Programm kann mittels Online-Change auf verschiedene Arten verändert werden, ohne im zyklischen Ablauf gestoppt zu werden. Häufig wird Programmcode im Implementierungsteil verändert, wozu auch im Deklarationsteil einzelne Variablen ergänzt werden.

Implementieren Sie Funktionsbausteine so, dass Instanzen in ihrer Funktionsfähigkeit nicht beeinträchtigt werden, sollten diese in Folge eines Online-Change im Speicher verschoben werden.

Details finden Sie im Kapitel Ausführen eines Online-Change in der TwinCAT-3-PLC-Dokumentation

Einheitliche Schnittstelle bei einmaliger asynchroner Abarbeitung

Zusätzlich zu den Namenskonventionen für Variablen und der Reihenfolge der Textblöcke bei Variablendeklarationen erleichtert eine einheitliche Schnittstelle die Verwendung von Funktionsbausteinen.

Bei Funktionsbausteinen, deren Rumpfaufruf eine asynchrone und einmalige ADS-Abarbeitung übernimmt, sollten Sie folgende Schnittstelle verwenden. Sollte es sich nicht um eine ADS-Kommunikation handeln, wird der Parameter sNetId weggelassen.

Die Abarbeitung startet bei steigender Flanke des Eingangs bExecute. Dies ist nur möglich, wenn der Funktionsbaustein nicht bBusy ist. Eingangsparameter sollen vom Anwender während einer laufenden Abarbeitung nicht verändert werden. Dies stellt auch sicher, dass die Ergebnisse der Abarbeitung (Ausgänge) zu den angegebenen Parametern (Eingänge) passen.

Ist die Abarbeitung beendet, wird bBusy := FALSE gesetzt. Spätestens jetzt müssen Sie alle Ausgangsparameter setzen. Der Anwender hat so die Möglichkeit, auf bBusy = FALSE zu reagieren und daraufhin die Ausgänge auszuwerten.

FUNCTION_BLOCK FB_Sample
VAR_INPUT
    bExecute      : BOOL;
    ...           : ...;                         // optional inputs
    ...           : ...;                         // optional inputs
    tTimeout      : TIME := DEFAULT_ADS_TIMEOUT; // ADS communication timeout
    sNetId        : T_AmsNetId := '';            // keep empty '' for the local device
END_VAR
VAR_OUTPUT
    bBusy         : BOOL;
    bError        : BOOL;
    hrErrorCode   : HRESULT;
    ...           : ...;                         // optional outputs
    ...           : ...;                         // optional outputs
END_VAR

Einheitliche Schnittstelle bei kontinuierlicher asynchroner Abarbeitung

Zusätzlich zu den Namenskonventionen für Variablen und der Reihenfolge der Textblöcke bei Variablendeklarationen erleichtert eine einheitliche Schnittstelle die Verwendung von Funktionsbausteinen.

Bei Funktionsbausteinen, deren Rumpfaufruf eine asynchrone und kontinuierliche ADS-Abarbeitung übernimmt, verwenden Sie die folgende Schnittstelle. Sollte es sich nicht um eine ADS-Kommunikation handeln, wird der Parameter sNetId weggelassen.

Die Abarbeitung startet bei steigender Flanke von bEnable. Der Funktionsbaustein arbeitet so lange wie bEnable gesetzt ist. Ein Zurücksetzen von bEnable hat aufgrund der asynchronen Abarbeitung nicht zwangsweise die sofortige Beendigung jeglicher Abarbeitung zur Folge. Diese wird mittels bBusy = FALSE angezeigt. Während bEnable gesetzt ist, können geänderte Eingangsparameter verarbeitet werden.

Der Ausgang bValid zeigt die erfolgreiche Abarbeitung und die Gültigkeit optionaler Ausgangsparameter an.

Der Ausgang bError zeigt einen eingetretenen Fehler an. Nähere Information liefert der Fehlercode am Ausgang hrErrorCode. Weil bError bei kontinuierlicher Abarbeitung jederzeit gesetzt werden kann und oft nur einen Zyklus lang ansteht, soll der Anwender diesen Ausgang dauerhaft abfragen.

FUNCTION_BLOCK FB_Sample
VAR_INPUT
    bEnable       : BOOL;
    ...           : ...;                         // optional inputs
    ...           : ...;                         // optional inputs
    tTimeout      : TIME := DEFAULT_ADS_TIMEOUT; // ADS communication timeout
    sNetId        : T_AmsNetId := '';            // keep empty '' for the local device
END_VAR
VAR_OUTPUT
    bValid        : BOOL;
    bBusy         : BOOL;
    bError        : BOOL;
    hrErrorCode   : HRESULT;
    ...           : ...;                         // optional outputs
    ...           : ...;                         // optional outputs
END_VAR

Alle Parameter eines Funktionsbausteins intern verwenden

Alle Parameter eines Funktionsbausteins sollten auch intern verwendet werden.

Negatives Beispiel:

FUNCTION FB_Sample_neg 
VAR_INPUT 
    nA       : INT;          // Variable a in term y = a*a
    nB       : INT;          // NON COMPLIANT: nB will not be used 
END_VAR
VAR_OUTPUT
    nY       : INT;
END_VAR

nY := nA * nA;

Positives Beispiel:

FUNCTION FB_Sample_pos       // COMPLIANT: no unused parameter
VAR_INPUT 
    nA       : INT;          // Variable a in term y = a*a
END_VAR
VAR_OUTPUT
    nY       : INT;
END_VAR

nY := nA * nA;

Gruppierung von Parametern als Struktur

Müssen Sie viele Parameter beim Funktionsbaustein angeben, so bietet es sich an, diese in einer oder mehreren Strukturen zu gruppieren. So können beispielsweise Konfigurationsparameter optisch gut von Kontrollparametern separiert werden.