Główne kody usterek Allen-Bradley: jak je odczytywać, kasować i im zapobiegać

Najważniejsze wnioski: W sterownikach Allen-Bradley Logix (ControlLogix, CompactLogix) awaria krytyczna zatrzymuje program i powoduje, że wskaźnik OK/FAULT sterownika przechodzi w stan błędu. Każda awaria krytyczna ma Typ i Kod (np. Typ 4 = błąd programu, z kodami dla błędów takich jak indeks tablicy poza zakresem).

Zakładka „Major Faults” we Właściwościach sterownika w Studio 5000 pokazuje rekord; błędy możliwe do odzyskania można tam wyczyścić lub obsłużyć automatycznie za pomocą rutyny obsługi błędów, więc pojedynczy zły indeks tablicy nie musi zatrzymywać całej linii.

Typy błędów, które rzeczywiście napotkasz

• Typ 1: błędy przy włączaniu zasilania, sterownik zgłosił błąd podczas uruchamiania (często handler uruchamiania jest skonfigurowany tak, aby celowo zgłaszał błąd, żeby proces nie restartował się bez nadzoru).
• Typ 3: błędy I/O, wymagane połączenie I/O zawiodło, gdy błąd był skonfigurowany jako krytyczny (np. brak modułu, nieaktywny węzeł sieci).
• Typ 4: błędy wykonywania programu, główna kategoria: indeks tablicy poza zakresem, przepełnienie arytmetyczne, JSR do brakującej rutyny, nieprawidłowe dane instrukcji.
• Typ 6: watchdog, zadanie przekroczyło czas watchdog, zwykle po dodaniu ciężkiej logiki lub pętli do szybkiego zadania okresowego.
• Typ 7: błędy pamięci nieulotnej, zapis lub odczyt karty pamięci nie powiódł się.

Szczegółowa lista znajduje się w dokumentacji kodów błędów Rockwell; istotne jest odczytywanie pary (Typ, Kod), zamiast traktować „awarię” jako jednorodne zdarzenie.

Odczytywanie i usuwanie błędu

• 1. Połącz się online w Studio 5000 i otwórz Właściwości sterownika, zakładkę „Major Faults”. Zapisz typ, kod i tekst błędu, w tym który program i która rutyna zgłosiły błąd.
• 2. Usuń przyczynę: popraw logikę (sprawdź granice indeksu, zabezpiecz operacje arytmetyczne), przywróć połączenie I/O, wydłuż watchdog tylko jeśli zadanie tego naprawdę potrzebuje.
• 3. Wyczyść błąd z zakładki „Major Faults” (lub przełącz tryb zgodnie z lokalną procedurą) i przywróć sterownik do trybu Run, przestrzegając zasad restartu i bezpieczeństwa obowiązujących w Twoim zakładzie.

Rutyny obsługi błędów: obsłuż to bez zatrzymywania linii

Dla odzyskiwalnych błędów typu 4 Logix pozwala każdemu programowi mieć rutynę obsługi błędów: gdy wystąpi błąd, uruchamia się rutyna, może zalogować zdarzenie i wyczyścić rekord błędu, a wykonywanie programu jest kontynuowane. Użyte prawidłowo, zmienia to katastrofę zatrzymującą linię w zarejestrowane zdarzenie z alarmem.

Użyte niewłaściwie, cicho maskuje prawdziwe problemy, więc ZAWSZE rejestruj to, co zostało przechwycone (dane rekordu błędu) w miejscu przeglądanym przez człowieka i generuj alarm przy powtórzeniach. Program obsługi błędów na poziomie sterownika pełni tę samą rolę dla błędów o zasięgu całego sterownika.

Od logu błędów do danych o niezawodności

Każda awaria krytyczna to zdarzenie przestoju z precyzyjną, czytelną maszynowo przyczyną, co czyni je wartościowym źródłem danych do prac nad niezawodnością, jeśli opuszcza PLC. Rejestruj błędy z ich Typem i Kodem w zleceniach pracy w systemie CMMS, analizuj je w analizie przestojów i projektuj kody błędów tak, aby określały rzeczywiste przyczyny zamiast ogólnych kategorii.

Fabrico spina to wszystko na hali: zweryfikowane komputerowo OEE rejestruje zatrzymanie i jego czas trwania nawet gdy nikt tego nie zapisze, a zamknięty obieg w CMMS łączy błąd z naprawą, dostarczając rzetelnych danych MTTR i MTBF. Dla dyscypliny projektowania po stronie PLC zobacz nasz przewodnik po PLC w produkcji.

Najczęściej zadawane pytania

Jaka jest różnica między awarią krytyczną a niekrytyczną?
Awaria krytyczna zatrzymuje wykonywanie programu; błąd niekrytyczny rejestruje stan i wykonywanie jest kontynuowane. Ta sama przyczyna źródłowa może być zakwalifikowana jako jedna lub druga, w zależności od konfiguracji.

Błąd się czyści, ale ciągle wraca. Co dalej?
Przyczyna nadal występuje. Odczytaj z rekordu błędu odniesienie do programu i rutyny i napraw logikę lub połączenie, które wskazuje; nie automatyzuj czyszczenia wokół nierozpoznanego błędu.

Czy każdy program powinien mieć rutynę obsługi błędów?
W programach, w których możliwy do odzyskania błąd danych nie powinien zatrzymać maszyny, tak, z logowaniem i alarmowaniem. Logika związana z bezpieczeństwem podlega odrębnym standardom i nigdy nie powinna być „wyczyszczona i kontynuowana” lekkomyślnie.

Aby zobaczyć, jak zweryfikowane wykrywanie zatrzymań i zamknięty obieg zadań serwisowych przekształcają logi błędów PLC w usprawnienia niezawodności, zarezerwuj demo.