Jedną z praktycznych różnic między programem uruchomionym w symulacji a programem uruchomionym na rzeczywistym obiekcie jest to, że w symulacji część „fizyczna” nie ulega uszkodzeniom. Moduły są zawsze sprawne, a komunikacja między elementami jest bezstratna. Upraszcza to pisanie programu, ponieważ programista, który nie miał wcześniej do czynienia z awariami po stronie sprzętowej lub nie narzucono mu wymogu diagnostyki, pomija bloki odpowiedzialne za diagnozowanie sterownika i jego komponentów. Takie postępowanie utrudnia określenie miejsca awarii oraz jej przyczyny.
Z pomocą przychodzi wbudowany w TIA Portal v16 blok: Diagnostic error interrupt, OB82. Jest to blok programowy, który wywołuje zapisany w nim program podczas zmiany stanu sterownika lub jego modułów. Poprzez zmianę stanu rozumiemy, że sterownik zatrzymałby się w wyniku awarii lub awaria została usunięta. Dzięki temu mamy możliwość nie tylko wykrycia awarii, ale także mamy informację o jej usunięciu.
Zastosowanie bloku OB82 wiąże się ze zmianą funkcjonowania sterownika. Domyślnie PLC po wykryciu błędu zostaje zatrzymany. Od teraz nie zatrzyma się, a zamiast tego wykona program zawarty w Diagnostic error interrupt block. Przenosi to problem zabezpieczenia maszyny/linii na programistę, który musi uwzględnić możliwe awarie.
Chcąc wykorzystać możliwości bloku OB82, musimy najpierw przygotować nowy projekt albo otworzyć już gotowy. Na potrzeby tego artykułu oraz w celu lepszego pokazania możliwości płynących ze stosowania diagnostyki, wykorzystałem sterownik firmy Siemens S7-1500 1513-1 PN oraz moduły cyfrowych wejść i wyjść, DI 32x24VDC HF i DQ 32x24VDC/0.5A ST. Nie oznacza to, że pokazane niżej przykłady znajdują zastosowanie tylko dla sterowników serii S7-1500, ponieważ można je wykorzystać także z innymi rodzinami np. S7-1200. Ważne jest, żeby moduły, które chcemy diagnozować, miały wbudowaną taką możliwość, bo niestety nie wszystkie na to pozwalają.
Kolejną rzeczą, którą musimy wykonywać za każdym razem, gdy dodajemy nowy moduł do sterownika, jest konfiguracja zakresu informacji, które moduł będzie wysyłać do PLC. Zaczynamy od modułu wejść cyfrowych. Otwieramy okno właściwości naszego modułu i widzimy poniższy rysunek.
Mamy do wyboru dwie opcje: No supply voltage L+ oraz Wire break. Pierwsza jest odpowiedzialna za zanik zasilania wejść modułu, druga odpowiada za przerwanie przewodu, podczas gdy do wejść jest podłączony enkoder. Wybór którejkolwiek z opcji spowoduje, że wszystkie wejścia modułu będą sprawdzane pod względem dostępu do zasilania lub poprawnego połączenia z enkoderem.
Dzieje się tak, dlatego że w pokazany sposób tworzymy wzorzec, wedle którego będą konfigurowane wszystkie wejścia, które domyślnie są ustawione właśnie na korzystanie ze wzorca. Jest to szybkie skonfigurowanie dużej ilości wejść, które nie wymaga dużego nakładu mozolnej pracy. Wadą jest potrzeba obsługi informacji stanu wszystkich wejść. Chcąc skonfigurować tylko jedno wejście, możemy zmienić źródło ustawień ze wzorca (template) na ręczne (manual), według poniższego rysunku. Możemy tak ustawić dowolne wejście.
Ważne jest, żeby po wprowadzeniu zmian dotyczących diagnostyki, wgrywać nie tylko sam program, ale też konfigurację hardware. W przeciwnym wypadku wprowadzona przez nas konfiguracja nie zadziała.
Mając tak skonfigurowany moduł, przechodzimy do dodania bloku diagnostycznego.
Jedyną ważną rzeczą, na którą należy zwrócić uwagę podczas dodawania bloku, jest język, w jakim będziemy pisać zawarty w nim program. W naszym przypadku jest to LAD.
Po otwarciu bloku widzimy powyższy rysunek. OB82 posiada wejścia, do których są dostarczane dane diagnostyczne i dzięki temu programista ma do nich dostęp.
IO_State – Za pomocą wartości zmiennej WORD opisuje stan PLC oraz jego modułów. Poszczególne bity tej zmiennej przyjmują wartości 0 i 1 w zależności od stanu sterownika i według poniższej rozpiski.
LADDR – Zmienna typu HW_ANY, która zawiera informację o adresie urządzenia, które zgłosiło problem. Dzięki niej wiemy, który spośród wielu (więcej niż jeden) modułów zgłasza awarię.
Channel – Zmienna typu Uint, która informuje o tym, który kanał zgłasza problem. Mówiąc bardziej zrozumiale, informuje ona które wejście (albo wyjście) jest np. niezasilone.
MultiError – Zmienna typu bool, informuje, jeśli wystąpi więcej niż jeden błąd w danym module. Do obsługi takiej ilości danych wygodnym rozwiązaniem jest utworzenie bloku danych „Data block”.
Mając Data block, przygotujmy jego zawartość zgodnie z poniższym rysunkiem.
Nazwy zmiennych w bloku nie muszą się pokrywać z nazwami zmiennych w OB82, ale typy danych już tak. Przystąpmy teraz do napisania prostego programu, który będzie nas informował o stanie układu.
Instrukcje MOVE pozwalają na przepisanie danych wejściowych do bloku danych. Teraz przejdźmy do trybu ONLINE z włączonym podglądem programu i sprawdźmy, czy wszystko jest poprawnie połączone.
Jak widzimy powyżej, sterownik nie wykrył żadnych błędów. Teraz popsujmy układ i zobaczmy, co się stanie.
Wyżej (rys. 14) został pokazany układ połączeń, który pomoże zrozumieć cechę diagnozowania wybiorczych wejść/wyjść. Jak widzimy, wejścia są zasilane grupami po 16 na jedno złącze L+. Odłączamy więc zasilanie całej grupie i widzimy następującą rzecz.
Tylko jedno wejście sygnalizuje problem, mimo że odłączone jest ich 16. Dlatego też wybór wejść diagnozowanych jest istotny i powinien być dokonywany rozważnie zależnie od potrzeb. Zobaczmy więc, co pokaże nam nasz program.
Otrzymaliśmy informację o problemie w formie graficznej oraz w formie liczbowej. Dla ułatwienia zmieńmy zapis wartości IO_State z szesnastkowego na dwójkowy. Powstaje nam zapis 10000 w kodzie binarnym. Bity liczymy od zerowego od lewej strony. Teraz przyda nam się wiedza z tabeli (rys 9). Wyszukujemy co oznacza ‘1’ na bicie czwartym.
Oznacza ona wystąpienie błędu, a to z kolei jest informacją dobrą, ale nie konkretną. Analizujemy pozostałe dane:
LADDR = 257, błąd występuje w module o tym adresie, czyli w naszym przypadku moduł wejść cyfrowych,
Channel = 3, błąd występuje na kanale nr 3, czyli wejście trzecie,
MultiError = 0, jest to jedyny błąd. Dla pełnego wglądu w sytuację sprawdźmy co powie nam standardowa opcja diagnozowania w TIA Portal.
Jak widzimy, pokrywa się ona w 100% ze wcześniejszymi wynikami. Skoro znamy usterkę, naprawmy ją i sprawdźmy co się zmieni. Pamiętamy, że blok OB82 reaguje na zmianę stanu sterownika, czyli nie tylko na wykrycie błędu, ale także na jego usunięcie.
Jak widzimy, otrzymaliśmy kod IO_State = 1, czyli zgodnie z tabelą, wszystko jest połączone poprawnie i nie występują żadne błędy.
Sprawdźmy jeszcze co oferuje nam drugi moduł.
Do dyspozycji mamy znaną nam już opcję wykrycia zaniku zasilania dla grupy wyjść oraz Short circuit to ground, czyli wykrycie zwarcia wyjścia do masy układu. Wynika z tego, że każdy moduł ma własne zabezpieczenia informujące o aktualnym (niebezpiecznym) stanie.
Popsujmy więc oba moduły i sprawdźmy co się stało.
Otrzymaliśmy informację o braku zasilania wejścia 3, modułu 257 (wejściowego) i brak MultiError’a. Mimo że widzimy błędy na dwóch modułach, MultiError odnosi się tylko jednego i nie informuje o uszkodzeniach kilku urządzeń, ale o uszkodzeniach jednego urządzenia o danym adresie. Trzeba o tym pamiętać podczas obsługi danych diagnostycznych.
Naprawiamy więc usterkę modułu wyjściowego i modyfikujemy parametry modułu wejściowego. Dodatkowo nie naprawiamy zasilania modułu wejść.
Teraz wystąpił wartość MultiError = 1, a więc wystąpiło kilka uszkodzeń z jednym module.
Podsumowanie
Blok OB82 wprowadza wiele możliwości do zautomatyzowania obsługi błędów modułów, jak i samego sterownika. Pokazane przykłady były proste i niezbyt praktyczne, bo miały jedynie pokazać obsługę błędów i informacje, jakie dostarczają. Programista chcąc przystosować program pod konkretne środowisko wykorzysta np. wystąpienie zwarcia wyjścia do wyłączenia pobliskich urządzeń, a nawet całej linii, jeśli wystąpi taka potrzeba. Uszkodzenie połączenia enkodera z PLC może wyłączyć silnik, a poważna awaria wielu modułów może załączyć program awaryjny, syrenę, sygnalizację świetlną bądź inne urządzenia. Mając wiedzę z zakresu obsługi bloku diagnostycznego, dochodzi podczas projektowania całej aplikacji nowy czynnik, którym jest zakres danych diagnostycznych określonych modułów.