Sterownik PLC CPU czy moduł I/O: odróżnianie jednostek w szafie

Maszyna staje i pytanie ląduje na Tobie: która jednostka w tej szynie padła? Sterownik PLC CPU wykonuje cykl programu sterującego, zarządza połączeniem sieciowym i koordynuje każdy moduł zamontowany wokół niego. Moduł I/O nie robi nic z tego. Karta wejść cyfrowych raportuje do CPU sygnały z terenu, takie jak stany włączenia i wyłączenia czujników. Karta wyjść analogowych oddaje do terenu wartości zadane, jak zadana prędkość.

Powiększony schemat systemu

×

Strzałki pokazują podział pracy, nie okablowanie. CPU jest jedyną jednostką, która decyduje; moduły przenoszą sygnały tam i z powrotem.

To rozróżnienie brzmi podstawowo, dopóki ktoś nie musi zdecydować, która jednostka faktycznie padła, bo obie siedzą obok siebie na tej samej szynie i potrafią wyglądać podobnie. CPU jest jedyną jednostką, która wykonuje program; każda inna albo raportuje do niego sygnały z terenu, albo działa na jego polecenia. Ten podział pracy jest kotwicą wszystkiego, co dalej.

Rozróżnienie zmienia też to, co żądanie powinno zawierać. Martwa karta wejść to pytanie o źródło o niskiej stawce, gdy szafa dalej pracuje na pozostałych kanałach. Padnięty CPU stawia na szali program, tożsamość sieciową i strojenie maszyny. To inny problem dowodowy, choć obie jednostki siedzą w tej samej szynie. Żądanie o niskiej stawce nadal potrzebuje pełnego odnośnika, bo zła karta wejść przychodzi równie pewnie jak zły CPU.

Warto wiedzieć, czym jest cykl programu, bo cały podział pracy na nim wisi. CPU powtarza tę samą pętlę bez przerwy: odczytaj wejścia, wykonaj program, zapisz wyjścia. Pętla biegnie wiele razy na sekundę, a każdy moduł I/O uczestniczy w niej tylko jako źródło odczytów albo cel poleceń. Nic po stronie modułów niczego nie rozstrzyga; decyzje zapadają w CPU albo nigdzie.

Zachowanie przy awarii rozdziela role w praktyce. Padnięty CPU zwykle pociąga za sobą cały program i komunikację, więc maszyna staje jako całość, a panel HMI, ekran operatorski, traci połączenie. Padnięty kanał I/O często pokazuje się jako pojedyncza diagnostyka, więc jeden aktuator odpada, a reszta maszyny dalej pracuje w stanie ograniczonym.

Powiększony schemat systemu

×

Dwa wzorce zachowań, dwie listy podejrzanych. Zapisanie wzorca z datą pozwala później zweryfikować klasyfikację.

Zapisz, które zachowanie widziałeś, z datą i godziną. Oba wzorce mieszczą się w jednym zdaniu każdy i oba są mocniejszym dowodem niż wspomnienie zdarzenia. Nawet zgrubna datownica zawęża to, co recenzent później sprawdza. Zachowanie to najszybsza wskazówka klasyfikacyjna, jaką dostaniesz, i nic nie kosztuje, bo i tak patrzyłeś, jak się dzieje.

Żaden wzorzec nie jest sam w sobie dowodem rozstrzygającym. Awaria komunikacji może z zewnątrz wyglądać jak padnięty CPU, a problem okablowania może udawać martwy kanał wejść. Zapisane zachowanie zawęża listę; nie zamyka jej. Dlatego zachowanie trafia do zapisu obok klasyfikacji, nie zamiast niej.

Traktuj stan ograniczonej pracy z tą samą starannością co pełny postój. Maszyna, która dalej pracuje bez jednego kanału, nadal mówi Ci, która jednostka padła, ale też nadal produkuje części, więc presja każe odłożyć zapis do końca zmiany. Zapisz mimo wszystko jednozdaniową obserwację, bo stan ograniczony to dokładnie ten dowód, którego potrzebuje recenzent, i dokładnie ten detal, który zaciera się do końca zmiany.

Nazewnictwo rodzin daje pierwszą wskazówkę strukturalną. Numer zamówienia Siemensa 6ES7214-1AG40-0XB0 otwiera się blokiem 6ES7, a blok 214 wybiera CPU 1214C. Moduły sygnałowe w tej samej rodzinie S7-1200 niosą w tej pozycji inny blok cyfr. Przeczytaj drugi blok numeru zamówienia i sklasyfikujesz nieznany moduł szybciej niż jakąkolwiek zgadywanką o jego rozmiarze czy kolorze.

Powiększony schemat systemu

×

Jeden blok sortuje szynę. Zdjęcie zamienia klasyfikację w dowód, który recenzent może sprawdzić.

Ten blok się nie rusza, niezależnie od tego, który katalog czytasz, więc jest pewniejszy niż wygląd. Zrób zdjęcie tabliczki znamionowej każdego klasyfikowanego modułu, także modułów, których nie podejrzewasz, bo klasyfikacji, której nie pokazujesz później, po prostu nie ma. Zdjęcie zasili też pozycjonowany zapis, którego żądanie będzie potrzebować. Zanotuj pozycję w gnieździe obok odczytu, bo pozycja to połowa tego, co identyfikuje jednostkę.

Pozycja w gnieździe to też dowód, bo ten sam odnośnik może wystąpić dwukrotnie w jednej szynie, a projekt może adresować każde wystąpienie inaczej. Zdjęcie przeglądu szyny plus jedno zdjęcie etykiety na moduł pozwalają później odtworzyć cały zestaw bez drugiej wizyty w szafie. Odczyt bloku, gniazdo i zdjęcie pokrywają się na tej samej jednostce, i to czyni klasyfikację sprawdzalną.

Układ fizyczny dodaje potwierdzenie. CPU niesie port PROFINET, połączenie Ethernet, po którym biegnie sieć sterująca, a na CPU 1214C niesie też mały wyświetlacz statusu. Moduły sygnałowe pokazują rzędy zacisków na okablowanie terenowe i nie mają własnego interfejsu sieciowego. Port to mocna wskazówka, bo prawie żaden moduł I/O go nie ma.

Powiększony schemat systemu

×

Port i cel kabla pracują razem. Strzałki opisują metodę obserwacji, nie schemat sieci.

Odwrotny przypadek też się liczy: na stacji rozproszonego I/O zbudowanej wokół CPU 1510SP-1 PN (6ES7510-1SJ01-0AB0) moduły ET 200SP wokół CPU wyglądają podobnie i dzielą tę samą szynę. Tam niezawodnymi rozdzielaczami są port sieciowy i bloki numeru zamówienia, nie wygląd. Jedno spojrzenie załatwia to, czego numer części nigdy nie załatwi. Zrób zdjęcie portu i kabla w jednej klatce, gdzie się da, żeby widzieć cel bez drugiego zdjęcia.

Jeśli nie potrafisz powiedzieć, która jednostka steruje szyną, idź za kablem sieciowym. Moduł, którego port łączy się z laptopem inżynierskim, przełącznikiem sieciowym albo panelem HMI, to prawie zawsze CPU, bo moduły I/O nie mają niezależnej obecności w sieci. Odnotuj tę obserwację w zapisie razem z celem kabla. To dowód, zanim ktokolwiek odczyta jakąkolwiek tabliczkę.

Mały wyświetlacz statusu na niektórych CPU to trzecia wskazówka. Zwykle pokazuje słowo statusu albo krótką diagnostykę, a zdjęcie zrobione w momencie awarii to dowód stanu samego CPU, nie strony terenowej. Brak też coś mówi: jednostka z zaciskami, bez wyświetlacza i bez portu to niemal na pewno moduł I/O, niezależnie od tego, co sugeruje jej etykieta, a ta obserwacja nic nie kosztuje obok zdjęcia.

Wypisz CPU i każdy moduł I/O jako osobne pozycje z własnymi pełnymi numerami zamówień. Żądanie, które miesza je w jeden opis, zmusza recenzenta do zgadywania, która jednostka jest sterownikiem. Jedno złe zgadywanie marnuje cykl pozyskania części. Pozycje z pozycjami gniazd usuwają zgadywanie, a numer gniazda pochodzi wprost ze zdjęcia przeglądu szyny, więc oba zapisy podpierają się wzajemnie.

Powiększony schemat systemu

×

Trzy wejścia czynią żądanie sprawdzalnym: pozycje, dowody na pozycję i datowane zachowanie. Żadne nie wymaga drugiej wizyty w szafie.

Podaj zaobserwowane zachowanie przy awarii obok modułu, którego podejrzewasz. Które kanały odpadły, czy HMI zostało połączone, czy usterka się powtarza: po jednej linii na każde pytanie daje recenzentowi coś, względem czego może sprawdzić klasyfikację. Ten kontekst kosztuje jedną linię zapisu i oddziela użyteczne żądanie od listy części. Pozycja, której nie da się prześledzić do zdjęcia, to twierdzenie, a twierdzenia to dokładnie to, przed czym ten zapis ma chronić.

Gotowa lista chroni żądanie, jeśli klasyfikację później się podważy. Każda linia niesie własny dowód: odczyt bloku, obserwację portu, zdjęcie i zachowanie. Recenzent może wtedy potwierdzić albo poprawić jedną linię bez otwierania całej szafy od nowa, i to właśnie utrzymuje przestój krótko.

• Drugi blok numeru zamówienia klasyfikuje moduł; 214 oznacza CPU 1214C.
• Idź za kablem sieciowym, żeby znaleźć sterownik. Moduły I/O nie mają własnego portu.
• Wypisuj odnośniki CPU i I/O jako osobne pozycje z pozycjami gniazd.
• Zanotuj zachowanie przy awarii: zatrzymanie całej maszyny i usterka jednego kanału wskazują różne jednostki.

• hub odnośników sterowników PLC i CPU
• jak odczytać pola tabliczki znamionowej
• lista dowodów do odzyskiwania aplikacji fail-safe