SPS-Diagnose und Online-Funktionen

Beim Arbeiten mit einer SPS gibt es zwei grundlegend verschiedene Situationen. Im Offline-Betrieb sitzt man am Programmiergerät — meist ein Laptop mit der Programmiersoftware — und bearbeitet das Projekt, ohne dass eine Verbindung zur Steuerung besteht. Man schreibt Code, ändert Netzwerke, legt Variablen an. Die SPS bekommt davon nichts mit; das Projekt liegt nur auf dem PC.

Im Online-Betrieb besteht eine aktive Verbindung zwischen Programmiergerät und laufender Steuerung. Jetzt sieht man nicht mehr nur den gespeicherten Programmtext, sondern das, was die CPU in diesem Moment tatsächlich tut. Diese Verbindung nennt man Online-Verbindung, und sie ist die Grundlage für so gut wie jede Diagnose.

Sobald man online geht, vergleicht die Software automatisch zwei Dinge: das Projekt auf dem PC und das Programm in der CPU. Stimmen beide überein, ist alles konsistent. Weichen sie ab — etwa weil jemand das Programm auf dem PC geändert, aber nicht in die CPU geladen hat — wird das angezeigt. Dieser Konsistenzvergleich ist wichtiger, als er klingt: Wer eine Störung an einem Programmstand sucht, der gar nicht in der Anlage läuft, sucht am falschen Ort.

Was man online sieht, hängt davon ab, in welchem Betriebszustand sich die CPU befindet und welche Signale gerade anliegen. Genau das schauen wir uns in den nächsten Kapiteln Schritt für Schritt an — beginnend mit dem, was man ganz ohne Laptop schon vor der Anlage erkennt.

Wer zu einer gestörten Anlage gerufen wird, braucht für den ersten Eindruck noch keinen Laptop. Die SPS und ihre Module zeigen über Leuchtdioden bereits eine Menge an. Diese Status-LEDs sind die schnellste Form der Diagnose — ein Blick in den Schaltschrank, und man weiß oft schon, in welche Richtung es geht.

An der CPU selbst finden sich meist mehrere Anzeigen. Eine LED signalisiert den Betriebszustand (läuft das Programm oder steht es?). Eine Sammelfehler-Anzeige — je nach Hersteller mit ERROR oder SF (Sammelfehler) beschriftet — leuchtet auf, sobald irgendwo ein Fehler ansteht, ohne ihn schon genau zu benennen. Eine Wartungsanzeige (oft MAINT) weist auf einen Zustand hin, der zwar noch kein Ausfall ist, aber Aufmerksamkeit verlangt.

Die folgende Übersicht zeigt typische LED-Bedeutungen. Beschriftungen und Farben unterscheiden sich je nach Fabrikat, das Prinzip ist aber überall gleich:

Besonders aufschlussreich sind die Kanalstatus-LEDs an den Ein- und Ausgabebaugruppen. Jeder Kanal hat in der Regel eine eigene LED, die anzeigt, ob das Signal logisch „1″ ist. Bei einem Eingang heißt das: Sensor oder Schalter liefert ein Signal. Bei einem Ausgang: Die SPS hat den Ausgang gesetzt. Damit lässt sich eine Wirkungskette prüfen, ohne ein einziges Mal zu messen — leuchtet die Eingangs-LED, wenn man den Sensor betätigt? Leuchtet die Ausgangs-LED, wenn das Programm schalten sollte?

Eine eigene Busfehler-LED zeigt Störungen in der Kommunikation an — etwa wenn ein dezentrales E/A-Modul nicht mehr erreichbar ist oder eine Leitung zum Feldbus unterbrochen wurde. Auch der Modul- oder Steckplatzstatus wird angezeigt: Fällt eine Baugruppe aus oder steckt sie nicht richtig, meldet das die Steuerung über eine entsprechende Anzeige.

Wie man eine solche Beobachtung anschließend systematisch weiterverfolgt — etwa mit Methodik und Signalverlauf im Stromlaufplan — gehört in den eigenen Beitrag zur Fehlersuche in Steuerungen. Hier geht es nur um die Werkzeuge, die die SPS selbst bietet.

Die Status-LEDs zeigen unter anderem an, in welchem Betriebszustand sich die CPU gerade befindet. Diese Zustände bestimmen, was die Steuerung tut — und was sie nicht tut. Drei sind grundlegend.

Im STOP bearbeitet die CPU kein Anwenderprogramm. Sie hält die Verbindung zur Programmiersoftware aufrecht und lässt sich laden oder diagnostizieren, aber die Ausgänge werden nicht vom Programm gesteuert — sie gehen in einen sicheren Zustand, üblicherweise abgeschaltet. Dieser Zustand wird gezielt zum Laden eines neuen Programms genutzt, oder die CPU geht von selbst in STOP, wenn ein schwerer Fehler auftritt.

Beim Übergang von STOP nach RUN durchläuft die CPU einmalig den ANLAUF (auch STARTUP genannt). Hier werden Anlaufroutinen abgearbeitet: Variablen bekommen ihre Startwerte, ein eventuell vorhandener Anlauf-Organisationsbaustein wird ausgeführt, die Peripherie wird initialisiert. Der Anlauf läuft genau einmal und geht dann in den zyklischen Betrieb über.

Im RUN arbeitet die CPU das Anwenderprogramm zyklisch ab — also der bekannte EVA-Ablauf: Eingänge lesen, Programm verarbeiten, Ausgänge schreiben, immer wieder. Das ist der Normalbetrieb, in dem die Anlage produziert.

STOP –(Anlauf anstoßen)–> ANLAUF –(einmalig durchlaufen)–> RUN
RUN –(Stopp-Befehl oder schwerer Fehler)–> STOP

Den Betriebszustand kann man auf zwei Wegen erkennen: über die LEDs an der CPU (siehe vorheriges Kapitel) und online im Programmiertool, das den aktuellen Zustand klar anzeigt. Online lässt sich die CPU auch gezielt umschalten — etwa von RUN nach STOP, bevor man ein geändertes Programm lädt. Geht eine CPU unerwartet in STOP, ist das fast immer das Zeichen eines schweren Fehlers, dessen Ursache man im Diagnosepuffer findet (Kapitel 5).

Die LEDs zeigen den groben Zustand. Will man genau wissen, welchen Wert eine bestimmte Variable trägt oder wie ein Signal durch die Logik läuft, braucht es die Online-Funktionen direkt im Programm.

Beim Beobachten liest man die aktuellen Signalzustände und Werte live im Programmcode mit. In der Kontaktplandarstellung wird etwa der Stromfluss eingefärbt — man sieht auf einen Blick, welche Kontakte geschlossen sind und wo der „Stromfluss“ durch das Netzwerk hängenbleibt. Bei Zahlenwerten, etwa einem Zähler- oder Analogwert, wird der aktuelle Wert direkt eingeblendet. Das Beobachten verändert nichts; es zeigt nur an.

Oft will man mehrere Variablen gleichzeitig im Auge behalten, die im Programm weit auseinanderliegen. Dafür gibt es die Beobachtungstabelle (auch Watch-Tabelle genannt). Man stellt sich darin die interessanten Variablen frei zusammen — Eingänge, Ausgänge, Merker, Bausteinparameter — und beobachtet ihre Werte gebündelt an einer Stelle. Für die Diagnose ist das das wohl meistgenutzte Werkzeug.

In derselben Tabelle lassen sich Werte auch vorgeben. Dabei sind zwei Funktionen streng zu unterscheiden:

Beim Steuern gibt man einer Variablen einen Wert vor. Dieser Wert wird aber vom laufenden Anwenderprogramm im nächsten Zyklus wieder überschrieben, sobald die Programmlogik die Variable neu berechnet. Steuern eignet sich also, um kurz einen Zustand anzustoßen oder einen Eingang testweise zu setzen, ohne die Logik dauerhaft auszuhebeln.

Beim Forcen (auch Zwingen) ist das anders. Ein geforcter Wert wird fest erzwungen — das Anwenderprogramm kann ihn nicht mehr überschreiben. Forcen wirkt direkt bis auf die Peripherieebene und hält den Wert, bis das Forcen aktiv wieder aufgehoben wird. Damit lässt sich ein Signal hart auf einen Zustand klemmen, unabhängig von Programm und tatsächlicher Verdrahtung.

Genau das macht das Forcen heikel. Es umgeht die Programmlogik — und damit potenziell auch Verriegelungen und Sicherheitsabfragen, die im Programm hinterlegt sind. Ein geforcter Ausgang schaltet, egal was die Sicherheitslogik eigentlich vorsieht.

Manche Fehler treten nur sporadisch auf oder liegen schon zurück, wenn man vor der Anlage steht. Hier hilft der Diagnosepuffer — ein chronologisches Ereignisprotokoll, das die CPU selbst führt.

Im Diagnosepuffer hält die Steuerung wichtige Ereignisse mit Zeitstempel fest: Übergänge zwischen RUN und STOP, erkannte Hardware- und Peripheriefehler, Programmfehler, Kommunikationsstörungen. Jeder Eintrag trägt einen Klartext und einen Zeitpunkt. Online ausgelesen, ergibt sich daraus eine Art Logbuch: Wann ist die CPU in STOP gegangen, und welches Ereignis ging unmittelbar voraus? Oft steht die Fehlerursache damit schon im Klartext da.

Der entscheidende Handgriff folgt erst danach. Aus einem Fehlereintrag heraus lässt sich in der Programmiersoftware direkt zur betroffenen Programmstelle springen — die Funktion heißt je nach System „Gehe zu Fehlerstelle“ oder „Baustein öffnen“. Damit landet man unmittelbar im fehlerhaften Netzwerk, im richtigen Baustein, an der richtigen Stelle. Ohne diese Verknüpfung bleibt der Diagnosepuffer eine bloße Textanzeige; mit ihr wird er zum Wegweiser direkt in den Code.

Was passiert nun bei einem Fehler im Programmablauf? Dafür gibt es Fehler-Organisationsbausteine (Fehler-OBs). Tritt ein bestimmter Fehler auf — etwa ein Zugriff auf eine nicht vorhandene Peripherieadresse oder ein Programmierfehler — und ist der passende Fehler-OB im Programm vorhanden, ruft die CPU diesen auf. Im Fehler-OB kann der Programmierer festlegen, wie reagiert wird: kontrolliert weiterlaufen, einen Ersatzwert setzen, eine Meldung absetzen.

Fehlt der passende Fehler-OB dagegen, reagiert die CPU mit der Standardreaktion — und die heißt bei schweren Fehlern: Übergang in den STOP. Die Anlage steht dann, was sicherheitstechnisch gewollt ist, aber den Betrieb unterbricht. Grob unterscheidet man dabei Programmfehler (Fehler in der Programmlogik, etwa unzulässige Adressierung) von Hardware- und Peripheriefehlern (ausgefallenes Modul, gestörte Kommunikation); für die verschiedenen Fehlerklassen gibt es jeweils eigene Reaktionsmechanismen, bis hin zum Diagnosealarm, mit dem ein Modul der CPU einen Fehler aktiv meldet.

Die Werkzeuge der SPS — Diagnosepuffer, Fehlerstelle anspringen, Fehler-OBs — zeigen, was und wo etwas schiefgeht. Wie man daraus eine systematische Suchstrategie aufbaut, etwa den Signalverlauf im Stromlaufplan verfolgt oder die Fehlersuche taktisch eingrenzt, ist Thema des eigenen Beitrags zur Fehlersuche in Steuerungen. Hier bleibt der Fokus auf den bordeigenen Diagnosefunktionen.

Eine SPS arbeitet ihr Programm zyklisch ab; die Dauer eines Durchlaufs ist die Zykluszeit. Im Normalbetrieb ist sie unauffällig — interessant wird sie bei der Diagnose von Performance-Problemen und scheinbar „hängenden“ Steuerungen. Online lässt sich die Zykluszeit direkt ablesen, meist als aktueller Wert sowie als minimale und maximale Zeit seit dem Anlauf.

Damit eine fehlerhafte oder zu lang gewordene Bearbeitung die Anlage nicht unkontrolliert blockiert, überwacht die CPU die Zykluszeit mit einem Watchdog — einer Zykluszeitüberwachung mit fest eingestellter Maximalzeit. Überschreitet ein Zyklus diese Grenze (etwa durch eine Endlosschleife oder eine sehr aufwendige Berechnung), löst der Watchdog aus und die CPU reagiert mit einer Fehlerreaktion, im Regelfall dem Übergang in STOP.

Wie viel Reserve zwischen tatsächlicher und maximal erlaubter Zykluszeit bleibt, sagt einiges über die Gesundheit des Programms aus:

Die prozentuale Auslastung der Überwachungszeit macht das anschaulich:

Liegt die Auslastung dauerhaft hoch, ist Vorsicht geboten: Schon eine zusätzliche Last kann den Watchdog auslösen. Neben der Zykluszeit lässt sich online auch die Speicherauslastung beobachten — wie viel Arbeits- und Ladespeicher das Programm belegt. Auch das gehört zur Beurteilung, ob eine Steuerung noch Reserven hat oder an ihre Grenzen kommt.