Programowanie w języku drabinkowym: obsługa awarii oraz wyświetlanie komunikatów

W języku drabinkowym podprogramy obsługi awarii są wykorzystywane do wychwycenia sytuacji odbiegających od normalnych, natomiast każda cela robocza lub urządzenie zwykle ma w programie sterującym swój własny podprogram obsługi awarii i może wysyłać komunikaty do interfejsu operatorskiego (HMI) lub programowalnego sterownika logicznego (PLC).

W języku drabinkowym, powszechnie używanym do programowania sterowników PLC (ladder logic, logika drabinkowa), podprogramy obsługi awarii (fault) są wykorzystywane do wychwytywania sytuacji odbiegających od normalnych, np. wówczas, gdy siłownik nie wykonuje całkowicie ruchu w przewidzianym czasie. Każda cela robocza lub urządzenie na linii produkcji zwykle ma w programie sterującym swój własny podprogram do obsługi awarii.

Zazwyczaj definiowana jest jedna awaria na każdy rodzaj ruchu (wysuwanie, chowanie, podnoszenie, opuszczanie itd.). Innymi awariami mogą być: brak ciśnienia powietrza, naciśnięcie przycisku stopu awaryjnego, otwarcie wyłącznika drzwi bezpieczeństwa oraz niewłaściwa praca lub przeciążenie napędu. Awaria systemu wyłącza układ czasowy (timer) na awaryjnym szczeblu drabinki. Służy to dwóm celom:

1️⃣ Tylko ta awaria, która występuje jako pierwsza, jest dozwolona. Zapobiega to występowaniu kolejnych awarii, które mogłyby być spowodowane przez awarię początkową. Jeśli w instalacji sprężonego powietrza wystąpi brak ciśnienia, to kilka siłowników pneumatycznych może ulec awarii podczas tego samego zdarzenia.

2️⃣ Po wystąpieniu awarii układ czasowy się zeruje, co umożliwia nowe odliczanie. Pozwala to na fizyczne usunięcie awarii przez pracowników utrzymania ruchu lub operatora.

Większość oprogramowania interfejsów HMI pozwala użytkownikowi sporządzać listę awarii, a następnie wywoływać te awarie po numerze w celu wyświetlania ich na banerze lub innym sposobem wyświetlania tekstu. Źródło: Automation Primer

Istnieje kilka metod kasowania (resetowania) awarii. Jedną z nich jest skasowanie tego słowa rejestru, które zawiera te awarie, w tym przykładzie słowa 10. To słowo awarii przyporządkowane może być tylko dla jednej konkretnej cali roboczej, co umożliwia systemowemu sygnałowi resetu skasowanie awarii w sekcjach, jeśli to pożądane; słowa 10 dla gniazda 1, słowa 11 dla gniazda 2 itd. Inną metodą jest indywidualne resetowanie lub odblokowywanie awarii.

Te sygnały kasujące mogą być także indywidualnie definiowane i uwarunkowywane w ten sposób dla każdego szczebla drabinki programu. Podprogramy obsługi awarii mogą być także wykorzystane na szczeblu dopuszczającym drabinki, aby zapobiec ruchowi siłownika wzdłuż osi. Bity awarii są także wykorzystywane do aktywacji komunikatów na ekranie dotykowym lub interfejsie operatorskim (HMI), np. bit 10.0 może spowodować wyświetlenie komunikatu „Axis SV1.0 Failed to Extend; Correct Fault and Press reset” („Oś SV1.0 – nie udało się wysunąć, usuń awarię i naciśnij Reset”). Komunikat ten może być skasowany po usunięciu awarii i naciśnięciu przycisku Reset.

Istnieje kilka różnych sposobów wyświetlania komunikatów o awariach na interfejsie HMI. Większość oprogramowania HMI pozwala użytkownikowi na przygotowanie listy awarii, a następnie wywołanie ich według liczby, aby wyświetlić w banerze lub jako inny typ wiadomości tekstowej.

Inną możliwością jest skonfigurowanie wyzwalacza wyświetlania komunikatów według liczby bitów. To pozwala także na wyświetlanie wielu komunikatów w cyklu czasowym – w przeciwieństwie do sytuacji, gdy komunikat miał być wyświetlany według wartości lub umieszczania liczby w rejestrze komunikatów.

Kolor tła komunikatu również może być skonfigurowany, tak więc komunikaty i ostrzeżenia o awariach oraz wszystkie inne istotne informacje tekstowe mogą być wyświetlone w tym samym banerze. Jest to szczególnie pomocne w przypadku, gdy interfejs HMI jest niewielki i nie ma w nim miejsca na duży wyświetlacz mogący pokazywać więcej niż pojedynczy komunikat. Poza awariami i komunikatami wyświetlacze te mogą być wykorzystane np. jako wskaźniki wielostanowe, do pokazywania trybu pracy maszyny lub statusu stacji. Mogą być także skonfigurowane inne właściwości wyświetlacza komunikatów, takie jak jego widoczność (kontrast).

Innym sposobem skonfigurowania wyzwalacza jest wyświetlanie komunikatu według numeru bitu, co umożliwia wyświetlanie wielu komunikatów w cyklu czasowym – w przeciwieństwie do sytuacji, gdy komu-nikat jest wyświetlany według wartości lub umieszczania liczby w rejestrze komunikatów. Źródło: Automation Primer

Konfigurowanie wyświetlania komunikatów według bitów, a nie według wartości

Wykorzystywanie bitów do wyświetlania komunikatów o awariach zamiast do przekazywania wartości ma zarówno zalety, jak i wady. Użycie bitów w tej konwencji umożliwia na jednoczesne zaistnienie kilku „stanów” lub komunikatów, podczas gdy wartość pozwala na wywołanie tylko jednego komunikatu. W przypadku gdy interfejs HMI nie ma możliwości cyklicznego wyświetlania komunikatów przy jednocześnie aktywnych kilku wyzwalaczach bitowych, będzie niezbędne napisanie kodu dla programowalnego sterownika logicznego (PLC), który będzie to umożliwiał.

Inną metodą, która jest czasami stosowana dla wyświetlaczy komunikatów, jest proste umieszczenie wyświetlacza ciągu tekstowego na ekranie. Metoda ta jest nieskomplikowana od strony interfejsu HMI, jednakże wymaga, aby program sterownika PLC realizował swoje cykle poprzez łańcuchy tekstowe i umieszczał je w rejestrze komunikatów, który oczywiście musi obsługiwać dane typu STRING.

Technika ta ma zarówno zalety, jak i wady.

Zaletą jest to, że programista sterownika PLC może zmieniać dynamicznie komunikaty tekstowe. W rzeczywistości programista ten może umożliwić dostęp do komunikatów użytkownikowi ekranu dotykowego przez umieszczenie na ekranie linków do lokalizacji rejestrów tekstu. To pozwala na konfigurowanie komunikatów bez konieczności użycia oprogramowania HMI.

Wadą jest natomiast to, że trudno jest zarządzać kolorem tekstu czy tła, używając łańcuchów tekstowych. Tło powinno mieć przypisany rejestr koloru, który będzie zarządzany osobno.


Frank Lamb jest założycielem firmy Automation Consulting LLC oraz członkiem Redakcyjnej Rady Konsultacyjnej Control Engineering.