Programowanie robotów przemysłowych: metody, języki i narzędzia

Programowanie robotów przemysłowych sprowadza się do zdefiniowania punktów w przestrzeni, rodzaju ruchu między nimi oraz logiki zadania: kiedy chwycić, kiedy puścić, na jaki sygnał czekać. Można to zrobić na trzy sposoby. Pierwszy to uczenie ręczne przy robocie, drugi to programowanie offline na modelu stanowiska, a trzeci to pisanie kodu w języku producenta. W praktyce zakłady łączą je, bo każda metoda ma inne zalety. Poniżej opisujemy, jak to wygląda i od czego zacząć.

Uczenie ręczne i teach pendant

Teach pendant to przenośny panel sterujący, z którego operator uruchamia ruchy osi i zapisuje kolejne pozycje. Najpierw ustawia się ramię w żądanym miejscu, na przykład nad detalem, potem zapisuje punkt, a następnie wybiera typ ruchu do kolejnego. Metoda jest intuicyjna, bo widać fizyczne położenie narzędzia i otoczenia, więc nadaje się do krótkich programów i poprawek na miejscu.

W części robotów współpracujących stosuje się też prowadzenie ręką. Operator łapie ramię i ustawia je, a robot zapamiętuje pozycje. Taka metoda ogranicza potrzebę znajomości języka programowania, jednak przy rozbudowanej logice i tak potrzebny jest edytor programu.

Programowanie offline

W programowaniu offline model komórki robotycznej powstaje w oprogramowaniu symulacyjnym. Programista układa ścieżki, sprawdza zasięg i kolizje, a gotowy kod przenosi do sterownika robota. Zaletą jest to, że robot może w tym czasie pracować na innym zleceniu, a stanowisko da się zaplanować jeszcze przed zakupem. Wymaga to dobrego modelu 3D oraz kalibracji, bo rzeczywiste położenie detali i narzędzi zawsze trochę różni się od modelu.

Języki programowania robotów

Każdy duży producent ma własny język, dlatego programu z jednego robota zwykle nie da się wprost uruchomić na innym. Wspólne jest podejście: instrukcje ruchu, instrukcje logiczne, zmienne i komunikacja z urządzeniami. Różnią się składnia, nazwy poleceń i sposób definiowania układów współrzędnych. Część sterowników oferuje graficzne środowisko z blokami, w którym program układa się z ikon, a kod powstaje w tle. Takie podejście skraca naukę, ale przy złożonych zadaniach programiści i tak przechodzą do edycji tekstowej.

Rodzaje ruchów i dane punktu

Ruch	Co robi	Kiedy go używać
Osiowy (PTP)	porusza wszystkimi osiami jednocześnie, tor narzędzia nie jest prosty	dojazdy swobodne, gdy tor nie ma znaczenia
Liniowy	prowadzi narzędzie po linii prostej	dojazd do detalu, wkładanie, odkładanie
Kołowy	prowadzi narzędzie po łuku przez trzy punkty	spawanie łuków, malowanie, uszczelnianie

Do każdego punktu przypisuje się narzędzie (TCP, czyli punkt roboczy narzędzia) i układ współrzędnych detalu lub stołu. Jeśli TCP jest źle zmierzony, robot dojeżdża w złe miejsce, nawet gdy punkty zapisano poprawnie. Podczas wymiany chwytaka trzeba go więc ponownie zdefiniować. Dobrze zaplanowaną wymianę narzędzi opisuje artykuł o szybkiej wymianie chwytaków w robocie.

Komunikacja z maszynami i sterownikiem nadrzędnym

Robot rzadko pracuje sam. Na stanowisku współdziała z przenośnikiem, prasą, obrabiarką, czujnikami i chwytakiem, więc program zawiera też obsługę wejść i wyjść cyfrowych. Typowy schemat to wymiana sygnałów zgłoszenia i potwierdzenia: robot czeka na sygnał, że maszyna jest gotowa na załadunek, wkłada detal, wysyła sygnał zakończenia i dopiero wtedy maszyna startuje cykl. Przy większych instalacjach komunikację prowadzi się przez sieć przemysłową ze sterownikiem PLC, który zarządza całą linią, a robot odbiera polecenia, na przykład numer programu do wykonania.

Warto uzgodnić z integratorem listę sygnałów jeszcze przed uruchomieniem i opisać ją w dokumentacji. Brak spójnej nomenklatury to częsta przyczyna długich poszukiwań usterek, gdy sygnał ma w programie robota inną nazwę niż w schemacie elektrycznym.

Kolejność prac przy uruchomieniu programu

1. Opisz zadanie: detal, miejsca pobrania i odłożenia, cykl, sygnały z maszyn i czujników.
2. Zdefiniuj narzędzie (TCP) oraz układy współrzędnych stołu, palety i maszyny.
3. Naucz punkty bazowe: pozycję spoczynkową, dojazdy i odjazdy oraz punkty robocze.
4. Napisz logikę programu: warunki, pętle, obsługę błędów, wymianę sygnałów ze sterownikiem nadrzędnym.
5. Uruchom program ręcznie krok po kroku w trybie testowym, z obniżoną prędkością.
6. Sprawdź kolizje i reakcję na zatrzymanie awaryjne, otwarcie osłony i brak sygnału.
7. Zwiększ prędkość etapami, a po odbiorze wykonaj kopię programu i zapisz wersję.

Typowe błędy początkujących

Pierwszy to zbyt wiele punktów uczonych osobno. Lepiej uczyć punkt bazowy i wyznaczać pozostałe względem niego, wtedy przesunięcie stołu wymaga korekty jednego miejsca. Drugi błąd to brak obsługi błędów. Robot, który nie wie, co zrobić po utracie detalu, zatrzyma się albo wejdzie w kolizję. Trzeci to brak dokumentacji i kopii: bez nich po awarii sterownika trzeba zaczynać od zera.

Warto też od początku zadbać o czytelne nazwy zmiennych i komentarze, bo program będzie modyfikować ktoś inny niż autor. Przy zakupie robota sprawdź, jakie narzędzia do programowania dostajesz, czy szkolenie wchodzi w zakres dostawy i jak wygląda wsparcie po uruchomieniu. Informacje o rodzaju robota ułatwia artykuł o rodzajach robotów przemysłowych.

Jak utrzymać program po uruchomieniu

Po odbiorze program żyje dalej: zmienia się detal, dochodzi nowy wariant, ktoś poprawia punkt po kolizji. Utrzymaj porządek, zapisując kopie programów i ustawień narzędzi po każdej zmianie, z datą i krótkim opisem, co zmieniono. Ogranicz liczbę osób z prawem edycji, a pozostałym zostaw tylko uruchamianie. Przy częstych zmianach produktu rozważ programy parametryczne, w których pozycje wynikają ze zmiennych, a nie z ręcznie uczonych punktów. Operatorzy powinni znać zasady postępowania po zatrzymaniu robota i wiedzieć, kogo wezwać, zamiast samodzielnie przesuwać punkty.

Kiedy wybrać którą metodę

• Uczenie ręczne sprawdza się przy prostych zadaniach, szybkich poprawkach i na stanowiskach z jednym detalem.
• Programowanie offline ma sens przy skomplikowanych ścieżkach, wielu wariantach detali i konieczności planowania przed zakupem.
• Kod w języku producenta jest potrzebny do logiki, komunikacji i obsługi błędów, niezależnie od wybranej drogi do zapisu punktów.