Programowanie programowalnych sterowników logicznych (PLC) jest często wykonywane w celu rozwiązania natychmiastowego problemu, ale może to prowadzić do długoterminowych problemów, zwłaszcza jeśli pierwotnego programisty nie ma w pobliżu.
Spostrzeżenia dotyczące programowania sterowników PLC
Programiści programowalnych sterowników logicznych (PLC) mają tendencję do pisania kodu z myślą o natychmiastowych rozwiązaniach, a nie długoterminowych, co może stanowić problem dla każdego, kto przejmie ich pracę w przyszłości.
Niektóre błędy w programowaniu sterowników PLC obejmują kopiowanie/wklejanie powtarzalnej logiki i używanie niemożliwych do rozszyfrowania nazw tagów bez oznaczeń.
Niektóre dos programowania sterowników PLC obejmują szukanie możliwości ponownego wykorzystania użytecznego kodu i używanie opisowych nazw tagów, aby łatwiej było je znaleźć.
Produkcja spadła, a klient traci 100 tysięcy dolarów na godzinę i wezwał programistę programowalnych sterowników logicznych (PLC), aby naprawił to tak szybko, jak to możliwe. Programista uruchamia wirtualną sieć prywatną (VPN), przeglądając loty last minute. Godzinę później programista patrzy na nowy (dla niego) program, tysiące szczebli logiki drabinkowej, brak opisów znaczników, niejasne konwencje nazewnictwa, kod, który został skopiowany i wklejony setki razy, a wszystko to w jednej, ogromnej procedurze. Może to prowadzić do tego, że programista zastanawia się, co myślał pierwotny programista.
Osiem zakazów i pięć zakazów programowania sterowników PLC
Przeciętny programista PLC ma tendencję do pisania kodu dla siebie w celu uzyskania natychmiastowego rozwiązania. Łatwo jest zapomnieć o biednym sapie, który musi to utrzymać w przyszłości. Jeśli nie będziemy uważni, możemy stać się powodem, dla którego ktoś krzyczy wykrzykniki na ekranie. Oto kilka prostych wskazówek, jak nie stać się takim programistą.
NIE Kopiuj i wklejaj powtarzalną logikę. Powiedzmy, że są dwie cewki, które chcesz aktywować w sekwencji. Możesz włączyć pierwszą cewkę, być może z opóźnieniem czasowym, a następnie włączyć kolejną cewkę. Poza zmianą nazwy tagu z “CoilOne” na “CoilTwo”, szczeble są identyczne. Wszyscy mamy taki kod, ponieważ zwykle to wszystko, tylko kilka szczebli. Ale co się stanie, gdy masz 50 cewek? Zanim zaczniesz wciskać Ctrl+V…
TAK Szukaj możliwości ponownego wykorzystania kodu. Pętle są twoim przyjacielem. AOI, podprogramy, a nawet podstawowe tablice mogą przyspieszyć czas programowania, utrzymać kod w czystości i ułatwić przyszłą konserwację. Zmiana logiki? Nie musisz wklejać 50 poprawek, wystarczy jedna mała zmiana w podprogramie i gotowe. Co? Klient chce, aby 50 zwojów było teraz 100? Jeśli zrobiłeś to dobrze, powinieneś dosłownie zmienić tag, “Coil Count” lub cokolwiek innego, z 50 na 100.
NIE Używaj niezrozumiałych nazw tagów bez oznaczeń
“tmrdelay” – “Timer” i “delay” są zbędne. Do czego służy to opóźnienie? Czy używamy go do migania światła lub odczekania bezpiecznego czasu przed opuszczeniem ciężkiej prasy?
“AB_XGI:I.Data[1]”, Oczywiście jest to struktura danych dla jakiegoś podłączonego urządzenia, ale odwoływanie się do niej w ten sposób w twojej głównej procedurze to marnowanie okazji do stworzenia zrozumiałego kodu.
“fireRobotMove”, Który robot? Jaki ruch? Czy potrzebuję gaśnicy? Te nazwy tagów same w sobie nie są bezużyteczne, ale bez kontekstu niewiele znaczą.
TAK Używaj opisowych nazw tagów
Nazwa powinna mówić, do czego służy tag. Należy również zwrócić uwagę na formatowanie. Nawet “tmrDelay” lub “tmr_delay” byłoby lepsze. Nikt nie powinien być zmuszony do zgadywania separacji słów.
TAK Dodaj opisy do tagów i szczebli
Prosta procedura buforowania lub alias może zmienić “AB_XGI:I.Data[1]” w coś bardziej użytecznego, jak “partXPos”. “tmrdelay” może stać się “tmrDrivesReady”. Jeszcze lepszym rozwiązaniem byłby opis na tagu lub szczeblu, który wyjaśniałby, do czego służy.
TAK Używaj poprawnej pisowni. Czy kiedykolwiek próbowałeś znaleźć wszystkie tagi dotyczące danych pozycji i jeden z nich jest napisany “poistion”? Tak…
NIE Zaniedbuj strukturę programu. Nikt nie chce przebrnąć przez 200 szczebli procedury o nazwie “Main”, która obejmuje wszystko, od wejścia / wyjścia (I / O) do przepływu procesu.
TAK Używaj rutyn i typów danych zdefiniowanych przez użytkownika (UDT) (lub “struktur” w zależności od producenta), aby zachować porządek. Po prostu podziel kod na kilka procedur o nazwach “Camera”, “InputBuffer” i “Faults”, dzięki czemu wszystko będzie bardziej czytelne. Nie musisz przekopywać się przez 50 szczebli niepowiązanej logiki – jeśli potrzebujesz logiki kamery, przeszukaj procedurę “Camera”.
TAK UDT są niezwykle przydatne. Pozwalają grupować i nazywać dane, nawet w tablicach. Na przykład, jeśli masz wiele danych o pozycji powracających z systemu wizyjnego, możesz je uporządkować, tworząc UDT “Position” ze znacznikami “X”, “Y” i “Z”. “point1” ze znacznikami podrzędnymi jest znacznie lepsze niż “point1X”, “point1Y” i “point1Z”. Łatwiejsza zmiana nazwy, łatwiejsze odniesienie, łatwiejsze do umieszczenia w tablicy i iteracji.
NIE Bądź optymistą:
“Ten projekt zajmie tylko kilka miesięcy”
“Klient dokładnie wie, czego chce”
“Nikt oprócz mnie tego nie zobaczy”
lub mój osobisty faworyt:
“Będę pamiętał, dlaczego to zrobiłem”.
TAK Pamiętaj o prawie Murphy’ego: “Wszystko, co może pójść źle, pójdzie źle”. Ten punkt ma na celu podkreślenie konieczności wszystkich pozostałych. Pozytywne nastawienie rzadko jest czymś złym, ale gdyby nic nigdy nie szło źle, prawdopodobnie nie mielibyśmy pracy. Rzeczy się psują, plany się zmieniają, wypadki się zdarzają. Skalowalny, czytelny i łatwy w utrzymaniu kod to śmiertelna słabość Murphy’ego.
Najlepszą rzeczą, jaką możemy zrobić, aby przygotować się na nieznaną przyszłość, jest pamiętanie o powyższych DO. Używając struktur danych, organizacji, spójnych stylów nazewnictwa i opisowych komentarzy, piszemy kod, który jest łatwy w utrzymaniu i elastyczny. Ułatwia to pracę każdej osobie, która będzie musiała spojrzeć na projekt w przyszłości.
Twój klient podziękuje Ci, gdy będzie musiał dodać nowy przycisk. Twoi współpracownicy podziękują Ci za łatwą do naśladowania strukturę. Ale z mojego doświadczenia wynika, że osobą, której pomagasz najbardziej, jesteś Ty sam. Ponieważ szczerze mówiąc, 50% czasu, kiedy narzekam na kod, to mój własny.
NIE Po prostu spraw, by działał.
TAK Poświęć czas, aby zrobić to dobrze. Pracuj mądrze teraz, aby ułatwić sobie pracę później.
Breen Machine Automation Services jest partnerem merytorycznym CFE Media and Technology.
