Jak diagnozować pracę przekaźnika? Cz.2

Powrót do listy artykułów Aktualizowany: 2021-09-27

| Kurs podłączania i konfigurowania przekaźników bezpieczeństwa dla maszyn i stanowisk produkcyjnych

Z tego artykułu dowiesz się:

jak działa diagnostyka w przekaźnikach Schneider Preventa XPS Universal,
jak skonfigurować środowisko Codesys do pracy z przekaźnikami,
jak napisać prosty program do diagnostyki pracy przekaźnika.

W poprzednim odcinku poznałeś/aś teorię na temat złącza diagnostycznego w przekaźnikach bezpieczeństwa Preventa XPS Universal. Skoro wiesz już, jak działa takie złącze i co można odczytać przy jego pomocy, przejdź do części praktycznej i skonfiguruj swój pierwszy program diagnostyczny.

Połączysz sterownik PLC Astraada One z przekaźnikiem bezpieczeństwa Preventa poprzez oprogramowanie Codesys.

Bloki funkcyjne przekaźników bezpieczeństwa

Na początek przygotujesz oprogramowanie Codesys do pracy z przekaźnikami bezpieczeństwa. Firma Schneider Electric przygotowała gotowe rozwiązanie w postaci biblioteki składającej się z dwóch bloków funkcyjnych: FB_PreventaDiag oraz FB_PreventaMain.

Pracę rozpocznij od pobrania i wgrania tej biblioteki, a potem poznasz obydwa bloki funkcyjne.

Preventa Support Library

Biblioteka Preventa Support Library służy do obsługi wyjścia diagnostycznego Z1 przekaźników bezpieczeństwa Preventa XPS Universal. Jak wiesz z poprzedniego odcinka kursu, przekaźniki bezpieczeństwa potrafią za pomocą tego wyjścia przesyłać kodowaną informację o swoim aktualnym stanie. Niska częstotliwość sygnału pozwala na podłączenie go do zwykłego wejścia cyfrowego tranzystorowego sterownika, bez znacznego obciążenia procesora.

Dzięki bibliotece Preventa Support Library potrafi możesz: odkodować sygnał diagnostyczny, określić zużycie przekaźnika i podłączonych urządzeń oraz zaplanować i przeprowadzić rutynowe testy systemu bezpieczeństwa.

Dokładny opis biblioteki możesz znaleźć w dokumencie:
https://download.schneider-electric.com/files?p_enDocType=User+guide&p_File_Name=EIO0000004435.00.pdf&p_Doc_Ref=EIO0000004435

Zacznij pracę od wgrania biblioteki do oprogramowania Codesys:

Wgrywanie biblioteki do środowiska Codesys, źródło: ASTOR

Po dodaniu biblioteki do środowiska dodaj ją do projektu:

Dodawanie biblioteki do projektu w Codesys, źródło: ASTOR

Biblioteka Preventa Support Library składa się z 4 struktur danych oraz następujących 2 bloków funkcyjnych:

FB_PreventaDiag – blok służący do odkodowania cyfrowego sygnału
FB_PreventaMain – blok służący do kalkulacji żywotności przekaźnika i podłączonych urządzeń oraz planowania i przeprowadzania okresowych testów zadziałania systemu bezpieczeństwa.

Wybierając bibliotekę w Library Manager możesz podejrzeć pełen opis dostarczanych bloków oraz struktur.

Opis bloków funkcyjnych w Codesys, źródło: ASTOR

Blok funkcyjny FB_PreventaDiag

Przejdź teraz do bloków funkcyjnych. Blok FB_PreventaDiag służy do odkodowania sygnału diagnostycznego przesyłanego przez wyjście Z1 przekaźnika bezpieczeństwa.

Blok funkcyjny FB_PreventaDiag, źródło: ASTOR

Blok ten posiada 3 wejścia:

i_xEnable – aktywacja bloku
i_xDiagSignal – sygnał z wejścia przekaźnika
i_timTaskCycle – okres wywoływania taska w którym znajduje się blok

Ważne: Blok ten należy wywoływać cyklicznie i nie rzadziej niż co 50 ms, w przeciwnym wypadku zgłoszony zostanie błąd.

Blok ten posiada także 8 wyjść oznaczających:

q_xBusy – przetwarzanie sygnału przez blok,
q_xError – wystąpienie błędu,
q_wErrorId – numer błędu,
q_xValid – wartość TRUE ustawiania jest na jeden cykl w momencie poprawnego zdekodowania sygnału,
q_stDiagCode – struktura stanów,
q_dwStatus – wartość ostatnich 6 bitów zdekodowanego sygnału,
q_xComWireInShort – wykrycie ciągłego zwarcia do stanu wysokiego na wejściu i_xDiagSignal,
q_xComWireInOpen – wykrycie ciągłego zwarcia do stanu niskiego na wejściu i_xDiagSignal.

Pierwsze 4 wyjścia informują o stanie procesu odczytywania kodu. W momencie wystąpienia błędu w funkcjonowaniu bloku, ustawiany jest sygnał wysoki na wyjściu q_xError, a na wyjściu q_xErrorId podawany jest kod błędu. Dokładne opisy kodów błędów możesz znaleźć w dokumentacji biblioteki.

Opis kodów błędów bloku FB_PreventaDiag, źródło: ASTOR

Jak to działa? Wyjście q_xBusy jest w stanie wysokim w trakcie przetwarzania sygnału wejściowego. W momencie poprawnego zdekodowania sygnału oraz odczytania kodu na jeden cykl w stan wysoki, ustawiane jest wyjście q_xValid.

Na wyjście q_stDiagCode podawana jest struktura ST_DiagCode, w której zawarta jest informacja diagnostyczna. Na wyjście q_dwStatus podawana jest wartość ostatnich 6 bitów wiadomości kodujących stan przekaźnika.

Ponadto, jeśli na wejściu wykryty zostanie sygnał stały zamiast impulsów, to zostaną ustawione:

w stan wysoki wyjście q_xComWireInShort – jeżeli sygnał jest stale wysoki lub
q_xComWireOpen – jeżeli sygnał jest stale niski.

Blok funkcyjny FB_PreventaMain

Przejdź teraz do drugiego bloku funkcyjnego. FB_PreventaMain służy do ewaluacji cyklu zużycia przekaźnika oraz podłączonych do niego komponentów. Ponadto pozwala na planowanie i przypominanie o rutynowych testach zadziałania systemu bezpieczeństwa.

Ważne: Blok ten musisz umieścić w tym samym programie, po bloku FB_PreventaDiag – w przeciwnym wypadku zostanie zgłoszony błąd konfiguracji.

Blok diagnostyczny FB_PreventaMain, źródło: ASTOR

Posiada on 12 wejść i 11 wyjść. Jak to działa? Podobnie jak w bloku FB_PreventaDiag, blok posiada wejście i_xEnable służące do aktywacji bloku oraz 3 wyjścia określające jego stan.

Wyjście q_xActive oznacza, że blok jest aktywny, a wyjścia q_xError oraz q_wErrorId oznaczają odpowiednio wystąpienie błędu oraz kod błędu. Kolejne wejścia służą do konfiguracji bloku – poznasz je w dalszej części kursu.

Struktury do konfiguracji wejść i wyjść bezpieczeństwa

Skąd przekaźnik ma wiedzieć, ile cykli ma wykonać dane wejście bądź wyjście? Będziesz musiał/musiała go poinformować o tym sam/a. Służą do tego dwie struktury:

- ST_InputControl – struktura do konfiguracji wejść bezpieczeństwa. Struktura zawiera pola:

udiMaxNumOp – oznaczającą ilość cykli pracy podłączonego urządzenia do wejść bezpieczeństwa, 0 oznacza brak zliczania.
byMonitorInput1 oraz byMonitorInput2 – numer pierwszego oraz drugiego wejścia bezpieczeństwa podłączonego urządzenia. Np. dla wejść S12 oraz S22 wartości wejść będą miały 12 oraz 22. 0 jeśli urządzenie jest nie podłączone.
xReset – resetowanie licznika, np. w momencie wymiany urządzenia.

- ST_DevControl – struktura do konfiguracji wyjść bezpieczeństwa. Zawiera pola:

udiMaxNumOp – maksymalna ilość cykli pracy urządzenia, 0 oznacza brak zliczania.
xReset – resetowanie licznika, np. w momencie wymiany urządzenia.

Struktury te podawane są na wejścia bloku:

i_stControlProc – określa maksymalną liczbę cykli zadziałania przekaźnika,
i_astControlInp – tablica określająca konfigurację urządzeń podłączonych do wejść bezpieczeństwa przekaźnika,
i_astControlOut – tablica określająca konfigurację urządzeń podłączonych do wyjść bezpieczeństwa przekaźnika oraz opcjonalnego modułu rozszerzającego.

Jeśli licznik cyklu pracy któregoś z komponentów osiągnie 0, wyjście q_xOpExceeded zostanie ustawione w stan wysoki, a na wyjściu q_wExceededId podany zostanie numer urządzenia dla którego licznik osiągną wartość zerową.

Wyjścia przekaźnika oznaczone są kodem 16#1005. Wejścia numerowane są kolejno od 16#101x, a wyjścia 16#102x. Dokładny opis kodów znajdziesz w sekcji q_wExceededId dokumentacji biblioteki, podanej na początku tego artykułu

Wyjście q_udiNumOpSystem określa liczbę cykli zadziałania systemu bezpieczeństwa. Na wyjściu q_stRemainNumOp podawana jest struktura ST_RemainNumOp określająca pozostałą ilość cykli pracy każdego z podłączonych urządzeń i posiada pola:

udiNumRemainingProc – pozostała ilość cykli pracy przekaźnika,
audiNumOpRemainInp – tablica wartości pozostałych ilości cykli pracy urządzeń wejściowych,
audiNumOpRemainOut – tablica wartości pozostałych ilości cykli pracy urządzeń wyjściowych.

Przykładowa aplikacja – cykliczne testy systemu bezpieczeństwa

W celu utrzymania poprawności działania systemów bezpieczeństwa, konieczne jest okresowe wykonywanie testów systemu. Jest to bardzo ważna rutynowa czynność, do której możesz wykorzystać system diagnostyczny Preventa XPS Universal.

Już za chwilę stworzysz od podstaw program, który pozwoli na wykonywanie takich testów, a także umożliwi ciągłe monitorowanie przekaźnika, dzięki czemu zwykły przekaźnik bezpieczeństwa możesz zintegrować z większym systemem sterowania tak jak sterownik safety.

Przygotowanie przekaźnika bezpieczeństwa i sterownika PLC do testów

Przykład omówimy na podstawie najbardziej popularnego systemu bezpieczeństwa, a więc przycisku E-STOP. Jako przekaźnik bezpieczeństwa wykorzystamy model XPSUAF13AP. Diagnostykę będzie obsługiwał sterownik Astraada One Compact ECC2150 programowany w Codesys.

Podłączanie komponentów

Zacznij od podłączenia komponentów. Wyłącznik E-STOP podłącz pomiędzy zaciskami S11 i S21, a także S12 i S22. W zaciski Y1 oraz Y2 podłącz przycisk resetujący działanie sterownika. Wyjście diagnostyczne Z1 podłącz do wejścia cyfrowego sterownika.

Na sam koniec do styków wyjściowych podłącz elementy umożliwiające zasymulowanie pracy przekaźnika. Na potrzeby tego przykładu w schemacie zawarliśmy dwa styczniki oraz lampkę. Wybierz na przekaźniku 1 funkcję aplikacji oraz 1 tryb start.

Jeżeli jest to Twoje pierwsze podłączenie przekaźnika bezpieczeństwa, wróć do pierwszych odcinków kursu , gdzie szerzej opisujemy podłączenie wyłącznika E-STOP, a także poszczególne tryby i funkcje na pokrętle przekaźnika Preventa XPS Universal.

Schemat podłączeniowy przekaźnika bezpieczeństwa, źródło: ASTOR

Tworzenie programu w Codesys

Po podłączeniu układu przejdźmy do tworzenia programu. Uruchom Codesys, utwórz projekt i skomunikuj się ze sterownikiem.

Jeżeli nie pracowałeś jeszcze z oprogramowaniem Codesys, sprawdź nasz kurs, w którym poznasz podstawy pracy z tym środowiskiem.

Następnie dodaj nowy Task z odpowiednim czasem cyklu. W tym wypadku będzie to 25 ms.

Tworzenie tasku w Codesys, źródło: ASTOR

Następnie utwórz nowy program i dodaję go do utworzonego Tasku. Na potrzeby tego przykładu, wybierz język drabinkowy.

Tworzenie programu w Codesys, źródło: ASTOR

Kolejno nadaj nazwę wejściu cyfrowemu sterownika PLC, które będzie zbierać sygnały z przekaźnika. Ułatwi Ci to dalszą pracę.

Zmiana nazwy wejścia cyfrowego w Codesys, źródło: ASTOR

Przygotowany program jest gotowy na dodanie pliku FB_PreventaDiag. Do programu przeciągnij zwykły box, ustaw jego typ na FB_PreventaDiag. Jako zmienną bloku możesz wybrać zmienną generowaną automatycznie. Do wejścia i_xEnable wykorzystaj zmienną bEnableDiag. Do wejścia i_xDiagSignal podłącz sygnał z wejścia sterownika DI1_Z1. Na wejście i_timTaskCycle podaj ustawiony czas cyklu taska, czyli T#25MS.

Dodawanie i konfigurowanie bloków w Codesys, źródło: ASTOR

W tym momencie możesz przeprowadzić już pierwszy test sytemu. Skompiluj program i wgraj go na sterownik.

Wstępne uruchomienie programu, Źródło: ASTOR

W trakcie dekodowania sygnału wyjście q_xBusy jest aktywne. Gdy zostanie wykryta poprawna sekwencja, na jeden cykl aktywowane jest wyjście q_xValid. W tym czasie wyjście q_xBusy jest nieaktywne.

Na wyjściu q_dwStatus podana jest wartość zdekodowanego stanu. W tym wypadku jest to wartość 47 odpowiadająca stanowi xOperational w strukturze na wyjściu q_stDiagCode. Oznacza to, że przekaźnik działa poprawnie, a jego wyjścia są załączone.

W przypadku zwarcia wejścia i_xDiagSignal do stanu niskiego lub wysokiego na stałe, załączane jest odpowiednie wyjście bloku.

Aktywowany blok FB_PreventaDiag, źródło: ASTOR

Jak pewnie sam/a widzisz, blok FB_PreventaDiag daje ogromne możliwości zaawansowanej diagnostyki przekaźnika. Blok FB_PreventaMain idzie o krok dalej, pozwalając obliczyć zużycie komponentów systemu bezpieczeństwa na podstawie zdekodowanych stanów.

Aby skorzystać z tej funkcji, w pierwszej kolejności dodaj blok do programu oraz podłącz sygnały dwStatus oraz xValid ze zdefiniowanego wcześniej bloku FB_PreventaDiag, tak jak na grafice poniżej:

Bloki FB_PreventaDiag oraz FB_PreventaMain w Codesys, źródło: ASTOR

Następnie utwórz odpowiednie zmienne odpowiedzialne za konfigurację ilości cykli zadziałania odpowiednich urządzeń.

W pierwszej kolejności musisz przyjąć żywotność cykli pracy dla wyjść przekaźnika. W tym przykładzie ustaw tę wartość jako 1000000. W tym celu zdefiniuj strukturę typu ST_DevControl z zainicjalizowanym parametrem udiMaxNumOp o wartości 1000000.

Definiowanie struktury, źródło: ASTOR

Ważne: Pamiętaj, że do wszystkich typów obiektów z biblioteki Preventa Support Library należy odnosić się poprzez przestrzeń nazw biblioteki, domyślnie jest to „preventa". Input Assistant automatycznie podpowiada typ struktur, który jest błędny. Pamiętaj aby dopisać przed nazwą typu słowo preventa zakończone kropką.

W podobny sposób zdefiniuj podłączone urządzenia wejściowe. Na wejście i_astControlInp podaj tablicę od 6 struktur ST_InputControl. W tej aplikacji E-Stop podłączony jest do wejść S12 oraz S22, a więc przypisz odpowiednio wartości 12 oraz 22 do zmiennych byMonitorInput1 oraz byMonitorInput2 pierwszego elementu tablicy. Wykorzystywany E-Stop może wykonać 300 000 cykli pracy, więc przypisz tę wartość do zmiennej udiMaxNumOp.

Definiowanie struktury dla wejść, źródło: ASTOR

Podobnie zdefiniuj żywotność urządzeń wyjściowych wykorzystując strukturę typu ST_ControlOut. Są to 2 styczniki o trwałości 6 mln cykli. Dla podłączonej lampki nie trzeba podawać zużycia.

Definiowanie struktury dla wyjść, źródło: ASTOR

Stworzony program wygląda następująco:

Program ze zdefiniowanymi zmiennymi strukturalnymi w Codesys, źródło: ASTOR

Następnie skonfiguruj wejścia odpowiedzialne za przeprowadzanie rutynowych testów systemu. Jeśli pozostawisz te wejścia nie podłączone, blok zgłosi błąd na wyjściu q_xError oraz q_wErrorId. Do wejścia i_dtTestIntervalRef podłącz aktualną datę i godzinę. W tym celu skorzystaj z bloku GetDateAndTime. Datę i godzinę odświeżaj co 30 sekund przy pomocy zegara TON.

Konfigurowanie czasu w Codesys, źródło: ASTOR

Zdefiniuj nową zmienną na wejściu i_udiTestInterv. Będzie ona określać, co ile dni powinien zostać wykonany test systemu. Dodatkowo podłącz sygnały do wejść i_xNewModuleActive oraz i_xTestExecuted.

Konfigurowanie cyklicznego testu w Codesys, źródło: ASTOR

Przyjmij, że test systemu powinien być wykonywany co 14 dni.

Przygotowany program diagnostyczny w Codesys, źródło: ASTOR

Ostatnią czynnością, jaką musisz wykonać, jest ustawienie wewnętrznych zmiennych bloku jako PERSISTENT RETAIN, aby po ponownym uruchomieniu sterownika nie utracić danych zapisanych w bloku. W tym celu dodaj do aplikacji obiekt Persistent Variables. Po otwarciu go, skompiluj ponownie aplikację a następnie w edytorze kliknij PPM i wybierz Add all instance paths.

Dodawanie obiektu Persistent Variables w Codesys, źródło: ASTOR

Automatycznie wygenerowane zostaną ścieżki do wewnętrznych zmiennych bloku FB_PreventaMain. Oznaczają one odpowiednio:

r_udiCountSystem – pozostała ilość cykli całego systemu,
r_audiCountInp – pozostała ilość cykli urządzeń wejściowych,
r_udiCountProc – pozostała ilość cykli przekaźnika Preventa,
r_audiCountOut – pozostała ilość cykli urządzeń wyjściowych,
r_adtProof – tablica ostatnich 10 wykonanych testów systemu bezpieczeństwa,
r_datTestStart – data pierwszego wykonanego testu dla nowego modułu.

Tak przygotowany program możesz wgrać do sterownika. W tym momencie blok FB_PreventaMain będzie zgłaszać błąd o numerze 4100 (16#1004). W dokumentacji znajdziesz informację, że wykryty został nowy moduł, ale nie został przeprowadzony pierwszy test instalacji.

W tej sytuacji trzeba przeprowadzić pierwszy test. W tym celu aktywuj wejście i_xNewModuleActive, co ustawi aktualną datę pierwszego testu oraz zrestartuje liczniki urządzeń i historię przeprowadzonych ostatnich 10 testów.

Uruchomienie pierwszego testu, źródło: ASTOR

Jak działa Twój program? Na wyjściu q_udiNumOpSystem podana jest ilość cyklów zadziałania systemu bezpieczeństwa. Rozwijając strukturę na wyjściu q_stRemainNumOp możesz odczytać pozostałą ilość cykli zadziałania poszczególnych urządzeń.

Gdy licznik danego urządzenia dojdzie do 0, na wyjście q_xOpExceeded podany zostanie stan wysoki a na q_wExceededId odpowiedni kod.

Liczba cykli zadziałania systemu, źródło: ASTOR

W tym wypadku dla podłączonego urządzenia wejściowego, czyli E-Stop, pozostały 2 aktywacje. Po wykonaniu 2 cykli, licznik audiNumOpRemainInp[1] osiąga 0. Aktywuje się wyjście wraz z kodem 16#1001 wskazującym na pierwsze urządzenie wejściowe. Zboczem narastającym dla zmiennej main_astControlInp[1].xReset zrestartujesz licznik na podaną wartość.

Rutynowe testowanie systemu bezpieczeństwa

Jak zatem działa rutynowe testowanie systemu bezpieczeństwa w stworzonej przez Ciebie aplikacji? Na wejście i_dtTestIntervalRef podana została aktualna data i godzina. Na wejściu i_udiTestInterv ustawione zostało, że test systemu powinien być wykonywany co 14 dni.

Data kolejnego testu podana jest na wyjściu q_datNextProof. Przekroczenie tej daty sygnalizowane jest poprzez wyjście q_xTestIntervViol. Wykonaj test systemu, a następnie zatwierdź wykonanie testu aktywując wejście i_xTestExecuted.

Wykonanie rutynowego testu systemu bezpieczeństwa, źródło: ASTOR

Data wykonanego testu zostanie zapisana w programie. Daty ostatnich 10 testów można odczytać z tablicy na wyjściu q_adtProofTests.

Możesz wcześniej zaplanowanie dni wykonywania testów bezpieczeństwa np. z poziomu panelu operatorskiego HMI. W tym celu musisz podać daty testów w formie tablicy na wejście i_adtProofTests i aktywować zapisanie zboczem narastającym na wejściu i_xSaveBProofTests.

Predefiniowane daty testów systemu, źródło: ASTOR

Tak oto udało Ci się stworzyć system monitorowania układu bezpieczeństwa w oparciu o zwykły przekaźnik bezpieczeństwa.

W kolejnej odsłonie kursu wrócisz do schematów i podłączeń, żeby skupić się na wyłącznikach krańcowych. Dowiesz się więcej o ich zastosowaniu, a także nauczysz się, jak je podłączyć.

Zobacz pełną wersję artykułu na Poradnik Automatyka.