Sterowniki PLC na stanowiskach zrobotyzowanych

 Rosnąca liczba urządzeń i systemów wchodzących w skład zrobotyzowanych komór produkcyjnych, ewolucja wymagań bezpieczeństwa oraz zwiększająca się ilość informacji koniecznej do przetworzenia przez kontrolery robotów, wymusza poszukiwanie nowatorskich rozwiązań spełniających oczekiwania rynku. Odpowiedzią producentów robotówprzemysłowych na te wymagania są m.in.: nowoczesne, wieloprocesorowe jednostki sterujące, implementacja sterowników PLC i sterowników bezpieczeństwa wraz z oprogramowaniem w kontrolerach.

Tworzenie wysoko wydajnych i niezawodnych zautomatyzowanych stanowisk produkcyjnych nie byłoby możliwe bez wykorzystania nowoczesnych systemów sterowania, nadzoru i monitoringu. Niewątpliwie mowa tutaj o sterownikach PLC (ang. Programmable Logic Controller), które w różnej formie i konfiguracji znalazły zastosowanie również w komorach produkcyjnych obsługiwanych przez roboty przemysłowe.
Rozwój sterowników trwa od połowy lat sześćdziesiątych ubiegłego wieku. Począwszy od zastąpienia układów elektromechanicznych (głównie przekaźników, liczników i układów czasowych), które cechowały m.in.: duża zawodność – zwłaszcza elementów mechanicznych, drgania styków, duża kubatura i nierównomierne zużywanie się poszczególnych komponentów systemu, ich elektronicznymi odpowiednikami. Poprzez charakteryzujący się większą niezawodnością, elastycznością, mniejszymi gabarytami, prostszą budową, obsługą i łatwym serwisowaniem system układów logicznych, który przyjął nazwę sterownika programowalnego PLC. Po bardzo rozbudowany system modułowy określany mianem programowalnego sterownika automatyki PAC (ang. Programmable Automation Controller), charakteryzujący się wydajnymi procesorami, rozbudowanymi sieciami komunikacyjnymi i oferujący wiele dodatkowych funkcji.

Historia wykorzystania sterowników PLC w Polsce rozpoczyna się pod koniec lat siedemdziesiątych ubiegłego wieku. Wówczas w polskich fabrykach było zainstalowanych około kilkuset urządzeń tego typu. Uruchomienie produkcji sterowników datuje się na rok 1977, kiedy to Zakłady Automatyki Przemysłowej MERA ZAP w Ostrowie Wielkopolskim rozpoczęły produkcję urządzenia o nazwie INTELSTER PC4K na licencji firmy PILZ GmbH.
Miejsce sterowników PLC w przemyśle
Popularność sterowników PLC jest spowodowana przede wszystkim ich funkcjonalnością. Od początku głównym założeniem było opracowanie urządzenia, którego programowanie, zrozumienie działania i obsługa będzie łatwa i nie będzie wymagała długotrwałego szkolenia operatorów. Wynikiem tego jest pierwszy w historii i do dzisiaj używany drabinkowy język programowania, który jest analogią do schematów stykowo-przekaźnikowych. Konstruktorzy sterowników zapewnili łatwość i szybkość programowania bez konieczności zagłębiania się w specjalistyczną wiedzę z zakresu systemów informatycznych, a oferowany w urządzeniach szeroki wachlarz modułów (I/O cyfrowych i analogowych, liczników, modułów komunikacyjnych itd.) pozwala na łatwe zbieranie informacji o otoczeniu, zaawansowane sterowanie urządzeniami peryferyjnymi i swobodną zmianę oprogramowania.

Rosnące ciągle zapotrzebowanie na coraz bardziej złożone systemy sterowania stymuluje rozwój sterowników PLC. Dzieje się tak głównie dlatego, że urządzenia tego typu można spotkać na wszystkich poziomach infrastruktury zakładów przemysłowych, we wszystkich gałęziach przemysłu, m.in.:

  • na poziomie pojedynczych maszyn (obrabiarki numeryczne, wtryskarki, gilotyny, krawędziarki itp.),
  • na poziomie gniazd produkcyjnych (synchronizacja maszyn oraz robota z urządzeniami specjalistycznymi),
  • na poziomie linii montażowych (sterowanie przepływem produktów),
  • na poziomie całego procesu technologicznego (zarządzanie i monitoring procesowy),
  • jako urządzenia sterujące systemami wspomagającymi (klimatyzacją, ogrzewaniem, oświetleniem itp.).

Budowa, działanie i programowanie sterowników PLC
Obszar stosowania sterowników PLC jest bardzo duży, stąd też na rynku można spotkać urządzenia różnych „rozmiarów”, od najmniejszych, wyposażonych jedynie w określoną liczbę I/O cyfrowych, po największe (najczęściej modułowe) dostosowane do potrzeb użytkownika. Z punktu widzenia programisty ich budowa nie ma najmniejszego znaczenia (rys.1), ponieważ korzysta on zawsze z tych samych zasobów (układy wejściowe/wyjściowe, liczniki, timery, rejestry itp.), a tworzony program zawsze ma podobną postać i zawsze jest automatycznie tłumaczony za pomocą interpretera rozkazów.

Zasada działania wszystkich sterowników PLC jest również taka sama. Podstawową zasadą jest cykliczna praca (rys. 2), w której sterownik wykonuje kolejno po sobie pojedyncze rozkazy programu w określonej kolejności. Każdy z cykli zawiera sztywno określoną sekwencję:

  • inicjalizacja,
  • odczyt stanu wejść,
  • wykonanie programu sterowania,
  • ustawienie wyjść,
  • testowanie i komunikacja.

Na początkowym etapie rozwoju sterowników PLC każdy producent stosował swoje rozwiązania programistyczne, co znacznie komplikowało programowanie i użytkowanie urządzeń. Prace normalizacyjne rozpoczęły się dosyć wcześnie, bo w 1970 roku. Trwały jednak bardzo długo, ponieważ języki programowania stosowane w sterownikach poszczególnych firm znacznie się różniły. Ostatecznie w roku 1993 Międzynarodowa Komisja Elektrotechniki (ang. IEC – International Electrotechnical Commission) zatwierdziła normę IEC 1131 pod tytułem „Programmable Controllers”, która od 1998 r. przyjęła oznaczenie IEC 61131. Według normy IEC 61131 języki programowania sterowników PLC można podzielić na dwie główne grupy: języki tekstowe oraz języki graficzne (rys. 3).
Do grupy języków tekstowych należą:

  • IL – Lista Instrukcji (ang. Instruction List) – język programowania niskiego poziomu, składający się z zestawu instrukcji. Struktura tego języka jest podobna do asemblera, a nazwy i sposób wywołania poszczególnych instrukcji zależą od typu sterownika. Język wykorzystywany zwłaszcza do zadań obliczeniowych.
  • ST – Tekst Strukturalny (ang. Structured Text) – język programowania wysokiego poziomu. Struktura języka ST jest przejrzysta i przypomina języki Pascal lub C. Również w tym przypadku, język najczęściej wykorzystywany jest obliczeń.

 Do grupy języków graficznych należą:

  • FBD – Schemat Bloków Funkcyjnych (ang. Functional Block Diagram) – język wzorowany na schematach ideowych stosowanych w elektronice i opisujących przepływ sygnałów w technice cyfrowej. Głównymi elementami wykorzystywanymi w języku FBD są bloki i elementy sterujące, a realizacja programu w FBD opiera się na przepływie sygnałów, których działanie definiuje topologia obwodu.
  • LD – Schemat Drabinkowy (ang. Ladder Diagram) – język wzorowany na symbolach schematów układów wykonanych w technice stykowo-przekaźnikowej. Podstawowymi symbolami języka drabinkowego są styki i cewki, choć zawiera również bloki funkcyjne (m.in.: liczniki, timery).

W normie IEC 61131-3 zdefiniowano dodatkową metodę programowania– Graf Sekwencji SFC (ang. Sequential Function Chart). Metoda ta jest wykorzystywana zwykle do opisu dużych zadań sterowania w sposób graficzny i znajduje swoje zastosowanie jako nadrzędna struktura programu zawierającego podprogramy.
Imigracja sterowników do kontrolerów robotów
W ostatnim czasie można zauważyć, że projektanci i konstruktorzy robotów przemysłowych oprócz modyfikacji i dodawania nowych opcji do systemów operacyjnych kontrolerów robotów oraz konstruowania nowych rozwiązań sprzętowych, próbują znaleźć optymalne rozwiązanie, zwłaszcza zwiększające ich wielozadaniowość. Pod pojęciem wielozadaniowości zwykle rozumie się cechę systemu operacyjnego umożliwiającą mu równoczesne wykonywanie więcej niż jednego procesu. W przypadku systemów informatycznych za poprawną realizację tej funkcji systemu odpowiedzialne jest zwykle jego jądro. Implementacja wielozadaniowości znacznie przyspiesza możliwości obliczeniowe komputerów, a czasami wręcz jest konieczna dla zapewnienia założeń przyjętych przez programistów. Dlatego dzisiaj trudno wyobrazić sobie systemy operacyjne, zwłaszcza te, od których wymaga się pracy w czasie rzeczywistym bez tej funkcji.
W przypadku kontrolerów robotów przemysłowych wielozadaniowość wydaje się być idealnym rozwiązaniem z kilku powodów:

  • konieczność zapewnienia ciągłego sterowania manipulatorem robota (rezerwacja jednego zadania do obsługi ruchu manipulatora),
  • coraz większa złożoność aplikacji sterujących, implementowanych w kontrolerach (konieczność jednoczesnej obsługi np. komunikacji, odczytywania sygnałów wejściowych i ruchu manipulatora),
  • rosnące wymagania pozyskiwania coraz większej ilości informacji o realizowanym procesie technologicznym (np. z inteligentnych systemów wizyjnych),
  • konieczność analizy danych z zaawansowanych systemówbezpieczeństwa (np. z systemu SafeMove),
  • alternatywa obsługi i zarządzania pracą urządzeń specjalistycznych wchodzących w skład zrobotyzowanej komory produkcyjnej (przejmowanie funkcji dodatkowych sterowników PLC),
  • wykonywanie złożonych obliczeń numerycznych.

Wymienione powyżej powody determinują konieczność ciągłego dostosowywania funkcjonalności kontrolerów robotów do wciąż rosnących potrzeb. Postać aplikacji sterowania od programu obsługującego pierwszego robota UNIMATE w latach 60. przeszła długą ewolucję, choć ich zadanie główne pozostało bez zmian – zapewnienie ciągłego sterowania manipulatorem. Obecnie do zadania tego doszła konieczność sterowania osiami dodatkowymi (pozycjonerami, torami jezdnymi czy wieloma manipulatorami), jednak właśnie to pierwsze wymaganie powoduje, że modyfikacje głównego zadania robota są bardzo ograniczone. Należy zauważyć, że zadanie to (w zależności od sposobu poruszania manipulatorem, a tym samym specyfiki procesu technologicznego) często wyklucza możliwość wykonywania dodatkowych zadań bez funkcji wielozadaniowości.

Dlatego, aby nie było przerw w obsłudze kanałów komunikacyjnych (np. obsługa sieci Ethernet z wykorzystaniem protokołu TCP/IP), nadzorowania procesu technologicznego (ciągłe sprawdzanie stanu czujników z dużą częstotliwością) lub wykonywania dodatkowych obliczeń arytmetycznych (złożone obliczenia zajmujące czas) należy utworzyć dodatkowe zadania, które będą pracowały „w tle” zadania ruchu.
Podążając dalej i dodając do kontrolera robota „funkcję sterownika PLC”, istnieje możliwośćprzeniesienia części zadań na inne urządzenie/system. Podejście takie rozwiązuje niejako co najmniej trzy problemy:

  • brak problemów ze sprzętową integracją sterownika PLC z kontrolerem robota podczas uruchamiania zrobotyzowanej komory produkcyjnej (urządzenia stanowią „jedną całość”),
  • brak konieczności montażu dodatkowej szafy dla sterownika PLC (redukcja przestrzeni stanowiska),
  • uproszczenie programowania i kontroli statusu sygnałów obsługiwanych przez sterownik PLC poprzez przeniesienie tych funkcji do panelu programowania (ang. Teach Pendanta – TP) robota.

Przykłady rozwiązań
Czołowi światowi producenci robotów przemysłowych od pewnego czasu proponują rozwiązania charakteryzujące się bardzo mocnym sprzężeniem sprzętowym i programowym kontrolerów robotów ze sterownikami PLC. Należy dodać, że kierunek ten ciągle się rozwija w postaci kolejnych funkcji systemowych, które są „zamykane” w kontrolerze robota.
Pierwszym przykładem może być system IRC5 firmy ABB. IRC5 jest wieloprocesorowym systemem sterowania opartym na szynie PCI i posiadającym m.in. opcje wielozadaniowości, przekazywania informacji z pliku do robota, komunikacji z komputerem PC i zaawansowanych zadań ruchowych. Dzięki temu nie ma żadnych przeciwwskazań, aby tworzyć złożone aplikacje zarówno przy użyciu panelu nauczania (FlexPendanta), jak i środowiska RobotStudio online zainstalowanego na komputerze PC (drugie rozwiązanie jest wygodniejsze). W kontrolerze IRC5 są również standardowo montowane karty umożliwiające współpracę robota z urządzeniami peryferyjnymi, jednak w przypadku konieczności obsługi dużej liczby czujników oraz urządzeń wykonawczych, celowym wydaje się zastosowanie dodatkowego sterownika PLC. Rozwiązanie proponowane przez firmę ABB polega na zamontowaniu na drzwiach szafy sterowniczej urządzenia AC500 (fot. 7), dzięki czemu możliwe jest ekonomiczne i szybkie zautomatyzowanie całej celi produkcyjnej. Sterownik ten, podłączany przez magistralę DeviceNet do kontrolera robota, jest zazwyczaj konfigurowany jako slave i wówczas odpowiada za koordynację sterowania wyposażeniem dodatkowym robota (np.: chwytakiem, przenośnikiem). Rozwiązanie takie pozwala na łatwy sposób zobrazowania statusu urządzenia, stanów wejść/wyjść oraz kontrolowanie sygnałów w sterownikach za pomocą FlexPendanta. Należy zaznaczyć, że zintegrowany sterownik w warstwie aplikacyjnej może również pełnić rolę mastera, wówczas staje się odpowiedzialny za interakcje pomiędzy robotem a jego otoczeniem w komorze produkcyjnej. Architektura programowa obu urządzeń (AC500 i IRC5) zapewnia możliwość ich pełnego wykorzystania w obu konfiguracjach. Integracja programowa umożliwia programowanie sterownika z wykorzystaniem standardowego serwisowego portu ethernetowego kontrolera IRC5 z użyciem komputera PC z oprogramowaniem narzędziowym PS501 Control Builder. Zgodnie z normą IEC 61131-3, programowanie można realizować w pięciu językach (IL, ST, FBD, LD, SFC – patrz pierwsza część artykułu) oraz opcjonalnie w języku C z interfejsem API. Montowany w szafie sterownik – w odpowiedniej konfiguracji – może przejąć również funkcje sterownika bezpieczeństwa i być odpowiedzialnym za zachowanie warunków bezpieczeństwa dla maszyn i ludzi.

W nieco innym kierunku zdaje się podążać firma Fanuc, w której kontrolerach serii R30iA oraz R30iB (dzięki strukturze wieloprocesorowej) istnieje możliwość realizacji operacji współbieżnych, których działanie może być niezależne zarówno od stanu robota, jak i jego statusu. Nowe kontrolery R30iB, posiadające w swej strukturze trzy procesory, pozwalają na w pełni niezależną realizację obsługi wejść/wyjść robota, co pozwala na implementację funkcji typowych dla małych sterowników PLC. Rozwiązanie to zostało nazwane Programmable Machine Controller (PMC) i w chwili obecnej stanowi standardowe wyposażenie wszystkich nowych kontrolerów robotów firmy Fanuc. Uzyskanie dostępu do tej funkcjonalności jest realizowane podobnie jak ma to miejsce w przypadku systemu wizyjnego – iRVision, poprzez uruchomienie opcji software’owej (opcja, którą należy dodatkowo zakupić).
W odróżnieniu od typowych rozwiązań oferowanych przez innych producentów robotów, PMC stanowi kompletny zintegrowany w kontrolerze robota sterownik PLC, którego programowanie może się odbywać w języku drabinkowym, sekwencyjnym lub też tworząc bloki funkcyjne obejmujące powtarzające się sekwencje logiczne programu. Programowanie jak też podgląd stanu wejść PMC może być realizowane poprzez dedykowane oprogramowanie Fanuc Ladder for Robot na Windows PC, choć instalując kolejne opcje (PMC Change Mode) mamy możliwość edycji programu naszego sterownika PMC za pośrednictwem panelu Teach Pendant. Ze względu na fakt, iż sterownik ma charakter sterownika software’owego jednak działającego na dedykowanym odrębnym CPU, po zainstalowaniu opcji MultiPatch istnieje możliwość jednoczesnego uruchomienia aż pięciu niezależnych PMC na jednym kontrolerze robota. Jak już wspomniano, taka struktura pozwala na pracę poszczególnych PMC nawet w przypadku wystąpienia błędu w aplikacji sterującej robotem czy w przypadku innych nieprzewidzianych sytuacji, w normalnych warunkach prowadzących do zatrzymania całego stanowiska. Plik każdego z PMC aktualizowany jest co 4 lub 8 ms, przy czym podczas programowania poszczególnych PMC istnieje możliwość nadawania priorytetów poszczególnych operacji, tak aby uzyskać pełną skalowalność opracowanego rozwiązania. Podobnie jak u innych producentów, zadbano tutaj również o przejęcie funkcji systemu bezpieczeństwa poprzez rozszerzenie standardowego PMC o moduł bezpieczeństwa DCS. Funkcja ta dostępna jest jako kolejna opcja pod nazwą PMC DCS i stanowi zintegrowany moduł sterownika bezpieczeństwa, zapewniający możliwość budowy systemów bezpieczeństwa. W odróżnieniu od standardowego PMC, w tym przypadku są do dyspozycji jedynie wejścia/wyjścia Safety I/O oraz pamięć wewnętrzna R-relay (rys. 4).

Opracowane przez firmę Fanuc rozwiązanie, polegające na integracji wielu modułów (systemu wizyjnego, PLC, sterownika bezpieczeństwa), jest rozwiązaniem pozwalającym na znaczące poszerzenie funkcjonalności budowanych zrobotyzowanych stanowisk produkcyjnych. W porównaniu do standardowego podejścia, polegającego na integracji robota
z niezależnym sterownikiem PLC, uzyskano korzyści w postaci krótszego czasu integracji wszystkich elementów oraz dostępu do danych z poziomu robota i PLC.
Reprezentowana w Polsce przez firmę ASTOR firma Kawasaki wydaje się również nie pozostawać w tyle za konkurentami w kwestii rozbudowy kontrolera robota o funkcje sterownika PLC. Obecnie wszystkie oferowane przez Kawasaki nowe kontrolery serii D (fot. 8) są standardowo (bez dodatkowych kosztów) wyposażone w funkcję KLogic, która daje możliwość wykorzystania kontrolera robota jako sterownika PLC. W tym przypadku (podobnie do produktów firmy Fanuc) istnieje możliwość pracy w trybie obsługi dodatkowego wątku procesora, wykonującego program napisany w języku drabinkowym. Głównym zadaniem tego programu jest obsługa I/O oraz realizacja operacji logicznych. W tym przypadku również mówi się o uproszczeniu całego układu
oraz skróceniu czasu integracji komory
produkcyjnej. Do tworzenia programu używane jest oprogramowanie KLadder, które działa analogicznie do innych tego typu programów. Po utworzeniu i zapisaniu programu można go przesłać do robota, gdzie zapisywany jest on pod nazwą lsqpg. W przeciwieństwie do innych programów, które są interpretowane linia po linii, program lsqpg jest kompilowany przed pierwszym wykonaniem do postaci binarnej.
W każdej chwili istnieje możliwość przeglądania dowolnej linii programu w postaci drabinkowej na ekranie Teach Pendanta. Jednak edycja z poziomu TP jest możliwa tylko w postaci tekstowej (poszczególnym operacjom logicznym w języku drabinkowy przyporządkowano odpowiadające im „mnemoniki” – rys. 5).
W przypadku niemieckiej firmy KUKA ścieżka rozwoju zarówno kontrolera robota, jak i funkcji programowego sterownika PLC ma swój początek w 1996 roku, kiedy to KUKA zaprezentowała pierwszy kontroler robota bazujący na oprogramowaniu Microsoft Windows. Kontroler został oznaczony symbolem KR C4 i podczas jego opracowywania inżynierowie zwrócili szczególną uwagę na bezpieczeństwo, wielozadaniowość oraz oszczędność energii. Programowe podejście do większości zastosowanych rozwiązań pozwoliło na zmniejszenie zasobów sprzętowych i połączeń kablowych o odpowiednio 35% i 50% w stosunku do poprzednika (fot. 9).
W kontrolerze KR C4 robot wykorzystuje otwarte standardy przemysłowe, gdzie mający postać specjalistycznej aplikacji KUKA.PLC zrealizowany jest w postaci zintegrowanego w układzie sterowania robota sterownika PLC. Rozwiązanie to pozwala na bezpośrednią komunikację i wymianę danych pomiędzy robotem a PLC. W najnowszych wersjach kontrolerów sercem systemu sterowania jest wielordzeniowa jednostka sterowania, zapewniająca odpowiednią moc obliczeniową, a także odseparowanie kluczowych dla działania i zachowania bezpieczeństwa procesów (fot. 10). Wielordzeniowa technologia umożliwia implementację wbudowanych funkcji bezpieczeństwa SIL2 zgodnie z wymaganiami określonymi w normie IEC 61508. Jak wspomniano wcześniej, całość oparta jest na systemie Microsoft Windows, a sama aplikacja KUKA Soft-PLC ma przyjazny użytkownikowi interfejs. Celem takiego rozwiązania jest m.in. skrócenie czasu programowania. KUKA.PLC stanowi zbiór kilku komponentów, w których KUKA.PLC ProConOS zajmuje się realizacją zadań związanych ze sterowaniem i w tym celu wyposażony jest w odpowiednie złącza komunikacyjne.
KUKA.PLC Multiprog jest specjalistycznym środowiskiem, przeznaczonym do tworzenia i konfiguracji procesu sterowania. Proces programowania realizowany jest w językach programowania sterowników PLC: lista instrukcji (IL), język drabinkowy (LD), schemat bloków funkcyjnych (FBD), tekst strukturalny (ST) i graf sekwencji (SFC). Ważnym komponentem z punktu widzenia sterownika PLC jest również KUKA.PLC Multiprog MCFB, udostępniający możliwość sterowania dodatkowymi osiami robota, jak też osiami KMC pod kontrolą zintegrowanego sterownika PLC. Rozwiązanie to pozwala na rozszerzenie funkcji układu sterowania KRC i KMC o funkcje Motion Control.
Analizując obszar wykorzystywania sterowników PLC w zrobotyzowanych komorach produkcyjnych, nie sposób pominąć rozwiązania proponowanego przez firmę Mitsubishi. Nowe podejście do kontrolerów robotów w postaci rozproszonej i w pełni skalowalnej platformy iQ pracującej na tej samej płycie bazowej wydaje się być lekarstwem na często spotykaną różnorodność sprzętu i systemów sterowania całą linią technologiczną u jednego przedsiębiorcy. Podobnie jak w innych przypadkach, tutaj również kierowano się m.in. zapewnieniem wielozadaniowości oraz pełnej synchronizacji pracy urządzeń. Projektanci systemu postanowili zbudować jednostkę (na wzór modułowych sterowników PLC), która zapewniłaby sterowanie wieloprocesorowe (do 4 procesorów z ponad 50 modułami dodatkowymi). Wśród głównych elementów systemu iQ należy wyróżnić jednostki: sterownika PLC, robota, maszyny CNC, systemu sterowania wieloma osiami, procesową, komputera PC oraz systemu programowanego w języku C++. W związku z tym, że poszczególne jednostki mają niezależne procesory, zapewniają wielozadaniową niezależną pracę, przy czym ich montaż na jednej płycie pozwala na szybkie wzajemne komunikowanie się i pełną wymianę informacji (fot. 11). Kolejnym udogodnieniem w omawianym przykładzie jest wykorzystanie jednej platformy programistycznej iQ Works dla wszystkich elementów systemu, co sprawia, że wszystkie procesory mogą pracować w oparciu o te same dane. Spięcie z innymi platformami jest realizowane w tym przypadku najczęściej za pomocą sieci Ethernet (CC-link lub TCP/IP).
Zaproponowana platforma iQ może pełnić również funkcje systemu bezpieczeństwa, wówczas w jej skład wchodzi moduł sterownika bezpieczeństwa połączony z urządzeniami bezpieczeństwa (np. kurtyną świetlną) za pomocą sieci CC-link Safety. Analogicznie do pozostałych producentów robotów przemysłowych, firma Mitsubishi oferuje środowisko do programowania robotów w trybie offline o nazwie MelfaWorks. I tutaj również można zauważyć nieco inne podejście
nie w postaci odrębnego oprogramowania (jak u pozostałych dostawców, np. RobotStudio firmy ABB, RoboGuide firmy Fanuc), ale modułu programowego rozszerzającego możliwości środowiska SolidWorks.
Zmianami konstrukcyjnymi oraz systemowymi charakteryzuje się również nowy kontroler C5G oferowany przez firmę Comau. C5G został wyposażony w komputer przemysłowy APC820 z procesorem Core 2 Duo, co pozwoliłona uzyskanie wysokiej wydajności przy niskim zużyciu energii. Ponadto konstruktorzy zaproponowali nowy modułowy system wspomagania sterowników ACOPOSmulti. Dzięki wprowadzonym zmianom uzyskano możliwość zarządzania kilkoma aplikacjami w tym samym czasie oraz synchronicznego sterowania kilkoma wieloosiowymi manipulatorami.
Firma Comau w zakresie komunikacji i układów sterowania współpracuje z firmą B&R, czego efektem jest (jak twierdzą przedstawiciele firmy Comau w Polsce) jedyny kontroler na rynku w pełni zgodny ze standardem Ethernet Powerlink.
Przy wykorzystaniu tego protokołu kontroler C5G (fot. 12) może komunikować się zarówno ze sterownikami PLC, jak też z innymi urządzeniami peryferyjnymi. Podobnie jak ma to miejsce w przypadku robotów ABB, sterownik PLC może być skonfigurowany jako slave i realizować zadania na potrzeby robota, lub jako master i nadzorować pracę całej komórki roboczej. Należy tutaj zaznaczyć, że Ethernet Powerlink jest ethernetowym protokołem czasu rzeczywistego umożliwiającym komunikację między urządzeniami na poziomie mikrosekund, co jest niezwykle istotne w wielu aplikacjach przemysłowych. Wydajność sytemu w czasie jednego cyklu jest mniejsza niż 100 mikrosekund, a jego synchronizacja jest możliwa na poziomie 100 ns. Oprócz możliwości podłączenia do 240 węzłów w jednej sieci, sieć Powerlink może być w pełni zsynchronizowana przy nieograniczonej rozszerzalności (rys. 13).
Rozwiązanie umożliwia synchroniczne i asynchroniczne przesyłanie różnego typu danych w czasie rzeczywistym, co ma kluczowe znaczenie nie tylko w obrębie jednej komory produkcyjnej, ale również przy integracji zrobotyzowanych systemów produkcyjnych z innymi systemami automatyki.
Podsumowanie
Niegdyś oddzielne urządzenia, jakimi są sterowniki PLC z dedykowanymi językami programowania, dziś na stałe zagościły w kontrolerach robotów przemysłowych. Zarówno producenci, jak też integratorzy i odbiorcy zauważyli, że rozwiązanie takie jest korzystne z uwagi na możliwość ograniczenia miejsca niezbędnego do montażu urządzenia (dodatkowe szafy procesowe), dłuższy czas integracji w przypadku budowy nowych stanowisk, konieczność zapewnienia wielozadaniowości oraz wymagania rosnące z uwagi na coraz większą ilość danych przesyłanych sieciami komunikacyjnymi (zarówno przez czujniki – np. kamery – do robota, jak i z robota do urządzeń wykonawczych – np. sterowanie wieloma osiami równocześnie). Obserwując rozwój stanowisk produkcyjnych oraz rosnącą na nich liczbę robotów, wydaje się być nieuchronne rozwijanie systemów sterowania poprzez tworzenie rozwiązań zapewniających z jednej strony coraz większą elastyczność, a z drugiej pełną kompleksowość. Widoczny dzisiaj trend rozbudowy systemów robotów (zarówno pod względem sprzętowym, jak i programowym) wskazuje, że w przyszłości urządzenia te zapewnią pełną obsługę nie tylko pojedynczych cel produkcyjnych, ale również większych obszarów linii technologicznych. Dziś trudno powiedzieć, co będzie stanowiło bazę systemów sterowania w przyszłości, czy będą to zamknięte w szafie kontrolery robotów (tak jak ma to miejsce u większości producentów), czy kontrolery będą stanowiły jedynie moduł dołączany do płyty bazowej (zgodnie z ostatnią propozycją firmy Mitsubishi).
Oczywiście niezależne sterowniki PLC dalej będą stosowane w wielu aplikacjach zarówno w zastosowaniach przemysłowych (np. obsługa urządzeń specjalistycznych, systemów w elektrowniach i gazowniach), jak i usługowych (obsługa wind, pieców i suwnic, systemów klimatyzacji itd.). Jednak analizując wprowadzane w ostatnim czasie rozwiązania (integracja sterowników PLC, sterowników bezpieczeństwa oraz kontrolerów robotów), możnazauważyć nowe podejście w sposobie wykorzystania kontrolera robota oraz jego panelu nauczania.
Za pomoc w opracowaniu artykułu autorzy dziękują firmom: ABB, ASTOR, Comau, Fanuc Robotics, KUKA, Mitsubishi.
CE

Ppłk dr inż. Wojciech Kaczmarek, Wojskowa Akademia Techniczna
Dr inż. Jarosław Panasiuk, Wojskowa Akademia Techniczna