Diagnostyka sterowników S7 300

Object 1 Diagnostyka sterowników S7 300 Wykrywanie błędów systemowych 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, ograniczenia zważywszy czasowe. na Złożoność stres i dzisiejszych systemów automatyki wymaga od inżynierów sprawnego posługiwania się dostępnymi narzędziami programowymi do obsługi systemów sterowania. 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. 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.

Rys. 1. Współpraca jednostki centralnej (CPU) sterownika, modułu wejść/ wyjść i programatora (np. stacja PC) podczas wystąpienia zdarzenia diagnostycznego 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 aplikacjihw 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. Szczegółowa informacja diagnostyczna o CPU i modułach Dwukrotne kliknięcie symbolu modułu w aplikacji HW Config otwiera okno Module Information z informacjami diagnostycznymi na temat błędnie działającego CPU lub modułu (rys. 3). Okno to wywołać można z następujących lokalizacji: W Simatic Manager - poprzez wybór opcji PLC -> Diagnose Hardware w oknie Online view i dwukrotne kliknięcie ikony Hardware wybranej stacji, w HW Config poprzez otwarcie stacji w trybie Online. Poprzez wybranie opcji Options -> Customize -> View w Simatic Manager i aktywacji funkcji Display Quick View when Diagnosing Hardware zostanie wyświetlona lista błędnych modułów w oknie Hardware Diagnostics. Jednostka centralna sterownika PLC ma wbudowane systemowe funkcje diagnostyczne. Nie wymagają one żadnej konfiguracji i programowania przez użytkownika. Taka diagnostyka umożliwia szybką identyfikację, lokalizację oraz późniejszą eliminację błędów. W przypadku jednostki centralnej CPU informacja o module jest znacznie bardziej rozbudowana. Okno z informacjami o systemie jest uruchamiane za pomocą funkcji:plc -> Module Information (rys. 3).

Tab. 3. Rodzaje błędów asynchronicznych obsługiwanych przez bloki organizacyjne Dostęp do niej możliwy jest również z poziomu aplikacji Simatic Manager lub edytorów (np. edytor STL/ LAD/FBD). Aplikacja Module Information odczytuje z podłączonego modułu dane diagnostyczne, które grupowane są w określonych zakładkach. Są to: General - zawiera podstawowe informacje o module, zainstalowanych wersjach hardware i firmware Diagnostic Buffer - zawiera wszystkie zdarzenia diagnostyczne; w trakcie szukania błędów, po sprawdzeniu meldunków, kolejnym krokiem powinna być właśnie analiza zdarzeń, które są tu pogrupowane w formie listy z opisem tekstowym wyjaśniającym miejsce powstania zdarzenia Memory - zawiera wielkość i wykorzystanie pamięci Load EPROM, Load RAM oraz pamięci Work Scan Cycle Time - czasy cyklu wykonania programu: najkrótszy, najdłuższy oraz aktualny/ostatni Time System - wyświetla zegar czasu rzeczywistego i zintegrowane czasy pracy Performance Data - zawiera informacje o zintegrowanych blokach systemowych, możliwe do przesłania bloki organizacyjne oraz wielkość obszarów adresowania (I, Q, M, T, C, L)

Communication - wyświetla możliwości komunikacyjne interfejsów oraz zajętość tych połączeń Stacks - wyświetla zawartość stosów: I Stack, B Stack i L Stack. Można je analizować w przypadku, gdy CPU jest w trybie Stop lub jest aktywna funkcja breakpoint. Jest to kolejny, ważny element wyszukiwania błędów systemowych Bufor Diagnostyczny Bufor diagnostyczny (zakładka Diagnostic Buffer aplikacji Module Information) jest to obszar pamięci podtrzymywany bateryjnie lub kondensatorem. Przechowuje on wszystkie zdarzenia diagnostyczne w kolejności wystąpienia ich w systemie. Bufor diagnostyczny nie jest kasowany przy wykonaniu funkcji kasowania pamięci CPU. Wszystkie zdarzenia występujące w tym buforze są wyświetlane w programatorze z opisami tekstowymi (rys. 3). Tab. 4. Rodzaje błędów synchronicznych obsługiwanych przez bloki organizacyjne Po wybraniu określonego zdarzenia w polu Details on Event znajdującym się pod listą wyświetlana jest szczegółowa informacja o zaistniałym zdarzeniu - jego ID, numer zdarzenia, typ i numer bloku oraz dodatkowe informacje zależne od zdarzenia, takie jak adres linii STL, w którym wystąpiło zdarzenie. Dodatkowe pomocnicze informacje o zdarzeniu można wywołać za pomocą przycisku Help on event. Możliwe jest także przejście do bloku, w którym wystąpiło przerwanie, poprzez kliknięcie Open block. Blok zostanie otwarty w trybie online. W języku STL kursor edytora ustawia się w pozycji bezpośrednio przed instrukcją generującą błąd. W przypadku języka LAD/FBD wyświetlana jest linia (network) zatrzymania przetwarzania programu.

Bloki organizacyjne do obsługi błędów Z błędami systemowymi powiązane są specjalne bloki organizacyjne, w których użytkownik/programista może umieścić swój program do obsługi określonej usterki. Bloki organizacyjne wywoływane są w następstwie wykrycia przez CPU tzw. błędów asynchronicznych lub synchronicznych. Błędy asynchroniczne są związane z problemami w funkcjonowaniu sterownika, które mogą pojawić się w dowolnym miejscu programu, tak więc są asynchroniczne względem jego wykonywania. Spis bloków związanych z błędami asynchronicznymi znajduje się w tabeli 3. Błędy synchroniczne są synchroniczne względem wykonywanego programu, czyli występują stale w tym samym miejscu programu użytkowego. One także mogą być obsłużone przez odpowiednie bloki organizacyjne z tabeli 4. Analiza stosów W przypadku błędów synchronicznych (OB 121, OB 122) ma sens wyświetlenie dodatkowych informacji o tym, co było powodem powstania błędu i zatrzymania przetwarzania programu. Takie informacje przechowywane są w stosach (I stack, B stack, L stack). Aby informacje zostały zapisane w stosach, CPU musi przejść w tryb STOP. Może się to zdarzyć tylko wtedy, gdy wystąpił błąd programowy, programowe przełączenie w tryb STOP (poprzez funkcję SFC) lub została załączona funkcja breakpoint. Stos B (B stack) - nazywany stosem bloków, jest podstawowym stosem widocznym w zakładce Stacks okna Module Information (rys. 3). Stos B zawiera listę wywoływanych bloków, które zostały otwarte w momencie przejścia CPU w tryb Stop, i jest przedstawiany w postaci graficznej hierarchii wywołań bloków do momentu zatrzymania przetwarzania programu. Podczas analizy stosu B należy zwrócić uwagę na blok umieszczony na końcu listy, ponieważ zostało w nim zatrzymane przetwarzanie programu. Stos B zawiera zatem listę wszystkich przerwanych bloków, bloki OB błędów oraz otwarte bloki DB. W celu otwarcia bloku online należy otworzyć stos B, następnie wybrać blok z listy oraz otworzyć edytor przyciskiem Open Block. W edytorze kursor od razu ustawi się w miejscu zatrzymania programu. Może być także potrzebna dokładniejsza analiza kolejnych bloków, ponieważ bloki są często w różnych miejscach wywoływane w programie sterowania. Informacja, która instrukcja i w jakim bloku przerywa przetwarzanie programu, nie wystarcza do znalezienia miejsca powstania błędu.

Stos I (I Stack) - jest nazywany także stosem przerwań. Stos przerwań przechowuje informacje o przerwaniach w odniesieniu do poziomu wykonywania przetwarzania programu. Otwiera się go w zakładce Stacks, zaznaczając odpowiedni blok organizacyjny w stosie B i klikając I Stack (rys. 4). Stos I zawiera wartości rejestrów systemowych w momencie wystąpienia przerwania. W polu Register Values and the Point of Interruption znajduje się zawartość akumulatorów i rejestrów adresowych oraz zawartość słowa statusu (bity 0 do 7). Za pomocą listy Display Format można wybrać format liczby do wyświetlenia zawartości akumulatorów i rejestrów adresowych. W polu Point of Interruption znajdują się informacje, jakie bloki danych zostały otwarte, jaki był przetwarzany program (np. OB 1 lub OB 10), informacja o bloku, w którym wystąpiło przerwanie z opcją bezpośredniego otwarcia oraz informacja o następnym przetwarzanym bloku. W tym oknie są wyświetlane bity 0 do 7 słowa statusu. Stos L (L Stack) - nazywany jest także stosem lokalnym. Otwiera się go w zakładce Stacks, zaznaczając odpowiedni blok organizacyjny w stosie B i klikając przycisk L Stack (rys. 4). W stosie L znajdują się wartości zmiennych tymczasowych niedokończonych w momencie przerwania dla całego bloku przedstawione w formacie szesnastkowym. Bloki niedokończone w momencie przejścia CPU w tryb STOP znajdują się w liście stosu bloków (B Stack). Rys. 4. Podgląd stosów B stack, I stack, L stack

Znajomość i umiejętne zastosowanie funkcji diagnostycznych znacznie ułatwia wykrycie i eliminację błędów aplikacji. W artykule opisano rodzaje błędów, jakie mogą wystąpić podczas pracy sterownika PLC Simatic firmy Siemens. Dokonano podziału na błędy systemowe i funkcjonalne. Opisano również sposób pracy z aplikacjami diagnostycznymi środowiska Step 7 pomagającymi w identyfikacji błędów systemowych. Są to podstawowe elementy diagnostyki sterownika, ponieważ już na etapie pracy CPU można dokładnie zidentyfikować zaistniałe problemy i je wyeliminować. W kolejnym artykule z tej serii zostanie przedstawiony sposób wykrywania błędów funkcjonalnych, które na etapie samej aplikacji mogą nastręczać wielu poważnych problemów i są trudniejsze do wykrycia niż błędy systemowe. Wykrywanie błędów funkcjonalnych W procesie produkcyjnym zdarza się, że zaprojektowana aplikacja zaczyna źle działać. Do zadań inżyniera utrzymania ruchu należy szybka reakcja na zaistniałą sytuację oraz znalezienie i próba wyeliminowania błędów. W artykule przedstawione zostały podstawowe funkcje sterowników PLC Simatic firmy Siemens, które pozwalają na przeprowadzenie testów diagnostycznych i wykrywanie błędów występujących wtedy, gdy sterownik wciąż pracuje, ale zapisana na nim aplikacja działa nieprawidłowo. Dobra znajomość omawianych funkcji pozwala na szybką reakcję obsługi, próbę poprawy działania aplikacji oraz skrócenie czasu przestoju, co pozwala na zmniejszenie strat i poniesionych kosztów związanych z zaistniałymi błędami. IDENTYFIKACJA BŁĘDÓW FUNKCJONALNYCH W poprzedniej części kursu dokonano podziału błędów na dwie podstawowe kategorie, w zależności od miejsca gdzie się pojawiają. Pierwsze to błędy systemowe, identyfikowane przez system operacyjny PLC, zwykle związane z błędami CPU oraz modułów peryferyjnych, m.in. błędy komunikacji, zasilania, uszkodzenie sterownika. Diagnostyka błędów systemowych z wykorzystaniem STEP 7 została opisany w poprzednim artykule z tej serii.

Rys. 1. Okno aplikacji Monitor/Modify Variables - tablica VAT Rys. 2. Pasek narzędziowy aplikacji Monitor/Modify Variables Znacznie poważniejszy problem pojawia się, gdy CPU przetwarza program sterowania, ale skonfigurowana funkcja systemu nie jest w całości przetwarzana lub jest przetwarzana błędnie. Użytkownik potrafi stwierdzić, że występuje błąd, ale CPU wciąż jest w trybie RUN. Występują wtedy błędy funkcjonalne, znacznie trudniejsze do zidentyfikowania niż błędy systemowe. Istnieją dwie podstawowe grupy błędów funkcjonalnych: błędy procesowe - identyfikowane jako złe funkcjonowanie różnych elementów systemu sterowania m.in. okablowanie czujnika/elementu wykonawczego, uszkodzenie czujnika/elementu wykonawczego oraz błędy logiczne programu błędy programowe, które nie zostały zidentyfikowane podczas pisania oraz uruchomienia programu, np. dwukrotne wysterowanie wyjścia w programie, złe adresowanie wejść/wyjść, itp. W artykule zostaną opisane podstawowe procedury diagnozowania sterownika PLC np. S7-300 z wykorzystaniem środowiska STEP 7, w którym zaimplementowano mechanizmy pozwalające na szybkie wykrycie błędów funkcjonalnych. Pozwala to na usystematyzowanie testów diagnostycznych działającej aplikacji. MONITOROWANIE I MODYFIKOWANIE ZMIENNYCH - TABLICA VAT Do przeprowadzenia testów diagnostycznych często przydatna jest aplikacja Monitor/Modify Variables, uruchamiana z poziomu Simatic Managera lub z edytora LAD/STL/ FBD po wybraniu opcji PLC -> Monitor/ Modify Variables (rys. 1). Służy do monitorowania oraz ewentualnej modyfikacji zmiennych w dowolnym formacie.

Rys. 3. Okno Trigger oraz możliwe punkty sprawdzenia zmiennych Rys. 4. Modyfikacja lub wymuszenie wyjść w trybie Stop Dotyczy to wszystkich zmiennych z pamięci sterownika i adresów z wyjątkiem zmiennych lokalnych przypisanych do bloku programowego. Funkcja ta może być wykorzystywana do następujących procedur testowych: test okablowania wejść, symulowanie stanu wejść, znalezienie różnic pomiędzy błędami sprzętowymi/programowymi.

Sposób pracy z aplikacją Monitor/Modify Variables może być następujący: utworzenie nowej lub otworzenie istniejącej tablicy zmiennych VAT (VAriable Table), edycja lub sprawdzenie zawartości tablicy VAT, utanowienie połączenia online pomiędzy daną tablicą VAT a określonym CPU, określenie punktu czasowego odczytania zmiennej i częstotliwości odczytu, włączenie lub wyłączenie funkcji monitorowania/modyfikacji zmiennych, zapisanie tabeli VAT. Rys. 5. Forsowanie wartości zmiennych

Rys. 6. Ustawianie punktów zatrzymania w edytorze LAD/FBD/STL Zmienne, których wartości są sprawdzane lub modyfikowane, należy wprowadzić do tablicy zmiennych VAT. Sposób wyświetlania zmiennych w tablicy definiuje się, korzystając z opcji View. W tablicy możemy wyświetlić następujące kolumny: Address - absolutny adres zmiennej, Symbol - symboliczna nazwa zmiennej, Symbol comment - komentarz do wyświetlanej zmiennej, pobierany z tablicy symboli i wyświetlany bez możliwości modyfikacji, Display format - format w jakim ma być wyświetlana dana (np. binarny, dziesiętny), Status value - aktualna wartość zmiennej w wybranym formacie, Modify value - wartość, jaką wpisujemy do zmiennej. Każdą zmienną możemy wprowadzać poprzez podawanie adresu absolutnego lub symbolicznego (jeżeli został wcześniej wprowadzony). W przypadku sprawdzania okablowania wejść/wyjść (bez względu na warunki wysterowania w programie) można także monitorować i wymuszać adresy na poziomie narzędzia HWConfig. Punkt czasowy odczytania zmiennej definiuje się za pomocą

funkcji Variable -> Set Trigger... lub poprzez wciśnięcie odpowiedniej ikony na pasku narzędziowym aplikacji Monitor/Modify Variables (rys. 2). Otwiera się wtedy okno Trigger (rys. 3), w którym definiujemy się punkty czasowe monitorowania i modyfikacji zmiennych. W polach Trigger Point for Monitoring/Trigger Point for Modifying definiowane są punkty uaktualniania wartości monitorowanych/modyfikowanych zmiennych (rys. 3). W polach Trigger Condition for Monitoring/Trigger Condition for Modyfying definiuje się, czy wartość wyświetlanej/ modyfikowanej zmiennej będzie sprawdzana tylko raz, czy też w każdym cyklu programowym. Tablica VAT jest zapisywana w katalogu "Blocks" w programie S7 i może być w każdym momencie powtórnie wykorzystana poprzez podwójnie wybranie jej klawiszem myszy. Jednak przed uaktywnieniem funkcji Monitor i Modify musi być ustalone połączenie online z CPU. Ustanowienie połączenia może być wykonanie poprzez wybranie następujących opcji z menu PLC -> Connect to i wybranie odpowiedniej opcji: Configured CPU - automatycznie ustalane połączenie ze stacją MPI, której konfiguracja została zdefiniowana w projekcie i tablica VAT jest zapisana w programie tej stacji; Direct CPU - połączenie jest ustalane z CPU bezpośrednio podłączonym z programatorem poprzez kabel PG-MPI; Accessible CPU - wyświetlane okno dialogowe z listą programów, po wybraniu programu połączenie z CPU jest ustalane na podstawie konfiguracji sprzętowej w programie. MODYFIKACJA WYJŚĆ W TRYBIE STOP Modyfikację wyjść umożliwia funkcja Enable Peripheral Outputs, która może być aktywowana tylko w przypadku, kiedy jednostka centralna jest w trybie STOP. Pozwala ona na test okablowania wyjść peryferyjnych. Funkcja ta może być również wykorzystana do sterowania urządzeniami w przypadku wystąpienia błędów. Rys. 7. Blok typu LAD otworzony za pomocą aplikacji Monitor Block

Rys. 8. Wybór trybu testowania CPU z poziomu edytora LAD/STL/FBD Sposób modyfikacji wyjść w trybie STOP jest następujący (rys.4): otworzyć tablicę zmiennych (VAT) zawierającą listę wyjść peryferyjnych, które muszą być przetestowane lub modyfikowane (modyfikować można poprzez adresowanie typu bajt, słowo lub podwójne słowo - nie można modyfikować pojedynczych bitów wyjściowych!), ustanowić połączenie z CPU, wybierając opcje PLC -> Connect to, przełączyć CPU w tryb STOP, wprowadzić wartość dla odpowiednich adresów w kolumnie Modify Value, uaktywnić modyfikację wyjść, wybierając opcje Variable -> Enable Peripheral Outputs, wymusić wartość na wyjściach wybierając opcje Variable -> Activate Modify Values, uaktualnić nowo wpisaną wartość, wybierając Variable -> Activate Modify Values.

Modyfikacja lub wymuszanie wyjść peryferyjnych jest aktywne do momentu dezaktywacji poprzez Variable -> Enable Peripheral Outputs lub wciśnięcie przycisku ESC. Przy zmianie trybu pracy CPU ze STOP na RUN lub STARTUP funkcja jest dezaktywowana z wyświetleniem meldunku. FORSOWANIE WARTOŚCI ZMIENNYCH Za pomocą funkcji Force możliwe jest ustawienie wartości zmiennych niezależnie od programu sterowania. Okno Force Values jest otwierane tylko dla CPU. W sterowniku S7-300 można wymuszać obszary odwzorowania wejść i wyjść (I/Q). Przed uruchomieniem funkcji Force należy sprawdzić, czy nie jest już ona uruchomiona dla danego CPU. "Wymuszanie" wartości zmiennych może być skasowane lub zakończone tylko za pomocą polecenia menu Variable -> Stop Forcing. Zamknięcie okna Force Values lub zamknięcie aplikacji Monitor / Modify Variables nie przerywa operacji wymuszania. W celu uruchomienia funkcji Force należy wybrać CPU, w którym będą wymuszane zmienne z poziomu programu Simatic Manager, a następnie: wybrać opcje PLC -> Display Force Values, po czym to ostanie uruchomiona aplikacja Monitor/Modify Variables z oknem Force Values i listą adresów, które aktualnie są wymuszone w CPU wraz odpowiadającymi im wartościami (rys. 5), w kolumnie Address wprowadzić zmienną i w kolumnie Force Values podać wartość, jaką chcemy nadać zmiennej, uruchomić wymuszanie za pomocą opcji Variable -> Force, W momencie zakończenia wymuszania wybrać opcję Variable -> Stop Forcing.

Rys. 9. Okno funkcji Call Environment of the Block Rys. 10. Określenie sposobu wyświetlania danych referencyjnych PUNKTY ZATRZYMANIA Za pomocą punktów zatrzymania (breakpoints) istnieje możliwość przetestowania programu linia po linii z każdorazowym wyświetleniem zawartości rejestrów. Ustawienie punktów zatrzymania jest możliwe tylko w języku programowania STL. Można zaznaczyć kilka punktów zatrzymania w

momencie przetwarzania programu, jednak ich liczba zależy od typu CPU. Z punktów zatrzymania można skorzystać, jeżeli zostaną spełnione następujące wymagania: w parametrach CPU musi być ustawiony tryb Test Operation, testowany blok musi być otwarty w trybie online, w edytorze LAD/FBD/STL musi być wybrana opcja View -> STL, testowany blok nie może być zabezpieczony. Testowanie z wykorzystaniem punktów zatrzymania można uruchomić w edytorze LAD/FBD/STL poprzez menu Test lub za pomocą paska narzędziowego Breakpoint Bar (rys. 6), uaktywnianego za pomocą opcji menu View -> Breakpoint Bar. Kolejne funkcje z paska Breakpoint Bar są opisane w tabeli 1. Jeżeli przetwarzanie programu zawierało zatrzymanie w ustawionych punktach, CPU przełączy się z trybu RUN w tryb HOLD. W tym trybie świeci się czerwona dioda LED Stop oraz jednocześnie miga dioda zielona LED Run. Wyjścia są dezaktywowane dla celów bezpieczeństwa. Funkcje Execute Next Statement i Execute Call wymagają wolnych zasobów w zakresie wolnych punktów zatrzymania. TESTOWANIE BLOKÓW Do sprawdzania działania programu wewnątrz wybranego bloku może być wykorzystywana funkcja testująca Monitor Block, pozwalająca na wyświetlanie w momencie przetwarzania programu stanów oraz wartości adresów wykorzystanych w bloku programowym. Aktywacja aplikacji monitorującej status bloku (rys. 7) jest wykonywana na bloku otwartym pod edytorem LAD/STL/FBD poprzez wybranie opcji Debug -> Monitor lub za pomocą ikony.

Rys. 11. Okno ze strukturą programu, ustawianie filtru Rys. 12. Lista Cross-referencess

Monitorowanie stanu może być uaktywnione dla otwartego bloku typu online lub offline. W momencie aktywacji sprawdzane jest, czy blok otwarty w edytorze jest identyczny z blokiem umieszczonym w sterowniku. W przypadku różnic edytor nie pozwoli na monitorowanie i należy testowany blok przeładować do CPU lub otworzyć blok znajdujący się w CPU. Stan bloku jest wyświetlany tylko wtedy, gdy jednostka centralna jest w trybie RUN oraz instrukcje są przetwarzane przez system. W trybie testowym stany adresów i elementy graficzne LAD/ FBD są wyświetlane w różnych kolorach (zmianę ustawień definiuje się za pomocą opcji Options -> Customize), np. jeżeli warunek jest spełniony, to element jest wyświetlany na zielono, natomiast jeśli warunek nie jest spełniony, to element jest wyświetlany na niebiesko. Podczas monitorowaniu programu w języku STL istnieje możliwość określenia, jakie informacje mają być wyświetlane (określa się je za pomocą opcji Options -> Customize -> STL), są to: RLO wynik sprawdzenia logicznego; STAT - status adresu (binarnego); Default (Akumulator 1)/ Accumulator 2 - zawartość akumulatorów 1 i 2; AR1/AR2 - rejestry adresowe 1 i 2, wartość podawana tylko przy adresowaniu pośrednim; DB Register 1/DB Register 2 - Numer globalnego lub pierwszego/drugiego otwartego bloku DB; Indirect - Zawartości MD, DBD lub LD, które są wykorzystywane przy adresowaniu pośrednim; Status Word - Stan bitów statusu (OV, OS, BR). Standardowo wyświetlane są dane: RLO, STATUS i STANDARD (akumulator 1). Istnieją dwa tryby pracy testowej CPU, tzw. przetwarzanie procesowe lub testowe, które mają wpływ na czas cyklu przetworzenia programu. Wywoływane są z poziomu edytora LAD/ STL/FBD poprzez wybranie Debug -> Operation i zaznaczenie opcji Test Operation / Process Operation (Rys. 8) lub w konfiguracji sprzętowej CPU (HW Config): CPU -> Protection -> Process Mode / Test Mode.

Rys. 13. Filtrowanie listy Cross-References Rys. 14. Otwieranie bloku z listy Cross-References

W trybie Test Operation wszystkie funkcje testowe mogą być wykonywane bez ograniczeń. Status pętli programowej jest uzależniony od każdorazowego jej przetworzenia. Czas cyklu programowego może się zmieniać w zależności od liczby wykorzystywanych funkcji testowych. CPU przechodzi w tryb Stop tylko w momencie przekroczenia nastawionego czasu skanowania. W trybie Process Operation istnieje możliwość czasowego ograniczenia liczby funkcji testowych. W tym trybie definiuje się o ile maksymalnie może wzrosnąć cykl programowy podczas programowego testowania CPU. Przy wybraniu tej opcji nie jest możliwe krokowe testowanie programu lub poprzez zaznaczenie punktów zatrzymania (breakpoint) oraz monitorowanie jednego z kilku wywołań tego samego parametryzowalnego bloku. Do monitorowania parametryzowanego bloku (FC,FB), który jest kilka razy wywoływany w programie z różnymi parametrami aktualnymi, służy kolejna funkcja diagnostyczna - Call Environment of the Block (rys. 9). Funkcja jest uaktywniana z menu edytora LAD/FBD/ STL: Debug -> Call Environment. W konfiguracji sprzętowej HW Config musi być zdefiniowany tryb Test Mode. Za jej pomocą definiowane jest monitorowanie wybranego wywołania bloku, jednak musi być ono zaprogramowane jako wywołanie bezwarunkowe. Jeżeli blok jest otwarty, pod edytorem LAD/STL/FBD istnieją dwie możliwości warunków wywołania (Call environment) monitorowanego bloku: Call-up Path oraz Open Data Block. Za pomocą wywołania Call-up Path (wykorzystanie stosu B STACK) zaznacza się monitorowany blok w drzewie struktury (można zdefiniować do trzech zagnieżdżeń monitorowania). Za pomocą wywołania Open Data Blocks definiuje się blok, który ma być monitorowany i z jakimi blokami danych: Global DB Number (1 rejestr DB) lub Instance DB Number (2 rejestr DB). WYŚWIETLANIE DANYCH REFERENCYJNYCH Przy rozległych programach praktycznie zawsze jest stosowane wyświetlanie danych referencyjnych. Szczególnie kiedy mają być sprawdzone: aktualny stan adresu, gdzie i w jaki sposób adres został użyty, które wejścia i wyjścia są aktualnie wykorzystywane w programie oraz jakie są elementy programu i jaka jest jego budowa. Funkcja Reference Data umożliwia przegląd struktury programu sterowania oraz listy użytych adresów.

Tab. 1. Funkcje paska narzędziowego punktów zatrzymania Dane referencyjne są generowane na podstawie programu zapisanego na programatorze w trybie offline. Korzystając z danych referencyjnych razem z funkcją Program Status, można szybko znaleźć błędy funkcjonalne np. podwójnie zastosowany adres. Generowanie i wyświetlanie danych referencyjnych jest wywoływane z poziomu oprogramowania SIMATIC Manager (przy zaznaczonym katalogu "Blocks") lub w edytorze LAD/STL/FBD poprzez wybranie opcji Options -> Reference Data -> Display lub ->Filter and Display (rys. 10). W oknie Customize określa się postać list, w których będą wyświetlane dane referencyjne. WYŚWIETLANIE STRUKTURY PROGRAMU Jedną z często stosowanych opcji jest wyświetlanie struktury programu. W tym celu w oknie dialogowym Customize (rys. 10) podczas wyświetlania danych referencyjnych należy zaznaczyć opcję Program Structure. Otwiera się wtedy okno (rys. 11) ze strukturą programu, która opisuje całkowitą hierarchię bloków w programie sterowania. "W zależności od ustawień filtru, wybranego za pomocą przycisku wyświetla się cały program w postaci drzewa lub wybrana część struktury bloków. Następujące symbole są wyświetlane w

strukturze drzewa (rys. 11): < maximum : nnn > - maksymalna ilość pamięci lokalnej (w bajtach) wymagana do przetworzenia całej struktury programu, [nnn] - maksymalna ilość pamięci lokalnej (w bajtach) wymagana do przetworzenia programu, licząc od ostatniego bloku. LISTA CROSS-REFERENCES Kolejna funkcja wyświetla informacje o tym, jakie adresy są wykorzystane, w jakich blokach i z jakimi instrukcjami. Jest ona otwierana za pomocą opcji View -> Cross References. W liście mogą być wyświetlane wszystkie wykorzystane wejścia, wyjścia, znaczniki (M), elementy czasowe (T), liczniki (C), bloki (z wyłączeniem OB), peryferyjne wejścia i wyjścia (rys. 12). Lista Cross-References jest przedstawiona w formie tablicy i ma następujące kolumny: Address absolutny adres rejestru, Symbol - symboliczna nazwa adresu, Block - blok, w którym został wykorzystany adres, Type - informacja, czy adres jest tylko do odczytu (R) lub tylko do zapisu (W), Language - język programowania, w którym zostały napisane funkcje wykorzystujące adres, Details - instrukcje z jakimi został użyty adres. Rys. 15. Wyświetlenie Cross-References z edytora LAD/STL/FBD

Rys. 16. Lista obszarów I/Q/M oraz T/C Po zaznaczeniu konkretnego adresu z listy, za pomocą prawego przycisku myszy i wybraniu opcji View -> Cross Reference for Address, otwiera się nowe okno przedstawiające referencje dla jednego wybranego wcześniej adresu. Za pomocą funkcji Filter wyświetla się referencje dla wybranych adresów lub obszarów pamięci (rys. 13). Filtrowanie uruchamiane jest za pomocą opcji View-> Filter reference data. W oknie dialogowym ustawia się następujące informacje: Addresses - definicja, jakie adresy będą wyświetlane w liście; Filter Area - specyfikacja wyświetlanego obszaru wewnątrz adresu; Access Type - informacja, gdzie jest odczytywana lub gdzie jest zapisywana wartość adresu; Columns definiowanie, które kolumny mają być wyświetlane. Jeżeli zdefiniowane ustawienia mają być ustawieniami standardowymi, należy je zapisać poprzez wybranie opcji Save as standard.

Standardowe lub podstawowe ustawienia można odzyskać za pomocą przycisku Load Default Setting. W momencie wyświetlania danych referencyjnych można uruchomić w dowolnym momencie funkcję znajdowania adresu (ciągu znaków) w liście referencyjnej, wybierając z menu okna Cross-References opcje Edit -> Find. Poprzez dwukrotne kliknięcie na adres w liście CrossReferences zostanie otwarty uruchomiony edytor LAD/FBD/STL i blok w miejscu, gdzie ten adres został wykorzystany (rys. 14). Dane referencyjny są generowane tylko z bloku, który został zapisany na dysku (offline). Podczas sprawdzenia programu znajdującego się w sterowniku bloki zapamiętane online i offline muszą być identyczne. Stan bloków sprawdzany jest w aplikacji SIMATIC Manager za pomocą funkcji z menu Options -> Compare Blocks. W trakcie diagnozowania programu bardzo często wymagane jest szybkie sprawdzanie miejsc wykorzystania konkretnego adresu. W takim przypadku należy zastosować funkcję Go to Location, która jest uaktywniana bezpośrednio z edytora LAD/FBD/STL i wyświetla listę Cross-References wybranego adresu. Funkcja jest uruchamiana poprzez kliknięcie prawym przyciskiem myszy na wybrany adres. Pojawi się okno dialogowe Go to Location (rys. 15). Wpisy są identyczne jak w edytorze CrossReferences. Następnie, po wybraniu interesującego miejsca wykorzystania adresu, kliknąć na przycisk Go To. Rys. 17. Lista niewykorzystanych nazw symbolicznych

Rys. 18. Edycja symbolu dla adresu bez symboliki Poprzez wciśnięcie przycisku Starting Point wraca się do pierwszego miejsca wykorzystania adresu. Standardowo uaktywnione są wszystkie miejsca wykorzystania adresu. Poprzez wybranie opcji Selection w polu Type of Access wyświetla się np. tylko miejsca, gdzie jest zapisywana wartość do rejestru (przyrównanie, set, reset). Wyświetlenie listy wykorzystanych pamięci z obszarów wejść (I), wyjść (Q) i znaczników (M) jest uaktywniane poprzez wybranie w oknie funkcji Cross-Referrences opcji View -> Assignment -> Inputs, Outputs and Bit Memory lub wciśnięcie ikony (rys. 16). Wyświetlenie listy wykorzystanych członów czasowych (T) i liczników (C) jest uaktywniane poprzez wybranie View -> Assignment -> Timers and Counters lub wciśnięcie ikony (rys. 16). W kolejnych liniach listy znajdują się elementy T/C wykorzystane w programie. Lista obszarów I/Q/M oraz T/C umożliwia sprawdzenie, które bity z bajtów zostały użyte w programie z obszarów I/Q/M oraz T/C. Każda linia przedstawia jeden bajt z obszaru pamięci, w którym są zidentyfikowane pionowo bity. Można także sprawdzić, czy obszar został wykorzystany w programie w formie bitu, bajtu, słowa czy też podwójnego słowa. Elementy listy są opisane następującymi symbolami: "-" - adres nie jest użyty w programie i jest nadal wolny, "o" - adres jest wykorzystany w programie bezpośrednio (jako bit), "x" - adres jest wykorzystany pośrednio jako bajt, słowo lub podwójne słowo. Dowolne ograniczenia lub warunki, jakie zakresy obszarów danych mają być wyświetlane, określa się wybierając opcje View-> Filter reference data.

W tym przypadku jest wyświetlane to samo okno dialogowe filtru co przy liście referencyjnej. Wyświetlenie listy niewykorzystanych nazw symbolicznych jest uaktywniane poprzez wybranie w menu okna Cross-Referrences opcji View -> Unused Symbols lub poprzez wciśnięcie ikony. Lista przedstawia adresy (rys. 17), które mają nazwę symboliczną, lecz nie zostały użyte w programie sterowania. Wybrany symbol i nazwę symboliczną kasuje się z tablicy symboli poprzez kliknięcie na niego prawym przycis kiem myszy i wybranie opcji Delete Symbols. Rys. 19. Porównanie bloków (1) Rys. 20. Porównanie bloków (2)

Wyświetlenie listy adresów bez symboliki jest uruchamianie przez wybranie opcji View -> Addresses without Symbols lub wciśnięcie ikony. Lista przedstawia adresy, które są wykorzystywane w programie sterowania, lecz nie mają nazwy symbolicznej w tablicy symboli. Poprzez kliknięcie prawym klawiszem i wybranie funkcji Edit Symbols definiuje się symbolikę dla wybranego adresu (rys. 18). Za pomocą funkcji filtrującej uruchamianej za pomocą opcji View-> Filter reference data określa się dokładniej sposób wyświetlania niewykorzystywanych adresów z nazwami symbolicznymi. PORÓWNANIE BLOKÓW W STEP 7 istnieje możliwość porównania bloków pomiędzy programem online i offline lub pomiędzy dwoma programami znajdującymi się na dysku twardym programatora (PG). Pozwala to sprawdzić, czy zostały wprowadzone zmiany w CPU oraz które linie i bloki zostały zmienione. Porównanie bloków można zrealizować następująco (rys. 19): za pomocą prawego przycisku myszy wybrać katalog Blocks z programu S7, następnie opcję Options -> Compare Blocks, wybrać, które programy mają być porównane online/offline, w kolejnym oknie zostaną wyświetlone różnice w porównywanych blokach, wybrać linię różnicy, która ma być sprawdzona i wcisnąć przycisk Details, w oknie Compare Blocks - Details sprawdzić, kiedy został zmieniony blok i jaką ma długość, po wciśnięciu przycisku Go To zostaną otwarte dwa bloki np. online i offline w edytorze LAD/STL/ FBD oraz przedstawione linie programowe, w których znajdują się różnice (rys. 20). Zmiany mogą być dokonane tylko w oknie offline. Znajomość i umiejętne zastosowanie funkcji diagnostycznych znacznie ułatwia wykrycie i eliminację błędów. Stosunkowo łatwo wykrywa się błędy systemowe, które powodują zatrzymanie pracy sterownika PLC. Jednak często poważnych problemów nastręczają błędy funkcjonalne, które występują, pomimo że sterownik wciąż pracuje i z tego powodu są one znacznie trudniejsze do wykrycia.

Mogą być związane z nieprawidłowym działaniem elementów peryferyjnych lub błędami programowymi, które nie zostały zidentyfikowane podczas pisania oraz uruchomienia programu w sterowniku PLC. W artykule opisano sposób pracy z funkcjami diagnostycznymi środowiska STEP 7 pomagającymi w identyfikacji błędów funkcjonalnych, których odpowiednie wykorzystanie znacznie poprawia niezawodność przygotowywanej aplikacji.