Do Projektu iAutomatyka dołączyli:

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

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


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


W ostatnim odcinku naszego kursu wykonamy docelową wizualizację naszej pompowni. Przedstawię Wam sposób, w jaki sposób tworzyć wzorce w wizualizacji. Na koniec krótko podsumujemy nasz kurs. W tym artykule:

  • Zapoznamy się z ideą tworzenia szablonu w symulacji.
  • Zdefiniujemy szablon pompy.
  • Utworzymy docelowy ekran główny.
  • Przeprowadzimy symulację i testy.
  • Podsumujemy cały kurs.

Szablon w wizualizacji

Tworząc wizualizację stajemy przed tym samym problemem co pojawił się w drugim odcinku. Mamy dwa identyczne obiekty, czyli napędy pomp, więc należałoby zadać sobie pytanie, jak możemy ułatwić sobie pracę, nie wykonując kopiuj wklej i przypisywania całej garści parametrów? Już nie mówiąc o tym, że na wizualizacji identyczne elementy powinny wyglądać dosłownie identycznie jak od stempla – nic tak nie rzuca się w oczy jak elementy różniące się o rząd pikseli. Z pomocą przychodzi nam szablon. Szablon (ang. template) w wizualizacji jest odpowiednikiem bloku funkcyjnego w programie sterowania. Pozwala na utworzenie matrycy, w której w interfejsie definiujemy zmienne wejściowe czy wyjściowe, które będą się różnić parametrami w poszczególnych instancjach. Używając w interfejsach struktur jeszcze bardziej ułatwiamy sobie sprawę, ponieważ zamiast przypisywać cały zestaw zmiennych przypisujemy od razu całą strukturę. Identyczną operację wykonaliśmy w drugim odcinku definiując blok pompy.

Rys. 1. Definicja pompy uzupełniona o stałą symbolu technologicznego

Pierwszym krokiem będzie uzupełnienie definicji struktury pompy. Dodamy do niej jeszcze jedną zmienną – jej symbol technologiczny (pole nr 1). Jest to zmienna znakowa typu „STRING” (pole nr 2). W komentarzu poza jej opisem zawarłem bardzo istotną uwagę, że zmienna musi być zainicjalizowana w deklaracji (pole nr 3). Oznacza to, że musimy tą zmienną zainicjalizować w deklaracji struktury, a nie jej definicji. Wynika to z faktu, że o ile czas opóźnienia sygnalizacji braku załączenia/wyłączenia pompy jest identyczny dla każdej z pomp (choć oczywiście nie musi tak być w każdej aplikacji), to już nazwa technologiczna każdej z pomp będzie inna. Spójrzmy, jak to będzie wyglądać w globalnej liście zmiennych, gdzie deklarujemy struktury pomp.

Rys. 2. Deklaracja pompy uzupełniona o inicjalizację w deklaracji o stałą symbolu technologicznego

W kolumnie „Initialization” wpisałem w nawiasie inicjalizowane pole struktury oraz przypisywaną wartość (pole nr 1) – wynika to z faktu, że na złożone typy danych takie jak struktury czy bloki funkcyjne składają się całe zestawy zmiennych, więc musimy konkretnie wskazać, o którą chodzi. Możemy również to samo wyklikać, wybierając ikonkę z wielokropkiem (pole nr 2). Otworzy się naw w takim przypadku okno inicjalizacji wartości „Initialization value” (pole nr 3). Warto zauważyć, jak wygląda różnica w inicjalizacji wartości zmiennych w definicji (pole nr 4) oraz w deklaracji (pole nr 5), gdzie te drugie są pisane pogrubioną czcionką.

Definicja szablonu pompy

Rys. 3. Definicja szablonu wizualizacji pompy.

Definicją szablonu pompy jest po prostu nowy ekran wizualizacji, który nazwałem „V_SzablonPompa” (pole nr 1). W nim umieściłem elementy wizualizacji związane z pompą, na które składają się:

  • Nagłówek z symbolem technologicznym pompy (pole nr 2).
  • Prostokąt informująca o trybie pracy pompy (pole nr 3).
  • Koło symbolizujące stan pompy (pole nr 4).
  • Pole diagnostyki pompy (pole nr 5).

W górnej części ekranu znajduje się edytor interfesju (pole nr 6) podobny do tego znajdującego się w chociażby w definicji bloku funkcyjnego. W nim zdefiniowałem jako zmienną wejściowo-wyjściową strukturę pompy (pole nr 7).

Rys. 4. Lista elementów.

W zakładce „Element List” (pole nr 1) znajdują się wszystkie elementy, z których składa się ekran wizualizacji. W poszczególnych kolumnach określamy:

  • Typ elementu (pole nr 2).
  • Pozycję oraz wymiary (pole nr 3).
  • Numer ID (pole nr 4).
  • Nazwę (pole nr 5).

Typ elementu mówi nam o rodzaju danego elementu z przybornika – prostokąt, przełącznik, przycisk itd. Najciekawszym typem elementu, którego w przyborniku nie znajdziecie, jest grupa – „Group” (pole nr 6). Grupę tworzymy, zaznaczając co najmniej dwa elementy i wybierając operację grupowania w przyborniku wizualizacji. W ten sposób są one ze sobą trwale związane, tworząc tak jakby jeden element. Wspólne dla nich stają się wymiary i pozycja, co ułatwia potem planowanie rozmieszczania elementów na ekranie. Kolejnym powodem grupowania elementów jest możliwość nadania nazwy całej grupie. Dzięki temu lista elementów staje się bardziej przejrzysta i czytelna.

Numer ID jest numerem nie tylko porządkowym, ale także informuje nas o poziomie warstwy, na której znajduje się element. Umieszczając element o wyższym numerze ID na elemencie o niższym numerze zasłonimy go, tj. ten o niższym numerze będzie się teraz znajdował pod spodem. Zwróćcie uwagę, że grupa ma swój własny numer ID, a elementy grupy swoje, co wynika z faktu, że także wewnątrz grupy elementy leżą na różnych warstwach. Jest to bardzo istotny fakt, który wykorzystałem przy tworzeniu elementów mających informować o więcej niż dwóch stanach, jak np. prostokąt informujący o trybie pracy pompy „Tryb pracy”, na który składają się „Tryb ręczny”, „Tryb auto” oraz „Odstawiona”.

Wszystkie elementy wchodzące w skład grupy posiadają wypełnione pole „Invisible” w zakładce „State variables” właściwości (pole nr 7). Dzięki temu w miejscu, gdzie znajduje się grupa, będą wyświetlane różne prostokąty zależne od tych zmiennych. Kolejność jest nieprzypadkowa, ponieważ prostokąt „Odstawiona”, jeśli tylko jest spełniony warunek zdefiniowany w bloku kontroli pompy, ma zawsze zasłonić prostokąty trybów ręcznego i auto, które są uzależnione tylko sygnałów pochodzących od przełącznika trójpozycyjnego. Warto zwrócić uwagę na to, jak jest wyspecyfikowane działania pola „Invisible” (pole nr 8). Jest to wartość boolowska decydująca czy element ma być niewidoczny, przy czym niewidoczny staje się dla wartości TRUE. Oznacza to, że:

  • w tym polu nie musi się znajdować tylko jedna zmienna, ale możemy zdefiniować bardziej złożony warunek przy pomocy wielu zmiennych oraz operatorów logicznych czy porównania,
  • oraz że musimy zwrócić uwagę na logikę zmiennych, czyli co oznacza TRUE, a co FALSE.

W naszym przypadku zastosowałem negację NOT w celu odwrócenia logiki, ponieważ „stPompa.xOdstaw” przyjmuje wartość TRUE, kiedy pompa jest odstawiona.

Ekran główny

Rys. 5. Wstawianie szablonu do ekranu wizualizacji.

Mając przygotowany szablon wizualizacji pompy możemy uzupełnić główny ekran naszej wizualizacji. Aby wstawić szablon do ekranu wizualizacji, w przyborniku należy wybrać zakładkę „Current project” (pole nr 1), skąd wybieramy szablon „V_SzablonPompa” (pole nr 2). W niej widzimy wszystkie pozostałe utworzone przez nas w projekcie ekrany, a więc także wirtualny pulpit „V_WirtualPulpitOper” (pole nr 3). Jest to związane z wspomnianym już wcześniej faktem, że szablon w wizualizacji to po prostu ekran, który różni się tym, że zamiast wyświetlać go bezpośrednio umieszczamy go na innym ekranie.

Wstawiając szablon na ekran wizualizacji pojawia się okno przypisania zmiennych do interfejsu szablonu (pole nr 4). W naszym przypadku jest to tylko jedna zmienna, czyli struktura pompy (pole nr 5). Zwróćcie uwagę na zaletę stosowania struktur analogiczną jak w przypadku interfejsu bloku funkcyjnego – zamiast całego zestawu parametrów przypisujemy w tym przypadku tylko jeden.

Po wstawieniu szablonów pomp (pole nr 1) oraz uzupełnieniu ekranu o synoptykę pomiarów i czujników w studni (pole nr 2) oraz nagłówek z nazwą obiektu (pole nr 3) nasz główny ekran wizualizacji jest gotowy.

Szablony w liście elementów mają przydzielony osobny typ „Frame” (pole nr 4). Poza standardowymi właściwościami taki wymiary czy położenie posiada on te zakładkę referencji „References” (pole nr 5). W niej widzimy, do którego ekranu wizualizacji się odwołujemy oraz widzimy zmienne przypisane do interfejsu szablonu.

Symulacja

Rys. 7. Symulacja

Tak prezentuje się utworzona przez nas wizualizacja w trybie symulacyjnym. Widzimy w niej dodane przez nas elementy znajdujące się w różnych stanach.

Zdecydowałem się zrobić screena ekranowi głównemu oraz umieszczonemu obok wirtualnemu pulpitowi. Dzięki temu możecie porównać efekt ustawionej przeze mnie kombinacji sygnałów na ekranie głównym.

Tak jak w poprzednich odcinkach zachęcam Was do pobrania aplikacji oraz jest przetestowania. Po ukończeniu pisania wizualizacji lub jej jakiegoś funkcjonalnego fragmentu należy ją przetestować, żeby sprawdzić, czy spełniliśmy założenia, ponieważ błędy mogliśmy popełnić błąd na każdym kroku – od błędnego zrozumienia zasady działania danego elementu, przez błędne przypisanie zmiennej do właściwości elementu, aż po nieprawidłowe ułożenie elementu przez błędne ułożenie kolejności umieszczenia elementów lub grup na kolejnych warstwach.

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

To już ostatni odcinek kursu. W tym miejscu chciałbym się podzielić z Wami kilkoma moimi uwagami, spostrzeżeniami i radami.

Po pierwsze – celem kursu było wspólne napisanie prostej, ale rzeczywistej aplikacji. W pewnym sensie się to udało – na tyle, na ile pozwoliła przyjęta formuła kursu składającego się z pięciu odcinków. W celu opisu prawdziwej aplikacji potrzebne byłoby kolejne pięć albo dziesięć odcinków, jeśli pamiętalibyśmy o takich rzeczach jak liczniki czasu i załączeń, dziennik zdarzeń, praca równoległa pomp, nastawianie parametrów pomp itd, a także zdecydowanie bardziej rozbudowana (także pod względem estetycznym) wizualizacja. W ramach nauki możecie się podjąć takiego zadania – szukając w google projektów przepompowni sanitarnych znajdziecie też opisy wymagań, które możecie przyjąć jako wytyczne do rozbudowy mojego programu lub też napisania własnego od zera.

Po drugie – objętość ograniczyła nas też w kwestii wgłębienia się w ciekawsze możliwości e!Cockpit i Codesys 3, takie jak receptury, programowanie obiektowe, język SFC i wiele innych. Polecam dalsze poszukiwania na własną rękę.

Po trzecie – końcowa wizualizacja jest powiedziałbym bardzo „ascetyczna”. Jest to celowy zabieg wymuszony przez długość kursu. Polecam poszukać ponownie razem z wujkiem Google grafiki i strony wykonawców takich systemów. W profesjonalnych aplikacjach często używa się gotowych bibliotek elementów czy nawet zleca się grafikom narysowanie bardziej złożonych elementów wizualizacji, a także zamieszcza się czy też symuluje animacje pewnych zdarzeń czy pracy obiektów jak np. obroty mieszadeł.

Po czwarte i ostatnie – dobry programista nie myśli tylko o algorytmach sterowania, ale też powinien mieć podstawową wiedzę z innych dziedzin takich jak elektryka, mechanika, pneumatyka i hydraulika, instalacje technologiczne. Pamiętajmy, że piszemy programy na potrzeby sterowania rzeczywistymi obiektami, a nie plikami w excelu czy stronami internetowymi, więc warto coś o tej rzeczywistości wiedzieć.

I na tym możemy zakończyć nasz kurs.

Do zobaczenia na obiekcie!


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