Dobrze napisany program powinien się charakteryzować działaniem zgodnym z założeniami, ale także jak największą odpornością na błędy. Napisanie kodu programu, aby realizował założenia projektowe nie jest aż tak dużym osiągnięciem. Zajmuje to około 40% czasu realizacji całego projektu. A pozostałe 60%? Ten czas jest potrzebny na przewidzenie niepożądanych zdarzeń i przygotowanie dla nich kodu realizującego ich obsługę.

Error – Dostępne błędy w PLC

Jednak to nie wszystko. Trzeba przewidzieć, co operator może zrobić coś w inny sposób, niż mówią założenia projektowe. Część błędów zauważysz podczas uruchomienia i testów maszyny lub linii technologicznej. Najłatwiej, aby ktoś inny obsługiwał maszynę. Programista powinien stać z boku i się tylko przyglądać. Wtedy zauważysz, jak zachowuje się dana osoba podczas obsługi. Błędy można podzielić na sprzętowe i programowe. Poniżej skupimy się na standardowych sterownikach PLC. W przypadku sterowników safety wygląda to trochę inaczej.

Sprzętowe

W przypadku błędów sprzętowych można wyróżnić błędy generowane przez urządzenia oraz błędy związane z uszkodzeniem elementów, które można wykryć programowo

Błędy generowane przez modułu

W przypadku sytuacji takich, jak: zwarcie, niedomiar, przerwa, przepełnienie, brak zasilania, system operacyjny (firmware) generuje zdarzenie błędu diagnostyki, który jest obsługiwany przez blok organizacyjny OB82 (domyślna nazwa to Diagnostic error interrupt). W sekcji interfejsu tego bloku zawarte są informacje pomagające określić programiście przyczynę błędu oraz urządzenie, w którym wystąpił problem. Na poniższym rysunku przedstawiono sekcje interfejsu tego bloku.

Podczas tworzenia nowego projektu blok 82 nie jest automatycznie dodawany. W przypadku pojawienia się błędów opisanych wyżej CPU zignoruje ten błąd. Najlepszym rozwiązaniem jest dodanie tego bloku do projektu, gdy wykorzystujemy urządzenia potrafiące zgłaszać błędy diagnostyczne.

Błędy wykrywane programowe

Niektóre zdarzenia można wykryć poprzez napisanie odpowiedniego kodu programu. Przykładem może być zwieranie do napięć zasilania (tz. mostkowanie) przycisków lub przełączników. Wówczas wystarczy zastosować w kodzie programu np. detekcję zboczy sygnałów.

Funkcja LED()

W jednym z wcześniejszych wpisów przedstawiłem Ci znaczenie poszczególnych diod LED, które znajdują się na przednim panelu sterownika. W naszym przypadku najbardziej interesuje nas dioda ERROR. Jest również możliwość odczytu stanu tych diod z poziomu kodu programu za pomocą funkcji LED(), która znajduje się w Instructions//Extended instructions/Diagnostics. Przykładowe wywołanie przedstawiono poniżej

″Led″.PlcLed := LED(LADDR := "Local~Common",
LED := 2);

Do parametru LADDR funkcji LED() należy przypisać numer identyfikacyjny CPU. Numer ten jest przydzielany automatycznie podczas dodania sterownika do konfiguracji sprzętowej. Można go znaleźć, rozwijając folder PLC tags z drzewa projektu i otwierając tabelę Show all tags. Wybieramy zakładkę System constants. W zakładce znajdują się wszystkie numery identyfikacyjne sprzętu występującego w sterowniku oraz modułów zewnętrznych w przypadku ich dołączenia.

Natomiast do parametru LED należy przypisać numer identyfikacyjny diody LED, której stan chcemy odczytać. Liczba 2 oznacza diodę ERROR. Funkcja zwraca wartość informującą o aktualnym statusie danej diody, która jest przypisywana do zmiennej PlcLed typu Int zdefiniowanej w bloku danych DB o nazwie Led. W analogiczny sposób można odczytać pozostałe diody. Szczegółowy opis znajduje się w pomocy środowiska TIA Portal. Znając aktualny status diod LED oraz ich znaczenie, należy stworzyć funkcję odpowiednio reagującą na ich stan.

Programowe

Każda aplikacja powinna cechować się stabilnością działania i niezawodnością. Jednak występują sytuacje, gdy program może się zablokować lub zapętlić. W takiej przypadku system musi sam poradzić sobie z takim problemem, ponieważ nie zawsze użytkownik może interweniować.

Przekroczenie czasu cyklu – Time error interrupt

Każdy sterownik PLC ma układ monitorujący czas cyklu programu (czas wykonania jednego obiegu pętli nieskończonej, czyli bloku OB1). CPU rozpoczyna odmierzanie czasu na początku cyklu i także sam kasuje zmierzony czas na końcu. Także nie ma bezwzględnego obowiązku zerowania odmierzonego czasu. Jednak również istnieje taka możliwość, która może być potrzebna, gdy dany fragment kodu jest czasochłonny i wykonywany tylko w określonych sytuacjach. Do tego celu służy funkcja RE_TRIGR() dostępna w Instruction/Basic instruction/Program control operations.

W TIA Portal należy dodać blok organizacyjny OB80 Time error interrupt, który jest wykonywany w przypadku przekroczenia czasu cyklu. Jeżeli nie ma OB80, to sterownik przechodzi w tryb STOP. Należy także pamiętać, że jeżeli czas cyklu zostanie przekroczony dwa razy w ramach tego samego obiegu pętli, to sterownik przejdzie w tryb STOP niezależnie od istnienia OB80.

Ustawienie maksymalnego czasu cyklu  dokonuje się w konfiguracji sterownika. Wygląd opcji umieszczonych w zakładce Cycle przedstawiono na poniższym rysunku.

Domyślna wartość, to 150 ms.

Funkcja GET_ERROR()

Przykładem błędu typowo programistycznego może być zapis wartości do elementu tablicy spoza zakresu. W takiej sytuacji zacznie pulsować dioda ERROR na przednim panelu sterownika informująca o błędzie. Sterownik PLC domyślnie reaguje na wystąpienie takiego błędu poprzez jego rejestrację w buforze diagnostycznym i przystąpi do wykonania następnych instrukcji. Błąd w tym przypadku nie jest na tyle poważny, aby sterownik przeszedł w tryb STOP. Niestety inne błędy mogą do takiej sytuacji doprowadzić. Jeżeli wiemy, że dana instrukcja w bloku może spowodować błąd, wówczas należy umieścić po tym kodzie funkcję GET_ERROR() znajdującą się w Instructions/Basic instructions/Runtime control. Przykładowe wywołanie przedstawiono poniżej

GET_ERROR(OUT => ″ErrorBuffer″.ActualError[0]);

Po przechwyceniu błędu funkcja przypisze go do zerowego elementu tablicy ActualError typu ErrorStruct znajdującej się bloku danych DB o nazwie ErrorBuffer.

Przechwyceniu błędu w ten sposób spowoduje, że nie nastąpi jego rejestracja w buforze diagnostycznym, jak również sterownik nie przejdzie w tryb STOP. Programista musi ten błąd odpowiednio zinterpretować i obsłużyć. Szczegółowy opis błędów znajduje się w pomocy TIA Portal.

Należy pamiętać, że wywołanie funkcji GET_ERROR() zwraca pierwszy błąd, jaki pojawił się od czasu ostatniego wywołania tej funkcji. Jeżeli w tym czasie pojawiły się dwa błędy, wówczas funkcję należy wywołać dwukrotnie. Najbezpieczniejszym rozwiązaniem jest umieszczanie tej funkcji bezpośrednio po kodzie, który może powodować błędne działanie.

Inne

Zazwyczaj podczas tworzenia projektu i spisywania założeń projektowych przewiduje się sytuacje, które będą traktowane jako błąd. Przechwycenie tych zdarzeń i obsługa zależy od programisty. W następnym wpisie zajmiemy się błędami, które zostały umieszczone w założeniach projektowych w Szkole PLC.

 

A Ty z jakimi błędami masz najczęściej odczynienia? Napisz w komentarzu.

Kurs wideo

Więcej na temat programowania w języku SCL znajdziesz w kursie Sterownik PLC w praktyce: