Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2018/05/kurs-programowania-plc-WAGO-pfc200-w-ecocpit-cz2.jpg

Kurs programowania sterowników PLC na przykładzie pompowni w e!COCKPIT – cz. 2/5


Artykuł z serii: Kurs programowania PLC na sterowniku WAGO PFC


Pierwszy odcinek naszej serii miał na celu utworzenie prostego projektu z programem w języku drabinkowym oraz wizualizacją, które będzie można uruchomić oraz przetestować w symulatorze. W drugiej części zajmiemy się zasadniczym celem całej serii – budową pełnowartościowej aplikacji.

W tym artykule:

  • Utworzymy definicję struktury napędu pompy.
  • Utworzymy definicję bloku kontroli pompy.
  • Zadeklarujemy w zmiennych globalnych struktury dwóch pomp oraz stop bezpieczeństwa.
  • Uzupełnimy program o bloki kontroli pomp.
  • Przeprowadzimy symulację programu.

Program e!COCKPIT można pobrać ze strony producenta >> TUTAJ. <<

Struktura w programowaniu sterowników PLC

Struktura zgodnie z normą IEC_61131-3 jest złożonym typem danych, który może się składać z jednej lub więcej zmiennych różnych typów – w przeciwieństwie do tablicy, która może się składać z wieli zmiennych, ale tego samego typu. Służy ona do modelowania zadanego problemu – przedstawienia go tak, ażeby stał się on dla programisty czytelniejszy, spójniejszy, bardziej intuicyjny.

W programowaniu sterowników przemysłowych modelujemy w ten sposób najczęściej – choć nie tylko – konkretne urządzenia, takie jak pompy, siłowniki, zawory, przetworniki, napędy itd. W ten sposób struktura danych związana z danym typem urządzeń czy układów zdefiniowana jest raz, a w programie może być wykorzystywana wielokrotnie. Użycie struktury gwarantuje spójność danych oraz ich powtarzalność.

Definicja struktury napędu pompy

W celu utworzenia definicji struktury klikamy PPM na aplikację i wybieramy typ danych użytkownika DUT <ang. Data User Type>.

Rys. 1. Tworzenie definicji struktury.

DUT jest w Codesys 3 ogólnym określeniem typów danych definiowanych przez użytkownika. Jednym z nich jest oczywiście struktura (pole nr 1), ale nie tylko. Możemy również zdefiniować typ wyliczeniowy <ang. enumeration> (pole nr 2), alias (pole nr 3) czy unię (pole nr 4). Tworząc strukturę możemy wykorzystać znany z programowania zorientowanego obiektowo <ang. Object-Oriented Programming> mechanizm dziedziczenia <ang. inheritance> dzięki wykorzystaniu funkcji „Extends” (pole nr 5), co jest jednak tematem daleko wykraczającym poza ramy tego kursu – polecam pliki pomocy Codesysa oraz tematy na forum poświęconym Codesysowi. My w tym momencie tylko skromnie nadamy nazwę definicji naszej struktury (pole nr 6).

Rys. 2. Definicja struktury pompy.

Na powyższym ekranie widzimy napisaną przeze mnie definicję napędu pompy. Okno przypomina funkcjonalnie okno zmiennych globalnych czy też chociażby zmiennych lokalnych programu – i w istocie ma prawie identyczną funkcjonalność. Widok definicji struktury w Codesys 3 jest dostępny tylko w postaci tekstowej zgodnej ze składnią języka ST – Structured Text, w przeciwieństwie do widoku tabelarycznego. W naszym przypadku widzimy nazwę zmiennej (pole nr 1), jej typ (pole nr 2),  komentarz(pole nr 3) oraz w przypadku stałej błędu wyłączenia/załączenia pompy wartość inicjalizacyjną (pole nr 4). Kolumny nie widoczne w tym widoku, takie jak adres czy atrybuty, możemy jak najbardziej wykorzystać, używając stosownej składni zgodnej z ST. Z drugiej strony mamy pełną swobodę w pisaniu komentarzy, co wykorzystałem do podzielenia pól struktury według funkcji, pisząc odpowiednie nagłówki(pole nr 5).

Zmienne zdefiniowałem zgodnie z konwencją przedstawioną w poprzednim artykule:

  • Nazwa zmiennej pisana zgodnie z notacją węgierską.
  • Prefiks informujący o typie zmiennej: x -> BOOL, t -> TIME.
  • Prefiks z podkreśleniem informujący o innych istotnych informacjach: I_ -> wejście fizyczne, O_ -> wyjście fizyczne, c_ -> stała.
  • Komentarz informujący o zmiennej oraz ewentualnie o jego logice.

Pozostałe elementy widoku stanowią słowa kluczowe, które są stałym elementem definicji struktury.

W strukturze zawarłem wejścia i wyjścia fizyczne związane z napędem pompy, które wynikają z założonych sygnałów idących do/ze sterownika – porównajcie z listą sygnałów przedstawionych w poprzednim artykule. Poza nimi umieściłem też flagi, które będą generowane przez blok funkcyjny kontroli pompy, o którym opowiem w następnym punkcie.

Blok funkcyjny kontroli pompy

Blok funkcyjny to jednostka organizacyjna programu POU, która posiada następujące cechy:

  • Zawiera kod programu napisany w jednym z dostępnych języków programowania IL, LAD, FBD, ST, CFC, SFC.
  • Nowy blok tworzymy poprzez utworzenie definicji – stanowi ona „matrycę” dla deklarowanych w programie instancji bloku. Definicja w momencie utworzenia stanowi nowy typ danych, taki sam jak BOOL czy INT.
  • Aby jego użyć, należy zadeklarować jego użycie, tworząc instancję bloku. Instancja stanowi przestrzeń pamięci, w którym przechowywane są zmienne bloku funkcyjnego.

Zadanie domowe dla czytelników – poszukajcie i porównajcie, czym blok funkcyjny różni się od funkcji, programu i akcji.

Powołajmy więc do życia blok funkcyjny kontroli pompy. Jej celem będzie na podstawie wejść i wyjść fizycznych kontrolować stan napędu pompy oraz generować informacje o jej stanie.

Rys. 3. Tworzenie definicji bloku funkcyjnego.

Aby utworzyć definicję bloku funkcyjnego, klikamy PPM na aplikację i wybieramy POU. W otwartym oknie wybieramy „Function block” (pole nr 1). Poniżej znajduje się kilka pól i opcji do wyboru, którymi się nie będziemy zajmować w tym kursie – związane są one z wspomnianym już programowaniem zorientowanym obiektowo (pole nr 2). W tym oknie musimy jeszcze wybrać język bloku funkcyjnego (pole nr 3) oraz nadać mu nazwę (pole nr 4).

Rys. 4. Definicja bloku funkcyjnego kontroli pompy

Spójrzmy na edytor bloku funkcyjnego. Na górze znajduje się znany już z edytora programu pole ze zmiennymi bloku funkcyjnego. Zwróćcie uwagę na ikonkę zmiany widoku  (pole nr 1) – można nią przełączyć na widok tekstowy poznany już z edytora struktury i z powrotem na tabelaryczny – w przypadku POU’ów możemy wybrać, choć osobiście preferuję tabelaryczny.

Jako zmienne służące do wymiany danych zadeklarowaliśmy:

  • Wejściowo-wyjściową: io_stPompa typu ST_Pompa (pole nr 2).
  • Wejściową: i_xStopBezp typu BOOL (pole nr 3).

Interesująca jest tu pierwsza zmienna, która jest strukturą. Dzięki temu nie muszę robić dziesięciu zmiennych wejściowych i dziesięciu wyjściowych, tylko przekazuję strukturę jako całość. Znacznie przyspiesza to pracę oraz zmniejsza podatność na błędy wynikające z metody „kopiuj-wklej” na powielanych wielokrotnie z drobnymi zmianami fragmentach kodu.

Pozostałe zmienne to lokalne deklaracje bloków funkcyjnych timerów typu TON oraz detekcji zboczy narastających typu R_TRIG (pole nr 4).

Edytor kodu języka LAD poznaliśmy w poprzednim odcinku, a kod tej pompy jest napisany zgodnie z przyjętą konwencją, więc omówimy tylko nowe elementy. Są nimi bloki funkcyjne – dwie instancje timerów TON oraz dwie instancje bloków detekcji  zbocz narastających R_TRIG. Są one blokami funkcyjnymi na tej samej zasadzie, co definiowany przez nas „FB_KontrPomp”. W tym momencie deklaracje tych bloków w „FB_KontrPomp” są jeszcze „wirtualne” – rejestry pamięci tych instancji będą im przydzielone w momencie deklaracji używającego ich bloku funkcyjnego, co nastąpi później w programie.

Sposób wstawienia bloków funkcyjnych omówiłem w następnym akapicie – w tym widoku ukryłem przybornik, żeby nie przysłaniał kodu programu.

Struktury i bloki funkcyjne w programie

Po zdefiniowaniu struktury oraz bloku funkcyjnego możemy przejść do wpisania ich do naszego programu.

Rys. 5. Zaktualizowana globalna lista zmiennych.

Pierwszym krokiem jest uzupełnienie globalnej listy zmiennych  o dwie deklaracje struktury pompy (pole nr 1) oraz stop bezpieczeństwa (pole nr 2). Umieścimy je właśnie w globalnej liście zmiennych, a nie w zmiennych lokalnych programu, ponieważ w późniejszym etapie byśmy mogli widzieć potrzebę ich użycia w innych programach – np. gdybyśmy stworzyli program detekcji i obsługi sytuacji alarmowych. Przejdźmy teraz do programu.

Rys. 6. Deklaracja bloku kontroli pompy w programie głównym

Zaczniemy od zadeklarowania dwóch bloków kontroli pomp (pole nr 1). Ich deklaracje zdecydowałem się umieścić w programie, ponieważ poza nim nigdzie nie będę korzystał ze zmiennych instancji tych bloków.

Wstawmy teraz rzeczone bloki do drabinki. Z przybornika bierzemy element „Box” (pole nr 2). Jest to element, w którego środku w polu tekstowym określamy jego funkcjonalność – słowo kluczowe, operator konwersji, wywołanie bloku funkcyjnego, funkcji, akcji lub programu (pole nr 3). Powyżej – jeśli mamy do czynienia tak jak w tym przypadku z blokiem funkcyjnym – znajduje się nazwa wywoływanej instancji (pole nr 4). Po prawej stronie bloku znajduję się zmienne wejściowo-wyjściowe, które są oznaczone przez obustronną strzałkę, czyli u nas „io_stPompa (pole nr 5) oraz zmienne wejściowe, czyli u nas „i_xStopBezp” (pole nr 6). Zwróćcie uwagę, że w przypadku, gdy zmienna wejściowa jest typu BOOL, to do wejścia zamiast „czystej” zmienne można podać w edytorze styk NO/NC lub też cały układ logiczny, którego wynik zostanie przypisany do zmiennej.

Symulacja i testowanie

Po napisaniu programu czas przetestować nasze dzieło.

Rys. 7. Widok online programu głównego.

Po uruchomieniu symulacji – co przećwiczyliśmy w poprzednim artykule – sprawdźmy działanie napisanych przez nas struktur oraz bloków funkcyjnych.

Z racji tego, że nasza aplikacja znacznie się rozrosła w porównaniu do pierwszego odcinka, symulację będziemy omawiać etapami. Zaczniemy od ekranu programu „P_ProgGlow”, którego ekran maksymalizowałem w celu przedstawienia większej ilości ciekawych szczegółów, które w poprzednim odcinku ze względu na objętość pominęliśmy.

Zaczynając od góry widzimy nazwę wywoływanego POU’a (pole nr 1). Brzmi ono „Controller.Application.P_ProgGlowny”. Skąd tak długa nazwa, skoro uruchamiamy tylko „P_ProgGlow”? Wynika to stąd, że w jednym projekcie Codesys 3 może się znajdować wiele sterowników – u nas domyślna nazwa „Controller” – oraz wiele aplikacji – „Application”. Zapisując w ten sposób nazwę otwartego w edytorze POU’a łatwiej jest się zorientować w dużych projektach, na czym pracujemy.

Poniżej znajduje się okno ze zmiennymi wewnętrznymi POU’a (pole nr 2). U góry znajduje się instancja bloku funkcyjnego kontroli pompy P1 (pole nr 3). Rozwijając widok bloku za pomocą „plusa” zobaczymy jego zmienne – wejściowo-wyjściową struktury pompy oraz stop bezpieczeństwa. Zwróćcie uwagę na opis typ „io_stPomp” – „REFFERENCE_TO_ST_Pompa” (pole nr 4). Oznacza to, że o ile w przypadku zmiennych wejściowych w trakcie wywołania POU’a jej wartość jest przekopiowywana do zmiennej wewnętrznej POU’a, to wartości zmiennych wejściowo-wyjściowych są czytane bezpośrednio oraz są modyfikowane bezpośrednio. Dlaczego to takie ważne? Trzeba być świadomym niebezpieczeństwa, że możemy przypadkiem zmodyfikować zawartość takiej zmiennej, ponieważ mamy do niej nieograniczony dostęp w kwestii odczytu i zapisu. Używając zmiennych wejściowo-wyjściowych – cytując kodeks drogowy – należy zachować szczególną ostrożność.

Spójrzmy na konsekwencje w praktyce. Spróbujcie zmodyfikować za pomocą znanej wam już kolumny „Prepered value” zmodyfikować zmienne składowe bloku kontroli pompy P1 „fbKontrP1.io_stPomp.I_xPraca”, „fbKontrP1.io_stPomp.xDostep”, a także „fbKontrP1.i_xStopBezp”. W efekcie:

  • Modyfikując „fbKontrP1.io_stPomp.I_xPraca” zmodyfikujecie „gSt1.stP1.I_xPraca” – sprawdźcie w widoku globalnej liście zmiennych.
  • Nie zmodyfikujecie „fbKontrP1.io_stPomp.xDostep”, ponieważ do niego na bieżąco zapisuje blok funkcyjny.
  • Nie zmodyfikujecie „fbKontrP1.i_xStopBezp”, ponieważ do niego jest na bieżąco zapisywana wartość „gSt1.I_xStopBezp”.

Poniżej widoku zmiennych programu widzimy znaną nam drabinkę. Warto zwrócić uwagę na widoczną na obrazku strukturę „gSt1.stP1” wchodzącą do bloku „fbKontrP1” – o ile zmienne typu BOOL są animowane za pomocą podświetlania na czarno lub niebiesko w zależności od stanu, to złożone typy danych w widoku edytorów kodu nie są w żaden sposób wyświetlane – mniejsza czytelność kodu w podglądzie online to w tym przypadku cena za jego zwięzłość i szybkość pisania, a także większą spójność.

Przejdźmy teraz do podglądu online tego, co się dzieje w środku bloku kontroli pompy. Można to zrobić na dwa sposoby. Pierwszy to dwuklik w miejscu wywołania, czyli w „P_ProgGlow”. My to zrobimy inaczej.

Rys. 8. Wybór instancji bloku funkcyjnego w widoku online.

Kliknijmy dwukrotnie na definicji bloku. Otworzy się nam okno wyboru instancji, którą chcemy otworzyć (pole nr 1). Wybierzmy blok kontroli dla pompy  P1 w programie P_ProgGlow (pole nr 2) w urządzeniu Device w aplikacji Application (pole nr 3).

Rys. 9. Widok online struktury oraz bloku funkcyjnego.

Przyszła pora na testowanie. Metoda jest Wam znana z poprzedniego odcinka. Na powyższym zrzucie ekranu na wierzch wyciągnąłem tylko strukturę pompy P1 oraz instancję bloku kontroli P1 – one nam wystarczą w zupełności do przetestowania bloku kontroli pompy. W celu wpisania wartości do zmiennych możecie użyć skrótu klawiszowego [Ctrl + F7], zamiast za każdym razem klikać „Write values”.

Jej przetestowanie już należy do was – sprawdźcie każdy network gałęzi. Czy są wpisane dobre zmienne wejściowe, czy wynik działania gałęzi odpowiada specyfikacji zawartej w komentarzu itd. Od razu podpowiem – wyniku gałęzi wykrywających zbocza tak łatwo nie zobaczycie, ponieważ stan wysoki ustawia się tylko na jeden cykl programu, co może być za krótkim czasem, żeby go w ogóle odnotować w trybie online.

DO POBRANIA

Program e!COCKPIT można pobrać ze strony producenta >> TUTAJ. <<

Projekt programu z tej części kursu: Program PLC do e!COCKPIT

Podsumowanie

W tym odcinku przedstawiłem Wam krok po kroku, jak utworzyć definicję struktury i kontroli pompy, zadeklarować je oraz przetestować ich działanie.

W następnym odcinku przejdziemy do podstaw wizualizacji – utworzymy wirtualny panel sterowniczy służący do testowania aplikacji.

Jeśli macie jakieś pytania, piszcie w komentarzach 😉

Pozdrawiam, 
Łukasz Kurzawa


Więcej z serii: Kurs programowania PLC na sterowniku WAGO PFC


Utworzono: / Kategoria: ,
  • Autor: Łukasz Kurzawa
  • Jestem absolwentem studiów inżynierskich Automatyki i Robotyki na Wydziale Elektroniki Politechniki Wrocławskiej. Moje zainteresowania zawodowe koncentrują się wokół automatyzacji procesów ciągłych (przemysł chemiczny, gospodarka wodno-ściekowa, HVACR, energetyka). Zapraszam do czytania moich publikacji oraz do kontaktu.
  • Profil Autora

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
  • EPSITRON®ECO & COMPACT Power OSZCZĘDNOŚĆ KOSZTÓW Zasilacze EPSITRON® ECO i COMPACT Power to nie tylko oszczędność przy zakupie, ale również niższe koszty dzięki łatwej obsłudze oraz braku konieczności serwisowania. Są one doskonałym roz...
  • Zapraszam Cię na kurs tworzenia wizualizacji HMI z wykorzystaniem panelu XV102 od firmy EATON. Kurs stworzyłem z myślą o każdym, kto chce zacząć przygodę z tworzeniem wizualizacji HMI przy użyciu programu Galileo. Stworzyłem kurs bazujący n...
  • SCADA z wbudowanym serwerem sieci Web i routerem, bez licencji, bez limitów rejestrów! Brzmi dobrze? A to dopiero początek! Jest to urządzenie umożliwiające zarządzanie zarówno w sieci lokalnej jak i przez Internet z komputera, bądź urządze...
  • Urządzenia XV300 wyposażone są w przemysłowe wyświetlacze wysokiej rozdzielczości z technologią wielodotyku. To, w połączeniu z precyzyjnym i intuicyjnym interfejsem użytkownika, umożliwia operatorom pracę od zaraz. Dodatkowo te wysoko wyda...
  • SIMATIC PN/MF Coupler zapewnia wymianę danych pomiędzy max. 1 sterownikiem PLC na stronę sieci posiada redundantne zasilanie oraz możliwość połączenie sieci Ethernet poprzez SIMATIC BusAdapter (BA). SIMATIC PN/MF Coupler (6ES7158-3MU10-0XA0...
  • Nowoczesne dotykowe panele operatorskie HMI firmy WEINTEK Labs. – Bezpłatne oprogramowanie narzędziowe w pełnej wersji – Precyzyjne, dotykowe ekrany wyświetlające szczegółową grafikę – Obszerne biblioteki komponentów grafi...