EtherNet/IP CIP Motion Achsfehlerdiagnose: Allen-Bradley Kinetix 5700 und Schneider Lexium 32

plcdcspro
2026-04-15T17:00:05+08:00

Ein praxisbewährtes 7-Schritte-Verfahren zur Behebung von Achsfehlerzuständen, Verbindungsabbrüchen und Antriebsabstimmungsfehlern in EtherNet/IP CIP Motion Netzwerken mit Allen-Bradley Kinetix 5700 und Schneider Lexium 32 Antrieben.
Mehr

Die tatsächlichen Kosten eines „Axis Faulted“-Zustands

Ein „Axis Faulted“-Zustand in einem EtherNet/IP CIP Motion-Netzwerk stoppt die Produktion sofort. Ingenieure verbringen Stunden damit, die Ursachen zu ermitteln. Die meisten Fehler lassen sich in vier Kategorien einteilen: Antriebshardware, Netzwerktiming, Abstimmungsparameter und Sicherheits-Eingangslogik. Sie alle als dasselbe Problem zu behandeln, kostet Zeit.

CIP Motion verwendet implizite Klasse-1-Verbindungen mit einem Requested Packet Interval (RPI) von 1–2 ms. Standard EtherNet/IP I/O läuft mit 10–20 ms. Ein verpasster Update bei 1 ms RPI löst innerhalb von 4–8 ms einen „Axis Major Fault“ aus. Netzwerklatenz über 250 µs verursacht intermittierende Fehler, die wie Antriebshardware-Ausfälle aussehen. Logix 5000 Firmware 33.011 und höher protokolliert CIP Motion-Verbindungsfehlerdetails im Modul-Fehlerprotokoll, nicht nur in den Antriebsstatus-Bits. Prüfen Sie immer beide Stellen. Der Allen-Bradley ControlLogix 1756-L75 Controller steuert CIP Motion-Achsen über das 1756-EN2TP EtherNet/IP-Modul.

Entschlüsselung der Fehlercodes von Kinetix 5700 und Lexium 32

Jeder Fehlercode verweist auf eine bestimmte Ebene. Lernen Sie die Code-Struktur, bevor Sie Hardware austauschen.

Allen-Bradley Kinetix 5700 verwendet ein zweibytes Fehlercode-Format. Das hohe Byte ist die Fehlerkategorie (0x01 = Hardware, 0x02 = Motion, 0x04 = Antriebsüberlast, 0x08 = Rückmeldung, 0x10 = Sicherheit). Das niedrige Byte ist die spezifische Fehlernummer. Lesen Sie diese in Studio 5000 unter Drive Properties → Fault Log Tab.

Schritt 1: Öffnen Sie Studio 5000 → Controller Properties → Module Properties für die Kinetix 5700 Achse.

Schritt 2: Navigieren Sie zum Fault Log Tab. Notieren Sie den Fehlercode (hex) und den Fehlerzeitstempel.

Schritt 3: Fehlercode 0x0204 = Geschwindigkeitsfehler. Überprüfen Sie die Verkabelung der Geschwindigkeitsrückmeldung am J13-Stecker, Pins 1–4.

Schritt 4: Fehlercode 0x0810 = Niedriger Encoder-Batteriestand. Ersetzen Sie die CR2032-Batterie am Absolutwertgeber. Setzen Sie nach dem Austausch die Encoder-Positionsreferenz zurück.

Schritt 5: Fehlercode 0x1001 = Safe Torque Off (STO) Eingang spannungsfrei. Prüfen Sie die 24 VDC Versorgung an den STO+ und STO− Klemmen (≥22 VDC erforderlich).

Schneider Lexium 32 speichert die Fehlerhistorie in den internen Registern MW100–MW109. Lesen Sie diese über Modbus TCP (Funktionscode 03). Das Fehlerwort-Format: Bits 0–3 = Fehlerklasse, Bits 4–7 = Fehleruntercode. Fehlerklasse 4 (0x40) zeigt Motorübertemperatur an. Fehlerklasse 6 (0x60) zeigt Encoder-Fehler an. Überprüfen Sie immer die Schirmung des Encoder-Kabels auf Durchgang, bevor Sie einen Encoder-Ausfall annehmen. Für Kinetix-Familien-Achsenmodule siehe das Kinetix 6000 Integrated Axis Module als Referenzplattform für die Fehlercode-Architektur.

Netzwerkschicht-Diagnose: Jitter und Paketverlust finden

CIP Motion-Fehler lassen sich oft auf das Netzwerk zurückführen, nicht auf den Antrieb. Drei spezifische Tests bestätigen schnell die Netzwerkgesundheit.

Erstens prüfen Sie die Portstatistiken des EtherNet/IP-Switches. CIP Motion-Verkehr erfordert QoS Class of Service (CoS) Markierung mit DSCP 55 (CIP Motion) und DSCP 46 (CIP Echtzeit). Der Allen-Bradley Stratix 5700 Managed Switch zeigt pro Port Verwerfungszähler an. Jeder nicht-null Eingang-Verwerfungszähler am Antriebsport weist auf einen Pufferüberlauf hin – reduzieren Sie Hintergrundverkehr oder erhöhen Sie die Port-Warteschlangenpriorität.

Zweitens messen Sie den tatsächlichen RPI-Jitter mit Wireshark. Erfassen Sie den Verkehr am Controller-Port. Filtern Sie nach Ethernet-Quell-MAC der Kinetix 5700 oder Lexium 32. CIP Motion erfordert Jitter ≤ 250 µs. Werte über 500 µs verursachen wiederkehrende Achsfehler alle 3–10 Minuten unter Last.

Schritt 1: Verbinden Sie den Laptop mit dem SPAN-Port des Managed Switch. Starten Sie die Wireshark-Erfassung, Filter: eth.src == [Antriebs-MAC].

Schritt 2: Fahren Sie die Achse mit 50 % Nennleistung für 5 Minuten. Exportieren Sie die Erfassung als CSV. Berechnen Sie die Standardabweichung der Zwischenpaketzeiten.

Schritt 3: Wenn der Jitter > 250 µs ist, prüfen Sie auf Multicast-Fluten. Aktivieren Sie IGMP Snooping auf allen Switches im CIP Motion VLAN.

Schritt 4: Vergewissern Sie sich, dass die Controller-Netzwerkkarte mit 100 Mbps Vollduplex läuft, nicht Auto-Negotiation. Erzwingen Sie 100FD an beiden Enden, wenn der Jitter über 300 µs bleibt.

Drittens prüfen Sie den Logix 5000 CIP Motion-Verbindungsstatus. Fügen Sie in Studio 5000 ein Watch-Tag für das AXIS_CIP_DRIVE-Tag hinzu. Überwachen Sie die Attribute .RunningFault, .StartInhibited und .MotionGroupFault. Ein .StartInhibited-Zustand ohne Fehlercode bedeutet, dass der Controller auf die Wiederherstellung der Verbindung wartet. Ein RPI-Mismatch in der Motion Group ist die häufigste versteckte Ursache.

Validierung der Antriebsabstimmung nach Fehlerbehebung

Das Löschen eines Fehlers und Neustarten der Achse ohne Abstimmungsvalidierung führt innerhalb von 30 Minuten zu wiederholten Fehlern. Folgen Sie dieser Reihenfolge nach jedem Achsen-Hauptfehler.

Für Kinetix 5700 öffnen Sie den Autotune-Assistenten in Studio 5000 (Motion Properties → Tune Tab). Stellen Sie den Autotune-Modus auf „Positionsregelung“. Verwenden Sie den Trägheitstest mit einer 10 % Nennmomentrampe. Der Assistent liefert das Lastträgheitsverhältnis (J_load/J_motor). Akzeptieren Sie Werte von 0,1–10. Werte über 10 deuten auf mechanische Kupplungsprobleme hin – prüfen Sie das Getriebe-Backlash vor der Abstimmung. Nach Abschluss des Autotunes vergewissern Sie sich, dass die Bandbreite (Hz) 80 Hz für starre Kupplungen bzw. 40 Hz für flexible Kupplungen nicht überschreitet.

Für Lexium 32 verwenden Sie die SoMove-Software (v3.3 oder höher) über den USB-Diagnoseport. Navigieren Sie zu Drive → Tuning → Auto-tuning. Der Antrieb führt einen symmetrischen Geschwindigkeitsstufentest bei 25 % Nennleistung durch. Prüfen Sie das Kp (Positionsverstärkung) Ergebnis. Werte unter 0,5 Hz deuten auf mechanische Steifigkeitsprobleme hin. Werte über 200 Hz deuten auf eine Encoderauflösungs-Diskrepanz mit der Spindelsteigung hin. Korrigieren Sie den Übersetzungsparameter (P3.006) vor dem erneuten Test.

Verlassen Sie sich bei hochdynamischen Anwendungen nicht nur auf Autotune. Ein manueller Sprungantworttest bei 10 %, 50 % und 100 % Nennleistung bestätigt die Abstimmung über den gesamten Betriebsbereich. Der maximale Positionsfehler bei 100 % Nennleistung sollte unter dem Doppelten des PET-Werts bleiben.

Fehler der Sicherheits-Eingangslogik und STO-Wiederherstellung

Safe Torque Off (STO)-Eingänge verursachen 30 % der „Axis Faulted“-Meldungen im Feld. Das Symptom ist identisch mit einem Antriebshardware-Fehler – die Achse fällt aus und lässt sich nicht aktivieren. Das Löschen des Fehlers und erneutes Aktivieren hat jedoch keine Wirkung, wenn STO nicht erfüllt ist.

Kinetix 5700 benötigt beide STO-Eingänge (STO-A und STO-B am Sicherheitsstecker J2, Pins 1 und 4) mit ≥22 VDC. Ein Einkanal-STO-Fehler erzeugt Fehlercode 0x1001. Ein Zweikanal-STO-Fehler erzeugt 0x1002. Wenn der STO-Kreis ein Sicherheitsrelais mit verzögertem Abfallen verwendet, prüfen Sie die Haltespannung des Relais – unter 18 VDC verursacht unter Vibration intermittierende STO-Auslösungen.

Die STO-Implementierung des Lexium 32 folgt EN/IEC 62061. Der STO-Eingang an Klemme CN7 Pin 5–6 benötigt 20–28 VDC für den aktiven Zustand. Prüfen Sie das STO_Active-Bit im Antriebsstatusregister MW0 Bit 14. Wenn STO_Active = 0 während des Normalbetriebs ist, verfolgen Sie das 24 VDC STO-Versorgungskabel auf Erdschluss. Verwenden Sie eine Stromzange am STO-Kabelschirm – ein Schirmstrom über 50 mA weist auf Isolationsfehler in einem Mehrachsen-Kabelkanal hin.

Testen Sie die STO-Funktion immer nach jeder Achsenfehlerbehebung. Führen Sie einen Anforderungstest durch, indem Sie die STO-Versorgung absichtlich entfernen. Vergewissern Sie sich, dass das Antriebsmoment innerhalb von 20 ms auf Null fällt (IEC 62061 Kategorie 3 Anforderung). Protokollieren Sie die STO-Reaktionszeit mit einem Oszilloskop. Dokumentieren Sie Datum und Bestehen/Nichtbestehen im Wartungsprotokoll für IEC 61511-Konformitätsprüfungen.

Fazit und Handlungsempfehlungen

EtherNet/IP CIP Motion-Fehler folgen einem vorhersehbaren Muster. Netzwerklatenz über 250 µs, STO-Eingangsausfälle und fehlgeschlagene Abstimmungsvalidierungen nach Fehlern verursachen 80 % der Wiederholungsfälle. Beginnen Sie jede Diagnose im Fehlerprotokoll, nicht an der Hardware. Entschlüsseln Sie den Fehlercode, bevor Sie an der Verkabelung arbeiten. Bestätigen Sie den Netzwerk-RPI-Jitter mit Wireshark, bevor Sie den Antrieb beschuldigen.

Führen Sie immer Autotune und einen manuellen Sprungantworttest durch, bevor Sie die Achse wieder in Betrieb nehmen. Halten Sie für Kinetix 5700 Studio 5000 und Antriebsfirmware-Versionen synchron – Firmware-Mismatch allein verursacht falsche CIP-Verbindungsfehler. Für Lexium 32 protokollieren Sie MW100–MW109 bei jedem Fehlerereignis. Fünf Fehleraufzeichnungen zeigen ein Muster und reduzieren die Diagnosezeit beim nächsten Vorfall um 60 %.

Planen Sie STO-Prüfungen im 6-Monats-Rhythmus und dokumentieren Sie die Ergebnisse. Verwenden Sie den Stratix 5700 Managed Switch mit aktiviertem IGMP Snooping und QoS als Grundlage für ein zuverlässiges CIP Motion-Netzwerk. Sicherheitsprüfer fordern zunehmend CIP Motion STO-Testprotokolle als Teil der IEC 62061-Konformitätsprüfungen an.