Fehlersuche in SPS-Programmen: systematisch eingrenzen statt raten

1.Warum Trial-and-Error der teuerste Weg ist

Eine Anlage steht. Die Produktion wartet, das Telefon klingelt, und im TIA Portal starrt einen ein Programm an, das gestern noch lief. Der Reflex in dieser Lage ist fast immer derselbe: irgendwo hineinschauen, wo man den Fehler vermutet.

Genau das ist der teuerste Weg. Nicht, weil Vermutungen grundsätzlich falsch wären – sondern weil eine widerlegte Vermutung nichts hinterlässt. Man weiß danach nicht mehr als vorher und hat zwanzig Minuten verloren. Nach der fünften Vermutung ist eine Stunde weg, und der Druck ist gestiegen.

Systematisches Eingrenzen verhält sich umgekehrt: Jeder Schritt halbiert den Suchraum, unabhängig davon, ob die Annahme stimmte. Auch ein negatives Ergebnis ist ein Ergebnis.

2.Die Reihenfolge, die unter Zeitdruck trägt

Jede effiziente Fehlersuche folgt derselben Kette:

Symptom → Hardware oder Software? → betroffener Baustein → Signalpfad → Ursache

Der erste Schritt wird am häufigsten übersprungen – und kostet dann am meisten.

2.1.Schritt 1: Hardware ausschließen, bevor Sie in den Code sehen

Der Diagnosepuffer der CPU ist der erste Blick bei jeder Störung, nicht der letzte. Er protokolliert Baugruppenausfälle, Peripheriefehler, STOP-Ursachen und Zeitfehler mit Zeitstempel. Wenn dort ein Baugruppenausfall steht, ist die Suche im Programmcode reine Zeitverschwendung.

Ergänzend: Die LEDs an CPU und Peripherie sagen in Sekunden, was der Code in Minuten nicht verrät. Eine rote SF-LED an einer ET 200 beendet die Diskussion über Programmlogik.

2.2.Schritt 2: Den zuständigen Baustein finden

Formulieren Sie das Symptom so konkret wie möglich: nicht „die Anlage geht nicht", sondern „Förderband 3 läuft nach Startbefehl nicht an, Störmeldung kommt nach 5 Sekunden".

Aus dieser Formulierung folgt der Baustein fast von selbst – vorausgesetzt, das Programm ist sauber strukturiert. Ist jeder Anlagenteil in einem eigenen, sprechend benannten Funktionsbaustein gekapselt, wissen Sie sofort, wo Sie suchen. Ist alles in OB1 verdrahtet, beginnt hier der mühsame Teil.

2.3.Schritt 3: Den Signalpfad rückwärts verfolgen

Nehmen Sie den Ausgang, der nicht schaltet, und arbeiten Sie sich zu seinen Bedingungen zurück. Welche Verknüpfung verhindert das Setzen? Welche dieser Teilbedingungen ist falsch? Und warum?

Dieses Rückwärtsgehen ist der Kern der Methode. Es endet immer an einem von drei Punkten: einer Eingangsbedingung, die nicht kommt (Hardware oder vorgelagerte Logik), einer Verriegelung, die greift (meist beabsichtigt), oder einer Zuweisung, die von woanders überschrieben wird.

3.Die Werkzeuge im TIA Portal

3.1.Forcen: das Werkzeug, das man fast nie braucht

Forcen überschreibt physische Ein- und Ausgänge und bleibt aktiv, bis es explizit aufgehoben wird – auch über einen CPU-Neustart hinweg. An einer laufenden Anlage mit bewegten Achsen ist das ein Sicherheitsrisiko, kein Diagnosewerkzeug.

Zum reinen Beobachten genügt die Beobachtungstabelle. Wenn Sie tatsächlich einen Wert setzen müssen, tun Sie es gezielt, dokumentiert und mit einem Kollegen, der die Anlage im Blick hat – und heben Sie es auf, bevor Sie gehen. Ein vergessener Force ist eine Zeitbombe, die beim nächsten Anlauf hochgeht, wenn niemand mehr weiß, dass er gesetzt wurde.

4.Fünf Fehlerklassen, die den Großteil ausmachen

4.1.1. Doppelzuweisungen

Dieselbe Variable wird in zwei Bausteinen geschrieben. Im zyklischen Ablauf „gewinnt" die zuletzt bearbeitete Zuweisung – der Ausgang flackert oder bleibt hartnäckig auf einem Wert, obwohl die sichtbare Logik etwas anderes sagt.

Erkennung: Querverweise. Jede Variable mit mehr als einer schreibenden Stelle ist verdächtig.

4.2.2. Flankenfehler

Eine Aktion feuert dauerhaft statt einmalig, oder gar nicht. Ursache ist meist eine fehlende steigende Flanke (R_TRIG) oder ein Flankenmerker, der an mehreren Stellen verwendet wird – dann verbraucht die erste Auswertung die Flanke, und die zweite sieht nie eine.

Erkennung: Beobachtungstabelle auf dem Flankenmerker plus Querverweise darauf.

4.3.3. Zeit- und Zyklusprobleme

Ein Timer, dessen Startbedingung im selben Zyklus zurückgesetzt wird, läuft nie ab. Umgekehrt lösen zu lange Zykluszeiten den Zeitfehler-OB (OB80) aus – sichtbar im Diagnosepuffer.

Erkennung: Zykluszeit in der CPU-Diagnose prüfen, Timer-Eingang in der Beobachtungstabelle mitlesen.

4.4.4. Datenbaustein-Verwechslung

Bei mehrfach instanziierten Funktionsbausteinen wird der falsche Instanz-DB übergeben. Die Logik stimmt, aber Antrieb 2 reagiert auf die Werte von Antrieb 1.

Erkennung: Aufrufstruktur ansehen – welcher Baustein bekommt welchen DB?

4.5.5. Hardware, die sich als Software tarnt

Ein wackelnder Initiator, ein Kabelbruch im Schleppketten-Bereich, eine Baugruppe mit sporadischem Ausfall. Das Symptom ist im Programm sichtbar, die Ursache nicht.

Erkennung: Sporadik ist das Warnsignal. Ein Fehler, der sich nicht reproduzieren lässt, liegt selten in der Logik – Logik ist deterministisch.

5.Wenn die Anlage steht: die Reihenfolge unter Druck

Wenn die Produktion wartet, hilft eine feste Reihenfolge mehr als Intuition:

1. Diagnosepuffer lesen. 30 Sekunden, klärt Hardware vs. Software.
2. Symptom präzise formulieren. Was genau passiert nicht, seit wann, unter welchen Bedingungen?
3. Letzte Änderung erfragen. „Lief gestern noch" ist die wichtigste Information überhaupt – der Online-/Offline-Vergleich zeigt, ob jemand etwas angefasst hat.
4. Beobachtungstabelle aufbauen für den verdächtigen Bereich, statt sich durch Netzwerke zu klicken.
5. Rückwärts vom Ausgang zu den Bedingungen.
6. Befund dokumentieren, bevor Sie die Anlage wieder freigeben – sonst wiederholt sich alles beim nächsten Mal.

Punkt 6 wird unter Druck fast immer weggelassen und ist der einzige, der verhindert, dass dieselbe Suche in drei Monaten von vorn beginnt.

6.Sauberer Code ist Diagnose-Infrastruktur

Die meisten Punkte oben setzen etwas voraus: eine klare Bausteinstruktur, sprechende Namen, kommentierte Symbolik. Das ist kein Selbstzweck und keine Ästhetikfrage.

Ein Programm, in dem jeder Anlagenteil gekapselt und benannt ist, verwandelt stundenlanges Rätselraten in ein gezieltes Eingrenzen von Minuten. Ein kommentierter Baustein sagt Ihnen schon beim Draufschauen, was er tun soll – und damit auch, wo er vom Soll abweicht. Ein Baustein voller M0.0 und DB1.DBX0.0 sagt gar nichts, und die Fehlersuche beginnt bei null.

7.Fazit

Fehlersuche ist Methode, nicht Talent. Drei Dinge tragen den größten Teil:

• Hardware zuerst ausschließen – der Diagnosepuffer beantwortet in 30 Sekunden, ob die Suche im Code überhaupt sinnvoll ist.
• Rückwärts vom Symptom statt vorwärts von der Vermutung – jeder Schritt verkleinert den Suchraum, auch wenn die Annahme falsch war.
• Reproduzierbar oder sporadisch? – diese Unterscheidung trennt Software- von Hardware- und Timing-Problemen, bevor Sie das erste Netzwerk öffnen.

8.Weiterführende Artikel

• SPS-Programmierung: 8 Best Practices für sauberen, wartbaren Code – die Struktur, die Fehlersuche erst effizient macht
• SPS-Dokumentation: Was hineingehört, was bei der Übergabe zählt – warum die Alarmliste im Störfall entscheidet
• Die 5 SPS-Programmiersprachen nach IEC 61131-3 – welche Sprache sich wie gut debuggen lässt