Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2019/04/Weidmuller_protop_nowe-1.jpg

5 porad programowania sterowników PLC


W tym artykule zawarłem wskazówki, które według mnie przydadzą się przede wszystkim początkującym automatykom. Niezależnie od tego, z jakimi sterownikami PLC masz styczność na co dzień oraz w jakim języku programujesz – jestem pewien, że stosowanie się do poniżej przedstawionych zasad znacznie ułatwi Ci pracę – przede wszystkim z rozbudowanymi aplikacjami.

1. Stosuj logikę pozytywną

Projektowanie algorytmu sterowania ułatwia konsekwentne stosowanie logiki pozytywnej (naturalnej) do opisu deklarowanych zmiennych. W przypadku bardziej złożonych aplikacji, uprości to nam i/lub osobom, które będą miały w przyszłości styczność z naszym kodem, interpretację poszczególnych funkcji zawartych w programie. W szczególności, kiedy projekt zostanie przywołany po dłuższym czasie. Używanie zaprzeczeń w wyrażeniach logicznych może często wprowadzać w błąd, dlatego przyjmuje się, że kiedy zmienna przyjmuje wartość “1”, powinno to oznaczać zaistnienie odpowiadającego jej zjawiska.

Przykłady poprawnego opisywania zmiennych:

  • zmienna “diSensor1” odpowiadająca sygnałowi z czujnika indukcyjnego, przyjmuje wartość “1”, kiedy czujnik wykrywa detal;
  • zmienna “diMotorFailure” opisująca wystąpienie awarii silnika elektrycznego, jest w stanie wysokim, kiedy silnik ulegnie uszkodzeniu;
  • zmienna “diButtonStart” odpowiadająca przyciskowi z panelu operatora, ma wartość “TRUE”, kiedy przycisk jest wciśnięty – bez względu na to, czy jego styki są normalnie otwarte (NO), czy normalnie zamknięte (NC).

Przykładem zmiennej, której opis może wprowadzać w błąd jest “motorStartNotEnabled” – przyjmująca wartość “1”, kiedy zezwolenie na pracę silnika elektrycznego jest nieaktywne. Używając tak opisanej zmiennej w złożonych konstrukcjach logicznych, możemy wprowadzić niepotrzebne zamieszanie.

Kiedy musimy użyć zaprzeczenia bądź sprawdzić warunek negatywny, w języku programowania ST możemy użyć funkcji NOT(), która zwraca przeciwną wartość przekazanej zmiennej typu BOOL, natomiast w języku programowania drabinkowego LD, należy użyć symbolu negacji:

2. Twórz opisowe nazwy zmiennych

Można żartobliwie powiedzieć, że sposobów nazywania zmiennych jest prawdopodobnie tyle, co opisujących ten temat programistów. Jednak z punktu widzenia projektowania algorytmów na sterowniki PLC, warto trzymać jednej zasady – symboliczna nazwa zmiennej powinna wskazywać funkcję, pochodzenie lub odbiorcę informacji, której odpowiada, np.:

  • “gMotorSpeed” – zmienna przechowująca zadaną prędkość pracy napędu,
  • “diButtonStart” – wejście cyfrowe skojarzone z przyciskiem uruchamiającym maszynę,
  • “doGreenLed” – wyjście binarne sterujące pracą zielonej diody led.

Dodatkowo, stosuję trzy przedrostki, które pozwalają mi wyróżnić kluczowe zmienne, co jest niezwykle przydatne przy rozbudowanych programach:

  • “g” – zmienne globalne,
  • “di” – zmienne przypisane do wejść cyfrowych,
  • “do” – zmienne przypisane do wyjść cyfrowych.

Ta praktyka nie jest konieczna. Jednak wracając do programu, który napisaliśmy jakiś czas temu lub modyfikując aplikację stworzoną przez innego automatyka, po napotkaniu zmiennych nazywanych w ten sposób, możemy od razu wywnioskować, jaka jest ich rola w algorytmie sterowania i do czego się odnoszą.

W zależności od producenta czy typu sterownika, mogą być narzucone różne ograniczenia odnośnie przypisywania nazw tagów. Obostrzenia mogą dotyczyć ilości znaków lub wykluczenia niektórych znaków specjalnych (np. podkreślnika). Bez względu na to, powinniśmy dążyć do tego, aby nazwy były jednoznaczne, opisowe i jak najkrótsze jednocześnie. Ta porada może wydawać się błaha, jednak niejednokrotnie spotykałem się z programami, w których użyte był zmienne o nazwach: “X” lub “aaa”. Szanuj więc czas swój (w przyszłości) i innych, którzy będą mieli dostęp do Twojego kodu.

3. Właściwie wykorzystuj zbocza

Zbocza, czyli informacje o zmianie stanu sygnału/zmiennej z niskiego na wysoki (zbocza narastające – ang. rising edge lub positive transition) lub z wysokiego na niski (zbocza opadające – ang. falling edge lub negative transition), są bardzo często używane w algorytmach sterowania. W układach automatyki sterowanych przy użyciu sterowników PLC, zbocza stosowane są najczęściej do kontrolowania uruchamiania urządzeń oraz śledzenia zmian sygnałów cyfrowych (np. z czujników).

Ich wykorzystanie w aplikacji umożliwia wykrycie momentu rozpoczęcia lub zakończenia jakiegoś zdarzenia, np. przełączenia pozycji kluczyka, naciśnięcia przycisku na panelu sterowniczym, czy też pojawienia się jakiegoś obiektu w zasięgu czujnika optycznego. “Wychwycenie” takiej zmiany stanu zmiennej (zbocza) sygnalizowane jest pojawieniem się impulsu dokładnie przez jeden cykl pracy sterownika.

Doskonałym przykładem obrazującym działanie zboczy może być przycisk panelu operatora, podłączony do wejścia cyfrowego PLC.

Jak widać na powyższym przebiegu sygnałów – nie ma znaczenia, na jak długo przycisk zostanie wciśnięty przez operatora – w przypadku zboczy, program otrzyma impuls tylko raz, na jeden cykl sterownika.

Początkującym automatykom zdarza się błędnie wykorzystywać zbocza sygnałów w konstrukcjach warunkowych, sprawdzających wystąpienie dwóch lub więcej zdarzeń jednocześnie. Rozważmy przykładową sytuację, w której działanie jednego z elementów algorytmu sterowania przenośnikiem taśmowym (doAction) uzależnione jest od równoczesnego pojawienia się stanów wysokich na wejściach cyfrowych sterownika PLC, do których podłączone są: czujnik optyczny wykrywający detal (diSensor1) oraz czujnik indukcyjny sprawdzający, czy wykryty detal jest metalowy (diSensor2).

Pamiętając o fakcie, że program rejestruje impuls wygenerowany przez wykrycie zbocza tylko przez jeden cykl pracy sterownika (trwający zazwyczaj ułamki sekundy), niepoprawnym rozwiązaniem w tym wypadku byłoby sprawdzanie jednoczesnego wystąpienia dwóch zboczy sygnałów ze wspomnianych czujników:

Praktycznie niemożliwym jest bowiem ustawić dwa różne czujniki w taki sposób, aby ich pola detekcji pokrywały się ze sobą w 100%. Zachodzi duże prawdopodobieństwo, że jeden z czujników poda sygnał na wejście sterownika PLC wcześniej od drugiego. W związku z tym, warunek logiczny, który sprawdza pojawienie się dwóch niezależnych zboczy sygnałów z czujników w tym samym momencie, nigdy nie zostanie spełniony, a tym samym maszyna nie będzie działać poprawnie.

Prawidłowym podejściem będzie zastosowanie detekcji jednego zbocza iloczynu logicznego sygnałów z dwóch czujników:

W powyższym fragmencie programu, iloczyn logiczny sygnałów z obu czujników przechowywany jest w zmiennej pomocniczej “bothSensorsActive”, której zbocze pozytywne wysterowuje wyjście sterownika “doAction”.

4. Używaj własnych typów danych

Projektowanie rozbudowanych algorytmów sterowania, w których wymagane jest kontrolowanie wielu urządzeń tego samego rodzaju, wymusza na programiście powielanie zmiennych. Chcąc uniknąć przedzierania się przez niewygodnie długą listę zadeklarowanych obiektów, warto zastosować własne typy danych (zmiennych), które umożliwią lepszą organizację naszego programu. W zależności od producenta, własne typy zmiennych występują pod różnymi nazwami, np.: w TIA Portal Siemens’a są określane mianem UDT (User Defined Datatype), z kolei w B&R Automation Studio nazywane są po prostu “Structure Type”.


Za dobry przykład, obrazujący korzyści wynikające z zastosowania własnych typów zmiennych, może posłużyć linia technologiczna składającą się z 10 przenośników taśmowych. Załóżmy, że każdy z tych przenośników wyposażony jest w:

  • napęd elektryczny z obsługą informacji o awarii,
  • dwa czujniki optyczne: na początku i na końcu transportera,
  • barierę optyczną służącą do określania, czy przejeżdżający detal ma odpowiednią wysokość.

Rozpatrując ten przypadek, dla każdego z przenośników musielibyśmy zadeklarować co najmniej 5 zmiennych: “doMotorStartX” (uruchomienie napędu), “diMotorFailureX” (awaria napędu), “diSensorStartX”, “diSensorEndX” (dwa sygnały cyfrowe z czujników krańcowych) oraz “diHeightOKX” (sygnał cyfrowy z bariery), gdzie X byłby numerem przenośnika. Mając do zaprogramowania pracę 10 przenośników, wiązałoby się to z wprowadzeniem aż 50 pozycji na listę zmiennych!

Tworząc własny typ zmiennej o nazwie “Conveyor”, zawierający wymienione powyżej pola (start/stop napędu, awaria napędu, itd.), zmniejszamy liczbę zadeklarowanych zmiennych do 10. Po takim zabiegu, wystarczy, że wprowadzimy 10 zmiennych typu “ConveyorX” (X – numer przenośnika).

Typ “Conveyor” wprowadzony w B&R Automation Studio.

10 zmiennych typu “Conveyor” zadeklarowanych w B&R Automation Studio.

Programując w języku ST na sterownikach B&R, możemy się odwołać do poszczególnych pól stawiając kropkę po nazwie zmiennej danego typu, np. chcąc uruchomić napęd przenośnika trzeciego wystarczy napisać następującą linijkę:

Conveyor3.doMotorStart := TRUE;


5. Porządkuj i komentuj kod programu

Ostatnia, lecz nie najmniej istotna porada, której stosowanie ułatwi Ci kontrolę nad Twoim programem, dotyczy szeroko pojętej organizacji kodu. Streściłem to zagadnienie do trzech punktów:

  • rozbijaj duże aplikacje na podprogramy odpowiadające funkcjonowaniu poszczególnych elementów maszyny bądź fizycznemu podziałowi linii technologicznej, którą programujesz. Zasada ta dotyczy przede wszystkim złożonych projektów. Nie ma nic gorszego niż przewijanie gigantycznego “Main’a” składającego się z tysięcy linijek kodu lub network’ów – o wiele łatwiej poruszać się po kilku osobnych podprogramach, których logiczna organizacja odpowiada rzeczywistemu porządkowi procesu;
  • używaj własnych funkcji i bloków funkcyjnych – dzięki temu zapobiegniesz zasypaniu Twojego projektu nadmiarowym kodem i znacznie przyspieszysz swoją pracę – w szczególności jeżeli zajdzie potrzeba rozbudować aplikację po jakimś czasie. Kiedy algorytm wymusza wielokrotne wykonywanie tej samej operacji, tak jak w przypadku wspomnianej w poprzednim punkcie linii przenośników taśmowych, warto zapisać powtarzający się kod w postaci funkcji, którą będziemy mogli wywołać w dowolnym momencie;
  • komentuj kod – wśród programistów popularne jest twierdzenie, że dobrze napisany program nie wymaga dodatkowych opisów – osobiście, po otwarciu czyjegoś projektu, wolałbym zobaczyć nadmiar komentarzy niż ich całkowity brak. Nie raz przekonasz się, powracając po czasie do napisanych przez siebie aplikacji, że komentarze mogą znacznie przyspieszyć pracę. Dokumentując swój proces myślowy oszczędzisz mnóstwo czasu w przyszłości!

Artykuł został nagrodzony w Konkursie iAutomatyka – edycja Kwiecień 2019

Nagrodę Voucher na szkolenie Mitsubishi Electric dostarcza ambasador konkursu, firma Mitsubishi Electric.

 



Utworzono: / Kategoria: , , ,

Reklama

Newsletter

Zapisz się i jako pierwszy otrzymuj nowości!



PRZECZYTAJ RÓWNIEŻ



NAJNOWSZE PUBLIKACJE OD UŻYTKOWNIKÓW I FIRM

Reklama



POLECANE FIRMY I PRODUKTY