Diagnostyka PLC: zapis przed resetem
Pierwszy alarm, warunki blokujące sekwencję i stan komunikacji. Jak zebrać informacje potrzebne do diagnozy powtarzającego się zatrzymania.
Po resecie alarmu część informacji o zatrzymaniu może już nie być widoczna. Jeżeli warunki na to pozwalają, najpierw zapisz komunikaty, czas wystąpienia i krok sekwencji. Nie zmieniaj nastaw ani programu tylko po to, żeby sprawdzić, czy błąd zniknie. Przy awarii powracającej po kilku godzinach krótki zapis wykonany w momencie zatrzymania bywa bardziej przydatny niż długa obserwacja maszyny, która akurat działa poprawnie.
Alarm to wskazówka, nie gotowa diagnoza
Kilka komunikatów może dotyczyć tego samego zdarzenia. Brak potwierdzenia z urządzenia może poprzedzać alarm czasu kroku, a zatrzymanie napędu wywołać kolejne meldunki. Zacznij od kolejności wystąpienia, nie od najbardziej ogólnego napisu na HMI. Historia alarmów pokazuje zdarzenia, których nie ma już na liście aktywnych komunikatów. Zapisz zarówno pojawienie się, jak i ustąpienie istotnych alarmów.
Sprawdź, czy PLC, HMI i urządzenia korzystają z porównywalnego czasu. Dwa wpisy z różnych zegarów nie muszą przedstawiać rzeczywistej kolejności. Do materiału dołącz produkt, recepturę, tryb pracy i ostatnie działanie operatora. Przy usterce sporadycznej ważna jest także informacja, czy wcześniej zmieniano program, czujnik, okablowanie lub parametry napędu. Numer alarmu bez tego kontekstu zwykle nie wystarcza.
Gdzie zatrzymała się sekwencja
Ustal aktywny krok i warunki jego zakończenia. Rozdziel warunek zezwalający na start, często nazywany permissive, od blokady działania, czyli interlocku. Nazwy i dokładne zachowanie zależą od projektu. Potrzebna jest lista konkretnych warunków oraz ich stan w momencie awarii. Sam zbiorczy bit „gotowy” nie mówi, który element uniemożliwił przejście do następnego kroku.
Porównaj polecenie, potwierdzenie urządzenia i czas oczekiwania. Jeżeli polecenie nie zostało wydane, trzeba wyjaśnić warunki logiki przed oceną urządzenia wykonawczego. Jeżeli zostało wydane, sprawdzenie dotyczy odpowiedzi oraz jej interpretacji. Nie omijaj interlocków i nie wymuszaj wyjść jako sposobu poszukiwania przyczyny. Diagnostyka powinna zachować wymagane zabezpieczenia oraz uzgodnione zasady pracy przy maszynie.
Sygnały DI, DO i wartości analogowe
Dla wejścia cyfrowego porównaj opis sygnału, adres i jego stan w programie. Rozróżnij brak fizycznego potwierdzenia od użycia niewłaściwego adresu albo odwróconej logiki. Przy wyjściu sprawdź, jaki warunek powoduje wydanie polecenia oraz gdzie program je cofa. W sekwencji z kilkoma miejscami zapisu tego samego sygnału końcowy stan nie wyjaśnia jeszcze, dlaczego polecenie było krótkie.
W sygnale analogowym liczy się nie tylko aktualna liczba. Sprawdź jednostkę, zakres, skalowanie i status kanału. Wartość bliska progowi alarmu może zmieniać się inaczej niż sugeruje pojedynczy odczyt z panelu. Trend pozwala porównać przebieg z momentem zatrzymania. Nie przesuwaj progu, żeby wyciszyć komunikat, zanim zostanie wyjaśnione, czy zmienił się proces, pomiar czy sposób przeliczenia danych.
Komunikacja i dane, które przestały się zmieniać
Zielony status połączenia nie jest pełną informacją o urządzeniu. Sprawdź diagnostykę sterownika, modułu i partnera komunikacyjnego oraz aktualność danych używanych przez sekwencję. Zachowana ostatnia wartość może wyglądać prawidłowo, chociaż nie pochodzi już z bieżącego cyklu. Warto ustalić, jak program rozpoznaje brak odpowiedzi i co robi po przywróceniu połączenia.
Gdy awaria jest krótka, zapisuj wybrane stany komunikacji wraz z krokami i potwierdzeniami. Dobierz odstęp próbkowania do zdarzenia i opisz znaczniki czasu. Odczyt online po kilku minutach może pokazać już stan po odzyskaniu połączenia. Nie traktuj braku błędu podczas późniejszej obserwacji jako dowodu, że komunikacja nie uczestniczyła w zatrzymaniu. Oddziel obserwację od hipotezy w notatce diagnostycznej.
Przed resetem i przed zmianą
Reset wykonuje się według procedury maszyny, po ocenie jej stanu. Wielokrotne kasowanie alarmu bez zapisu może usunąć ślad powtarzającego się problemu. Jeśli maszyna po resecie rusza, potwierdza to możliwość wznowienia, a nie usunięcie przyczyny. Nie zwiększaj w ciemno czasu oczekiwania, ponieważ może on również sygnalizować uszkodzenie urządzenia lub brak warunku procesu.
Przed poprawką zabezpiecz aktualną wersję projektu i ustal test obejmujący warunki awarii oraz funkcje objęte zmianą. Zakres serwisu i diagnostyki powinien wynikać z zebranych informacji. Jeżeli potwierdzono problem w logice, modyfikacja PLC jest kolejnym, opisanym krokiem, a nie próbą zastąpienia diagnostyki serią przypadkowych zmian.
Co przygotować do zgłoszenia
Pomocny zestaw obejmuje:
- zdjęcie alarmu i fragment historii z czasem zdarzenia
- typ PLC i HMI oraz informację o dostępnej kopii projektu
- krok sekwencji, produkt i okoliczności zatrzymania
- ostatnie zmiany i działania podjęte po awarii
- warunki dostępu do instalacji oraz dopuszczony sposób odczytu.
Taki materiał pozwala ustalić następne sprawdzenie i potrzebny udział personelu na obiekcie. Jeżeli danych brakuje, lepiej wskazać je wprost niż opisywać niepotwierdzoną przyczynę jako ustaloną.