FC310x - PCI-Karten für PROFIBUS

Fehlerreaktionen

 

Ausfall eines Slaves

Wenn ein Slave nicht oder gestört antwortet, wiederholt der Master das Telegramm entsprechend des Max Retry-Limit (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Bus-Parameter) mehrere Male. Beim Empfang eines gestörten Telegramms wiederholt der Master sofort, im Timeout-Fall hat der Master die Slot-Time (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Bus-Parameter) auf eine Antwort des Slaves gewartet. Bei 12 Mbit/s, einer Slot-Time von 1000 Bit-Zeiten und einem Max Retry-Limit von 4 (Defaultwerte) bei einem Data_Exchange-Telegramm verzögert sich das Senden des folgenden Telegramms um den Wert

TDelay = (4 x ((15 + Anzahl Outputs) x 11 + 1000) - (15 + Anzahl Inputs) x 11)/12 µs

Der DpState des Slaves wird auf 0x02 (Timeout) bzw. 0x0B (gestörtes Telegramm) gesetzt. Die Auswirkung auf die DP-Verbindung kann eingestellt werden (s.u.).

Normaler DP-Zyklus (12 Mbit/s, 5 Slaves, im Schnitt 20 Bytes I, 20 Bytes O je Slaves)

 
Normaler DP-Zyklus

erstmalig gestörter DP-Zyklus (Slave 3 antwortet nicht)

 
Erstmalig gestörter DP-Zyklus

folgende DP-Zyklen (Slave 3 nicht mehr in der Poll-Liste)

 
Folgende DP-Zyklen

Weiterhin kann es noch passieren, dass der Slave falsch antwortet (z. B. weil aufgrund eines lokalen Ereignisses auf dem Slave die DP-Verbindung abgebaut wurde). In diesem Fall wird das Telegramm nicht wiederholt, sondern mit dem Senden des folgenden Telegramms fortgefahren. Der DpState wird auf einen Wert ungleich 0 gesetzt, der Slave wird aus der Poll-Liste ausgetragen und im nächsten DP-Zyklus nicht mehr angesprochen (d.h. der Sendezeitpunkt des nachfolgenden Telegramms verändert sich), bis die DP-Verbindung wieder erneut aufgebaut wurde.

 
 

Reaktionen im Master

Die Reaktion im Master kann je Slave eingestellt werden (s. Karteireiter Features des Slaves).

 
 

Auswirkung auf die DP-Verbindung (NoAnswer-Reaction), falls Slave nicht oder nicht ungestört antwortet

Hier wird festgelegt, ob der die DP-Verbindung zu dem Slave sofort oder erst nach Ablauf der DP-Watchdog-Zeit (s. Karteireiter PROFIBUS des Slaves) ohne korrektes Empfangstelegramm abgebaut werden soll.

1.
Wenn die DP-Verbindung sofort abgebaut werden soll (Leave Data-Exch, Default-Einstellung), wird der Slave aus der Poll-Liste ausgetragen und im nächsten DP-Zyklus nicht mehr angesprochen, bis die DP-Verbindung wieder erneut aufgebaut wurde. Um die DP-Verbindung zu dem Slave wieder aufzubauen werden mindestens 7 Telegramme gesendet, der Vorgang dauert in der Regel mindestens 10 bis 20 ms.
2.
Wenn die DP-Verbindung erst abgebaut werden soll, wenn innerhalb der DP-Watchdog-Zeit der Slave nicht oder ungestört geantwortet hat (Stay in Data-Exch (for WD-Time)), wird im nächsten Pollzyklus erneut versucht, den Slave anzusprechen, falls der Slave aber nicht antwortet, wird keine Wiederholung gesendet.

Die Einstellung "Stay in Data-Exch (for WD-Time))" (2.) macht dann Sinn, wenn der PROFIBUS-Zyklus auch beim Ausfall eines Slaves zeitlich möglichst konstant ablaufen soll und der Ausfall eines Slave für einen oder mehrere Zyklen toleriert werden kann (z. B. in der Betriebsart DP/MC (Equidistant)). In diesem Fall sollte die DP-Watchdog-Zeit des Slaves entsprechend der noch tolerierbaren Ausfall-Zeit des Slaves eingestellt und das Max Retry-Limit (DX) (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Bus-Parameter) auf 0 gesetzt werden.

Normaler DP-Zyklus (12 Mbit/s, 5 Slaves, im Schnitt 20 Bytes I, 20 Bytes O je Slaves) im Mode "Stay in Data-Exch (for WD-Time)"

 
Normaler DP-Zyklus bei Stay in Data-Exch (for WD-Time)

erster gestörter und folgende DP-Zyklen im Mode "Stay in Data-Exch (for WD-Time)" (Slave 3 antwortet nicht)

 
Erster gestörter und folgende DP-Zyklen bei Stay in Data-Exch (for WD-Time)
 
 

Auswirkung auf die Input-Daten des Slaves (Changes of the Input Data), falls Slave nicht richtig antwortet

Hier wird festgelegt, ob die Input-Daten des Slaves bei dessen Ausfall auf 0 gesetzt ("Inputs will be set to 0", Default-Einstellung) oder der alte Wert erhalten bleiben soll ("No changes"). In beiden Fällen wird auf jeden Fall der DpState des Slaves auf einen Wert ungleich 0 gesetzt, so dass die Task immer erkennen kann, ob die Daten gültig sind oder nicht. Wenn ein Slave gestört antwortet, werden die Inputdaten, unabhängig von der Einstellung Changes of the Input Data immer auf 0 gesetzt.

 
 

Einstellung des Wiederanlauf-Verhaltens des Slaves (Restart Behaviour of the Slave), falls die DP-Verbindung zu dem Slave abgebaut wurde

Hier wird festgelegt, ob die DP-Verbindung zu einem Slave, dessen DP-Verbindung abgebaut wurde, automatisch wieder aufgebaut wird, oder ob dieses manuell durch einen ADS-WriteControl-Aufruf (s. ADS-Interface) passieren soll.

 
 

Auswirkung auf den Zustand des Masters (Reaction of the Master), falls die DP-Verbindung zu dem Slave abgebaut wurde

Hier wird festgelegt, ob der Abbau der DP-Verbindung zu einem Slave ohne weitere Auswirkungen bleiben (No Reaction, Default-Einstellung) oder ob der Master den STOP-Zustand einnehmen und damit die DP-Verbindungen zu allen Slaves abbauen soll.

 
 

Auswirkung auf den Zustand des Masters (Clear Mode), falls die DP-Verbindung zu dem Slave abgebaut wurde

Mit dem Clear Mode (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Fault-Settings) kann eingestellt werden, dass der Master in den Zustand "Clear" wechselt bzw. bleibt, solange mindestens ein MC-Slave (Einstellung "Only MC-Slaves") bzw. irgendein Slave (Einstellung "All Slaves") nicht korrekt antwortet (einen DpState ungleich 0 hat).

Die Einstellung Reaction of the Master (s. Karteireiter Features des Slaves), die im vorangegangenen Kapitel beschrieben wurde, hat gegenüber dem Auto-Clear Mode Vorrang, d.h. wenn ein entsprechend eingestellter Slave ausfällt, geht der Master in den Zustand STOP.

 

Ausfall des Masters

 

Überwachung in der SPS/IO-Task

Bei dauerhaften Busstörungen kann sich der DP-Zyklus auch bei 12 Mbit/s auf bis zu 100 ms verlängern. Um den DP-Master zu überwachen, gibt es eine Status-Variable CycleCounter, die in der SPS verknüpft werden kann (s. KapitelMaster-Diagnose). Diese Variable wird vom Master nach jedem DP-Zyklus inkrementiert, durch Überwachen dieser Variable in der SPS kann also ein Ausfall des Masters festgestellt werden.

 
 

Überwachung im Slave

Um den Ausfall des Masters bzw. die Übertragung auf dem PROFIBUS zu überwachen, kann beim Slave ein Watchdog (s. Karteireiter PROFIBUS der Box) aktiviert werden (Default-Einstellung: Watchdog aktiviert mit 200 ms). Der Watchdog muss mindestens zweimal so groß wie das Maximum aus Estimated Cycle Time und Cycle Time (s. Karteireiter "FC310x" (für TwinCAT 2.8 bzw. TwinCAT 2.9) des Masters) eingestellt werden.

 
 

Ausfall der SPS/IO-Task

Es wird zwischen den Fällen SPS-Stop, Erreichen eines Breakpoints und Task-Stop (IO-Task, NC-Task wird nur beim System-Stop gestoppt) unterschieden. Beim SPS-Stopp werden die Ausgangsdaten von der SPS noch auf 0 gesetzt, beim Erreichen eines Breakpoints bleiben die Daten zunächst unverändert.

Im Master wird mit einer Überwachungszeit (TwinCAT 2.8: entsprechend der Einstellung Clear-Delay x Task-Zykluszeit auf dem Karteireiter PROFIBUS des Masters, TwinCAT 2.9: entsprechend der Einstellung Task-Watchdog x Task-Zykluszeit auf dem Dialog Fault-Settings) die Task überwacht. Wenn innerhalb dieser Überwachungszeit keine neue Datenübergabe erfolgt, geht der Master entsprechend der Einstellung Reaction on PLC-Stop bzw. Reaction on Task-Stop (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Fault-Settings) in den Zustand "Clear" (Ausgänge werden auf 0 bzw. in den sicheren Zustand (Fail_Safe = 1 in der GSD-Datei) gesetzt, Default-Einstellung) oder bleibt im Zustand "Operate" (Ausgänge behalten den letzten Wert). Die Einstellung "Operate" macht Sinn, wenn beim Erreichen eines Breakpoints in der SPS die Ausgänge nicht abfallen sollen, bei einem SPS-Stopp würden die Ausgänge trotzdem auf 0 gesetzt (durch die SPS), auch wenn der Master in "Operate" bleibt. Dabei ist allerdings zu beachten, dass die Ausgänge nur genullt werden, wenn der vorangegangene DP-Zyklus rechtzeitig fertig war (s. Kapitel Synchronisierung), es sollte daher nur während der Inbetriebnahmephase eingestellt werden.

 
 

Ausfall des Hosts

Um einen Absturz des Hosts (z. B. Blue Screen bei PC) zu überwachen, kann eine Watchdog-Time (TwinCAT 2.8: s. Karteireiter FC310x des Masters, TwinCAT 2.9: s. Dialog Fault-Settings) eingestellt werden. Wenn diese Watchdog-Time abläuft, geht der Master in den Zustand OFFLINE, d.h. die DP-Verbindungen zu allen Slaves werden abgebaut und der Master meldet sich vom PROFIBUS ab, d.h. er führt keine Buszugriffe mehr durch.

 
 

Start-Up Verhalten

Beim Start des TwinCAT Systems werden die DP-Verbindungen zu allen Slaves aufgebaut. Solange die höchstpriore zugehörige Task noch nicht gestartet wurde, sendet der Master auch nach dem Aufbau der DP-Verbindung noch keine Data_Exchange-Telegramme sondern Diagnose-Telegramme. Sobald die höchstpriore zugehörige Task einmal Daten übergeben hat und die DP-Verbindung des entsprechenden DP-Slaves aufgebaut ist, sendet der Master zyklisch (mit der höchstprioren zugeordneten Task) je ein Data_Exchange-Telegramm zu den entsprechenden Slaves.

Darüber hinaus kann über die Einstellungen Operate-Delay und Clear Mode (TwinCAT 2.8: s. Karteireiter PROFIBUS des Masters, TwinCAT 2.9: s. Dialog Fault-Settings) festgelegt werden, wann der Master vom "Clear"-Zustand (Ausgänge werden auf 0 bzw. in den sicheren Zustand (Fail_Safe = 1 in der GSD-Datei) gesetzt) in den "Operate"-Zustand (Ausgänge entsprechen den von der Task übergebenen Ausgängen) wechselt. Das Operate-Delay gibt an, wie lange der Master nach dem erstmaligen Übergeben der Daten mindestens noch im Zustand "Clear" bleiben soll. Mit dem Clear Mode wird, wie weiter oben beschrieben, eingestellt, ob der Master beim Ausfall eines allgemeinen bzw. eines MC-Slaves in den Zustand "Clear" wechselt bzw. bleibt.

 
 

Shut-Down Verhalten

Beim Stopp des TwinCAT Systems wird genauso reagiert, wie weiter oben im Kapitel "Ausfall des Hosts" beschrieben, die DP-Verbindungen aller Slaves werden abgebaut und der Master meldet sich vom Bus ab.