EtherNet/IP-Datenverkehr von einem Allen-Bradley 842E erfassen
Ein nichtinvasiver Workflow zur Paketerfassung für einen Allen-Bradley-842E-Encoder mit Informationen zur Platzierung des Spiegelports, zu EtherNet/IP-Verkehrsklassen, zum RPI-Timing, zu Switch-Nac...
Ein Laptop, der an denselben verwalteten Switch wie ein Allen-Bradley-842E-Encoder angeschlossen ist, empfängt den zyklischen Datenverkehr des Encoders nicht automatisch. Ein Switch leitet Unicast-Frames normalerweise nur zum Zielport weiter. Der Analyzer kann daher fast nichts anzeigen, während die Steuerung einen E/A-Timeout meldet.
Eine nützliche Aufzeichnung beginnt mit einer überprüfbaren Fehlerhypothese und einem Aufzeichnungspunkt, an dem die relevanten Frames beobachtet werden können.
Die Frage vor der Paketsammlung definieren
Formulieren Sie das Symptom in messbaren Begriffen. Beispiele sind ein Verbindungstimeout während eines bestimmten Maschinenübergangs, ein Encoderwert, der sich nicht mehr ändert, wiederholte Neuverbindungen oder Positionsdaten, die später als von der Steuerung erwartet eintreffen. Notieren Sie den Steuerungsfehlercode, die Uhrzeit, die Encoder-Anzeigen und den Zustand des Switch-Ports.
Entscheiden Sie, welche Belege jede Hypothese stützen oder widerlegen würden. Wenn die Frage lautet, ob Frames den Encoder verlassen, spiegeln Sie den zum Encoder führenden Port. Wenn es darum geht, ob sie den Uplink zur Steuerung erreichen, überwachen Sie diese Verbindung. Eine Aufzeichnung nur auf einer Seite eines zwischengeschalteten Switches kann den Verlust nicht immer lokalisieren.
Encoder-Hardware finden Sie in der Sensorsammlung, während verwaltete Switches und Netzwerkadapter unter Kommunikation & Netzwerke zusammengefasst sind.
Den Netzwerkpfad des 842E verstehen
Rockwell Automation beschreibt den 842E als eine EtherNet/IP-Familie absoluter Encoder mit zwei Ethernet-Ports für unterstützte lineare Topologien und Device-Level-Ring-Topologien. Katalognummer und Projektkonfiguration bestimmen im Einzelnen die Datenverbindung, die Assembly, das angeforderte Paketintervall und das Diagnoseverhalten.
Dokumentieren Sie beide physischen Ports, die IP-Einstellungen, die Steuerungsverbindung, die Topologie, die Firmware und, ob Device Level Ring aktiv ist. In einer linearen Topologie kann ein nachgeschaltetes Kabel oder Gerät den Datenverkehr durch den Encoder beeinflussen. In einem Ring liefert ein Topologieereignis zusätzliche Hinweise, die mit dem Verbindungsfehler abgeglichen werden müssen.
Gehen Sie nicht davon aus, dass der der Steuerung nächstgelegene Port immer der einzige sinnvolle Aufzeichnungspunkt ist. Zeichnen Sie den tatsächlichen Pfad auf, einschließlich Switch-Ports, Uplinks, Ring-Supervisor, Medienkonvertern und redundanter Routen.
Eine nichtinvasive Aufzeichnungsmethode auswählen
Eine Spiegelungssitzung am verwalteten Switch ist normalerweise die am wenigsten störende Methode. Konfigurieren Sie als Quellport den Encoder-Port, den Steuerungsport oder den für die Hypothese erforderlichen Uplink. Legen Sie den Port zum Analyzer als Ziel fest und bestätigen Sie, ob der Switch eingehenden, ausgehenden oder Datenverkehr in beide Richtungen spiegelt.
Ein speziell dafür vorgesehener passiver Netzwerk-TAP ist eine weitere Option, sofern Architektur und Ausfallprozedur dies erlauben. Schalten Sie keinen unmanaged Switch und keinen gewöhnlichen Büro-Hub in einen laufenden Steuerungspfad ein. Eine solche Änderung kann Topologie, Dienstgüte, Multicast-Verarbeitung, Link-Aushandlung und Fehlerzeitpunkt beeinflussen.
Verwenden Sie eine dedizierte Analyzer-Schnittstelle. Deaktivieren Sie unnötige Protokolle und Dienste, sofern es das Betriebsverfahren erlaubt. Der Analyzer soll beobachten, nicht Geräte ankündigen, Adressen anfordern oder zu einem weiteren Teilnehmer des Steuerungsnetzwerks werden.
Überprüfen, ob die Spiegelung die Realität korrekt wiedergibt
Erzeugen oder identifizieren Sie einen bekannten Frame und bestätigen Sie, dass er auf dem Analyzer erscheint. Prüfen Sie, ob bei Bedarf beide Richtungen sichtbar sind. Eine Spiegelungssitzung kann Fehler der physikalischen Schicht auslassen, Pakete verwerfen, wenn der Zielport überlastet ist, oder nur eine Richtung kopieren.
Vergleichen Sie die Geschwindigkeit des Quellports mit der Kapazität des Spiegelungsziels. Das Spiegeln beider Richtungen eines ausgelasteten Gigabit-Uplinks auf einen einzelnen Gigabit-Port kann die Zielbandbreite überschreiten. Schränken Sie die Quelle oder das Aufzeichnungsfenster ein, statt automatisch anzunehmen, dass jede Lücke im Steuerungsnetzwerk entstanden ist.
Notieren Sie Switch-Modell, Firmware, Spiegelungskonfiguration, Quellport, Zielport, VLAN-Verhalten und Einstellungen der Aufzeichnungsschnittstelle. Ohne diese Aufzeichnungen kann ein anderer Techniker die Messung nicht reproduzieren.
EtherNet/IP-Datenverkehrsklassen unterscheiden
EtherNet/IP verwendet explizite Nachrichten für Verbindungsverwaltung, Konfiguration und Diagnose, während zyklische E/A-Daten häufig über UDP übertragen werden. Discovery-Austauschvorgänge sind kein Beweis dafür, dass eine bestehende E/A-Verbindung fehlerfrei arbeitet. Sichern Sie den Verbindungsaufbau und -abbau rund um den Fehler, nicht nur die zyklischen Pakete.
Beginnen Sie mit den bekannten IP-Adressen von Encoder und Steuerung. Identifizieren Sie anschließend die relevante Verbindung, statt jeden UDP-Frame als Encoderdaten zu bezeichnen. Übliche EtherNet/IP-Ports können helfen, die Aufzeichnung einzugrenzen, doch Endpunkte, Zeitverhalten und Verbindungskontext liefern aussagekräftigere Belege.
Bewahren Sie ARP-, Topologie- und Switch-Managementdaten rund um das Ereignis auf. Ein Adresskonflikt oder Link-Übergang kann außerhalb des gefilterten E/A-Datenstroms sichtbar werden. Speichern Sie die ungefilterte Aufzeichnung und verwenden Sie für die Analyse Anzeigefilter, damit der Kontext nicht dauerhaft verworfen wird.
RPI-Zeitverhalten und Lücken analysieren
Das angeforderte Paketintervall legt die erwartete Aktualisierungsrate der konfigurierten E/A-Verbindung fest. Messen Sie die Zeit zwischen dem Eintreffen von Paketen während eines fehlerfreien Zeitraums und rund um den Fehler. Achten Sie auf fehlende Intervalle, nach einer Pause auftretende Bursts, doppelte Sequenzen sowie einen Verbindungsabbau oder -aufbau.
Betrachten Sie nicht jedes Paket, das später als das nominale RPI eintrifft, als Steuerungsfehler. Vergleichen Sie die beobachtete Lücke mit dem in der Steuerung konfigurierten Verbindungs-Timeout. Eine Abweichung von wenigen Mikrosekunden und ein Ausfall über mehrere Intervalle haben unterschiedliche Bedeutungen.
Stellen Sie die Paketankunftszeit dem Fehlerbit der Steuerung, dem Task-Zustand, dem Maschinenereignis und den Switch-Protokollen gegenüber. Wenn der Paketstrom endet, bevor ein Link-Down-Ereignis erscheint, verdienen das Quellgerät oder der vorgelagerte Pfad besondere Aufmerksamkeit. Wenn die Spiegelung weiterhin Encoder-Frames sieht, während die Steuerung einen Timeout meldet, untersuchen Sie den verbleibenden Pfad und die Verarbeitung in der Steuerung.
Switch-Daten zusammen mit der Aufzeichnung verwenden
Lesen Sie die Portzähler vor und nach dem Test aus. CRC- oder Frame-Check-Fehler, Link-Übergänge, verworfene Pakete, Geschwindigkeitsänderungen und Ringereignisse können eine Paketlücke erklären. Ein über der fehlerhaften Verbindung angeschlossener Paket-Analyzer empfängt möglicherweise nie beschädigte Frames, weil der Switch sie verwirft.
Prüfen Sie Zustand von Kabeln und Steckverbindern, Schirmungs- und Erdungsmaßnahmen, Biegeradius, Verschmutzung und Zugentlastung. Tauschen Sie erst dann eine einzelne kontrollierte Komponente aus, nachdem Sie die Ausgangssituation gesichert haben. Wenn mehrere Kabel und Switch-Einstellungen gleichzeitig geändert werden, lässt sich die Ursache nicht mehr zuverlässig bestimmen.
Bestätigen Sie die ausgehandelte Geschwindigkeit und den Duplexmodus entsprechend der unterstützten Gerätekonfiguration. Vermeiden Sie das Erzwingen von Einstellungen, ohne die Handbücher von Encoder und Switch zu konsultieren. Eine Fehlanpassung kann Fehler verursachen, die von der Auslastung abhängen.
Aufzeichnung und Netzwerk schützen
Begrenzen Sie die Aufzeichnungsdauer oder verwenden Sie einen Ringpuffer, damit der Speicher des Analyzers nicht vollläuft. Kennzeichnen Sie die genaue lokale Zeit und Anlagenzeit. Paketaufzeichnungen können Adressen, Gerätenamen, Konfigurationen und Prozessverhalten offenlegen. Speichern Sie sie daher mit angemessener Zugriffskontrolle.
Entfernen Sie die Spiegelungskonfiguration nach dem Test und prüfen Sie, ob der Zielport in seinen vorgesehenen Zustand zurückkehrt. Eine vergessene Spiegelung kann Steuerungsdatenverkehr einem unbefugten Gerät zugänglich machen oder Switch-Ressourcen verbrauchen.
Nehmen Sie niemals allein aufgrund einer Paketaufzeichnung Konfigurationsänderungen vor. Gleichen Sie die Belege mit Steuerungsdiagnosen, Encoder-Anzeigen, Switch-Zählern und einem reproduzierbaren Maschinenereignis ab. Die Aufzeichnung dokumentiert den Datenverkehr; sie zertifiziert weder die mechanische Position noch beweist sie, dass der Encoder selbst korrekt arbeitet.
Beobachtungen in eine Fehlerbewertung überführen
Frames stoppen an beiden Aufzeichnungspunkten
Untersuchen Sie die Stromversorgung des Encoders, seinen internen Zustand, die vorgelagerte Programmverbindung oder die gemeinsame Verbindung vor dem ersten Aufzeichnungspunkt. Prüfen Sie, ob das Gerät neu startet oder die Verbindung absichtlich gesperrt wird.
Frames erscheinen am Encoder, aber nicht am Uplink
Konzentrieren Sie sich auf den Pfad über den zwischengeschalteten Switch, VLAN, Ringereignisse, Portfehler, Überlastung oder Verkabelung. Wiederholen Sie den Test mit zeitlich synchronisierten Zählern, bevor Sie den Encoder austauschen.
Frames erreichen den Pfad zur Steuerung, doch die SPS meldet einen Timeout
Überprüfen Sie die konfigurierte Verbindung, RPI, Timeout, Auslastung der Steuerungs-Tasks, doppelte Adressierung und, ob die aufgezeichneten Pakete zur erwarteten Verbindung gehören.
Eine Paketaufzeichnung wird wertvoll, wenn Aufzeichnungsplatzierung, Zeitverhalten und Netzwerkkontext kontrolliert werden. Ziel ist keine große Wireshark-Datei, sondern eine kompakte Beweissammlung, die zeigt, wo sich der zyklische Austausch verändert hat und welches physische oder konfigurationsbezogene Ereignis sich gleichzeitig verändert hat.