Podłączony do tego samego zarządzalnego przełącznika co enkoder Allen-Bradley 842E laptop nie zobaczy automatycznie cyklicznego ruchu enkodera. Przełącznik zwykle przekazuje ramki unicast wyłącznie w kierunku portu docelowego. Dlatego analizator może pokazywać niemal nic, podczas gdy sterownik zgłasza przekroczenie czasu oczekiwania na wejścia/wyjścia.

Skuteczne przechwytywanie zaczyna się od sprawdzalnej hipotezy usterki oraz punktu przechwytywania, który może obserwować odpowiednie ramki.

Zdefiniuj pytanie przed zebraniem pakietów

Opisz objaw w mierzalnych kategoriach. Przykłady obejmują przekroczenie czasu oczekiwania na połączenie podczas określonej zmiany stanu maszyny, wartość enkodera, która przestaje się zmieniać, wielokrotne ponowne nawiązywanie połączenia lub dane pozycyjne docierające później, niż oczekuje tego sterownik. Zapisz kod usterki sterownika, czas, wskaźniki enkodera oraz stan portu przełącznika.

Określ, jakie dowody potwierdzą lub wykluczą każdą hipotezę. Jeśli pytanie dotyczy tego, czy ramki opuszczają enkoder, wykonaj kopię lustrzaną portu podłączonego do enkodera. Jeśli chodzi o to, czy docierają do łącza nadrzędnego sterownika, obserwuj to łącze. Przechwytywanie danych tylko po jednej stronie przełącznika pośredniego nie zawsze pozwala zlokalizować miejsce utraty.

Sprzęt enkoderów można znaleźć w kolekcji czujników, natomiast zarządzalne przełączniki i karty sieciowe są zgrupowane w sekcji Komunikacja i sieci.

Poznaj ścieżkę sieciową 842E

Firma Rockwell Automation opisuje 842E jako rodzinę absolutnych enkoderów EtherNet/IP z dwoma portami Ethernet, przeznaczoną do obsługiwanych topologii liniowych i Device Level Ring. Dokładny katalog oraz konfiguracja projektu określają połączenie danych, zespół danych, żądany interwał pakietów i sposób działania diagnostyki.

Udokumentuj oba porty fizyczne, ustawienia IP, połączenie ze sterownikiem, topologię, wersję oprogramowania sprzętowego oraz to, czy aktywny jest Device Level Ring. W topologii liniowej kabel lub urządzenie znajdujące się dalej może wpływać na ruch przechodzący przez enkoder. W pierścieniu zdarzenie topologiczne dostarcza dodatkowych dowodów, które należy skorelować z usterką połączenia.

Nie zakładaj, że port znajdujący się najbliżej sterownika jest zawsze jedynym użytecznym punktem przechwytywania. Narysuj rzeczywistą ścieżkę, uwzględniając porty przełączników, łącza nadrzędne, nadzorcę pierścienia, konwertery mediów oraz wszelkie trasy redundantne.

Wybierz nieinwazyjną metodę przechwytywania

Sesja dublowania portów w zarządzalnym przełączniku jest zwykle najmniej zakłócającą metodą. Skonfiguruj jako źródło port enkodera, port sterownika lub wymagane przez hipotezę łącze nadrzędne. Ustaw port podłączony do analizatora jako miejsce docelowe i potwierdź, czy przełącznik kopiuje ruch przychodzący, wychodzący czy oba kierunki.

Inną opcją jest specjalizowany pasywny tap sieciowy, jeśli pozwalają na to architektura i procedura przestoju. Nie wstawiaj niezarządzalnego przełącznika ani zwykłego koncentratora biurowego do działającej ścieżki sterowania. Taka zmiana może wpłynąć na topologię, jakość usług, obsługę multicastu, negocjację łącza oraz czas wystąpienia usterki.

Używaj dedykowanego interfejsu analizatora. Jeśli pozwala na to procedura operacyjna, wyłącz zbędne protokoły i usługi. Analizator powinien obserwować, a nie rozgłaszać urządzeń, żądać adresów ani stawać się kolejnym uczestnikiem sieci sterowania.

Sprawdź, czy kopia lustrzana pokazuje prawdę

Wygeneruj lub zidentyfikuj jedną znaną ramkę i potwierdź, że pojawia się ona w analizatorze. Sprawdź, czy w razie potrzeby widoczne są oba kierunki. Sesja dublowania może pomijać błędy warstwy fizycznej, gubić pakiety, gdy port docelowy jest przeciążony, albo kopiować tylko jeden kierunek.

Porównaj szybkość portu źródłowego z przepustowością miejsca docelowego kopii. Dublowanie obu kierunków zajętego łącza nadrzędnego o szybkości gigabitowej do jednego portu gigabitowego może przekroczyć przepustowość docelową. Zawęź źródło lub okno przechwytywania, zamiast zakładać, że każda luka wystąpiła w sieci sterowania.

Zapisz model przełącznika, wersję oprogramowania sprzętowego, konfigurację dublowania, port źródłowy, port docelowy, sposób obsługi VLAN oraz ustawienia interfejsu przechwytywania. Bez tych informacji inny inżynier nie będzie mógł odtworzyć pomiaru.

Rozdziel klasy ruchu EtherNet/IP

EtherNet/IP wykorzystuje komunikaty jawne do zarządzania połączeniami, konfiguracji i diagnostyki, natomiast cykliczne dane wejścia/wyjścia zwykle korzystają z transportu UDP. Wymiany związane z wykrywaniem urządzeń nie dowodzą, że ustanowione połączenie wejścia/wyjścia działa prawidłowo. Zachowaj konfigurację i zamknięcie połączenia wokół momentu wystąpienia usterki, a nie tylko pakiety cykliczne.

Zacznij od znanych adresów IP enkodera i sterownika. Następnie zidentyfikuj odpowiednie połączenie, zamiast oznaczać każdą ramkę UDP jako dane enkodera. Typowe porty EtherNet/IP mogą pomóc zawęzić ślad, ale silniejszych dowodów dostarczają punkty końcowe, czas oraz kontekst połączenia.

Zachowaj informacje o ARP, topologii i zarządzaniu przełącznikiem z okresu zdarzenia. Konflikt adresów lub zmiana stanu łącza może pojawić się poza odfiltrowanym strumieniem wejścia/wyjścia. Zapisz nieprzefiltrowane przechwycenie i używaj filtrów wyświetlania podczas analizy, aby nie utracić trwale kontekstu.

Analizuj taktowanie RPI i luki

Żądany interwał pakietów określa oczekiwaną częstotliwość aktualizacji dla skonfigurowanego połączenia wejścia/wyjścia. Zmierz czas między nadejściem pakietów w zdrowym okresie oraz w pobliżu usterki. Szukaj pominiętych interwałów, serii pakietów po przerwie, powtarzających się zachowań sekwencji oraz zamknięcia lub ponownego otwarcia połączenia.

Nie traktuj każdego pakietu, który pojawił się później niż nominalny RPI, jako usterki sterownika. Porównaj zaobserwowaną przerwę z działaniem limitu czasu połączenia skonfigurowanego w sterowniku. Kilka mikrosekund odchylenia i wielointerwałowa przerwa oznaczają coś innego.

Przedstaw na wykresie czas nadejścia pakietów obok bitu usterki sterownika, stanu zadania, zdarzenia maszyny i dzienników przełącznika. Jeśli strumień pakietów zatrzymuje się, zanim pojawi się zdarzenie utraty łącza, należy zwrócić uwagę na urządzenie źródłowe lub ścieżkę nadrzędną. Jeśli kopia lustrzana nadal rejestruje ramki enkodera, a sterownik przekracza czas oczekiwania, zbadaj pozostałą część ścieżki oraz przetwarzanie w sterowniku.

Używaj informacji z przełącznika razem ze śladem

Odczytaj liczniki portów przed testem i po nim. Błędy CRC lub kontroli ramki, zmiany stanu łącza, odrzucone pakiety, zmiany szybkości oraz zdarzenia pierścienia mogą wyjaśnić lukę w pakietach. Analizator pakietów podłączony powyżej uszkodzonego łącza może nigdy nie otrzymać uszkodzonych ramek, ponieważ przełącznik je odrzuca.

Sprawdź stan kabli i złączy, sposób ekranowania i uziemienia, promień gięcia, zanieczyszczenia oraz odciążenie przewodów. Wymieniaj pojedynczy kontrolowany element dopiero po zachowaniu wartości bazowych. Jednoczesna wymiana kilku kabli i ustawień przełącznika uniemożliwia ustalenie przyczyny.

Potwierdź uzgodnioną szybkość i tryb dupleksu zgodnie z obsługiwaną konfiguracją urządzenia. Nie wymuszaj ustawień bez konsultacji z instrukcjami enkodera i przełącznika. Niezgodność może powodować błędy zależne od obciążenia.

Chroń przechwycenie i sieć

Ogranicz czas przechwytywania lub użyj bufora pierścieniowego, aby nie zapełnić dysku analizatora. Zapisz dokładny czas lokalny i czas zakładowy. Ślady pakietów mogą ujawniać adresy, nazwy urządzeń, konfigurację i sposób działania procesu, dlatego przechowuj je z odpowiednią kontrolą dostępu.

Po zakończeniu testów usuń konfigurację dublowania i sprawdź, czy port docelowy powrócił do zamierzonego stanu. Pozostawiona konfiguracja dublowania może ujawniać ruch sterowania nieuprawnionemu urządzeniu lub zużywać zasoby przełącznika.

Nigdy nie wprowadzaj zmian konfiguracyjnych wyłącznie na podstawie śladu pakietów. Skoreluj dowody z diagnostyką sterownika, wskaźnikami enkodera, licznikami przełącznika oraz powtarzalnym zdarzeniem maszyny. Przechwycenie rejestruje ruch, ale nie poświadcza położenia mechanicznego ani nie dowodzi dokładności samego enkodera.

Przekształć obserwacje w ustalenie przyczyny usterki

Ramki zatrzymują się w obu punktach przechwytywania

Zbadaj zasilanie enkodera, jego stan wewnętrzny, połączenie z programem nadrzędnym lub wspólne łącze przed pierwszym punktem przechwytywania. Sprawdź, czy urządzenie uruchamia się ponownie lub czy połączenie jest celowo blokowane.

Ramki pojawiają się przy enkoderze, ale nie na łączu nadrzędnym

Skoncentruj się na ścieżce przełącznika pośredniego, sieci VLAN, zdarzeniu pierścienia, błędach portu, przeciążeniu lub okablowaniu. Powtórz test, synchronizując wcześniej liczniki, zanim wymienisz enkoder.

Ramki docierają do ścieżki sterownika, ale sterownik PLC przekracza czas oczekiwania

Sprawdź skonfigurowane połączenie, RPI, limit czasu, obciążenie zadania sterownika, zduplikowane adresowanie oraz to, czy przechwycone pakiety należą do oczekiwanego połączenia.

Przechwytywanie pakietów staje się wartościowe, gdy kontrolowane są miejsce przechwytywania, czas i kontekst sieciowy. Celem nie jest duży plik Wireshark. Celem jest niewielki zestaw dowodów pokazujący, gdzie zmieniła się cykliczna wymiana oraz jakie zdarzenie fizyczne lub konfiguracyjne zmieniło się razem z nią.