Feldbusse - Allgemeiner Teil
Begriffsdefinitionen
Ausgangstelegramm ist das protokollspezifische Telegramm (Safety-PDO) von der Sicherheitssteuerung in das sichere Feldgerät. Dieses Telegramm beinhaltet die Ausgangsdaten an das sichere Feldgerät. | |
Eingangstelegramm ist das protokollspezifische Telegramm (Safety-PDO) vom sicheren Feldgerät in die Sicherheitssteuerung. Dieses Telegramm beinhaltet die Eingangsdaten vom sicheren Feldgerät. | |
Treiberinstanz: für jedes konfigurierte logische E/A wird implizit Code für eine Treiberinstanz des unterstützten Protokolltyps (z. B. für ein FSoE-Feldgerät eine Treiberinstanz vom Typ |
Interface-Beschreibung
Die Sicherheitssteuerung überwacht die Übertragung der E/A-Daten vom, bzw. zum sicheren Feldgerät. Für jedes sichere Feldgerät wird ein logisches E/A vom Programmiersystem erzeugt. Pro logisches Gerät wird automatisch eine Treiberinstanz angelegt.
Mit dem Anlegen der Treiberinstanz wird impliziter Code generiert, der für Ein- bzw. Ausgangsvariablen folgendes bewirkt:
Phase 1 (Eingangsphase): Bearbeitung der Eingangstelegramme (implizit)
Die Treiberinstanz empfängt das Eingangstelegramm und überprüft dies gemäß dessen Protokollspezifikation, z. B. PROFIsafe
Die Eingangsdaten oder im Fehlerfall die Ersatzwerte werden in die gemappten Eingangsvariablen der Applikation kopiert.
Phase 2: Bearbeitung der Anwenderapplikation
Die Ausgangsdaten werden in Abhängigkeit der Eingangsdaten und des Zustands der Applikation generiert.
Phase 3 (Ausgangsphase): Bearbeitung der Ausgangstelegramme (implizit)
Die gemappten Ausgangsdaten der Applikation werden der Treiberinstanz übergeben. Die Treiberinstanz generiert das Ausgangstelegramm gemäß dessen Protokollspezifikation und schickt dieses an das sichere Feldgerät.
Default-Verhalten des Treibers
Hinweis Drv_1 (Start der Applikation)
Mit Start der Applikation kann es ab dem ersten Zyklus zum Austausch von Prozessdaten zwischen Feld und Applikation kommen. Durch die Verwendung von Funktionsbausteinen mit Anlaufsperre (S_StartReset = FALSE) oder ansonsten durch die Implementierung anderer System- und Applikationsmaßnahmen (siehe Safety-Anwenderhandbuch: "Regeln zur Verwendung PLCopen-konformer Funktionsbausteine") ist sicherzustellen, dass es beim Start der Applikation nicht zu einem unerwarteten (oder unbeabsichtigten) Starten der Maschine kommt.
Hinweis Drv_2 (Kommunikationsfehler am Start)
Die üblichen Kommunikationsfehler am Start verhindern per Default nicht den automatischen Beginn der Prozessdatenkommunikation, sondern verzögern ihn nur. Siehe Eingang für automatische Quittierung von Anlauffehler (auto-Quitt-Anlauffehler).
Das Default-Verhalten des Treibers für das Anlaufen nach einem Reset bzw. für das Wiederanlaufen nach einem Kommunikationsfehler wird von dem Initialwert des jeweiligen Eingangs definiert. Um das Default-Verhalten zu überschreiben, muss der Baustein in der Applikation aufgerufen werden und der entsprechende Eingang entsprechend belegt werden:
Der automatische Beginn der Prozessdatenübertragung nach dem Start wird programmatisch verhindert, indem der Baustein in der Applikation aufgerufen und der Eingang auto-Quitt-Anlauffehler auf FALSE gesetzt wird (siehe Eingang für automatische Quittierung von Anlauffehler).
Die automatische Wiederaufnahme der Prozessdatenübertragung wird programmatisch freigegeben, indem der Baustein in der Applikation aufgerufen und der Eingang auto-Quitt-Unterbrechung auf TRUE gesetzt werden (siehe Eingang für automatische Quittierung nach Unterbrechung).
Eingang für automatische Quittierung von Anlauffehler
Name | Datentyp | Initialwert | Beschreibung, Parameterwerte |
|---|---|---|---|
‹auto-Quitt-Anlauffehler› |
|
| Anlaufverhalten nach einem Reset (Befehle: Reset kalt - Safety und Neu starten) der Applikation, z. B. PowerON.
|
Wichtig
Beachten Sie Hinweis Drv_2 (Kommunikationsfehler am Start): Der Initialwert für den Eingang für das Anlaufverhalten nach einem Reset ist TRUE. Es werden sämtliche Fehler für das Anlaufverhalten nach einem Reset bestätigt.
Folglich setzt die Prozessdatenkommunikation ein, sobald der initiale Kommunikationsfehler verschwunden ist.
Wichtig
Beachten Sie Hinweis Drv_1 (Start der Applikation): Mit Setzen von auto-Quitt-Anlauffehler auf FALSE kann man das automatische Anlaufen der Prozessdatenkommunikation nicht unterbinden. Treten beim Anlauf keine Fehler auf, so kann der Stack automatisch anlaufen, selbst wenn auto-Quitt-Anlauffehler auf FALSE ist. Dies muss der Anwender in der Applikation berücksichtigen.
Eingang für automatische Quittierung nach Unterbrechung
Name | Datentyp | Initialwert | Beschreibung, Parameterwerte |
|---|---|---|---|
‹auto-Quitt-Unterbrechung› |
|
|
|
Hinweis Drv_3 (Eingang für automatische Quittierung nach Unterbrechung)
Achtung
Sind <auto-Quitt-Anlauffehler> und >auto-Quitt-Unterbrechung> TRUE, so werden sämtliche Fehler bestätigt. Dies ist nur in absoluten Ausnahmefällen sinnvoll.
Wiederanlaufverhalten nach einem Kommunikationsfehler
Der Initialwert für den Eingang für das Wiederanlaufverhalten nach einem Kommunikationsfehler ist FALSE, es wird der Fehler bzgl. Kommunikationsübertragung nicht automatisch bestätigt.
Es ist ein expliziter Aufruf der Baustein-Instanz mit entsprechender Beschaltung der Eingänge erforderlich.
Eingang zur Quittierungsflanke (manuelle Quittierung)
Fehler können mit einer positiven Flanke am Eingang zur Quittierung bestätigt werden, sofern der Ausgang für die Quittierungsanforderung (Ausgang zur Quittierungsanforderung) gesetzt ist.
Wenn sämtliche Fehler automatisch bestätigt werden (was nur in Ausnahmefällen sinnvoll ist), dann wird dieser Eingang nicht benötigt und kann unbelegt bleiben.
Wenn aktuell keine Quittierung angefordert wird, wird der Eingang ignoriert: Deshalb kann das gleiche Signal mit dem Eingang zur Quittierungsflanke aller Treiberinstanzen verbunden werden, um eine unspezifische Bestätigung von Kommunikationsproblemen zu realisieren.
Name | Datentyp | Initialwert | Beschreibung, Parameterwerte |
|---|---|---|---|
‹Quitt-Flanke› |
|
| Mit einer steigenden Flanke des Eingangs wird die Wiederaufnahme der Sicherheitsfunktion nach einem Fehler bestätigt. |
Hinweis Drv_4 (Quitt-Flanke)
Achtung
<Quitt-Flanke> ist ein Eingang zur Bestätigung durch den Anwender. Er soll nicht programmatisch gesetzt, sondern mit einem Eingangssignal verbunden werden.
Tipp
Der Eingang <Quitt-Flanke> benötigt eine steigende Flanke. Er sollte, nachdem der Anwender die Bestätigung gestoppt hat, wieder auf FALSE gehen, um die Quittierung abzuschließen. Erst dann wird beim nächsten Kommunikationsfehler am Ausgang <Quitt-Anf> die nächste Quittierung angefordert.
Ausgang zur Quittierungsanforderung
Der Ausgang steht auf TRUE, wenn ein Kommunikationsfehler aufgetreten ist (Anlauffehler oder Unterbrechung) und dieser nur manuell bestätigt werden muss, um die Kommunikation wieder aufzunehmen.
Ob die Verbindung eine Bestätigung durch den Anwender benötigt, wird durch den Ausgang <Quitt-Anf> = TRUE angezeigt. Normalerweise wird es dem Anwender gemeldet, dass seine Bestätigung gebraucht wird (zum Beispiel mithilfe einer Austauschvariablen zur Standardsteuerung und Anzeige in der Visualisierung)
Wenn der Ausgang gesetzt ist, kann der Fehler am Eingang zur Quittierung bestätigt werden.
Name | Datentyp | Initialwert | Beschreibung, Parameterwerte |
|---|---|---|---|
‹Quitt-Anf> |
|
|
Tipp
Die Anzeige am Ausgang Quitt-Anf kann nur erfolgen:
wenn der Kommunikationsfehler nicht automatisch quittiert wird, d. h. wenn <auto-Quitt-Anlauffehler> bzw. <auto-Quitt-Unterbrechung>
FALSEist.wenn der Eingang <Quitt-Flanke> momentan
FALSEist, d. h. wenn eine manuelle Quittierung begonnen, aber noch nicht abgeschlossen wurde.
Falls also ein neues Kommunikationsproblem auftritt, während der Anwender ein vorher aufgetretenes Problem noch bestätigt, so wird das neue Kommunikationsproblem erst angezeigt und bearbeitet, nachdem der Anwender die Bestätigung des vorherigen Problems beendet hat.
Explizites Aufrufen des Bausteins
Wird der Baustein vom Anwender in der Applikation explizit aufgerufen (Phase 2), dann können die Funktionsbaustein-Eingänge gesetzt und die Funktionsbaustein-Ausgänge gelesen werden, wobei der Funktionsbaustein selbst keine Operationen ausführt. Zu jeder Treiberinstanz kann es in der Applikation höchstens einen Aufruf geben.
Die Funktionsbaustein-Ausgänge der Treiberinstanz können unabhängig von einem Aufruf ausgelesen werden.