Diagnostyka sterownika S7 – 300. Część 1 – wykrywanie błędów systemowych

| Technika

W procesie produkcyjnym błędne działanie zaprojektowanej aplikacji lub wręcz zatrzymanie się procesu technologicznego związane jest zwykle ze stratami ekonomicznymi, a w skrajnych przypadkach może stanowić zagrożenie dla zdrowia i życia ludzi. Sprawne wykrycie usterki i uruchomienie zatrzymanej awarią maszyny lub instalacji to niebagatelne wyzwanie dla służb utrzymania ruchu, zważywszy na stres i ograniczenia czasowe. Złożoność dzisiejszych systemów automatyki wymaga od inżynierów sprawnego posługiwania się dostępnymi narzędziami programowymi do obsługi systemów sterowania.

Diagnostyka sterownika S7 – 300. Część 1 – wykrywanie błędów systemowych

W prezentowanym artykule zostaną przedstawione podstawowe funkcje sterowników programowalnych PLC Simatic firmy Siemens, które umożliwiają przeprowadzenie testów diagnostycznych. Ich dobra znajomość pozwala na szybką reakcję, próbę poprawy działania aplikacji oraz skrócenie czasu przestoju, co powoduje zmniejszenie strat i poniesionych kosztów związanych z zaistniałymi błędami.

Rys. 1. Współpraca jednostki centralnej (CPU) sterownika, modułu wejść/ wyjść i programatora (np. stacja PC) podczas wystąpienia zdarzenia diagnostycznego

Sterownik PLC stanowi jeden z elementów, którego praca powinna zostać dokładnie przeanalizowana zarówno podczas projektowania aplikacji, jak i w trakcie wystąpienia awarii maszyny lub błędów w procesie technologicznym. Jego diagnostyka polega na ocenie działania aplikacji zaprojektowanej na danym sterowniku, a funkcje diagnostyczne służą do rozwiązywania błędów powodujących jego nieprawidłowe działanie.

W sterownikach Simatic zaimplementowano wiele mechanizmów pozwalających na szybkie wykrywanie błędów. Dzięki temu proces diagnostyki staje się usystematyzowany zarówno na poziomie testów, jak i już działającej aplikacji. W artykule opisano podstawowe procedury diagnozowania błędów sterownika PLC S7- 300 z wykorzystaniem środowiska STEP 7.

Kategorie błędów

Błędy występujące w systemie sterowania możemy podzielić na dwie kategorie w zależności od miejsca ich powstania:

  • Błędy systemowe - są identyfikowane przez system operacyjny sterownika PLC i sygnalizowane stanem diod na CPU. W momencie wystąpienia błędu CPU może przejść w tryb Stop i przerywa wykonywanie programu sterowania. Błędy systemowe mogą mieć źródło wewnętrzne lub zewnętrzne. Źródłem wewnętrznym błędów systemowych są stany nieprawidłowe, zlokalizowane w obrębie samej jednostki CPU - np. utrata komunikacji ze zdalną kasetą I/ O, wykonanie przez program użytkownika niedozwolonej operacji matematycznej, przekroczenie czasu cyklu CPU, zaadresowanie przez program nieistniejącego obszaru pamięci lub wywołanie nieistniejącej funkcji. Źródłem zewnętrznym są usterki zlokalizowane poza samą jednostką centralną np. w modułach I/O, poszczególnych kanałach modułów I/O lub np. w zasilaniu CPU i modułach I/O. Błędy systemowe są stosunkowo łatwe do zlokalizowania, ponieważ istnieje możliwość podłączenia komputera z oprogramowaniem narzędziowym do sterownika PLC.
  • Błędy funkcjonalne - w tym przypadku CPU przetwarza program sterowania, jednak zaprogramowana przez użytkownika funkcja nie jest w całości przetwarzana lub jest przetwarzana błędnie. Występują dwa typy błędów funkcjonalnych:
    • Błędy procesowe - są identyfikowane jako nieprawidłowe funkcjonowanie odpowiednich elementów systemu sterowania m.in. okablowania czujnika/elementu wykonawczego lub uszkodzenie czujnika/elementu wykonawczego. Są to błędy generowane przez program użytkownika w wyniku analizy przez algorytm sterujący informacji z czujników, stanów wewnętrznych i sekwencji zdarzeń programu. W poprawnie skonstruowanym systemie sterowania błędy tej kategorii powinny być dokładnie identyfikowane i lokalizowane. Informacja o zaistnieniu, czasie i miejscu zdarzenia powinna być wyświetlana na panelach operatorskich, systemach wizualizacji lub tablicach synoptycznych.
    • Błędy logiczne programu - są to błędy programowe, które nie zostały zidentyfikowane podczas pisania oraz uruchomienia programu i nieobsłużone przez mechanizm alarmów procesowych użytkownika. Przykładowo może to być dwukrotne wysterowanie wyjścia w programie, złe adresowanie wejść/wyjść, itp.

TABELA 1. Symbole diagnostyczne opisujące jednostkę centralną lub moduł funkcyjny

TABELA 2. Symbole diagnostyczne opisujące tryb pracy CPU

Wykrycie i lokalizacja błędów funkcjonalnych, nieobsłużonych prawidłowo w programie użytkownika jest trudna i wymaga oprócz sprawnego posługiwania się oprogramowaniem również dokładnej znajomości procesu technologicznego i schematu elektrycznego. Z punktu widzenia sterownika PLC błędy funkcjonalne nie są traktowane jako usterka, stąd też nie są sygnalizowane stanem diod.

Reakcja CPU na błędy systemowe

Wystąpienie błędu systemowego w jednostce centralnej CPU prowadzi do następujących zdarzeń. Do listy informacji statusowych systemu (ang. SSL) wprowadzane są dane o zaistniałym zdarzeniu, takie jak czas i miejsce wystąpienia zdarzenia, typ zdarzenia (błąd synchroniczny/asynchroniczny, zdarzenie generowane przez program użytkownika, zmiana trybu pracy). Informacje diagnostyczne są archiwizowane w CPU i przechowywane w wewnętrznej strukturze danych zwanej buforem diagnostycznym.

Bufor diagnostyczny CPU jest zatem czarną skrzynką procesora i służy do przechowywania meldunków o kolejno zaistniałych i wykrytych przez CPU zdarzeniach. Liczba przechowywanych meldunków jest ograniczona i zależy od typu CPU (np. CPU 314 = 100 wpisów). Bufor diagnostyczny nie jest kasowany w momencie resetu pamięci CPU. Informacje na temat sekwencji wywołań bloków przed zaistnieniem zdarzenia oraz wartości rejestrów CPU i zmiennych lokalnych zapisywane są w tzw. stosach (ang. Stack).

Rys. 2. Edytor konfiguracji sprzętowej – diagnostyka modułów

System operacyjny CPU wywołuje blok programowy do obsługi wykrytego zdarzenia awaryjnego. Jest to jeden z bloków organizacyjnych OB, o konkretnym numerze np. OB86 (błąd komunikacji ze zdalną kasetą). Zmienne lokalne wywołanego bloku OB są wypełniane informacjami o zaistniałym zdarzeniu awaryjnym. W przypadku wspomnianego bloku OB86 będą to przykładowo: adres kasety, z którą CPU utracił komunikację, stan zdarzenia (przychodzące, odchodzące), data i czas zdarzenia.

W trakcie pracy sterownika mogą wystąpić zdarzenia generowane przez funkcje diagnostyczne modułów I/O, np. wykrycie braku zasilania obiektowego modułu, przerwania toru pomiarowego lub przekroczenie zakresu pomiarowego. Usterka w obrębie modułu I/O przekazywana jest do CPU w formie przerwania diagnostycznego. Sposób przetwarzania przerwań od modułów jest analogiczny jak w przypadku błędów systemowych i logicznych wykrytych przez diagnostykę jednostki centralnej.

Dodatkowe informacje diagnostyczne mogą pochodzić również z programu użytkownika. Są to zgłoszenia diagnostyczne generowane za pośrednictwem funkcji systemowych SFC52. Na rysunku 1 przedstawiony jest sposób diagnostyki błędów systemowych przez sterownik z modułem wejść/wyjść (modułem peryferyjnym) i komunikacja z programatorem. W przypadku nieobsłużenia przez program użytkownika danego zdarzenia diagnostycznego CPU przechodzi samoczynnie w tryb STOP.

Odczytywanie informacji o błędach systemowych

Dokładne informacje o błędzie i miejscu wystąpienia przerwania znajdują się w liście SSL, w buforze diagnostycznym i stosach I stack, B stack, L stack. Właściwe odczytanie powyższych danych umożliwia dokładną lokalizację i określenie przyczyny błędu. Informacje diagnostyczne mogą być odczytane zarówno za pośrednictwem oprogramowania narzędziowego Step 7, jak i przez funkcję systemową SFC51 w programie użytkownika. W artykule omówiono tylko sposób odczytu informacji diagnostycznych z poziomu oprogramowania narzędziowego.

Diagnostyka sprzętowa w edytorze HW Config

Najprostszym sposobem odczytania informacji diagnostycznych jest wykorzystanie edytora konfiguracji sprzętowej HW Config i widoku online. Dane pokazywane są w formie piktogramów i okienek. Za pomocą funkcji diagnostyki sprzętowej można odczytać informacje, między innymi o statusie lub trybie pracy modułu. Otwarcie edytora konfiguracji sprzętowej możliwe jest z poziomu głównego okna Simatic Manager. W tym celu w oknie ze strukturą projektu należy rozwinąć drzewo katalogowe i zaznaczyć wstawioną stację.

Rys. 3. Wywołanie okna Module Information z informacjami o CPU i modułach

W polu elementów wybrać Hardware, dwukrotnie klikając jego ikonę lub zaznaczając go i wybierając z menu głównego Edit -> Open Object. Spowoduje to otwarcie okna aplikacji HW Config, która służy do konfigurowania, parametryzacji i diagnostyki sprzętu (rys. 2). Uruchomienie trybu Online następuje po naciśnięciu przycisku Offline/Online znajdującego się w lewym górnym rogu edytora (rys. 2). W oknie aplikacji HW Config przy symbolach dodanych modułów znajdują się symbole diagnostyczne identyfikujące status modułu i tryb pracy CPU. Odpowiednie symbole i ich znaczenie zostały zebrane w tabelach 1 i 2.

Zobacz również