Jeszcze kilka lat temu zdecydowana większość stanowisk robotycznych programowana była w sposób nietekstowy, czyli online. Takie podejście ma jednak sporo wad, co powoduje, że na znaczeniu zyskują wirtualne środowiska do programowania robotów na ekranie komputera. Problem w tym, że jest ich dziś na rynku zbyt wiele.

W 2015 r. jedynie ok. 3% robotów przemysłowych programowych było z wykorzystaniem wirtualnych środowisk pracujących w trybie offline. Dziś proporcje te się zmieniają – głównie ze względu na ciągły rozwój robotyzacji oraz zmiany charakteru produkcji przemysłowej z wielkoseryjnej na średnio- i małoseryjną. Rosnąca indywidualizacja procesów wytwórczych oraz towarzysząca jej konieczność częstego przezbrajania robotów sprawiają, że kwestia ich programowania bez wstrzymywania produkcji nabiera kluczowego znaczenia. A to właśnie potrafią środowiska programistyczne przeznaczone do tworzenia programów wykonawczych na ekranie komputera. Każdy producent robotów ma w swojej ofercie takie oprogramowanie – i każdy wymaga, aby do parametryzacji jego robota wykorzystywać dedykowane rozwiązania software’owe.

Offline lepsze niż online

Krótki czas programowania, niewielkie wymagania sprzętowe oraz duża precyzja ruchów robota – wydawać by się mogło, że programowanie konwersacyjne, zwane także nietekstowym lub online, ma same zalety. Stosowane przez długi czas jako podstawowa metoda programowania robotów, ma w sobie sporo z klasycznych metod nauczania. Polega bowiem na „pokazywaniu” jednostce robotycznej określonego ruchu, a następnie jego zapisaniu i odtworzeniu przez sterownik robota. Sam proces uczenia może być realizowany na dwa sposoby: przez fizyczne prowadzenie ramienia robota bądź z punktu do punktu (Point-To-Point), bądź wzdłuż zadanej trajektorii (Continuous Path – CP) lub przy użyciu konsoli albo panelu HMI. W tym drugim przypadku operator definiuje parametry pracy robota na ekranie, stosując kombinację wielkości fizycznych i modeli ruchów.

Metody te łączy jedno: konieczność fizycznej dostępności robota, a tym samym wstrzymania prac na czas programowania. Kwestia ta w przypadku małych robotów współpracujących stosowanych np. na stanowiskach montażowych ma znaczenie drugorzędne, ale w przypadku jednostek zintegrowanych z linią produkcyjną może generować olbrzymie koszty. Wady tej pozbawiona jest metoda programowania offline, w której rolę interfejsu programistycznego pełni komputer desktopowy, zaś sam program obróbczy tworzony jest całkowicie autonomicznie i wtórnie załadowywany do sterownika jednostki robotycznej. Dzięki temu można programować roboty i przeprowadzać symulacje ich pracy zdalnie, tj. bez ich fizycznego udziału – i to na dużo bardziej zaawansowanym poziomie niż w przypadku metod nietekstowych.

Rozbudowane symulacje 3D

Jako metoda tekstowa programowanie offline wymaga instalacji odpowiedniego środowiska programistycznego współpracującego z daną jednostką robotyczną. Dostępne dziś na rynku oprogramowanie tego typu oferuje cały szereg przydatnych funkcjonalności – od projektowania trajektorii ruchu robota, przez analizę przestrzenną jego komponentów i kontrolę przemieszczeń oraz orientacji chwytaków, po zadania z zakresu rozmieszczenia i współpracy poszczególnych gniazd robotycznych w zakładzie produkcyjnym. Możliwość taką zapewniają rozbudowane biblioteki zawierające zarówno poszczególne modele robotów danej marki, jak i ich wyposażenie (m.in. pozycjonery, tory jezdne, przenośniki i czujniki). Co więcej, tworzone w nich programy obróbcze można wszechstronnie symulować z zastosowaniem różnorodnych kryteriów i opcja analizy (np. detekcji kolizji). Funkcjonalność taką oferuje m.in. oprogramowanie, ABB RobotStudio, FANUC Roboguide, Mitsubishi Melfa Works, Stäubli Robotics Suite czy YASKAWA MotoSim. Wszystkie zapewniają dostęp do rozbudowanych bibliotek danych, a także możliwość importu modeli komponentów w postaci danych CAD i eksportu gotowego programu bezpośrednio do sterownika robota. Środowisko ABB RobotStudio dodatkowo ułatwia pracę programiście, bardzo dokładnie odwzorowując oprogramowanie do obsługi robota. Z kolei Mitsubishi Melfa Works przoduje pod względem zasobów bibliotek: jako dodatek do systemu SolidWorks ma dostęp do wszystkich komponentów zapisanych w jego bazie danych. Nie może jednak funkcjonować autonomicznie: aby z niego korzystać, trzeba najpierw zainstalować SolidWorks.

Wieża Babel

Cieniem na tym pozytywnym obrazie kładzie się fakt, że każde z tych środowisk bazuje na innym języku programowania specyficznym dla danego producenta. ABB korzysta z Rapid, Comau z PDL2, FANUC z Karela, KUKA z KRL, Mitsubishi posługuje się językiem Melfa-Basic, Stäubli wybrał VAL3, a YASKAWA – Inform. I nie zrobiły tego bez powodu: jest to bardzo dobry sposób na związanie ze sobą klienta, który, jeśli raz kupił robota danego producenta, będzie przy kolejnym zakupie skłonny wybrać go ponownie, aby móc korzystać z posiadanego już oprogramowania.

Kilka firm próbowało obejść to ograniczenie, projektując uniwersalne środowiska programistyczne, takie jak Delmia, RobCAD czy Process Simulate. Rozwiązania te są jednak drogie, a tym samym opłacalne jedynie dla dużych przedsiębiorstw z takich sektorów jak branża motoryzacyjna – główny odbiorca tego typu oprogramowania. Ich funkcjonalności wykraczają zresztą znacznie poza zwykłe programowanie robotów: umożliwiają wspólne prowadzenie całych projektów i równoległą pracę nad danymi przez różnych członków zespołu. Z punktu widzenia średniej wielkości przedsiębiorstwa funkcje te są zbyteczne. Na razie brak jednak na rynku sensownych alternatyw, które łączyłyby w sobie uniwersalność zastosowań z konkurencyjną ceną – na podobieństwo choćby protokołu komunikacyjnego OPC UA, który ma szansę zrewolucjonizować przetwarzanie danych w systemach produkcyjnych i okołoprodukcyjnych działających w chmurze.

Komentarz eksperta

Źródło: Redakcja Automatyka Przemyslowa.pl