Planowanie wydajności CompactLogix L35E EtherNet/IP

Sterownik CompactLogix 1769-L35E nadal jest często używany w maszynach, które pracują dłużej niż zakładano w pierwotnym planie sieci. Problemy z rozbudową zwykle zaczynają się wtedy, gdy listę urządzeń traktuje się jako liczbę połączeń. Możliwości EtherNet/IP zależą od rodzaju ruchu generowanego przez każde urządzenie, częstotliwości wymiany danych oraz zasobów sterownika wykorzystywanych już przez aplikację. Dlatego bezpieczna ocena powinna rozpoczynać się od działającego projektu i diagnostyki, a nie od ogólnej zasady określającej liczbę urządzeń przypadających na port.

Planowanie połączeń musi uwzględniać skonfigurowany ruch, częstotliwość aktualizacji i ryzyko związane z cyklem życia, a nie liczbę wtyczek Ethernet.

Zacznij od udokumentowanego limitu sterownika

Instrukcja obsługi sterowników 1769 CompactLogix firmy Rockwell Automation określa, że model L35E obsługuje 100 połączeń CIP. Jest to limit zasobów, a nie zgoda na podłączenie 100 urządzeń. Jedno urządzenie może wymagać więcej niż jednego połączenia, podczas gdy niektóre rodzaje komunikacji mogą współdzielić zoptymalizowane połączenie. Na końcową liczbę wpływają wersja oprogramowania sprzętowego, konfiguracja modułów, tagi produkowane i konsumowane, buforowane komunikaty oraz klienci HMI lub systemów nadrzędnych.

Sterownik ten jest również produktem wycofanym z produkcji. Firma Rockwell podaje, że model 1769-L35E został wycofany 20 grudnia 2020 r. Nie oznacza to, że działający system jest bezużyteczny, ale zmienia decyzję inżynierską: problem z wydajnością należy analizować razem z dostępnością części zapasowych, obsługą oprogramowania sprzętowego, narażeniem na cyberzagrożenia oraz kosztem nieplanowanej awarii.

Utwórz wykaz połączeń na podstawie projektu

Otwórz projekt offline odpowiadający działającemu sterownikowi i wymień każdy skonfigurowany adapter I/O, napęd, tag produkowany lub konsumowany, ścieżkę komunikatu, serwer danych HMI, rejestrator danych, bramę oraz połączenie programistyczne. Zapisz, czy każda wymiana jest cyklicznym I/O, danymi produkowanymi, komunikatem jawnym czy odpytywaniem przez klienta. Nie przypisuj stałego zapotrzebowania na połączenia wyłącznie na podstawie nazwy producenta. Rzeczywista konfiguracja jest źródłem rozstrzygającym.

W przypadku rozproszonego I/O sprawdź, czy wybrany format komunikacji tworzy bezpośrednie połączenia z modułami, czy połączenie zoptymalizowane dla całej kasety. W przypadku instrukcji MSG ustal, które połączenia są buforowane oraz czy kilka komunikatów może być aktywnych jednocześnie. W systemach nadrzędnych policz niezależne ścieżki komunikacji i przeanalizuj sposób ich odpytywania. Arkusz kalkulacyjny powinien łączyć każde założone połączenie z obiektem projektu lub przetestowaną konfiguracją klienta.

Oddziel liczbę połączeń od obciążenia pakietami

Sterownik może pozostawać poniżej limitu połączeń, a mimo to zapewniać słabą wydajność sieci. Żądane interwały pakietów, częstotliwość komunikatów, rozmiar pakietów, działanie multicast, konfiguracja przełączników oraz serie żądań od wielu klientów wpływają na obciążenie pakietami. Bardzo krótkie interwały RPI powinny być uzasadnione wymaganiami procesu mechanicznego i wymaganą reakcją układu sterowania; przyspieszenie każdego urządzenia nie sprawi, że maszyna będzie działać lepiej.

Ustal wartości bazowe podczas normalnej produkcji. Zapisz wykorzystanie połączeń, liczniki błędów Ethernet, pominięte lub przekroczone czasowo komunikaty, stan I/O, szybkość reakcji HMI oraz działanie skanowania sterownika. Powtórz rejestrację podczas uruchamiania, pobierania receptur, serii alarmów, dostępu serwisowego i innych wiarygodnych wartości szczytowych. Średnie mogą ukrywać krótki przedział czasu powodujący sporadyczną usterkę.

Zarządzalne przełączniki, udokumentowana topologia i powtarzalne pomiary ułatwiają diagnozowanie sporadycznych problemów z wydajnością.

Nie używaj 1769-AENTR jako drugiego portu L35E

1769-AENTR to adapter EtherNet/IP przeznaczony do zdalnego zestawu Compact I/O sterowanego przez sieć. Nie jest to dodatkowy interfejs Ethernet zwiększający pulę komunikacyjną sterownika L35E i nie można go podłączyć jako drugiego portu sterownika w celu przeniesienia ruchu HMI lub komunikatów z wbudowanego interfejsu. Projektowanie na podstawie takiego założenia tworzy topologię, która nie może działać w deklarowany sposób.

Jeśli zdalne I/O jest odpowiednim rozwiązaniem, adapter może skonsolidować fizyczne I/O w innej lokalizacji, ale wynikające z tego połączenie I/O nadal kończy się w sterowniku. Jeśli aplikacja wymaga większej wydajności komunikacyjnej, drugiej niezależnej sieci, nowoczesnych funkcji bezpieczeństwa lub dłuższego wsparcia cyklu życia, rozwiązaniem może być migracja do nowszej rodziny sterowników, a nie zastosowanie kolejnego adaptera.

Ogranicz możliwe do uniknięcia obciążenie, nie ukrywając problemu

Optymalizacja powinna zachowywać wymagania procesu. Usuń nieużywane ścieżki i klientów. Konsoliduj połączenia I/O tam, gdzie obsługują to platforma i typy modułów. Buforuj tylko te połączenia MSG, które wymagają szybkiego, powtarzalnego wykonywania, a komunikaty niekrytyczne uruchamiaj sekwencyjnie, aby nie otwierały się wszystkie jednocześnie. Zwiększaj interwał RPI lub odpytywania dopiero po potwierdzeniu, że czas wykrywania, blokady wzajemne, alarmowanie i jakość sterowania pozostają akceptowalne.

Stosuj zarządzalne przemysłowe przełączniki i dokumentuj ustawienia VLAN, multicast oraz IGMP, jeśli mają zastosowanie. Przełącznik może ograniczyć niepotrzebne zalewanie sieci i poprawić obserwowalność, ale nie utworzy dodatkowych zasobów połączeń sterownika. Podobnie dodanie przełącznika niezarządzalnego zwiększa liczbę portów, a nie możliwości sterownika.

Metodycznie diagnozuj podejrzenie problemu z wydajnością

Najpierw potwierdź działający projekt, numer katalogowy sterownika, wersję oprogramowania sprzętowego i topologię sieci. Następnie porównaj skonfigurowane połączenia z bieżącą diagnostyką. Szukaj modułów I/O przełączających się między stanem pracy a błędem, instrukcji MSG przekraczających czas oczekiwania przy szczytowym obciążeniu lub wartości HMI, które stają się nieaktualne, mimo że logika sterownika nadal jest wykonywana.

Zmieniaj jedną zmienną naraz. Odłącz zatwierdzonego klienta niekrytycznego, wstrzymaj niekrytyczną usługę odpytywania lub tymczasowo uruchamiaj komunikaty sekwencyjnie podczas kontrolowanego okna serwisowego. Jeśli objaw się zmieni, zmierz obciążenie przed i po zmianie, zamiast uznawać problem za rozwiązany na podstawie jednej spokojnej godziny. Nigdy nie wydłużaj limitów czasu ani nie wyciszaj alarmów komunikacyjnych wyłącznie po to, aby ukryć przeciążenie.

Uruchamiaj rozbudowę wraz z testami awaryjnymi

Przed dodaniem urządzenia określ typ połączenia, wymagania dotyczące aktualizacji, osobę odpowiedzialną oraz reakcję na awarię. Przetestuj normalną produkcję i najgorsze wiarygodne zapotrzebowanie występujące jednocześnie. Odłącz nowe urządzenie, przywróć je, wyłącz i włącz jego zasilanie sieciowe oraz potwierdź, że sterownik, HMI i alarmy rozróżniają nieprawidłowe lub nieaktualne dane od prawidłowego stanu procesu. Sprawdź, czy przywrócenie połączenia nie spowoduje nieoczekiwanego ponownego uruchomienia urządzeń.

Dołącz wykaz, migawki diagnostyczne, konfigurację przełączników i wyniki odbioru do kopii zapasowej systemu sterowania. Aby zapoznać się z aktualnymi opcjami sprzętowymi, odwiedź systemy PLC i PAC; zarządzalne przełączniki i komponenty sieciowe znajdziesz w kolekcji komunikacji i sieci. Wniosek redakcyjny jest prosty: rozbudowa L35E jest uzasadniona tylko wtedy, gdy udokumentowano jej zmierzone obciążenie szczytowe, zachowanie w przypadku awarii oraz plan dotyczący cyklu życia.