Zum Inhalt springen
AMA SYSTEMS

SPS-Störung systematisch eingrenzen

Geprüft von Alexandru Andronic (Siemens SITRAIN)·Stand:

Wenn die Anlage steht, entscheidet die Reihenfolge: erst den Zustand sichern, dann den Diagnosepuffer lesen, dann eingrenzen – Peripherie oder Programm. Diese Referenz fasst die Schritte für Siemens-Steuerungen (S7-300/400, S7-1200/1500) so zusammen, wie wir sie im Einsatz selbst abarbeiten.

Sofort-Checkliste: Was sagen die LED-Zustände?

Sicherheit zuerst

Alle Schritte in dieser Referenz sind lesend: LEDs ablesen, Diagnosepuffer sichern, beobachten. Arbeiten an elektrischen Anlagen und im Schaltschrank sind Elektrofachkräften vorbehalten; Eingriffe ins laufende Programm (Steuern, Forcen) nur mit Freigabe und Kenntnis der Anlage.

Die CPU-Front beantwortet die erste Frage – läuft die Steuerung überhaupt, und wenn nein, warum nicht? LED-Bezeichnungen und Blink-/Leuchtverhalten sind familien- und gerätespezifisch: Die Tabelle nennt die typische Zuordnung je CPU-Familie; verbindlich ist immer das Handbuch der konkreten CPU (Bestellnummer). Alles Weitere steht im Diagnosepuffer.

LED-Zustände von S7-CPUs nach CPU-Familie mit möglicher Bedeutung und nächstem Schritt
CPU-FamilieLED-BildMögliche BedeutungSinnvoller nächster Schritt
alle FamilienRUN leuchtet, keine Fehler-LEDCPU arbeitet – die Störung liegt eher in Peripherie, Antrieben oder im ProzessHMI-Meldungen und Diagnosepuffer prüfen, betroffene Station oder Achse identifizieren
alle FamilienSTOP leuchtetCPU gestoppt: Fehler ohne passende Fehlerbehandlung, Baugruppen- oder Netzausfall, manueller Stoppnicht sofort neu starten – erst den Diagnosepuffer lesen, sonst überschreiben Folgeereignisse die Spur
S7-300SF leuchtetSammelfehler: Diagnosealarm einer Baugruppe, Programmfehler, defektes ModulDiagnosepuffer: der Ereignistext nennt meist Baugruppe/Kanal oder Baustein
S7-400INTF bzw. EXTF leuchtetdie S7-400 trennt interne Fehler (Programm, CPU) und externe Fehler (Peripherie, Verdrahtung) auf zwei LEDsDiagnosepuffer auswerten; bei EXTF zusätzlich Peripherie und Feldverdrahtung in den Blick nehmen
alle FamilienBF/BUSF blinkt oder leuchtetFehler am Kommunikationsbus (Profibus/Profinet). Ob Blinken oder Dauerlicht z. B. fehlende Teilnehmer oder einen Fehler am eigenen Anschluss bedeutet, ist CPU-, schnittstellen- und betriebsartspezifischBedeutung im Gerätehandbuch nachschlagen, Online-Sicht in TIA Portal/STEP 7 prüfen; bei Busverdacht weiter mit der Profibus-Fehlerbilder-Referenz
S7-300DC5V dunkelinterne Stromversorgung der CPU fehlt oder Netzteil defektEinspeisung und Netzteil-LEDs kontrollieren – Prüfung der Versorgung ist Sache der Elektrofachkraft
alle Familienalle LEDs ausVersorgung der Station komplett wegEinspeisung, Sicherungen und Netzteil prüfen lassen (Elektrofachkraft)
S7-300/400FRCE leuchtet dauerhaft oder blinktDauerlicht: Force-Aufträge aktiv, Ein- oder Ausgänge sind fest überschrieben. Blinken kann je nach Produkt einen Teilnehmer-/Blinktest anzeigenvor jeder weiteren Fehlersuche klären, wer forciert hat und warum
S7-1200/1500ERROR (rot) / MAINT (gelb)ERROR blinkend: Fehler aufgetreten. Aussagekräftig ist die komplette LED-Kombination samt Gerätediagnose; MAINT kann bei der S7-1500 auch einen aktiven Force-Auftrag anzeigenLED-Muster im Gerätehandbuch nachschlagen; Diagnosepuffer über TIA Portal, CPU-Display (S7-1500) oder Webserver lesen

Wie lesen Sie den Diagnosepuffer im TIA Portal aus?

Der Diagnosepuffer ist die Ereignisliste der CPU – er überlebt Spannungsausfall und STOP. In fünf Schritten:

  1. PG/PC mit der CPU verbinden (Ethernet; bei Altanlagen MPI-/PROFIBUS-Adapter). Ohne Projekt geht es über „Online-Zugänge → Erreichbare Teilnehmer“.
  2. CPU markieren → „Online & Diagnose“ → „Diagnose → Diagnosepuffer“.
  3. Einträge stehen chronologisch, der neueste oben. Die letzten zeitlich zusammengehörenden Ereignisse vor dem STOP als Kette auswerten: Ereignis-ID, Zeitstempel und Kommend-/Gehend-Status führen zum ersten auslösenden Fehler – der direkte Vorgänger des STOP-Eintrags ist häufig, aber nicht zwingend die Primärursache.
  4. „Hilfe zum Ereignis“ liefert den Klartext samt betroffener Baugruppe, Adresse oder Baustein.
  5. Puffer sichern (als Text exportieren), bevor jemand neu startet oder lädt.

Ohne Laptop

Bei der S7-1500 zeigen das Front-Display und – falls aktiviert – der Webserver den Diagnosepuffer auch ohne TIA Portal. Bei S7-300/400-Altanlagen mit STEP 7 classic führt der Weg über „Zielsystem → Baugruppenzustand“.

CPU in STOP: Diagnosepuffer gezielt auswerten

Gerade wenn die CPU in den STOP-Zustand wechselt, verrät der Puffer nicht nur das Symptom, sondern oft den exakten Auslöser. Wichtig: die letzten zusammengehörenden Ereignisse vor dem STOP als Kette lesen – Folgefehler führen sonst in die Irre, und der unmittelbare Vorgänger des STOP-Eintrags ist nicht zwingend die Primärursache.

Typische Einträge im Diagnosepuffer, ihre Bedeutung und erste Maßnahmen
Typischer EreignistextBedeutungZulässige Erstmaßnahme
STOP durch Programmierfehler (OB nicht geladen oder nicht möglich) – S7-300/400: Event-ID W#16#4562Dieser Eintrag dokumentiert den STOP, weil der angeforderte Fehler-OB nicht geladen oder nicht ausführbar war. Der auslösende synchrone Fehler steht gewöhnlich davor im Puffer.Zuerst den auslösenden Fehler, die OB-Startinformation und die Programmstelle auswerten. Ein leerer Fehler-OB ist allenfalls in einem kontrollierten Diagnosefenster nach Risikobewertung vertretbar; vor der Freigabe müssen Ursache und Fehlerreaktion implementiert und getestet sein. CPU-Neustart nur nach sicherer Anlagenfreigabe.
Ausfall eines IO-Devices / Baugruppe gestörtEin Profinet-Device oder Profibus-Slave antwortet nicht – oder eine erreichbare Station meldet Baugruppen-/Kanaldiagnosen. Stationsausfall und „Baugruppe gestört" sind nicht dasselbe.Spannungsversorgung und Busverkabelung am betroffenen Teilnehmer prüfen; bei erreichbarer Station die Baugruppen-/Kanaldiagnose im Detail lesen.
Peripheriezugriffsfehler, lesend / schreibendDas Anwenderprogramm greift direkt (Peripheriezugriff) auf eine Adresse zu, die nicht vorhanden ist oder nicht quittiert – das betrifft nicht jeden Prozessabbild-Zugriff.Hardwarekonfiguration abgleichen. Als Folge eines Stationsausfalls tritt der Fehler nur auf, wenn das Programm weiterhin direkt auf die betroffene Peripherie zugreift.
Bereichslängenfehler beim Lesen / Schreiben – S7-300/400: Event-ID 16#2522 / 16#2523Programmfehler: Zugriff über die Grenze eines Speicherbereichs hinaus – betrifft neben Datenbausteinen auch Merker, Ein-/Ausgänge und weitere Bereiche (z. B. DB zu kurz, fehlerhafter Pointer).Letzte Code-Änderungen prüfen. Baustein und Fehlerstelle stehen im Detail des Diagnosepuffer-Ereignisses.

Was bedeuten die Fehler-OBs OB80 bis OB122?

Fehler-OBs fangen definierte Störungsklassen ab. Fehlt der passende OB im Programm, reagieren die CPU-Familien unterschiedlich – die Tabelle nennt das dokumentierte Default-Verhalten für S7-300/400 und S7-1500. Die S7-1200 weicht teils ab und ist hier bewusst nicht abgedeckt; maßgeblich ist das jeweilige Systemhandbuch. Taucht einer dieser OBs im Diagnosepuffer auf, liefert er die Marschrichtung für die Suche:

Fehler-OBs mit Auslöserklasse, Default-Verhalten ohne geladenen OB (je CPU-Familie) und Suchrichtung
OBAuslöserklasseOhne OB: S7-300/400 vs. S7-1500Wo Sie weiter suchen
OB82 – Diagnosealarmunterstützte und aktivierte Diagnosealarme – z. B. Drahtbruch, Kurzschluss, fehlende Geberversorgung, Übertemperatur, aber auch weitere gerätespezifische DiagnosenS7-300/400: STOP. S7-1500: bleibt in RUN.OB-Startinformation plus Geräte-/Baugruppen-/Kanaldiagnose auswerten – die Ursache liegt oft in Feldverdrahtung oder Sensor, nicht in der Baugruppe selbst
OB86 – Stations-/Trägerausfallein DP-Slave oder PN-Device fällt aus bzw. kehrt zurück, ein Erweiterungsrack ist gestört. Ein HMI-Verbindungsabriss löst keinen OB86 aus; ein Antrieb nur, wenn er als DP-Slave/PN-Device projektiert istS7-300/400: STOP. S7-1500: bleibt in RUN.fällt ein einzelner Teilnehmer oder ein ganzer Strang? Das Muster trennt Geräteproblem von Leitungs-/Busproblem
OB121 – Programmierfehlerdas Programm greift ins Leere: nicht (mehr) vorhandener DB, Bereichsüberschreitung bei indirekter Adressierung, ungültige BCD-ZahlS7-300/400: STOP. S7-1500: STOP.tritt oft nach Änderungen auf – wer hat zuletzt geladen? Baustein und Adresse stehen im Ereignistext
OB122 – Peripheriezugriffsfehlerein direkter Peripheriezugriff trifft eine Adresse, die nicht vorhanden ist oder nicht quittiert – nicht jeder Prozessabbild-ZugriffS7-300/400: STOP. S7-1500: bleibt in RUN.prüfen, ob die adressierte Baugruppe gesteckt, projektiert und erreichbar ist
OB80 – Zeitfehlerverschiedene Zeitfehler – u. a. Zykluszeitüberschreitung, aber auch weitere zeitbezogene Ereignisse; die konkrete Ursache steht in Fault_ID und EreignisdatenS7-300/400: STOP. S7-1500: abhängig vom konkreten Zeitfehler.Fault_ID und Ereignisdaten prüfen; Programmschleifen und die Häufung von Alarmen/Interrupts kontrollieren

Zusammenspiel von OB86 und OB122

Ein Stationsausfall (OB86) führt nur dann zusätzlich zu Peripheriezugriffsfehlern (OB122), wenn das Programm weiterhin direkt auf die ausgefallene Peripherie zugreift. Beheben Sie bei der Störungsanalyse zuerst die Ursache für den OB86.

Peripherie oder Programm – wie trennen Sie sauber?

  • Feld gegen Steuerung vergleichen: Zeigt die Beobachtungstabelle denselben Zustand wie die Sensor-LED vor Ort? Abweichung → Verdrahtung, Baugruppe oder Bus. Übereinstimmung → die Logik dahinter.
  • Querverweis nutzen: Welcher Baustein schreibt den Ausgang, welche Freigabe oder Verriegelung fehlt? Von dort rückwärts verfolgen.
  • Diagnosepuffer als Weiche: Kanaldiagnose und Stationsausfall deuten auf Peripherie, OB121 auf das Programm – meist auf die letzte Änderung.
  • Muster lesen: Sporadisch und quer über die Anlage → Versorgung, EMV oder Bus. Reproduzierbar an einer Stelle oder in einem Schrittzustand → Logik oder Prozess.
  • Steuern und Forcen sind keine Diagnosewerkzeuge erster Wahl: Sie verändern den Prozess real – nur mit Freigabe, Anlagenkenntnis und klarem Rückweg.

Wann ist externe Diagnose sinnvoll?

  • Der Diagnosepuffer ist leer oder widersprüchlich und die Störung bleibt sporadisch.
  • Busfehler betreffen wechselnde Teilnehmer – dann hilft Messen der Busphysik, nicht Teiletausch.
  • Es gibt keine aktuelle Doku und kein Quellprogramm mit Symbolik.
  • Die Störung besteht seit einem Umbau und die Wechselwirkung ist unklar.
  • Die Stillstandskosten pro Stunde übersteigen den Diagnoseaufwand deutlich.

In diesen Fällen sichern wir zuerst Diagnosepuffer und Istzustand und grenzen dann strukturiert ein – mit TIA Portal, STEP 7 und Busanalyzer. So bleibt die Beweislage erhalten, statt durch Neustarts überschrieben zu werden.

Grundlagen & Quellen