Alle paar Tage geht die SLC in einen Fehlerzustand. Schwerwiegender Fehler 0020. Die Bediener zucken mit den Schultern, die Instandhaltung setzt den Fehler zurück, die Produktion läuft wieder an – bis derselbe Rechenfehler in der Nachtschicht erneut auftritt. Dieses Muster ist das Überlauf-Fangbit S:5/0, das genau das tut, wofür Rockwell es entwickelt hat: Es bleibt gesetzt, damit niemand so tun kann, als wäre die fehlerhafte Berechnung nie passiert.

Bei einer 5/04 wie der 1747-L524 bedeutet 0020, dass eine Anweisung ein Ergebnis außerhalb des zulässigen Ganzzahlbereichs erzeugt hat. Für vorzeichenbehaftete 16-Bit-Berechnungen gilt der Bereich von −32768 bis +32767. Wird diese Obergrenze mit ADD oder MUL überschritten, durch null geteilt, ein FIFO/LIFO über seinen Puffer hinaus durchlaufen oder −32768 mit NEG negiert, setzt der Prozessor S:5/0 und bleibt anschließend im Fehlerzustand, bis dieses Bit zurückgesetzt wird. Die Handbücher der Publikationsfamilie 1747-UM011 / 1747-UM001 beschreiben den Fangmechanismus; in der Anlage sieht man lediglich eine ausgefallene CPU.

In Legacy-SLC-Prozessoren steckt noch viel diskrete Maschinentechnik. Überlauf-Fangfehler sind fast immer auf die Anwendungsberechnung zurückzuführen – nicht auf eine ausfallende Rückwandplatine.

Das OTU, das die Situation stabilisiert

Bei den meisten schnellen Wiederherstellungen wird ein OTU auf S:5/0 gesetzt, damit der Scan nach dem Fangmechanismus fortgesetzt werden kann. Entscheidend ist die Platzierung. Setzen Sie es als letzte Zeile in LAD 2 – der Datei, die Ihre JSR-Aufrufe enthält –, damit jede Unterroutine abgeschlossen ist, bevor Sie das Latch zurücksetzen. So wird der Überlauf während des Scans erkannt und anschließend einmalig vor dem Leerlauf zurückgesetzt.

LAD 2 – letzte Zeile
  S:5/0
----] [----(OTU)----

Setzen Sie dasselbe OTU in die überlaufende Unterroutine, erzeugen Sie einen neuen Fehlermechanismus: Sie setzen das Bit zu früh zurück, der Überlauf tritt später im selben Scan erneut auf und es kommt sofort wieder zu einem Fehler. Oder das OTU wird in einem Pfad ausgeführt, in dem die fehlerhafte Berechnung in diesem Scan gar nicht stattfindet. Dann glauben Sie, das Problem „behoben“ zu haben, obwohl die eigentliche Zeile weiterhin zweimal pro Woche den Fehler auslöst.

Übertragen Sie das Programm, schalten Sie auf RUN und beobachten Sie, ob S:5/0 über mehrere Schichten hinweg gelöscht bleibt. Wenn es ruhig bleibt, haben Sie Zeit gewonnen – die Ursachenanalyse ist damit jedoch noch nicht abgeschlossen.

Finden Sie die Berechnung, bei der der Überlauf tatsächlich auftrat

Betrachten Sie das OTU als Sicherheitsgurt. Dann beginnen Sie mit der Suche:

• Jede aktuelle Änderung, die Ganzzahlen betrifft – Chargenzähler, skalierte Analogwerte in N-Dateien, ein „temporäres“ MUL zur Einheitenumrechnung
• ADD / SUB / MUL / DIV / DDV ohne Bereichsbegrenzungen
• Stellen, an denen LADD / LMUL (32 Bit) erforderlich wären, sobald Werte den komfortablen 16-Bit-Bereich verlassen
• NEG bei einem Wert, der −32768 erreichen kann
• FIFO/LIFO-Länge im Verhältnis zum tatsächlich reservierten Puffer

Weitere Statusbits, die beim Debuggen hilfreich sind: S:5/1 Aktivierung des Überlauf-Fangmechanismus, S:1/0 erster Scan, S:2/0 Prozessorfehler. Setzen Sie Fangbits bei Online-Änderungen nicht blind zurück, ohne zu wissen, welche Zeile den Fehler verursacht.

Realitätscheck zur Hardware

CPUs der Klasse 1747-L524 5/04 sind weitgehend veraltet. Wenn das Chassis weiter betrieben wird, sollten Sie eine geprüfte 5/04 als Ersatz auf Lager halten – Anlagen, die noch Komponenten dieser Familie kaufen, greifen häufig auf Module wie die 1747-L542 zurück. Kleinere Maschinen werden manchmal seitlich auf eine 5/03 wie die 1747-L532 migriert, aber das ist eine Projektentscheidung und keine Lösung für den Überlauf. Langfristig verlagern die meisten Standorte den Prozess auf CompactLogix oder ControlLogix und verabschieden sich mit der Plattform von den 16-Bit-Rechenfallen. Die Ersatzteilstrategie für gemischte Logix-Flotten sollte weiterhin daran ausgerichtet sein, wie Sie SPS- und PAC-Systeme bevorraten.

Bis die Migration umgesetzt ist, gilt eine einfache Regel: OTU zuletzt in LAD 2 platzieren und anschließend nachweisen, welches ADD/MUL seinen Wertebereich falsch einschätzt.