W niniejszej publikacji omówiono zagadnienia związane z opracowaniem algorytmów oraz programów sterujących dla rozbudowanego programowania sekwencyjnego oraz współbieżnego sterowników PLC wraz z ich przykładami wykorzystania. Wyjaśniając przedmiotowe zagadnienia autor posłużył się zaleceniami normy EN61131-3, która precyzuje metody programowania sterowników PLC, jak również semantykę algorytmu SFC, jednak do bardziej szczegółowych opisów tej normy autor odsyła Czytelnika do innych publikacji autora.
Analizując rodzaje urządzeń sterujących, które od wielu już lat dominują w sterowaniu różnymi procesami przemysłowymi jako „mózgi” układów sterowania można zauważyć, że są to przede wszystkim nadal sterowniki cyfrowe PLC (ang. Programmable Logic Controllers), ale jednak w urozmaiconej konstrukcji logicznej, sprzętowej oraz programowej, które to cechy ewoluowały na przestrzeni kilkudziesięciu lat. Autor użył celowo przysłówka „nadal” aby podkreślić Czytelnikowi, iż pomimo faktu, iż pojawienie się pierwszych sterowników cyfrowych PLC należy odnotować w latach 70-tych XX w., to jednak jak się okazuje są one w pewien sposób nieśmiertelne, jako urządzenia centralne w układach sterowania procesami przemysłowymi. Jedynie to, co się zmieniło to systemy operacyjne, dzięki którym można było i można te urządzenia w dalszym ciągu zaprogramować, czyli utworzyć w programatorze (czytaj: komputerze/laptopie/smartfonie, itp.) program użytkowy dla CPU sterownika (ang. Central Processing Unit), nazywany często po prostu programem PLC.
Należy podkreślić, że w tamtym czasie, tj. w momencie pojawienia się tych pierwszych sterowników cyfrowych do utworzenia programu PLC używane były siermiężne (w stosunku do obecnych) systemy operacyjne, zainstalowane w programatorach, których przykładem może by system operacyjny o nazwie DOS (ang. Disc Operating System). Funkcjonujące „pod” DOS-em w programatorach edytory tekstów o kodowaniu znaków alfanumerycznych w standardzie ASCII (ang. American Standard Code for Information Interchange) pozwalały jedynie na utworzenie programu PLC w tzw. metodzie tekstowej, nazywanej metodą STL (ang. Statement List), a później również i w metodzie LAD (ang. Ladder Diagram). Jednak tworzenie programu w tej drugiej metodzie sprowadzało się najczęściej nie do „wstawiania” instrukcji na ekran programatora myszą komputerową tak, jak to odbywa się teraz, tylko poprzez „rysowanie” na ekranie programatora przy użyciu odpowiednich klawiszy diagramu LAD, używając znaków dostępnych na klawiaturze komputera, czyli najczęściej znaku myślnika („-”), podkreślenia („_”), wykrzyknika („!”) czy nawiasów („(„ i „)”). Postać programu LAD utworzonego w ten sposób i złożonego z dwóch sieci programowych ilustruje rysunek 1.
Rysunek 1: Fragment programu użytkownika utworzony pod DOS-em z wykorzystaniem metody LAD
Częstą praktyką pod DOS-em w uzyskiwaniu programu PLC metodą LAD (np. dla celów dokumentacyjnych) było najpierw utworzenie w programatorze programu PLC posługując się metodą STL, by potem dokonać jego konwersji na program LAD przy użyciu środowiska programistycznego sterownika cyfrowego. (Przykładem takiego środowiska, które umożliwiało tworzenie programów PLC pod DOS-em oraz dokonywanie ich wzajemnej konwersji STL-LAD było oprogramowanie SH-400 dla sterowników niemieckiej firmy SCHIELE, której sterowniki cyfrowe PLC używane były m.in. w automatyzacji linii montażowych fabryk samochodów BMW).
Podkreślmy, jako istotne, że testowanie wgranego do pamięci CPU programu PLC przebiegało również wtedy inaczej niż obecnie. O
zmianie kolorów (to „duże” słowo) operandów programu w zależności od ich stanu podczas pracy sterownika nikt nawet nie myślał, a szczytem podglądu aktualnych (wtedy tylko dwóch) stanów takich operandów było pokazywanie tychże na ekranie programatora wyłącznie przy wyświetleniu programu PLC w metodzie STL. Pokazywał to odpowiedni kod zero-jedynkowy przy adresie danego operandu: zero logiczne („0”) – brak działania, oraz jedynka logiczna („1”) – działanie (np. wciśnięto przycisk START, STOP, itp.). Później w miarę zwiększania możliwości graficznych ekranów programatorów (lub już „pomału” komputerów typu PC) pojawiła się możliwość testowania stanu operandów programu użytkownika przy wyświetlaniu programu w LAD. Określone działające operandy były wtedy odpowiednio „kolorowane”, jak na możliwości tamtejszych kart graficznych ekranów programatorów. Postać sieci programowych programu PLC z rysunku 1, ale które pokazują diagnostykę operandów programu poprzez kolorowanie na szaro zilustrowano na rysunku 2.
Rysunek 2: Fragment programu użytkownika z testowaniem operandów w metodzie LAD
Widoczne na rysunku 2 szare pola pokazują stany aktywnych operandów w chwili analizowania tych sieci przez CPU sterownika w trybie połączenia go z programatorem. Widać, że w sieci nr 1 wcześniej musiało zaistnieć działanie operandów o adresach I0.0 oraz I0.3, ponieważ został wysterowany końcowy operand o adresie M0.0. Teraz, jeżeli zadziała operand o adresie I0.1 zostaną uruchomione dwa Timery TON o adresach: T0 i T1. Itd.
Nie trzeba dużej wyobraźni aby stwierdzić, że w tamtym czasie wdrożenie do układu sterowania oraz kontrola pracy sterownika cyfrowego PLC w takim układzie sterowania procesami musiały być poprzedzone dużym nakładem sił oraz środków, jak również dużą wiedzą personelu technicznego, który zamierzał to zrobić i później kontrolować działanie takiego układu sterowania, który można było od tamtej pory nazywać sterowaniem PLC.
Należy zaznaczyć, że wprowadzenie już możliwości tworzenia programu PLC dla sterownika cyfrowego przy użyciu komputera typu PC wraz z pojawianiem się nowszych wersji DOS-a dla tych maszyn cyfrowych ułatwiło w jakimś stopniu, ale tylko nieznacznie tworzenie tego programu i późniejszą diagnostykę pracy CPU sterownika. Wprowadzono np. możliwość używania przez programistę przypisanych do edytora programu PLC klawiszy funkcyjnych klawiatury komputerowej (np. F1, F2, itd.) do wstawiania elementów sieci STL czy bloczków diagramu LAD oraz linii tworzących ten diagram, zamiast tak jak do tej pory używania wspomnianych znaków interpunkcyjnych, przemieszczanych po ekranie programatora przy użyciu odpowiednich klawiszy. Z kolei notowana poprawa parametrów kart graficznych monitorów ekranowych tych komputerów PC wprowadziła możliwość większej kolorystyki przy diagnostyce sieci programowych programu użytkownika. Przykładem takiego oprogramowania narzędziowego o zwiększonych możliwościach funkcjonalnych było np. środowisko STEP 5 dla tworzenia programu użytkowego dla sterowników rodziny SIMATIC S5 firmy Siemens.
Podkreślmy, że w owym czasie ze względu na istniejące ograniczenia sprzętowe oraz programowe programatorów nie istniała jeszcze metoda tworzenia programu PLC znana obecnie pod nazwą FBD (ang. Fuction Block Diagram). Metoda ta pojawiła się dopiero wraz z rozpowszechnieniem się systemów operacyjnych „okienkowych” typu Windows, Linux czy innych, instalowanych w programatorach, którymi powszechnie stały się już komputery PC czy odpowiednio skonfigurowane i „wzmocnione” komputery przenośne, np. laptopy.
Jak można się domyślać pojawienie się systemów operacyjnych okienkowych było możliwe tylko dzięki rozwojowi sprzętu komputerowego i oprogramowania, co ze względu na programistę i użytkownika sterowników PLC mogło być tylko zaletą, która przyczyniła się w konsekwencji do pojawienia się m.in. wspomnianej metody tworzenia programu FBD oraz zwiększonych możliwości testowania programu w CPU sterownika PLC poprzez wykorzystanie pełnej palety kolorów przy testowaniu poszczególnych sieci programowych, jak i innych możliwości testowania działania układu sterowania, opartego na sterownik PLC. Programista tworząc program PLC przestał się już posługiwać wyłącznie wspomnianymi klawiszami funkcyjnymi F1, F2, itd., a zaczął tworzyć program na ekranie monitora przy użyciu myszy komputerowej stosując metodę tzw. „przeciągania” wybranych z menu elementów programu dla konkretnej metody, np. LAD czy FBD.
Notując rozwój techniki w budowie sterowników cyfrowych PLC i dedykowanego dla nich oprogramowania narzędziowego, które pozwalało dokonywać aplikacji sterowników w różnych układach sterowania nie wolno pominąć pojawienia się najwyższego poziomu testowania takich układów, jak chociażby wykorzystywania opracowanych tzw. systemów wizualizacji procesów, określanych terminem SCADA (ang. Supervisory Control And Data Acquisition). Przypomnijmy, że systemy te, instalowane zazwyczaj na komputerach typu PC, ale o najwyższych parametrach technicznych, czyli z szybkim procesorem, odpowiednią kartą graficzną, wielkością monitora, odpowiednią ilością pamięci RAM (ang. Random-Access Memory), odpowiednią ilością kart dla sygnałów wejściowych obiektowych, itp. zaczęły pozwalać na wyświetlanie na ekranach tych monitorów tzw. map synoptycznych procesu przemysłowego. Mapy te odzwierciedlały graficznie stan tego procesu, kontrolowanego przez sterowniki PLC, na podstawie sygnałów przesyłanych do SCADA przez te sterowniki. Przykład mapy synoptycznej kontrolowanego procesu przemysłowego ilustruje rysunek 3.
Rysunek 3: Mapa synoptyczna pracy rozdzielnic systemu NEMESIS
Widoczne na rysunku 3 graficzne kolorowe elementy, to nic innego jak ikony reprezentujące konkretne urządzenia (np. sterowniki PLC), które połączone na rysunku liniami odwzorowują rzeczywiste połączenia sygnałowe tych urządzeń na kontrolowanym obiekcie przemysłowym, którym tutaj jest podsystem w zakładzie przeróbki mechanicznej węgla kamiennego. Przy prawidłowej pracy urządzeń umowna, zastosowana na mapie synoptycznej kolorystyka, np. zielona może oznaczać prawidłową pracę tych urządzeń, zaś przy innym kolorze, np. czerwonym może oznaczać przegrzanie odpowiednich elementów, ich uszkodzenie lub coś zupełnie innego. Wszystko zależy od przyjętej przez projektanta mapy synaptycznej konwencji.
Należy wyraźnie podkreślić, że pomimo odnotowanego rozwoju sprzętu sterownikowego oraz oprogramowania narzędziowego dla tworzenia programów PLC, które jak zapewne Czytelnik już zauważył poprawiło „współdziałanie” w relacji człowiek – maszyna HC (ang. Human Collaboration), to w zakresie aplikacji samego sterownika cyfrowego PLC w układzie sterowania niewiele się zmieniło. Należy w dalszym ciągu tworzyć poprawny program PLC, który najlepiej by było, aby był poprzedzony utworzeniem tzw. algorytmu procesu dla kontrolowanego procesu, zaś później na podstawie tego pierwszego utworzeniem tzw. algorytmu sterowania. Zaznaczmy, że od szeregu już lat do realizacji pierwszego stosuje się algorytm GRAFCET (fr. Graphe Fonctionnel de Commande des Étapes et Transitions), opracowany przez francuskich specjalistów z branży automatyki, zaś do realizacji drugiego algorytm SFC (ang. Sequential Fuction Chart), ujęty w normie EN 61131-3 z 1993 roku.
Silne akcentowanie przez autora niniejszej publikacji sensu a nawet konieczności tworzenia tych dwóch algorytmów przed utworzeniem docelowego programu PLC posiada swoje uzasadnienie. O ile bowiem dla hipotetycznego procesu przemysłowego, dla którego program PLC „zawierałby” się tylko w kilku prostych sieciach, np. takich, jak na rysunku 1, być może tworzenie tych algorytmów dla takiego procesu byłoby „zawracaniem” głowy i generowaniem niepotrzebnej makulatury (którą obecnie raczej nazwalibyśmy tworzeniem niepotrzebnych stron w edytorze tekstów). Rysunek ten bowiem pokazuje, że ten hipotetyczny proces przemysłowy nie może cechować się złożonością, ponieważ występuje w sieciach programowych niewiele operandów wejścia/wyjścia i wprawny programista raczej nie potrzebowałby tworzyć postaci wspomnianych algorytmów przed utworzeniem tych sieci programowych z rysunku 1. Jednak tak proste procesy przemysłowe raczej nie występują, lub inaczej, aplikacja sterownika cyfrowego PLC jest na tyle kosztowna, że jeżeli już wystąpi cel jego wykorzystania, to dla sterowania bardziej złożonym procesem przemysłowym niż taki, dla którego program PLC zawarłby się tylko w dwóch sieciach programowych z rysunku 1. (Nawiasem mówiąc sterowanie takim hipotetycznym procesem przemysłowym zgodnie z sieciami programowymi z rysunku 1 można zrealizować przy użyciu tzw. sterowania stykowego, czyli poprzez połączenia elektryczne kilku zestyków oraz dwóch przekaźników czasowych, które będą reprezentowały Timery T0 i T1). Zatem dla złożonych procesów przemysłowych (czytaj: generujących wiele sygnałów wejścia / wyjścia), utworzenie przed programem PLC najpierw rozbudowanego algorytmu GRAFCET i potem na podstawie tego pierwszego algorytmu SFC powinno być obowiązkiem projektanta systemu sterowania.
Należy podkreślić, że zalecenie wcześniejszego (tzn. przed programem PLC) utworzenia rozbudowanego algorytmu GRAFCET i później SFC ma swoje uzasadnienie m.in. w tym, że te grafy, opisujące działanie kontrolowanego przez sterownik PLC procesu przemysłowego powinny odzwierciedlać wszystkie zdarzenia, które mogą wystąpić w takim procesie, włączając w to nawet zdarzenia awaryjne, które mogą pojawić się albo losowo na skutek uszkodzenia czujników czy układów wykonawczych, albo pojawić się celowo na skutek sabotażu. Takie sytuacje ilustruje poglądowo rysunek 4.
Na rysunku 4 pokazano trzy sytuacje, których przyczyny wystąpienia opisano powyżej, tj.:
- Przypadek nr 1 – celowe uszkodzenie przewodu sygnałowego, uniemożliwiające w efekcie zadziałanie elementu wykonawczego EZ1, pomimo wysterowania tego operandu w module wyjść przez program PLC;
- Przypadek nr 2 – niezamierzone (np. przez elektryka) pominięcie podczas prac instalacyjno-montażowych połączenia elementu sygnalizacyjnego Ż2 z zaciskiem modułu wyjść, wykluczające wysterowanie tego przez program PLC;
- Przypadek nr 3 – przypadkowe uszkodzenie czujnika indukcyjnego CI1, wykluczające dostarczenie sygnału wejściowego dwustanowego z tego czujnika do zacisku modułu wejść sterownika PLC pomimo wystąpienia elementu metalowego w polu działania tego czujnika, do kontroli czego został czujnik przewidziany.
Rysunek 4: Sytuacje awaryjne w układzie sterowania PLC
Autor podkreśla, że sytuacje awaryjne w układzie sterowana PLC, które zostały uwidocznione na rysunku 4 zaproponowano zupełnie ad hoc. Uczyniono tak jedynie dla pokazania istoty problemu, który może się pojawić, i który na „nieszczęście” dla programisty musi on rozwiązać (przynajmniej powinien się postarać). Już sama liczba tych zdarzeń (czytaj: trzy) w tak niewielkim układzie sterowania PLC wprowadza przecież sporą liczbę sytuacji awaryjnych (czytaj: osiem, ponieważ 23 = 8). Dalej, jedne awarie mogą być krytyczne dla sterowania procesem i obsługi, czyli nie powinny wystąpić lub natychmiast powinny być zauważone i rozwiązane, zaś inne mnie krytyczne, ale czy dopuszczalne? Na przykład uszkodzenie czujnika CI1, co w efekcie pozbawi program PLC informacji o kontroli metalowego elementu może być w efekcie krytyczne lub mniej krytyczne. Wszystko zależy od rodzaju procesu przemysłowego. Jeżeli sygnał ten tylko „zlicza” wyroby transportowane do pojemnika, to „pół biedy”. Przeładowanie takiego pojemnika może być szybko zauważone i problem natychmiast zauważony. Ale co wtedy, kiedy brak tego sygnału, który powinien być zezwoli na dalszą operację technologiczną, która bez tego sygnału nie powinna się odbyć? Zatem widzimy, że jakikolwiek algorytm (najpierw GRAFCET a potem SFC) powinien to przewidzieć. Można zadać pytanie: jak wyglądałaby struktura takiego algorytmu, gdyby programista zastosował w algorytmie procedury uwzględniające wszystkie przypadki awaryjności takie, jak na rysunku 4?
Należy nadmienić, (odpowiadając sobie wcześniej na ostatnie zadane pytanie), że już przy stosunkowo niewielkim układzie sterowania PLC brak odpowiednio zaprojektowanego algorytmu (czy to procesu czy sterowania) może uniemożliwić prawidłową realizację procesu przemysłowego dla którego taki algorytm stworzono. Zatem bez dwóch zdań teza, iż zanim przystąpimy do napisania programu PLC powinniśmy utworzyć odpowiedni algorytm dla tego sterowania nie wymaga już dalszego dowodu. Twórca programu PLC, mając bowiem „przed sobą” taki algorytm i tworząc program PLC dla konkretnego procesu przemysłowego, posiada mniejszą „szansę” się pomylić i nie uwzględnić takich zdarzeń w programie PLC, niż gdy tworzy taki program na podstawie nawet dokładnego opisu słownego tego procesu.
Dalej, ponieważ z zasady liczba kroków takich algorytmów jest nieograniczona (o zasadach ich tworzenia będzie mowa w dalszej części tekstu), to projektant tychże może przewidzieć dosłownie „wszystko” to, co może wystąpić lub powinno w danym procesie i umieścić odpowiednie zależności w programie PLC. Oczywiście zależy to od jego wiedzy o samym procesie oraz sposobie działania poszczególnych urządzeń. Przykładowo, jeżeli twórca (programista) programu PLC z elementami pneumatyki typu siłowniki pneumatyczne nie uwzględni faktu, iż urządzenia te cechuje niekiedy duża bezwładność w ich ruchu w stosunku do działania czujników, które tę pracę kontrolują, to napisany program PLC, chociaż poprawny semantycznie i logicznie nie będzie funkcjonował w takim procesie.
Autor niniejszej publikacji chce podkreślić, że jego zamiarem nie było pokazanie Czytelnikowi samego rozwoju sterowników PLC oraz przykładów ich programowania czy testowania. Autor uczynił to już w innych swoich publikacjach, np. w ramach projektu SECAM NERW OKNO Politechniki Warszawskiej. Zamiarem autora było zaś zaprezentowanie Czytelnikowi sposobu tworzenia rozbudowanego programowania sekwencyjnego oraz współbieżnego, na co złożyło się po pierwsze pokazanie tworzenia rozbudowanych algorytmów procesu, czyli GRAFCET oraz później algorytmów sterowania, czyli SFC by potem pokazać tworzenia programów PLC dla realizacji tych algorytmów.
Postawiony sobie powyższy cel wynika po prostu z faktu, iż pomimo gwałtownego rozwoju sterowników cyfrowych PLC oraz rozwoju oprogramowania narzędziowego dla tychże, to w dalszym ciągu na wykształconym programiście spoczywać będzie obowiązek utworzenia prawidłowego algorytmu procesu, sterowania oraz później utworzenie programu PLC. Póki co bowiem nie istnieją systemy narzędziowe tworzące program PLC na podstawie słownych poleceń wydawanych takiemu środowisku do mikrofonu, więc poznanie zasad tworzenia w sposób prawidłowy rozbudowanych algorytmów i później programów PLC powinno być celem samym w sobie dla osób, które chcą być profesjonalistami w tym zakresie automatyki i sterowania nowoczesnymi procesami przemysłowymi.
Czytelnikowi w przyswajalności materiału oraz sprawdzeniu jego stopnia we własnym zakresie. Tytuły modułów publikacji są następujące:
I. Sterowanie sekwencyjne procesami przemysłowymi – w module tym autor przypomniał Czytelnikowi zagadnienie sekwencyjności procesów przemysłowych oraz po przedstawieniu podstaw konstrukcji tzw. sieci Petriego P-N wprowadził dwa algorytmy: algorytm procesu GRAFCET i algorytm sterowania SFC oraz zaprezentował ogólną strukturę rozbudowanego sterowania sekwencyjnego.
II. Współbieżne sterowanie procesami przemysłowymi – w module tym autor rozwinął zagadnienie sterowania procesami przemysłowymi o tzw. współbieżność. Zaprezentował zasady konstrukcji algorytmów do takiego sterowania wraz ze wskazaniem na sytuacje niedopuszczalne, które mogą wystąpić przy tego typu rozwoju algorytmów;
III. Zasady tworzenia programów sterujących realizujących sterowanie sekwencyjne i współbieżne – w tym module autor zaprezentował na przykładach zasady tworzenia rozbudowanego algorytmu SFC dla procesów realizowanych sekwencyjnie oraz współbieżnie oraz zilustrował sposób powstawania programu PLC, który powinien te algorytmy realizować w układzie sterowania;
IV. Wykorzystanie programowania sekwencyjnego i współbieżnego w sterowaniu przykładowymi procesami przemysłowymi – w tym module autor pokusił się o przedstawienie Czytelnikowi praktyczne przykłady procesów przemysłowych, w których wykorzystano rozbudowane sterowanie sekwencyjne i współbieżne.
Autor niniejszej publikacji podkreśli, że odbiorcami tejże mogą być Czytelnicy, zajmujący się zawodowo projektowaniem układów sterowania w oparciu o sterowniki cyfrowe PLC, które jak wiadomo są wykorzystywane w procesie produkcji różnych wyrobów, których rodzaje trudno wymieniać. Niniejsza publikacja będzie również przydatna dla studentów wydziałów elektrycznych, informatycznych, mechatronicznych, itp., różnych uczelni technicznych, czyli wszędzie tam, gdzie występuje kształcenie studentów na kierunku Automatyka, Mechatronika, Robotyka lub specjalnościach im pokrewnych. Za wszelkie uwagi dotyczące prezentowanego materiału autor będzie bardzo wdzięczny. Czytelnicy mogą je kierować drogą elektroniczną na adres e-mail: zbigniew.seta@pw.edu.pl.