Parafrazując pewnego białostockiego klasyka “Kiedyś nie było niczego”. Żadnych materiałów o programowaniu PLC. Czy kod, który piszę, jest dobry? A może mam jakieś nawyki, które sprawiają, że pracuję mało wydajnie i prosty kod zajmuje mi za dużo czasu. Teraz jest inaczej. Jest internet, który skrywa mnóstwo wiedzy. Mamy też wiele dobrych książek. Wiedzy jest mnóstwo, trzeba tylko chcieć po nią sięgnąć i ją przerobić. Do tego wszystkiego i ja dorzucę swoje trzy grosze. Poniżej znajdziesz 10 wskazówek dobrego programisty PLC, możesz je potraktować jako swoisty dekalog w swojej pracy.
1. Pamiętaj o zapisywaniu programu swojego.
Co najbardziej frustruje przy programowaniu? Nie możesz wgrać programu? Komunikacja z PLC jest nieprawidłowa? Nie wiesz jak napisać kod?
Nie!
Najbardziej wkurza, jak się napracujesz nad programem i przez błąd oprogramowania, zmiany nie zostały zapisane.
Chyba, każdy, bez wyjątku miał taką sytuację. Dlatego niech kombinacja CTRL+S będzie Twoim przyjacielem. Zapisuj program często, ale uważaj, aby zachowywać wersje programu i nie nadpisywać oryginału. Kolejna ważna sprawa, to trzymanie backupów skończonych programów. Bo ludzie dzielą się na dwie grupy. Ci, co robią backupy i Ci, co zaczną je robić 🙂
2. Techniki szybszego programowania będziesz stosował.
Zanim wystartujesz z pisaniem kodu, upewnij się, że zapoznałeś się z możliwościami oprogramowania. Przyśpieszą one Twoją pracę!
Pierwszy krok to podział obszaru roboczego (zazwyczaj w zakładce VIEW/WIDOK/WINDOWS). Poustawiaj interfejs, wykorzystując narzędzia, których najczęściej używasz. Niektóre softy, takie jak TIA Portal to istne kombajny i w standardowym widoku pootwierane okna zmniejszają obszar roboczy. Zapoznaj się z możliwościami chowania tych okien, poustawiaj je tak, abyś obszar roboczy miał, jak największy. Poznaj możliwości dzielenia okien na jednym ekranie. Np. widok tagów i obszar roboczy. Do zaglądania w inne okna możesz wykorzystać skróty klawiaturowe, zamiast za każdym razem ich szukać myszką.
Właśnie! Stosuj skróty klawiaturowe. W TIA Portal jak wejdziesz w Options > Settings > Keyboard shortcuts, to znajdziesz spis kombinacji. Wydrukuj sobie tę listę i stosuj nagminnie, aż wejdzie Ci to w krew. Po kilku dniach docenisz i zauważysz, jak przyśpieszy to Twoją pracę.
3. Nazywaj tak tagi (zmienne), tak abyś mógł je łatwo wybrać z podpowiedzi.
Pisząc kod programu w języku SCL lub LAD, w chwili, gdy zaczynasz wpisywać zmienną do danej operacji, to TIA Portal podpowiada Ci zmienne, które są już w tablicach tagów. Warto w nazwie zmiennej zastosować jakiś znacznik, który będzie je grupował, np.:
G2119A_M101_Transporter
G4119A_M401_Transporter
W takim wypadku mamy już dwa znaczniki, według których możemy wyszukać zmienną. Litera M – oznacza silnik (a w zasadzie wysterowanie stycznika) i jeśli znamy numer silnika, to gdy zaczniemy pisać M10… To już oprogramowanie podpowie nam którą zmienną wstawić. Drugi znacznik to słowo „Transporter”, gdy nie znamy numeru silnika, ale chcemy wstawić w kod PLC uruchomienie transportera. Gdy zaczniemy pisać „Trans…” to TIA Portal podpowie nam wszystkie tagi zawierające “Trans”.
Bardzo istotna jest tutaj konsekwencja w nazewnictwie zmiennych! Jeśli wejdzie to w krew, to późniejsze pisanie kodu jest jak głaskanie klawiatury 🙂 Takie nazewnictwo dotyczy także innych elementów jak bloki danych i zmienne w tych blokach. Programuj tak, abyś za rok kod swój zrozumiał. Zazwyczaj jest tak, że w dniu skończenia kodu wszystko jest jasne. Jego zasada działania i zastosowane „tricki” w kodzie. Uwierz mi jednak na słowo. Gdy usiądziesz do tego kodu nawet po kilku tygodniach, to g**** będziesz z tego rozumiał. Dlatego istotne jest, abyś projekt opisywał tak, jakbyś pisał dla kogoś innego, a ten miał go zrozumieć bez Twojej pomocy.
4. Organizacji projektu nie omijaj.
Taki mały, taki duży może czytelnym być!
Nie ładuj całego programu do bloku głównego (MAIN, czy OB1). Taki tasiemiec spowoduje, że organizacja programu będzie nieczytelna.
Screen z jednej z lekcji kursu online programowania PLC Siemens
Stosuj podział na programy, podprogramy, funkcje i bloki danych, które organizujesz tematycznie w osobnych folderach w drzewie projektu. Doświadczony programista PLC Tomasz Gilewski, który na sterownikach Siemensa zjadł zęby, wyjaśnia (i naciska, aby tak robić) to na każdym kroku.
5. Tagi PLC i bloki swe odpowiednio nazywaj.
Jeśli zachowamy konsekwencję w nazewnictwie tagów i bloków to dodatkowe komentarze będą zbędne, a Twój program każdy programista przeczyta jak lekturę z podstawówki. Najlepsza znana mi metoda jest taka, aby nazwa zmiennej była kompatybilna ze schematem elektrycznym, zawierała swoją funkcję w maszynie oraz lokalizację. Przykłady nazwania zmiennej:
„CzujnikOptyczny1” – niewiele zawiera informacji, w dodatku jest po polsku, a zaleca się język angielski. Nie polecam.
“16B1opticalSensor” – Już lepiej. Na schemacie elektrycznym ten sam czujnik jest oznaczony 16B1, wiemy zatem, że znajduje się na stronie 16 w kolumnie 1.
“GKT5001_B321_OpticalSensor” – tutaj wiemy, że ten fotoprzekaźnik pracuje w funkcji GKT w sekcji dokumentacji 5001, znajdziemy go w tej sekcji na stronie 32 w kolumnie 1.
Wszystko zależy od metody oznaczania elementów na schemacie elektrycznym.
Dodatkowa porada: Jeśli dla danej funkcji jest wiele zmiennych, to umieszczamy je w bloku np. GKT5001 a kolejne wiersze w tabeli możemy nazywać B321_OpticalSensor i tak dalej.
Dobrze, jeśli na panelu HMI zmienne też będą w ten sposób oznaczone, gdzie alarmy również zawierają wskazówkę do schematu elektrycznego.
6. Wersje programów i opisy do nich stosuj.
Gdy pracujemy zespołowo lub aktualizujemy oprogramowanie w PLC w działającej maszynie, to zaleca się trzymanie wcześniejszych wersji projektu. Co w przypadku, gdy nadpiszesz oryginalny program, ale maszyna staje po wgraniu i nie do końca pamiętasz, co tam pozmieniałeś? Nie fajnie 🙁
Dodatkowo w folderze z wersjami projektów warto mieć plik tekstowy, w którym opisujesz, co zmieniłeś, można też to robić bezpośrednio w projekcie, ale nie każdy tam zajrzy. Natomiast gdy ktoś wejdzie w folder z projektami i zobaczy plik tekstowy „CZYTAJ, TO ZANIM WGRASZ PROGRAM – zmiany” to jest spora szansa, że w to wejdzie.
7. Programy będziesz optymalizował, a kompetencje swe podnosił.
Program można napisać w 100 linijek kodu albo w 50 i będzie robił dokładnie to samo, ale sterownik PLC będzie miał mniej obliczeń i zużyje mniej pamięci.
Przykładowo, pewną operację można zapisać tak:
IF (#PoziomWody >= 50) THEN
#Pompa := TRUE;
ELSE
#Pompa := FALSE;
END_IF;
Albo tak:
#Pompa := #PoziomWody >= 50;
I zrobią dokładnie to samo.
Na początku niektórzy programują w stylu „oby działało”, ale nie spoczywaj nad tym. Czytaj fora, książki o programowaniu, a przede wszystkim ćwicz i programuj, bo to jest najlepszy sposób na naukę.
A jak naprawdę chcesz nauczyć się porządnie programować PLC w języku SCL – to zobacz ten Kurs Online
8. Cudzołóż z innymi sterownikami PLC.
Moje zdanie jest następujące. Poznaj jak najwięcej sterowników PLC i gdy tylko masz możliwość wejścia w coś nowego, to skorzystaj z tego. Wiadomo, że jak poznasz jedno środowisko programistyczne, to wpada ono do Twojej strefy komfortu i na myśl poznania czegoś od nowa pojawia się wewnętrzny opór 😉
Natomiast jak zapoznasz się z 3-4 różnymi modelami i interfejsami to później żaden soft do programowania urządzeń automatyki nie będzie Ci straszny, a Twoje portfolio i kompetencje staną się bogatsze.
9. Czytelność kodu zachowaj.
Podczas programowania może pojawić się pokusa, aby w pierwszej fali napisać go byle jak, oby jak najszybciej sprawdzić proprawność działania „a później się dopisze poprawne nazwy zmiennych i komentarze”. Też tak miałem i wielu przypadkach „jakoś później tak zostało”, bo deadline projektu dawno jest spóźniony. To zły nawyk. Pisz od razu porządnie! Niech Twoje zasady wejdą Ci w krew.
Dodatkowo! Jeśli piszesz w języku SCL, to zachowaj również pisanie kaskadowe np.:
IF x THEN
IF x THEN
IF x THEN
do;
END_IF;
END_IF;
END_IF;
Poczytaj też literaturę na temat „czystego kodu” – polecam.
10. Pisz program tak, jakbyś kiedyś miał go jeszcze rozbudować.
Warto myśleć kilka kroków do przodu podczas pisania programu np.:
- Czy w przyszłości w tej tablicy będę potrzebował więcej zmiennych?
- Czy maszyna się rozbuduje i będzie potrzebna dołożyć więcej wejść lub wyjść?
- Czy będzie system SCADA odpytywać tablicę? Więc lepiej od razu organizować pod to rejestry?
Po prostu postaraj się o szerszą perspektywę efektu finalnego 🙂
