Menu
Allen‑Bradley‑Hauptfehlercodes: Wie man sie ausliest, löscht und verhindert

Allen‑Bradley‑Hauptfehlercodes: Wie man sie ausliest, löscht und verhindert

Allen-Bradley ControlLogix und CompactLogix: Hauptfehler erklärt — Fehlertypen und Fehlercodes, wie man das Fehlerprotokoll in Studio 5000 liest, Löschverfahren und Fehlerroutinen, die Produktionslinien am Laufen halten.
Allen‑Bradley‑Hauptfehlercodes: Wie man sie ausliest, löscht und verhindert

Wichtigste Erkenntnisse: Bei Allen‑Bradley‑Logix‑Controllern (ControlLogix, CompactLogix) stoppt ein Major‑Fault das Programm und setzt die OK/FAULT‑Anzeige des Controllers in einen Fehlerzustand. Jeder Major‑Fault hat einen Typ und einen Code (z. B. Typ 4 = Programmausfall, mit Codes für Fehler wie Array‑Index außerhalb des Bereichs). Die Registerkarte „Major Faults“ in den Controller‑Eigenschaften von Studio 5000 zeigt den Eintrag; wiederherstellbare Fehler können dort gelöscht oder automatisch von einer Fehlerroutine behandelt werden, sodass ein einzelner fehlerhafter Array‑Index nicht die gesamte Anlage anhalten muss.

Fehlertypen, denen Sie tatsächlich begegnen werden

  • Typ 1: Power‑Up‑Fehler, der Controller ist beim Hochfahren fehlertätig geworden (oft wird der Power‑Up‑Handler so konfiguriert, dass er absichtlich fehlerhaft meldet, damit der Prozess nicht unbeaufsichtigt neu startet).
  • Typ 3: I/O‑Fehler, eine benötigte I/O‑Verbindung ist ausgefallen, während der Fehler als Major konfiguriert war (ein fehlendes Modul, ein ausgefallener Netzwerkknoten).
  • Typ 4: Programm‑Ausführungsfehler, die häufigste Kategorie: Array‑Index außerhalb des Bereichs, arithmetischer Überlauf, JSR zu einer fehlenden Routine, ungültige Instruktionsdaten.
  • Typ 6: Watchdog, eine Task hat ihre Watchdog‑Zeit überschritten, typischerweise nach Hinzufügen umfangreicher Logik oder Schleifen in einer schnellen periodischen Task.
  • Typ 7: Nichtflüchtiger Speicherfehler, ein Schreib‑ oder Lesezugriff auf die Speicherkarte ist fehlgeschlagen.

Die genaue Liste steht in Rockwells Fehlercode‑Dokumentation; wichtig ist, das Paar (Typ, Code) zu lesen, anstatt „fehlerhaft“ als ein undifferenziertes Ereignis zu behandeln.

Fehler lesen und löschen

  • 1. Gehen Sie in Studio 5000 online und öffnen Sie Controller Properties → Major Faults. Notieren Sie Typ, Code und den Fehlermeldungstext, einschließlich welches Programm und welche Routine den Fehler verursacht haben.
  • 2. Beheben Sie die Ursache: korrigieren Sie die Logik (Indexgrenzen prüfen, Berechnungen absichern), stellen Sie die I/O‑Verbindung wieder her, und verlängern Sie die Watchdog‑Zeit nur, wenn die Task diese tatsächlich benötigt.
  • 3. Löschen Sie den Fehler auf der Registerkarte „Major Faults“ (oder schalten Sie nach verfahrensrelevanter Site‑Anweisung den Betriebsartenschalter) und bringen Sie den Controller gemäß den Neustart‑ und Sicherheitsregeln Ihrer Anlage wieder in Run.

Fehlerroutinen: behandeln, ohne die Anlage anzuhalten

Für wiederherstellbare Typ‑4‑Fehler erlaubt Logix jedem Programm eine Fehlerroutine: Tritt der Fehler auf, läuft die Routine, kann das Ereignis protokollieren und den Fehlerdatensatz löschen, und die Ausführung läuft weiter. Richtig eingesetzt verwandelt das einen zeilenstopenden Absturz in ein protokolliertes Ereignis mit Alarm. Falsch eingesetzt verschluckt es echte Probleme stillschweigend; protokollieren Sie daher IMMER, was abgefangen wurde (die Fehleraufzeichnungsdaten) an einer Stelle, die ein Mensch überprüft, und geben Sie bei Wiederholungen Alarm. Ein controllerweiter Fehlerbehandler erfüllt dieselbe Rolle für Controller‑weite Fehler.

Vom Fehlerprotokoll zu Zuverlässigkeitsdaten

Jeder Major‑Fault ist ein Ausfallereignis mit einer präzisen, maschinenlesbaren Ursache und damit hochwertiger Input für die Zuverlässigkeitsarbeit, sofern er das SPS‑System verlässt. Erfassen Sie Fehler mit ihrem Typ und Code in Ihren CMMS-Arbeitsaufträgen, werten Sie sie in der Ausfallanalyse aus und gestalten Sie Ihre Fehlercodes so, dass sie reale Ursachen benennen statt generischer Kategorien. Fabrico verbindet das auf der Halle: computervisions‑verifiziertes OEE erfasst den Stopp und dessen Dauer, auch wenn niemand ihn protokolliert, und das geschlossene CMMS verbindet den Fehler mit der Reparatur und liefert ehrliche MTTR‑ und MTBF-Werte. Zur SPS‑seitigen Gestaltungsdisziplin siehe unseren Leitfaden zu SPS in der Fertigung.

FAQ

Was ist der Unterschied zwischen einem Major- und einem Minor‑Fault?
Ein Major‑Fault stoppt die Programmausführung; ein Minor‑Fault protokolliert den Zustand und die Ausführung läuft weiter. Dieselbe Grundursache kann, abhängig von der Konfiguration, entweder Major oder Minor sein.

Der Fehler löscht sich, kommt aber immer wieder. Was nun?
Die Ursache ist weiterhin aktiv. Lesen Sie die Programm‑ und Routinenreferenz im Fehlerdatensatz und beheben Sie die dort benannte Logik oder Verbindung; automatisches Löschen um einen nicht diagnostizierten Fehler herum ist nicht ratsam.

Sollte jedes Programm eine Fehlerroutine haben?
Programme, bei denen ein wiederherstellbarer Datenfehler die Maschine nicht anhalten sollte, ja — mitsamt Protokollierung und Alarmierung. Sicherheitsrelevante Logik folgt eigenen Standards und wird niemals leichtfertig „gelöscht und weitergeführt”.

Um zu sehen, wie verifizierte Stopp‑Erfassung und geschlossene Arbeitsaufträge PLC‑Fehlerprotokolle in Zuverlässigkeitsverbesserungen verwandeln, vereinbaren Sie eine Demo.

Das Neueste aus unserem Blog

Definieren Sie Ihren Zuverlässigkeitsfahrplan
Überzeugen Sie sich selbst!
Definieren Sie Ihren Zuverlässigkeitsfahrplan
Indem Sie auf die Schaltfläche „Akzeptieren“ klicken, erklären Sie sich mit der Nutzung einverstanden.Cookies beim Zugriff auf diese Website und bei der Nutzung unserer Dienste. Erfahren Sie mehrWeitere Informationen zur Verwendung und Verwaltung von Cookies finden Sie in unserem Datenschutzrichtlinie und Cookie-Erklärung