Mendelova univerzita v Brně Provozně ekonomická fakulta
Řízení výrobní linky s průmyslovým robotem MELFA. Diplomová Práce
Vedoucí práce: Dr. Ing. Radovan Kukla
Bc. Petr Minařík
Brno 2013
2
Na tomto místě chci poděkovat vedoucímu mé práce panu Dr. Ing. Radovanu Kuklovi, za odborné vedení a shovívavý přístup při mém zpracování této práce. Dále bych chtěl poděkovat všem, kteří se mi během tvorby snažili pomoct.
3
Prohlašuji, že jsem tuto práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu. V Brně dne 19. května 2013
_________________
4
Abstrakt: Tato diplomová práce se zabývá analýzou možnosti začlenit průmyslového robota Mitsubishi Melfa RV-2AJ do výrobní linky SMC FMS200 pomocí technologie OPC. Dále práce pojednává o analýze a rozboru komunikačního protokolu průmyslového robota Melfa s následnou aplikací nabytých znalostí do systému Control Web. Práce obsahuje popis tvorby prvku Active X v jazyce Visual C++, automatu pro lexikální analýzu. Také se zde nachází popis tvorby výsledné aplikace pro řízení v systému Control Web.
Abstract: The concern of this diploma thesis is an analysis of the possibility to incoorporate Mitsubishi Melfa RV-2AJ industrial robot in SMC FMS200 production line using OPC technology. Analysis of the robot´s communication protocol and application of ecquired knowledge are included in order to use the Control Web system as a communication and control interface. The creation of an Active X object in Visual C++ and lexical analysis automat are explained. Development of the application for controlling the robot via Control Web system is documented as well.
5
Obsah 1
Úvod a cíl práce ............................................................................................................. 8 1.1
Úvod: ..................................................................................................................... 8
1.2
Cíl práce: ................................................................................................................ 8
Analýza problému:................................................................................................................ 9 1.3
Výrobní linka SMC FMS200: .................................................................................. 9
1.4
Profibus (Process Field Bus): ............................................................................... 10
1.5
OPC server: .......................................................................................................... 10
1.6
Průmyslový robot Mitsubishi Melfa RV – 2AJ: .................................................... 12
1.6.1 Řídící jednotka CR1-571: ................................................................................ 13 1.6.2 Enkodéry: ........................................................................................................ 15 existují dva typy enkodérů..................................................................................... 15 1.6.3 Inkrementáln senzor ...................................................................................... 15 1.6.4 Absolutní senzor ............................................................................................. 16 1.7
Připojení robota přes RS – 232: ........................................................................... 17
1.8
RT – Toolbox: ....................................................................................................... 18
1.9
Teorie formálních jazyků: .................................................................................... 19
1.9.1 Chomského klasifikace gramatik[2]: .............................................................. 21 1.9.2 Konečný automat: .......................................................................................... 22 1.9.3 Znázornění přechodové funkce ...................................................................... 23 1.9.4 Implementace konečného automatu: ............................................................ 23 1.10 Technologie COM a prvek active X: ..................................................................... 23 1.10.1 COMobjekty: ................................................................................................ 24 1.10.2 COM rozhraní: .............................................................................................. 24 1.10.3 COM klient a server ...................................................................................... 24 1.10.4 Unikátní identifikátor COM objektů: ............................................................ 25 1.11 Active X ................................................................................................................ 25 1.12 Prostředí control web:......................................................................................... 26 1.12.1 Přístroje: ....................................................................................................... 27 1.12.2 Rozšíření Control Webu pomocí externí technologie: ................................. 29 1.13 Microsoft Visual studio........................................................................................ 29 1.14 Závěr kapitoly: ..................................................................................................... 30 Metodika ............................................................................................................................ 31 1.15 Začlenění průmyslového robota Melfa do výrobní linky FMS 200...................... 31
6
1.16 Tvorba active X komponenty: ............................................................................. 31 1.17 Tvorba aplikace v Control Webu: ........................................................................ 31 Vlastní práce: ...................................................................................................................... 32 1.18 Začlenění průmyslového robota Melfa do výrobní linky FMS200: ..................... 32 1.19 Komunikační protokol mezi RT-Toolbox a kontrolérem CR571: ......................... 34 1.20 Metodika odposlechu komunikace na sériovém portu: ..................................... 36 1.21 Analýza získaných dat:......................................................................................... 36 1.22 Zachycená komunikace: ...................................................................................... 36 1.23 Závěr kapitoly: ..................................................................................................... 39 1.24 Tvorba active X komponenty: ............................................................................. 41 1.24.1 Redukce příkazů jazyka Movemaster Command: ........................................ 41 1.24.2 Implementace lexikálního analyzátoru: ....................................................... 43 1.24.3 Kontrola tvaru příkazu: ................................................................................. 43 1.24.4 Automat parse:............................................................................................. 44 1.24.5 Automat checkParam: .................................................................................. 45 1.24.6 Implementace active X komponenty: .......................................................... 46 1.24.7 Vytvoření a nastavení projektu: ................................................................... 47 1.25 Závěr kapitoly: ..................................................................................................... 48 Aplikace Control Web ......................................................................................................... 49 1.26 Import Active X do Control Webu: ...................................................................... 50 1.27 Tvorba aplikace ................................................................................................... 50 Závěr ................................................................................................................................... 52 1.28 Shrnutí práce: ...................................................................................................... 52 1.29 Zhodnocení výsledků: .......................................................................................... 53 1.30 Budoucí využití a možná rozšíření: ...................................................................... 53 Zdroje: ................................................................................................................................ 54
7
1 Úvod a cíl práce 1.1 Úvod: Použití robotů v průmyslu výrazně urychlilo výrobu, zvýšilo přesnost a snížilo výrobní náklady. Odvětví průmyslových robotů je rychle vyvíjející se disciplína, která skýtá velký potenciál rozvoje. Překotný rozvoj zapříčinil, že se na trhu pohybuje řada renomovaných výrobců, z nichž každý používá vlastní komunikační rozhraní. Tento fakt někdy může vést k problémům s komunikací mezi zařízeními různých výrobců. Tomuto se snaží zabránit technologie OPC a také systém Control Web, který zastupuje rozhraní člověk-stroj. V této
práci se
pokusíme
začlenit
průmyslového
robo-
ta Mitsubishi Melfa RV-2AJ do výrobní linky SMC FMS200.
1.2 Cíl práce: Cílem práce je analyzovat možnost začlenění průmyslového robota MELFA do výrobní linky FMS 200 (řízené PLC moduly Siemens Simatik) pomocí technologie OPC. Dále pak prozkoumání komunikačního protokolu průmyslového robota Melfa RV2-AJ při komunikaci s dodanou aplikací RT–Toolbox. Poté ze získaných informací následná tvorba aplikace v prostředí programu Control Web, ve kterém bude obsažen lexikální analyzátor jazyka Movemaster command sloužící jako ochranný prvek proti použití nevhodného příkazu, který by mohl vést k poškození průmyslového robota nebo zranění obsluhy. Tato komponenta bude vytvořena jako prvek COM technologií Active X a následně implementována jako příslušný modul. Dále bude aplikace v Control Webu obsahovat komunikační rozhranní pro okolní přístroje a příkazová řádka pro obsluhu. Jako další komponenta systému bude archivační funkce, která bude ukládat provedené příkazy pro případnou pozdější analýzu práce robota a pro vyhodnocení možných chyb, které mohou vzniknout při činnosti.
8
Analýza problému: Pro další tvorbu programového vybavení je potřeba seznámit se s jednotlivými komponentami, které budeme v průběhu práce potřebovat. Jedná se zejména o hardware průmyslového robota Mitsubishi Melfa RV – 2AJ a jeho ovládací software programe RT – Toolbox a další technologie, které připadají v úvahu pro možné použití.
1.3 Výrobní linka SMC FMS200: Je to modulární výrobní linka, která se skládá z oddělených pracovních stolů, na nichž probíhají jednotlivé kroky výroby (či spíše skládání) pouzdra s ložiskem. Jednotlivé takty výroby jsou na sobě nezávislé a dají se provozovat s určitými omezeními i mimo celek výrobní linky. Mohou tak posloužit jako demonstrační prostředek při výuce. Celá výrobní linka FMS200 je určena především k výuce automatizace a slouží také jako tréninková linka pro výcvik zaměstnanců, kteří přijdou do styku s výrobky firmy SMC. Tomuto je také přizpůsobena koncepce výrobní linky, která dovoluje simulovat množství chyb, které mohou nastat na průmyslově nasazené lince. Jednotlivé stoly mají pečlivě vedené a označené rozvody tlakového vzduchu a signálních vodičů včetně snadno identifikovatelných čidel, které mají jasně definované polohy. Zároveň je linka stavěna s ohledem na maximální bezpečnost při výuce nebo tréninku. Linka kombinuje pneumatické efektory s elektronickým řízením pomocí PLC modulů Siemens Simatic, které komunikují pomocí sběrnice Profibus a umožňuje použití OPC serveru jako centrálního řídícího prvku. Stlačený vzduch je do jednotlivých pracovních pozic dodáván pomocí rozvodu hadic od kompresoru se vzdušníkem, který má maximální pracovní tlak 8bar.
9
1.4 Profibus (Process Field Bus): Jedná
se
průmyslovou
sběrnici,
která
je
určena pro
automatiza-
ci zejména výrobních linek a řízení průmyslových technologií. Sběrnice má na základě své délky různou přenosovou rychlost (od 9kbit/s až po maximum 12Mbit/s). Maximální rozsah sítě je 100m až 1,2 km, podle použité přenosové technologie. S převodníky na standard RS485 lze kombinovat metalický a optický přenos dat. Řízení přístupu na sběrnici řeší buď metoda tzv.token ring (v logickém kruhu), pomocí řídícího člena sítě (tzv. Master), který po ukončení komunikace s podřízeným zařízením (tzv. Slave) uvolňuje řízení sběrnice pro ostatní účastníky. Druhou možností je využití metody klient-server, kdy komunikuje aktivní Master s přiděleným zařízením Slave.
1.5 OPC server: OLE for process Control je standardizující komunikační rozhraní mezi prvky průmyslové automatizace. Standard OPC spravuje nezisková organizace, tudíž implementace standardu je dostupná bez licenčních poplatků. Uživatelům tedy odpadají překážky ve formě uzavřených komunikačních protokolů a z toho vyplývajících potíží při vývoji aplikací. OPC tvoří programovou vrstvu mezi technickým vybavením a programy s tímto hardwarem komunikujícím. Prvky průmyslové automatizace vybavené OPC serverem jsou tak dobře použitelné, takže stačí pouze nainstalovat příslušný ovladač a vše pracuje bez větších obtíží. Stejně tak stačí na daném počítači instalovat patřičný OPC server pro použitý hardware a programy schopné se na tento server napojit (OPC klient) a komunikovat s jeho hardwarem. Viz. obrázek 1. Technicky je standard OPC založen na komponentové technologii COM firmy Microsoft. Název napovídá spíše na použití nadstavby COM pro tvorbu složených dokumentů – OLE (Object Linking and Embedding). Jelikož je však technologie COM používána k implementaci řady komponent v operačních systémech Windows, je COM široce podporován, a tudíž je využit i v tomto případě. Obsahuje řadu vlastností velmi užitečných i pro OPC, jako například globální registraci komponent (každý OPC klient přesně ví jak se dostat k OPC serveru), kategorie komponent (OPC klient může snadno zjistit které OPC servery a jakých verzí jsou na daném počítači dostupné), apod. . 10
Obrázek 1
OPC standard definuje řadou způsobů komunikace, aby vyhověl různým požadavkům klientů: Synchronní komunikace vždy čekající na přenos dat z/do zařízení. 2. Synchronní komunikace pracující s vyrovnávací pamětí serveru (cache). 3. Asynchronní komunikace (vždy komunikuje se zařízením). 4. Periodická komunikace serveru se zařízením a zpětné volání klienta při změně dat. 1.
Druhý a čtvrtý způsob komunikace předpokládá, že server sám dokáže vyvolávat komunikaci s periferií a buď jen ukládat přečtená data do vyrovnávací paměti (odkud mohou být synchronně čtena) nebo předávat data klientovi zpětným voláním (jeden ze způsobů asynchronní komunikace).
11
1.6 Průmyslový robot Mitsubishi Melfa RV – 2AJ: Jedná se o robota, který může být využíván v průmyslových aplikacích ve stísněných prostorech při manipulaci s předměty do 2kg hmotnosti. Manipulátor má dosah 410mm a maximální rychlost 2100mm/s a přesnost ±0,02mm(ve zvláštním
režimu
pohybu).
Paže
jsou
poháněny
střídavými elektromotory
s integrovanými číslicovými snímači absolutní polohy, které přispívají k velké přesnosti a vysoké spolehlivosti při provozu. Robot je vybaven rozvodem pro použití pneumatického chapadla (efektoru) včetně ventilů. Tlakové hadice jsou vedeny vnitřkem konstrukce, takže se výrazně snižuje riziko jejich poškození nebo zničení při kolizi. Elektrický efektor, který je nainstalován na robotovi postrádá senzory o stisku a přítomnosti cizího tělesa. Umožňuje však regulovat sílu stisku pomocí nastavení registrů elektrického gripu. [1] Robot vzhledem k výše uvedeným výkonům a schopnosti přenášet hmotnější tělesa není navzdory své odolnosti a vybaveností systémem detekce kolize navržen k tomu, aby pracoval současně s lidskou obsluhou. Reakce na možnou kolizi se dá nastavit v několika stupních, anebo se dá úplně vypnout [1]. I při vyšší citlivosti na možnou kolizi hrozí při vysoké rychlosti pohybu ramene s nákladem vážné zranění. Výrobce proto důrazně doporučuje oddělit výrobní procesy s lidskou obsluhou od robotické části výrobní linky. Podrobný popis parametrů robota Melfa je v tabulce 1.
12
1.6.1 Řídící jednotka CR1-571: Řídící jednotka robota je stejná jako u vyšších modelů a jedná se o poměrně výkonný počítač s 64 bitovým RISC procesorem s DSP. Kontrolér dokáže zaráz obsluhovat až 6 pohyblivých os, 4 gripy (efektory) a komunikovat po různých rozhranních (standardně RS232C, RS422 – na něj je napojena ruční ovládací jednotka tzv. teaching pedant, Ethernet, Profibus, CC link a jiné). Řídící jednotka dokáže při použití jazyka Melfa-Basic IV dokáže používat až 8 paralelních (multitaskingových) procesů a pomocí výstupně/vstupních portů ovládat potřebné periferie. Při použití jazyka Movemaster Command je možnost použít multitasking vypnutá a nedá se použít. Robot je schopný nepřetržité práce na tři směny s minimálními přestávkami na periodickou kontrolu. Robot a řídící jednotka CR1571 je navržena tak, že je schopna operovat zcela samostatně, bez použití řídícího počítače, a zároveň umožňuje pomocí komunikačního rozhranní CC link řídit další jednotky (zvláště pak PLC moduly značky Mitsubishi). Tato skutečnost velmi usnadňuje aplikaci do řady průmyslových provozů, jelikož celek vyniká nejen vysokou rychlostí, ale také zároveň velkou přesností.[1] Rozšiřující komponenty je však třeba dokoupit. Náklady na jejich pořízení představují nemalou částku.
13
Tabulka 1 [1]
14
1.6.2 Enkodéry: existují dva typy enkodérů
inkrementální
absolutní
1.6.3 Inkrementáln senzor Inkrementální senzory jsou charakteristické svou vysokou rozlišovací schopností, malými rozměry a nízkou hmotností. Název inkrementální, je vzat z principu činnosti, založeném na otáčivém mezikruží s pravidelně se střídajícími průhlednými a neprůhlednými ryskami, které při otáčení přerušují emitované světlo LED diody umístěné na jedné straně tohoto mezikruží. Toto světlo je detekováno fototranzistorem, umístěným na druhé straně mezikruží naproti LED diodě. Do optické cesty mezi zdrojem a přijímačem světla je u většiny snímačů zařazen ještě nepohyblivý maskovací kotouč s ryskami o stejné rozteči, jako má kotouč pohyblivý. Světlo ze zdroje prochází přes průhledné rysky pohyblivého kotouče. Jsouli v zákrytu průhledné rysky pohyblivého kotouče a průhledné rysky segmentu pevného maskovacího kotouče, dopadá na fotosenzor maximální světelný tok. V případě, že jsou v zákrytu průhledné rysky pohyblivého kotouče a neprůhledné rysky segmentu nepohyblivého kotouče, světlo neprochází a světelný tok na fotosenzoru je minimální. Mezi těmito polohami se světelný tok mění přímo úměrně posunutí obou kotoučů. Výstupní signál fotosenzoru má periodu nepřímo úměrnou počtu rysek na otáčku a rychlosti otáčení pohyblivého kotouče. Tento kvazi-sinusový signál je komparátorem převeden na obdélníkový průběh. Kromě zmíněného transmisního principu snímání, je využíván také reflexní. Je-li potřeba navíc rozlišit i smysl otáčení, musí být maskovací kotouč senzoru polohy opatřen druhým segmentem s ryskami posunutými vůči ryskám prvního segmentu o příslušný úhel. K tomuto segmentu přísluší druhý fotosenzor, snímající fázově posunutý světelný tok. Detekováním změny fáze těchto dvou signálů získáme informaci o změně směru otáčení. Pro úplnost dodejme, že otáčivý kotouč bývá někdy doplněn jedním otvorem (průhlednou ryskou), dalším zdrojem světla a fotosenzorem, detekujícím tzv. výchozí (referenční, nulovou) pozici a generující jeden pulz na otáčku. Tento signál se nazývá jako nulový, index-pulz nebo referenční. Kromě využití této informace k najetí do výchozí polohy, lze tento signál také využít pro detekování případné akumulované chyby polohy způsobené rušivými signály v rámci jedné otáčky. 15
Chyby rotačního inkrementálního senzoru se ve svém důsledku projevují na výstupních signálech. Pokud tento senzor hodláme využít pro potřebu rychlostního řízení pohonu, je z důvodů vyšší rozlišitelnosti v případě použití převodovky, jeho umístění na straně motoru. Další nevýhoda tohoto typu snímače (a tohoto přístupu ke snímání počtu otáček) je nemožnost uchování aktuální polohy snímaného zařízení po vypnutí napájení, protože snímač udává pouze relativní polohu. Je tedy nutné při zapnutí zařízení, které používá tento systém snímání, provést kalibraci, která provede vyhledání referenční bodu (spínač) nebo indexního pulsu. 1.6.4 Absolutní senzor Tento typ senzoru využívá komplikovanější typ kódování než inkrementální a vyžaduje větší počet snímacích prvků. Předností tohoto senzoru je to, že výstupní hodnota ze senzoru udává absolutní velikost natočení v rozsahu 0 až 360°. Pro větší počet otáček je vybaven čítačem inkrementujícím počet otáček kódového kotouče. Obsah tohoto čítače pak spolu s kódem aktuální pozice kódového kotouče součástí tvoří absolutní údaj o poloze natočení. Princip kódování spočívá v tom, že je svazek optických parsků kódován optickým kotoučem a senzory zaznamenávající tyto paprsky jsou rozmístěny tak, že jejich výstupem je přímo digitální informace o poloze v binární hodnotě. [4] Vlastní kódovací kotouč existuje v několika provedeních. Jejich funkce je totožná. Na obrázku níže jsou vidět dvě varianty, pravá využívá Grayův (tzv. zrcadlový) kód, jeho výhodou je větší odolnost vůči chybám, protože se kód liší v maximálně jednom bitu. Vlevo je pak vidět klasické binární kódování (viz obr.2). U obou případů existují dvě nevýhody. Je potřeba zajistit paralelní sběrnici a u binárního kódování ošetřit přechod z hodnoty 255 na 0. [4]
16
Obrázek 2
V případě robota Mitsubishi Melfa RV – 2AJ jsou enkodéry absolutní, takže kontrolér ví v každém okamžiku po poloze jednotlivých os manipulátoru. Tyto souřadnice automaticky neustále přepočítává do několika souřadných systémů a následně je ukládá do příslušných registrů, tudíž odpadá potřeba kalibrace po každém spuštění [1] (např. na rozdíl od manipulátoru Katana 6M180). Zároveň jsou motory většiny os vybaveny automatickou brzdou, takže není nutné manipulátor odkládat do klidové polohy.
1.7 Připojení robota přes RS – 232: Standardní komunikační rozhranní robota (respektive kontroléru CR1-571) je uskutečněno pomocí standardu RS232C (Za účelem propojení kontroléru robota a osobního počítače s řídícím softwarem je možné použít řadu komunikačních rozhranní, které jsou v průmyslu standardem. K tomuto je však zapotřebí zvláštní rozšiřující kartu, která obvykle představuje nemalé náklady na pořízení.). Tento port je nedílnou součástí řídící jednotky a má svůj výstup na předním panelu. Slouží jako základní a univerzální komunikační rozhranní robota s okolím, především pak jako nejčastěji používaný komunikační kanál s osobním počítačem, na kterém je nainstalované vývojové a konfigurační prostředí pro robota. Jako standardní nastavení komunikace přes port RS232 výrobce doporučuje níže uvedené nastavení: Baud rate: 9600baud, délka datového bajtu 8bit, parita: Even (lichá), stop bit: 2, ukončovací znak: CR [1]
17
Toto nastavení je možné změnit v registrech kontroléru a na přistupujícím zařízení (osobní počítač). Nicméně toto nastavení je podle výrobce nejméně problematické, a tudíž změnu příliš nedoporučuje. V manuálu je ještě vysvětleno nastavení DTR, které má sloužit k synchronizaci komunikace v případě nestandardních nastavení, anebo problematickém připojení. Pokud bude osobní počítač posílat data do kontroléru a zároveň bude ignorovat řídící příznaky CS, DR může se stát, že se kontrolér přepne do chybového stavu. Z tohoto důvodu je nutné změnit časování na straně osobního počítače. Toto nastavení pak zabrání odesílání příkazů do řídící jednotky robotu, která během vykonávání předchozího příkazu nereaguje na příkaz nově příchozí. Pokud kontrolér robota obdrží přes rozhranní RS232 chybný příkaz, přepne se do chybového stavu. Poté je nutno jej resetovat. [1]
1.8 RT – Toolbox: Program RT – Toolbox je dodáván společně s robotem. Tento program umožňuje nastavování parametrů a registrů robota. Dále slouží jako základní servisní prostředek (pomocí něj se dají změnit některé systémové čítače jako doba běhu, stav záložní baterie atp.), k vytváření programů a jejich simulaci. Pro napojení se ke kontroléru robota je potřeba použít základní nastavení komunikace (viz. výše), toto nastavení pak využije integrovaný komunikační server. Vývojové prostředí má dvě hlavní části (módy): offline a online Offline mód slouží především k vývoji programů pro robota a případně jejich simulaci. Umožňuje přednastavovat některé systémové registry kontroléru a po připojení tyto registry automaticky změní. Jako simulační prostředek slouží jednoduché grafické znázornění robota v souřadném systému. Toto zobrazení je možné podle potřeby různě natáčet a provádět tak případnou kontrolu zda robot vykonává pohyby tak jak bylo potřeba. Online mód umožňuje kompletní přehled o stavu robota, obsahu paměti a nastavení registrů v kontroléru. Většina hodnot se po změně projeví ihned a bez nutnosti restartování robota, tudíž má uživatel dobrý přehled o provedených změnách. V online režimu je možné nahrávat předem nachystané programy z offline režimu do paměti kontroléru. Po nahrání do paměti se dá program otevřít již 18
v paměti kontroléru a provést případnou kontrolu programu v reálném čase. Kontrola (ladění) programu se nijak neliší od simulace v offline režimu až na to že kromě simulátoru, který pracuje s vypočítanými daty, robot ještě uskutečňuje zkoumaný program fyzicky. Nedílnou součástí ladění programu v online režimu je konzola, která umožňuje provádět přímé příkazy bez nutnosti uložení do programu v paměti kontroléru. Tato možnost je dostupná v panelu, který je podobný fyzickému panelu na řídící jednotce robota (pro možnost řídit robota z vnějšího zdroje je nutné mít klíč v kontroléru zcela vpravo na pozici AUT ext, jinak se řídící jednotka přepne do chybového stavu). Další důležitou součástí je monitor telemetrických dat v průběhu práce robota. Tento panel obsahuje veškerá možná data ze senzorů obsažených v robotu (od příznaku otevření kleštin efektoru, přes provozní teplotu a počet cyklů jednotlivých servomotorů, statické a dynamické zatížení jednotlivých os po výpočet pravděpodobnosti střední doby poruchy a případný počet cyklů do této poruchy). Přes všechny své přednosti se program RT–Toolbox nedá použít k ničemu jinému než k vývoji programů a údržbě robota. Zároveň nemá příliš rozsáhlou dokumentaci, která se omezuje jen na vysvětlení příkazů jazyků Melfa–Basic IV a Movemaster Command. Tato skutečnost může při práci s robotem a jeho případným zapojením do výrobní linky přinést značné potíže.
1.9 Teorie formálních jazyků: Abychom mohli vytvořit příslušný analyzátor jazyka Melfa Basic IV nebo Movemaster Command, je nutné seznámení se základy teorie formálních jazyků. Tuto teorii rozpracoval koncem 50. let americký matematik Noah Chomsky, který studoval přirozené jazyky. Chtěl je formalizovat a dosáhnout jejich automatizovaného zpracování. Přestože tento původní záměr nebyl uspokojivě vyřešen, vznikla propracovaná
teorie
omezených
formálních
jazyků,
s konečnými abecedami a konečnými množinami gramatických
pracujících
pravidel.
Tato
teorie nachází největší uplatnění při konstrukci překladačů programovacích jazyků a syntaktických i sémantických analyzátorů nejrůznějších typů. [2] Je vhodné uvést několik uvést pár pojmů, které budou potřeba při tvorbě analyzátoru.
19
Abeceda Σ: je libovolná konečná množina, prvky abecedy nazýváme znaky (symboly, písmena). Slovo nad abecedou Σ je libovolná konečná posloupnost znaků této abecedy. ε znamená prázdné slovo, |v| je délka slova v, #a (v) znamená počet výskytů znaku a ve slově v. Σ* je množina všech slov nad abecedou Σ. Σ+ je množina všech neprázdných slov. Gramatika G je čtveřice (N, Σ, P, S), kde N je neprázdná konečná množina neterminálních symbolů, Σ je konečná množina terminálů taková že N ∩ Σ= ᴓ, P je konečná množina produkčních pravidel. Jedná se o konečnou podmnožinu kartézského součinu je startovací (počáteční) neterminální symbol gramatiky. Prvek (α,β) z množiny P budeme zapisovat ve tvaru
. Řetězec α je le-
vá strana, řetězec β je pravá strana přepisovacího pravidla. Gramatika je produkční systém, v němž lze aplikaci přepisovacích pravidel ze startovacího symbolu generovat věty patřící do jazyka L. V průběhu generování postupně vznikají řetězce složené ze slovníku gramatiky (větné formy, tj. prvky ). Cílem generování je vytvoření řetězce
, který neobsahuje non-
terminální symboly. [2] Příklad generování věty: Je dána abeceda abecedou, jejíž množina nonterminálních symbolů je je
a gramatika nad touto , množina pravidel
. Startovací symbol je S. Pravidla přepíšeme
do přehlednější podoby a pro usnadnění orientace je očíslujeme:
Generování věty sestává z posloupností větných forem a začíná startovacím nonterminálem. U každé derivace je použití příslušného pravidla gramatiky naznačeno číslem.
Výsledná věta abbc patří do jazyka generovaného uvedenou gramatikou G. [2] 20
1.9.1 Chomského klasifikace gramatik[2]: Podle tvaru přepisovacích pravidel gramatiky lze usoudit i na obecnost jazyka generovaného touto gramatikou. Klasifikace se provádí podle pravidel gramatiky takto: Gramatika typ 0: jedná se o tzv. frázové gramatiky. Zahrnují v sobě všechny formální gramatiky a generují jazyky, které mohou být rozpoznány pomocí Turingova stroje. Tyto jazyky se někdy nazývají rekurzivně spočetné jazyky. V případě, že je jazyk generován úplným Turingovým strojem (
Turingův
stroj akceptuje nebo zamítá), je tento jazyk nazýván jako rekurzivní. Gramatiky typu 1: kontextové gramatiky, geenerují kontextové jazyky. Tyto gramatiky se skládají z pravidel a neterminálů a Pravidlo
, kde
je řetězec terminálů
, neboli gramatika neobsahuje "zkracovací pravidla". je povoleno, pokud se
nevyskytuje na pravé straně žádného
pravidla. Tyto jazyky jsou právě jazyky rozpoznatelné lineárně ohraničeným Turingovým strojem. Gramatiky typu 2: bezkontextové: generují bezkontextové jazyky. Skládají se z pravidel Pravidlo
s neterminálem
a řetězcem terminálů a neterminálů
je povoleno, pokud se
.
nevyskytuje na pravé straně žádného
pravidla. Tyto jazyky jsou právě jazyky rozpoznatelné nějakým nedeterministickým zásobníkovým automatem. Gramatiky typu 2 mohou obsahovat
pravidla.
Přesto jsou podmnožinou gramatik typu 1, protože existuje algoritmus na převod libovolné gramatiky typu 2 na gramatiku bez pravidel. Gramatiky typu 3 regulární gramatiky: Generují regulární jazyky. Pravidla těchto gramatik jsou omezena na jeden neterminál na levé straně. Pravá strana se skládá z řetězce terminálů, který může být následován jedním neterminálem (tedy pravidla
a
, kde
). Tyto gramatiky se
také nazývají pravé lineární. Podobně se definují i levé lineární gramatiky, kde může být na pravé straně pravidel jeden terminál předcházen jedním neterminálem. Nikdy se však nesmí vyskytovat v jedné gramatice zároveň pravidla jak z pravolineární gramatiky, tak z levolineární. Pravé lineární gramatiky a levé lineární gramatiky jsou ekvivalentní. Pravidlo
je povoleno, pokud se
nevy-
skytuje na pravé straně žádného pravidla. Tyto jazyky jsou rozpoznatelné konečným automatem. 21
Gramatiky typu 3 jsou zároveň i typu 2,1 a 0. Gramatiky typu 2 jsou zároveň typu 1 a 0 atd. Jedná se tedy vždy o vlastní podmnožiny, to znamená, že existují rekurzivně spočetné jazyky, které nejsou rekurzivní, rekurzivní jazyky, které nejsou
kontextové,
kontextové
jazyky,
které
nejsou
bezkontextové
a bezkontextové jazyky, které nejsou regulární. 1.9.2 Konečný automat: Konečný automat je virtuální stroj skládající se z řídící jednotky, která se může nacházet v konečném počtu vnitřních stavů, a ze čtecího zařízení, schopného snímat jednotlivé symboly vstupní věty ze vstupní pásky. Vstupní páska je čtena z leva doprava. [2] Zatímco gramatiku lze chápat jako generativní systém, který postupnými derivacemi ze startovacího nonterminálu vygeneruje výslednou větu, automat je systém akceptační, jehož vstupem je věta a výstupem informace, zda tato věta patří nebo nepatří do jazyka L. [2] Konečný automat je definován jako pětice
, kde 1. Q je ko-
nečná množina stavů automatu, 2. Σ je konečná vstupní abeceda, 3. δ je zobrazení 4. 5.
je počáteční stav je množina koncových stavů.
Činnost automatu lze znázornit posloupností konfigurací. Konfigurace definuje situaci, v níž se automat nachází, pomocí aktuálního vnitřního stavu qi a dosud nepřečtené části vstupní věty. Přechod automatu od jedné konfigurace k následující definuje přechodová funkce δ, a to na základě přečteného terminálního symbolu ze vstupní pásky. Počáteční konfigurace automatu je definována dvojicí (q0, ω), kde q0 je počáteční stav automatu a ω je celá vstupní věta. Koncová konfigurace je definována jako (qf , @), kde
. Dostane-li se automat během své činnosti do této kon-
figurace, je vstupní věta přijata (akceptována), tedy patří do daného jazyka. V opačném případě věta není akceptována. Přechod mezi jednotlivými konfiguracemi značíme Ⱶ. Jedná se o relaci na množině konfigurací. Přechodová funkce δ určuje na základě současného 22
vnitřního stavu a čteného symbolu následující vnitřní stav. Je-li těchto následujících stavů více, jedná se o nedeterministický konečný automat. Je-li následující stav nejvýše jeden, jde o deterministický automat. Nedeterministický automat lze algoritmicky převést na deterministický. 1.9.3 Znázornění přechodové funkce Obvyklým způsobem znázornění přechodové funkce je tabulka, jejíž řádky jsou označeny všemi stavy z Q a sloupce všemi symboly z abecedy Σ. Pole tabulky obsahují výsledky přechodové funkce, tj. obecně podmnožiny množiny stavů. Další způsob znázornění přechodové funkce je grafické zobrazení. Jednotlivé stavy jsou znázorněny jako uzly grafu, mezi nimiž jsou orientované spojnice ohodnocené příslušným terminálním symbolem. Koncové stavy jsou vyznačeny dvojitým kroužkem. 1.9.4 Implementace konečného automatu: Činnost konečného deterministického automatu lze simulovat poměrně jednoduchým
programovým
modulem,
přecházejícím
me-
zi jednotlivými konfiguracemi. Aktuální vnitřní stav je modelován jednoduchou proměnnou, která může nabývat hodnot z množiny stavů. Čtecí mechanismus je realizován procedurou (metodou), která je schopna ze vstupu dodat následující terminální symbol. Typicky se jedná o přepínač SWITCH/CASE, kde jednotlivé položky přepínače (CASE) znamenají jednotlivé stavy automatu. [6]
1.10 Technologie COM a prvek active X: Technologie
Object
Linking
and
Embedding
neboli OLE,
by-
la vyvinuta za účelem integrace kancelářských aplikací balíku Microsoft Office, protože vznikla nutnost tvorby složených dokumentů, které obsahují různé datové typy (typicky kombinace tabulek a grafů). Tato původní verze přesahovala výpočetní možnosti tehdejších počítačů a byla značně těžkopádná. Později vznikla technologie Component Model Object (neboli COM), na jejímž základě vznikla nová verze OLE, ze které se postupně vyvinulo Active X. [9] Hlavním důvodem pro vývinutí technologie COM byl pokus o standardizaci dynamických knihoven dll, které kvůli nízké standardizaci trpěly značný23
mi problémy jako například neunikátnost knihovny, z důvodů použití příliš častého názvu a tak se stávalo, že knihovnu přepsal při instalaci jiný program. Mezi obvyklé obtíže také patří využívání více verzí jedné knihovny různými aplikacemi, takže kvůli tomu vzniká problém v závislosti na pořadí instalace dotyčných aplikací. Další obtíže tvoří také nedostatečná kompatibilita u různých programovacích jazyků. Tento problém vznikl, protože u dll knihoven není nutné se držet žádného standardu z hlediska pořadí předání parametrů na zásobník a jeho následného úklid. Podobný problém platí i u exportovaných funkcí, u kterých některé kompilátory mohou provádět změny. [6] Technologie COM se tyto problémy snaží řešit pomocí unikátních identifikátorů a jasně definovaných rozhranní identifikace. 1.10.1 COMobjekty: S takto označeným objektem se můžeme setkat nejčastěji v dokumentaci. Přitom se nejedná o objekt jako takový, ale jedná se spíše o třídu v C++ , která má určité specifické vlastnosti. Toto je zjevné hlavně v případě viditelnosti. U COM objektů jsou všechny proměnné nebo funkce před klienty skryty a jsou dostupné pouze metody a property. Komunikaci s okolím obstarává tzv rozhraní.[7]
1.10.2 COM rozhraní: Kvůli standardizaci kompatibility při komunikaci s okolním světem musí mít metody rozhraní přesně definované způsob volání a návratové hodnoty. Toto se nevztahuje na implementační část, ale pouze na rozhraní. Rozhraní je tak definováno jako datový typ, který obsahuje seznam metod, které může okolí využívat [7] Objekty mohou mít podle složitosti i více rozhraní. Klient přistupuje k COM objektu přes ukazatel na dané rozhraní, takže mohou volat metody, které daný interface obsahuje. [8] 1.10.3 COM klient a server COM technologie v tomto směru kopíruje komunikační model klient – server, kdy klienti využívají funkce, které poskytuje server. Jedná se o stěžejní část COM technologie. Za klienta označujeme objekt, který disponuje ukazatelem
24
na rozhraní serveru a používá jeho služby voláním metod daného rozhraní. Server je pak analogicky objekt, který poskytuje služby. Služby může volat libovolný klient, který získal ukazatel na rozhranní serveru [8]
1.10.4 Unikátní identifikátor COM objektů: Pro jedinečnou identifikaci COM třídy se používá identifikátor CLSID, který omezuje záměnu knihoven nebo rozhraní se stejným jménem. Číselné identifikátory obsahují jednotlivá rozhraní a třídy objektů, tzv. GUID. CLSID číslo se skrývá pod jménem dané komponenty a není tak pro uživatele patrné. Nejvýznamnější vlastností tohoto identifikátoru je jeho jedinečnost. Žádná komponenta v místě a čase by neměla mít stejný identifikátor. Této jedinečnosti bylo
dosaženo
pomocí
128bitového
identifikátoru,
který
je
zapsán
v hexadecimální soustavě s jasně danými pravidly umístění rozdělovníku mezi podřetězce. Identifikátor má tento tvar: HHHHHHHH-HHHH-HHHHHHHH-HHHHHHHHHHHH CLSID identifikátorem se registruje do příslušných registrů v operačním systému. [7]
1.11 Active X active x komponenty jsou COM objekty, které splňují některá kritéria navíc. Těmito kritérii jsou hlavně: Nutnost implementace rozhraní IUnknown, dále registrovat prvek v systému tzv. Selfregistration o který se stará DllRegister/UnregisterServer (microsoft d) Active X byla od počátku vyvíjena zejména jako rozšiřující prvek HTML stránek. Účelem tohoto jednání bylo dodat funkce, které Huml ani skripty nemohly poskytnout. Active X prvek byl umístěn na stránce a spouštěn u návštěvníka stránky jako běžný binární kód aplikace win 32, což samo o sobě přinášelo velké bezpečnostní problémy a kvůli tomu zůstal potenciál této technologie nerozvinut. [7] 25
Původnímu způsobu práce z webových stránek odpovídá způsob spouštění ActiveX, která musí být využívána v rámci kontejneru. Kontejner je aplikace, která využívá Active X prvky a pracuje s nimi. Nejznámějším kontejnerem je ze zřejmých důvodů Microsoft Internet Explorer [7] S active X prvky pracuje i aplikace Control Web, kde se jedná o virtuální přístroj active_x. Active X přes svá rozhraní zprostředkovává několik způsobů předávání dat: jedná se zejména o události (ty jsou volány v komponentě a kontejner musí implementova jejich zachycení), dále se jedná o metody (které volá komponenta a jsou přiřazeny danému rozhraní) a nakonec vlastnosti (používá se zejména v GUI a je skrz ně možné předávat data do jazyků, které nepodporují ukazatele).
1.12 Prostředí control web: Control Web je programový systém rychlého vývoje aplikací pro průmyslová odvětví, laboratoře a školy. Slouží k vizualizaci a řízení technologických procesů řízení v reálném čase a tvoří most mezi technologií a informačním systémem podniku. Usnadňuje vytvoření přehledného rozhranní člověk-stroj a současně umožňuje přímé řízení strojů a technologií. Zároveň je i snaha pokrýt co největší množství hardwaru, aby byl Control Web co nejvíce nezávislý na konkrétním typu hardwaru. Dále control Web obsahuje množství standardních ovladačů, které umožňují komunikovat s řadou průmyslových zařízení. Architektura ovladačů je otevřená se záměrem o vedení pečlivé dokumentace. [9] Z pohledu programátora lze Control Web považovat za objektově orientovaný, ale ne všechny principy z tohoto druhu programování důsledně aplikuje. Jedná se o jakousi kombinaci objektového a procedurálního programování, kdy se používají událostí řízené procesy a komponenty. [9] Místo obvyklých objektů se zde používají tzv. přístroje, ze kterých se vyvíjená aplikace skládá. Každý přístroj má sadu svých standardních reakcí na událost (procedury, či spíše metody) a možnost přidat vlastní proceduru. Jako každé vývojové prostředí nabízí i Control Web několik možných pohledů na tvořenou aplikaci. Jednotlivé pohledy mají svůj specifický význam:
26
Textový editor: v tomto editačním okně je možné napsat celou aplikaci pomocí textových příkazů, zároveň se zde zobrazuje všechen kód, který byl implementován pomocí jiných pohledů (zvláště pak z grafického editoru). V tomto pohledu je možné prohlédnout celý zdrojový kód bez nutnosti se přepínat mezi přístroji. (podobně jak je tomu zvykem u jiných vývojových prostředí) Datové inspektory: slouží k definici globálně používaných datových proměnných a k definici ovladačů pro komunikaci s jinými prvky, nebo externími zařízeními. V tomto pohledu se dají nastavit stěžejní parametry celého programu (priorita v operačním systému, časování aplikace, zálohování atd.) Grafický editor: jedná se o poslední kartu pohledů na aplikaci. Tento pohled umožňuje vytvoření grafické podoby vyvíjené aplikace. To znamená, že se na pracovní plochu umísťují z palety přístrojů jednotlivé komponenty. Prostřednictvím tohoto pohledu je možné pracovat i s přístroji, které nemají grafické rozhranní a tudíž nemusí být (nejsou, v závislosti na nastavení) vidět. 1.12.1 Přístroje: Přístroje v programu Control Web tvoří základní prvek vyvíjené aplikace. Seznam všech přístrojů je nazván paleta přístrojů, která je rozdělena do několika sekcí podle typu a účelu přístroje. Každý přístroj má své nativní procedury, které vycházejí zejména z toho, k čemu daný přístroj slouží a jak se případně ovládá. Zároveň je možné pro každý přístroj definovat lokální data, která nejsou ostatním přístrojům a globálnímu inspektoru dat viditelná (zde je další podobnost s objektovými principy programování). Pokud by nativní procedury nepostačovaly, nebo z jakéhokoliv důvodu nebyly vhodné k zamýšlenému účelu, je zde možnost definovat uživatelské procedury, které nejsou závislé na chování přístroje a jeho nativních procedurách. Každý přístroj, zejména ten, který zobrazuje měřené veličiny, má několik možností zobrazení, které se dá měnit podle potřeby a účelu použití tak, aby byla aplikace přehledná. Zároveň je možné přístroji nastavit viditelnost na panelu. Při přepnutí přístroje do neviditelného módu, tento přístroj pak plní hlavně úlohu podpůrnou a zajišťuje pro ostatní potřebnou funkcionální základnu. [9] Poněkud zavádějícím se může zdát nazývání procedur, které může navozovat dojem toho, že Control Web pracuje na principu procedurálního programování. Naproti tomu program takto nepracuje a funguje na základě zpracování událostí a aktivaci. To znamená, že pokud uživatel například stiskne tlačítko 27
na myši, Control Web na toto v reálném čase zareaguje na základě události, kterou obdrží od ovladače daného zařízení nebo podle informace od virtuálního přístroje. Reakce na tuto událost je pak zavolání daného kódu (procedury). Události jsou provázány s přístroji, tudíž se nemůže stát, že by existovala událost bez konkrétního přístroje (opět je zde podobnost s metodami objektově orientovaného programování). Aktivací se rozumí provedení akce konkrétního elementu nebo přístroje, což je podstatou funkčnosti dané aplikace, jelikož ta je souhrnem akcí všech přístrojů a datových elementů. Aktivace pak má svého původce a zároveň musí vždy projít jádrem, které aktivuje dotčené přístroje.
28
Control Web používá několik druhů aktivací:
Aktivace daty: aktivace přístroje proběhne na základě změny dat ve sledované proměnné nebo vyhodnocením jejího obsahu
Aktivace vnitřní: Na základě vnitřního vyhodnocení systému je přístroj aktivován pro umožnění další činnosti po přerušení procedury.
Zpráva od přístroje: Aktivace přístroje proběhne na základě požadavku od jiného přístroje nebo od sebe sama.
Zpráva od ovladače: Aktivování přístroje proběhne na základě výjimky ovladače v systému Control Web.
Uplynutí
periody:
Na základě
uplynutí
periody
časovače
dojde
k aktivaci přístroje, tento časovač je globální a může řídit aktivování více přístrojů naráz. Tyto aktivace se dále dělí na dvě skupiny. Adresné, které aktivují jenom konkrétní přístroje (např. aktivace daty nebo přístrojem) a neadresné, které se registrují do zdroje aktivace. Jedná se zejména o systémové časovače. 1.12.2 Rozšíření Control Webu pomocí externí technologie: Jediný možný způsob jak program Control Web rozšířit je použití technologie Active X. Tuto komponentu lze vybrat v paletě přístrojů a pomocí CLSID ji vyhledat v registrech operačního systému. Přístroj active X je pak využit jako kontejner pro příslušnou komponentu a zprostředkovává volání metod kontejneru v aplikaci Control Web. Technologie Active X je implementována v jazyce Visual C++ od Microsoftu.
1.13 Microsoft Visual studio Slouží jako vývojové prostředí podporující různé programovací jazyky (jazyky rodiny visual: Basic, C++ a C#). Pro založení projektu se používá průvodce, který do projektu přidává potřebné soubory a generuje potřebnou strukturu projektu včetně přichystaných částí zdrojového kódu. Průvodce tedy usnadňuje tvorbu aplikace a minimalizuje riziko chyby způsobené manuální tvorbou zdrojového kódu. Práci na projektu usnadňuje strukturování pohledu na projekt do těchto komponent: Solution view (zobrazuje jednotlivé soubory ve složce projektu)
29
Class view (zobrazuje u objektově orientovaného kódu jednotlivé třídy a jejich metody, se kterými se dá dále pracovat). Resource view (slouží pro definici parametrů v operačním systému a pro nastavení grafického rozhranní) Property manager (má na starosti vlastnosti celého projektu např. systémové knihovny) Editor zdrojového kódu (zde se vytváří a upravuje vyvíjený zdrojový kód)
1.14 Závěr kapitoly: V této kapitole jsme se teoreticky seznámili s výrobní linkou FMS 200, komunikačním standardem Profibus a technologií OPC. U průmyslového robota Mitsubishi Melfa jsme prozkoumali možnosti propojení s okolními periferiemi přes RS232. Dále pak použití servisního a vývojového prostředí RT-Toolbox, které zajišťuje vývoj aplikací a nastavení parametrů v kontroléru robota. Navíc jsme zjistili, že tento program umí manipulovat s robotem přímo. Také bylo zjištěno, že ke snímání polohy jednotlivých os používá absolutní enkodéry. Na závěr byly prozkoumány možnosti rozšíření programu Control Web o externí Active X komponentu, která bude vyvíjena v jazyce Visual C++.
30
Metodika Tato kapitola obsahuje metodiku potřebnou ke splnění cílů práce.
1.15 Začlenění průmyslového robota Melfa do výrobní linky FMS 200
studium možností výrobní linky FMS 200 a PLC modulům Simatic
studium dokumentace k Mitsubishi Melfa RV-2AJ
Analýza komunikačního rozhranní pro Mitsubishi Melfa
1.16 Tvorba active X komponenty:
studium vývoje konečných automatů
studium technologie Active X
vytvoření lexikálního analyzátoru pro jazyk Movemaster Command
implementace konečného automatu do Active X komponenty
1.17 Tvorba aplikace v Control Webu:
import Active X komponenty do prostředí Control Web
návrh grafického rozhranní
vytvoření aplikace v jazyce Control Web s použitím metod Active X komponenty.
31
Vlastní práce: 1.18 Začlenění průmyslového robota Melfa do výrobní linky FMS200: V této kapitole se bude řešit přičlenění robotu Melfa do výrobní linky FMS200. Výrobní linka a robot mají vzájemně nekompatibilní komunikační rozhranní. Robot je standardně vybaven komunikačním rozhranním RS232C a pro rozšíření komunikačních možností kontroléru, je potřeba zakoupit doplňující komponenty v podobě přídavné komunikační karty, která se integruje do rozšiřujícího slotu uvnitř kontroleru, a příslušné kabeláže. Současně, ač jsou PLC moduly Simatik, které jsou namontovány na jednotlivých taktech linky FMS200, vybaveny podstatně výkonnějším komunikačním rozhranním Profibus, nedochází ke kompatibilitě se standardem RS232. K těmto PLC modulům je i příslušný ovládací software, který dokáže jednotlivé PLC moduly identifikovat a po té s nimi individuálně komunikovat (viz kapitola Analýza). Bohužel, tento software slouží zejména k vývoji aplikací pro PLC moduly Siemens Simatik a neposkytuje možnost komunikace s okolím. Průmyslový robot Melfa je taktéž vybaven určitým softwarem v podobě programu RT-Toolbox. Ten vedle již zmíněné údržby a vývoje aplikací (viz kapitola Analýza) umožňuje komunikaci s několika řídícími jednotkami robotů, ale co se týče komunikace s okolím, je uzavřený. Jako možné řešení tohoto problému vzájemné nekompatibility komunikačních rozhranní se nabízelo využití technologie OPC, která komplexně zastřešuje komunikaci průmyslových
zařízení
(viz
kapitola Analýza).
Zároveň
by
při implementaci technologie OPC na vzájemnou komunikaci odpadl problém s návrhem komunikačního protokolu, jelikož by se předávaly zprávy využívající prvků COM., která zahrnuje nejen skalární veličiny, ale i celá pole. Bohužel, tento způsob přenosu dat může být v některých případech neefektivní (namísto jedné skalární veličiny je potřeba vyhodnotit celé pole, a s tím se pojí zvýšené požadavky na výpočetní a přenosovou rychlost zařízení). OPC server je možné použít i v systému Control Web, ale je nutné si stáhnout z webových stránek OPC foundation příslušné DLL knihovny, které poté použije OPC server Control Webu jako základní ovladače.
32
Aplikace OPC serveru na linku FMS200 a robot Melfa by mohlo vypadat takto:
Obrázek 3
Při snaze aplikovat technologii OPC na začlenění průmyslového robota Melfa do výrobní linky FMS200 nastaly problémy, z nichž se některé nepodařilo překonat a ukázaly se jako problémy klíčové, které zapříčinily neřešitelnost situace. Jsou jimi zejména tyto:
Neexistující ovladač OPC pro kontrolér CR571 připojený přes RS232. Ovladače pro prvky od Mitsubishi sice existují, ale pouze pro PLC moduly. Další nalezené ovladače jsou rovněž pro PLC moduly a jsou zpoplatněny (viz např. http://www.matrikonopc.com/opc-drivers/opc-mitsubishi/basedriver-details.aspx).
Jediné komunikační rozhranní na kontroleru CR 571 je RS232, které má primárně sloužit jako port, ke kterému se připojuje osobní počítač s konfiguračním softwarem (např. již zmíněný RT-Toolbox). Komunikaci s jinými zařízeními výrobce příliš nedoporučuje, důvod je uveden níže.
Připojení k OPC serveru by bylo možné přes rozšiřující komunikační kartu (například Ethernet, nebo firemní sběrnice CC link, kterou Mitsubishi u svých výrobků preferuje). Rozšiřující karta je však značně nákladná, a proto nebyla zakoupena. Na závěr této kapitoly ještě provedeme shrnutí zjištěných informací. Jed-
notlivé stoly výrobní linky FMS 200 s PLC moduly Simatik je možné připojit k OPC serveru, protože mají k dispozici příslušné ovladače a na sběrnici Profibus nemají žádná omezení plynoucí z použití tohoto typu komunikace. OPC server
33
tyto moduly dokáže sám vyhledat a komunikace s jednotlivými PLC moduly je možná. Naproti tomu je situace u robota Melfa do značné míry komplikovaná. Port RS232, který se nachází na kontroleru má určitá omezení, která použití tohoto portu výrazně omezuje a defakto tak slouží jako přípojný bod pro konfigurační PC. Dalším problémem jsou chybějící ovladače pro OPC. V dokumentaci je sice popsána možnost použít kontroler robota jako PLC modul, který se chová podobně jako ostatní PLC moduly od Mitsubishi, takže by se dala vyřešit situace s chybějícími ovladači pro kontrolér, jelikož ovladače pro komunikaci s PLC moduly fy. Mitsubishi existují. Tato možnost je však opět podmíněna instalací rozšiřující komunikační karty. V dostupné dokumentaci k robotovi je stručně zmíněna možnost odesílat do kontroleru příkazy přímo, bez nutnosti je mít předem naprogramované. Příkaz se odesílá v normálním tvaru a bez čísla řádky. Tato zmínka ovšem neřeší celou komunikaci, ale soustředí se jenom na přímý příkaz, takže není patrné jak má vlastní komunikace vypadat a jestli stačí jen odeslat příkaz. Při podrobnějším zkoumání bylo zjištěno, že se možnost přímého odeslání příkazu vztahuje na prostředí RT-Toolbox. Aby bylo možné začlenit robota do výrobní linky, je nutné detailně prozkoumat komunikační protokol mezi kontrolérem a programem RT-Toolbox. Bez této skutečnosti není možné pokračovat v dalším vývoji aplikace, která bude zajišťovat ovládání robota.
1.19 Komunikační protokol mezi RT-Toolbox a kontrolérem CR571: Abychom mohli zjistit, jak vlastně probíhá komunikace mezi programem a kontrolérem, je potřeba zachytávat komunikaci na sériovém portu. Jelikož dodaný software k robotovi nic takového neumožňuje, bylo nutné najít potřebný software, který by odchyt komunikace zajistil. Požadovaný software by do této komunikace neměl nijak negativně zasahovat (v podobě vkládání nežádoucích prvků nebo jiného rušení, včetně zdržování komunikace mezi zařízením a PC). Dalším požadavkem bylo přehledné a detailní logování komunikace pro pozdější offline analýzu. Analyzátor by měl zachycovat vše včetně řídících znaků.
34
Z toho důvodu, že je standard RS232C dobře známý a popsaný, byla k dispozici celá řada programů, které více či méně odpovídaly požadavkům kladeným na tento software. Nakonec byl jako nejvhodnější vybrán program Free Serial Monitor, který i v bezplatné verzi poskytuje širokou škálu funkcí a přehledné zobrazení komunikace, včetně detailního rozlišení odchozích a příchozích dat. Pro ukládání výstupu je k dispozici uložení do HTM souboru, který je názorně členěný, a je zněj dobře patrný průběh komunikace(viz obrázek 3)
Obrázek 34
.
35
1.20 Metodika odposlechu komunikace na sériovém portu: Abychom zjistili, jaká data jsou odesílána z osobního počítače do robota a jaká je jeho reakce, je nutné provést experimentální odposlech dat během průběhu komunikace. Za účelem zisku vhodných dat, je nejlepší začít odchyt už od otevření portu (tedy v okamžiku zahájení komunikace), abychom zachytili způsob, jakým RT-Toolbox požaduje po kontroléru CR571 zahájení vzájemné komunikace. Aktivací programu Free Serial monitor před spuštěním samotné aplikace Tool Box zabráníme zablokování přístupu k portu, který si po spuštění rezervuje komunikační server této aplikace. Tímto postupem zabráníme možnému úniku dat a komunikaci začneme zachytávat ihned, při první snaze o spojení COM1 portu osobního počítače s kontrolérem.
1.21 Analýza získaných dat: Po ukončení odposlechu dat je nutné provést vyhodnocení komunikace a jednotlivé příkazy podrobit analýze a pokusit se jim přiřadit význam. Pro větší přehlednost je dobré zobrazit jenom potřebná data, která jsou nutná pro analýzu. Typicky se jedná o to, který proces otevřel port, časové razítko, rozlišení odesílatel-příjemce (zde Request a Answer) a zobrazení řetězce v hexadecimálním tvaru (kvůli lepšímu přehledu tzv. bílých znaků, které se v textovém zobrazení nemusejí ukázat a mohou tak být přehlédnuty, což může mít pro analýzu fatální následky). Dále je pro rychlejší orientaci také vhodné zobrazení datového řetězce v textové podobě, která umožní lepší chápání příkazů pro obsluhu, jenž provádí analýzu zachycené komunikace.
1.22 Zachycená komunikace: V této kapitole je uveden výtah ze vzájemné komunikace mezi RT-Toolbox a kontrolérem CR571, celý záznam komunikace je v příloze. Celá komunikace začíná pokynem ze stolního počítače a vypadá takto: 1;1;OPEN=TOOLBOX. Příkaz je na první pohled zřejmý, jedná se o pokyn Toolboxu k zahájení komunikace. Program ještě za pokynem OPEN provede svoji identifikaci. Význam počátečních čísel znamená otevřít COM 1, robot číslo 1. Tečka za řetězcem TOOLBOX představuje konec řádky (CR, hexadecimálně 0D) a značí to ukončující 36
prvek pro komunikační řetězec. Tento řetězec je standardně nastaven i v kontroléru a dá se v případě potřeby změnit na LF nebo LF + CR. Kontrolér následně zašle odpověď, která je vždy stejná. Obsahuje potvrzení o tom, že příjem proběhl v pořádku a zasílá stručné informace o verzi firmwaru, typu robota, typu kontroléru a na závěr pošle i svého výrobce. Význam čísel, která jsou uvedena za tímto textovým řetězcem, se nepodařilo identifikovat. QoK1F;37;6,0;3,5 ,A,1E,32,46,64;M B4;PRM;RV-2AJ;CR n-5xx;MELFA;09-0 8-08;Ver.K9b;ENG ;COPYRIGHT(C)199 9-2009 MITSUBISH I ELECTRIC CORPO RATION ALL RIGHT S RESERVED;1;1;8 ;. Dále následuje snaha Toolboxu zjistit nastavení programovacího jazyka, který momentálně používá kontrolér. Zde u komunikace následuje chybové oznámení kontroléru ve tvaru: QeR601000000.
kde číslo 6010000 znamená číslo chyby, které pravděpodobně vyjadřuje Illegal Command tj. neznámý příkaz. Poté Toolbox pošle z dosud neobjasněných důvodů znova řetězec otevírající port, kontrolér odpoví stejně jako při úvodním příkazu. Další komunikace znamená dotazování Toolboxu na verzi systému. Zajímavějsí začne být komunikace, až po zodpovězení těchto příkazů, kdy se Toolbox ptá na polohu ramene příkazem: 1;1;JPOSF. Tento příkaz zřejmě označuje žádost o zaslání tzv. joint interpolation, tedy polohy jednotlivých ramen. Kontrolér vrátí řetězec, kde jsou uvedeny všechny dostupné osy J1-J6. Hvězdičkami jsou označeny místa os, které nejsou v příslušném robotovi implementovány: QoKJ1;0.00;J2;-1 0.21;J3;108.50;J 4;****;J5;-8.28; J6;0.00;;****,** 37
**;70;0.00;00000 000. V další sadě dotazů se Toolbox dotazuje kontroleru na pozici ramene v souřadnicích X, Y, Z a polohu ramene v osách J4 a J5. Jedná se o podobné příkazy, které vrací stejné nebo mírně odlišné výsledky, které obsahují kombinace souřadného systému s polohou ramen: Na tento příkaz se kontrolér ptá dvakrát, poprvé po příkazu JPOSF a po druhé po proběhnutí ostatních dotazů na polohu: 1;1;PPOSF. Odpověď kontroléru je v obou případech stejná: QoKX;400.02;Y;9. 30;Z;699.94;A;0. 00;B;90.02;;5368 70918,0;70;0.00; 00000000.
Soupis dalších příkazů, které vracejí polohu ramene: 1;1;WPOSF. 1;1;XPOSF. 1;1;RPOSF. Jak je z dosavadního průběhu patrné, tak řídící jednotka ví v každém okamžiku, v jaké poloze se nachází rameno manipulátoru. Pokud je potřeba zjistit aktuální polohu, vždy zašle program RT-Toolbox dotaz do kontroléru. Další průběh komunikace není pro potřeby řízení robota až tak důležitý, jelikož se jedná o jednotlivé kroky, které používá RT-Toolbox k otevření programu uloženého v paměti řídící jednotky, program nejprve zjišťuje obsah chybové databáze. Poté se dostane k otevření složky s uloženými programy, kdy dotazem 1;1;PDIR01 otevře složku s prvním programem, kontrolér poté vrátí podrobnosti o programu (tzn. název programu, typ programovacího jazyka ve kterém je program napsán, časové razítko uložení a další parametry). Po ukončení těchto dotazů pošle kontrolér příkaz 1;1;CNTLON který zjevně aktivuje čekání na příkazy vedoucí k zavedení programu do operační paměti.
RT-Toolbox
poté
v pravidelných
intervalech
udržuje
kontrolér
v připraveném stavu pomocí příkazu 1;1; STATE. Odpověď řídící jednotky je podle fáze otevření programu buď potvrzení o připravenosti, nebo v případě otevření programu výpis aktuální řádky, která je momentálně načtena v paměti. 38
Po této fázi komunikace jsme se dostali až k samotnému přímému spouštění příkazu z terminálu na virtuálním kontroléru v programu RT-Toolbox. Zachycení této fáze je mimořádně důležité pro pozdější využití. První
krok
spočívá
v odeslání
příkazu
1;1;CNTLON,který
v komunikaci již několikrát proběhl. Po potvrzující zprávě od řídící jednotky QoK, je vyslán požadavek 0;1;SRVON, který zapne servomotory robota (ten je tak připraven přesunout svojí polohu). Poté, kvůli prodlevě mezi napsáním a odesláním přímého příkazu (několik vteřin) je odeslán příkaz 1;1; STATE. V okamžiku, kdy je příkaz v terminálu odeslán proběhne znova příkaz 1;1;CNTLON, a ihned po obdržení odpovědi z kontroléru robota se odesílá přímý příkaz, který vypadá například takto: 1;9;EXECGO. Počátek příkazu EXEC znamená přímé provedení příkazu, který následuje bez časového prodlení hned poté. V tomto případě se jedná o příkaz GO (grip open, jazyk Movemaster command). Po provedení operace kontrolér oznámí výsledek (buď QoK, QeR, nebo QokSyntax error, který znamená, že příkaz obsahuje chybu v syntaxi). Pokud nepřichází další příkaz, je v pravidelných intervalech zasílán příkaz STATE. Kontrolér pak odpovídá stejně jako předtím (tzn. podle stavu, ve kterém se momentálně nechází). Pokud v programu RT-Toolbox ukončíme terminál zasílání příkazů, je do kontroléru zaslána serie příkazů: 1;1;CNTLOFF 1;1;SRVOFF Uvedené příkazy ukončí čekání na příkaz a vypnou servomotory. Pokud program ukončíme, je zaslán příkaz: 1;1;CLOSE Na který je ještě z řídící jednotky robota zaslána odpověď QoK.
1.23 Závěr kapitoly: V této kapitole jsme stanovili metodiku provedení odposlechu na sériovém portu COM 1, na kterém vzájemně komunikuje software RT-Toolbox a řídící jednotka CR571. Poté jsme zahájili samotný odchyt, kdy jsme provedli v programu RT-Toolbox všechny běžné úkony, které se obvykle při vývoji a ovládání robota vykonávají. Zachycenou komunikaci jsme pak podrobili analýze, při které jsme objasnili způsob, jakým tyto dvě zařízení spolu komunikují. Mezi důležité poznatky patří zejména příkazy, které se dotazují na aktuální polohu jednotlivých os manipulátoru a aktuální souřadnice gripu. Dalším podstatným poznatkem je od39
halení, jak program RT-Toolbox přikazuje řídící jednotce provedení příkazu, který není uložen v jeho paměti. Tento soubor příkazů nám dovolí přímé řízení robota bez nutnosti jej programovat, takže bude možné používat jakýkoliv software, který umožní komunikaci přes sériový port. Této skutečnosti je možné využít při vývoji aplikace v systému Control Web, a díky tomu bude umožněno robota využívat v široké škále aplikací. Mezi další poznatky rovněž patří způsob přístupu do programové paměti kontroléru a nahlížení do ní, tato funkce bude užitečná zejména v případě, kdy nebudeme chtít používat software dodávaný výrobcem. V tomto případě by bylo vhodné další odchyt dat zaměřit zejména na práci s programovou pamětí kontroléru. Na závěr zbývá ještě dodat, že pro komunikaci přes RS232 se více hodí přepnout robota do jazyka Movemaster Command, která podstatně méně zatěžuje komunikační linku mezi osobním počítačem a kontrolérem. Sice oproti jazyku Melfa Basic IV přijdeme o některé možnosti kontroléru (zejména o možnost používat
multitasking)
a místo
vyššího
jazyka budeme
používat
jazyk
na úrovni assembleru, ale díky tomu podstatně snížíme nároky na komunikační linku a nebudeme tak zbytečně zatěžovat osobní počítač a kontrolér neustálou komunikací mezi sebou (při použití Melfa Basic IV je totiž komunikační linka neustále, prakticky v reálném čase, vytěžována odesíláním informací o stavu robota a kontroléru). V průběhu odchytu bylo zároveň zjištěno, že některé složitější pohybové příkazy jazyka Melfa Basic IV se překládají právě do několika příkazů jazyka Movemaster Command a jsou následně postupně odesílány do kontroléru. Je vhodné ještě zmínit skutečnost, že získané informace o tom, jak spolu RT-Toolbox a kontrolér CR571 komunikují, nemusí být úplná a zároveň nemusí pokrývat výjimečné stavy při práci s robotem. Tudíž se vyplatí dbát zvýšené opatrnosti a držet se ověřených informací, aby nedošlo k poškození robota anebo újmě na zdraví.
40
1.24 Tvorba active X komponenty: Tato kapitola se bude zabývat vytvořením externí komponenty pro Control Web, která zajistí kontrolu správnosti příkazu zaslaného vnějším zdrojem (uživatelským terminálem, nebo jiným rozhranním). Tento prvek je důležité do vyvíjeného systému včlenit, jelikož umožní filtrovat vadné příkazy a zabrání tak častým přechodům řídící jednotky robota do chybového stavu, kdy je znemožněna jakákoliv komunikace a pohyb robota. Chybový stav je ještě doplněn o akustický signál, který může být při častějším výskytu značně rušivý, navíc je nutný fyzický reset kontroléru, což může při větší vzdálenosti od řídícího počítače přinášet jisté obtíže. Navíc se tato komponenta hodí i pro další vývoj programového vybavení pro robota, protože snižuje závislost na softwaru od výrobce, který jsme si představili v na začátku práce. Jako další důvod proč tuto část vyčlenit do externího prvku je ten, že řídící jednotka robota Melfa umožňuje použít jak jazyk Melfa Basic IV, tak Movemaster Command. Takže bylo rozhodnuto tento analyzátor vytvořit jako externí komponentu. Důvody tohoto rozhodnutí jsou zejména tyto:
Odstínění kódu v Control Webu od kódu analyzátoru (Control Web bude pracovat jenom s danými metodami externí komponenty).
Snadná záměna komponenty za jinou (která vychází z původní komponenty), aniž by se změnila funkčnost aplikace vytvořená v Control Webu.
Snadná rozšiřitelnost externí komponenty o jiné knihovny (důvodem je zejména značné rozšíření jazyka C++)
1.24.1 Redukce příkazů jazyka Movemaster Command: Vzhledem k doposud získaným poznatkům ohledně komunikačního protokolu robota a jeho dalším zamýšleným použitím, se ukázalo používání některých příkazů jazyka Movemaster Command jako zbytečné. Důvodem je nadřazení počítače s řídícím softwarem nad kontrolér robota (viz obrázek 4).
41
Obrázek 5
S ohledem na strukturu systému je totiž zjevné, že řídící počítač bude do kontroléru robota zasílat pouze příkazy, které se týkají pohybu manipulátoru, takže se programová logika ke kontroléru robota ani nedostane. Na jednu stranu se tak sice degraduje vysoký výpočetní výkon samotné řídící jednotky robota, ale na straně druhé se dá lépe a jednodušeji využít výpočetní výkon a snadná rozšiřitelnost běžného PC, které navíc stojí zlomek ceny, oproti ceně rozšiřující karty do řídící jednotky robota. Tento významný fakt vedl k prozkoumání příkazů jazyka Movemaster a následnému výběru vhodných příkazů, které budou použity k rozpoznání pomocí lexikální analýzy. Ostatní příkazy se dají v případě potřeby implementovat později. Vybrané příkazy se dají rozdělit do těchto skupin:
Příkazy, které slouží ke změně polohy manipulátoru (Change figure, Draw Joint, Decrement position, Draw straight, Draw, Here, Home, Increment Position, Move Approach, Move Continuous, Move joint, Move, Move position, Position Define, Speed define, Speed, Timer)
Příkazy ovládající grip: (Grip Close, Grip Flag, Grip Open, Grip pressure)
Ostatní: (Number, Reset) Jak je vidět z výběru příkazů, převažují příkazy sloužící ke změně polohy
manipulátoru. Tyto příkazy spolu s příkazy grip, budou používány zřejmě nejčas42
těji. Příkaz Number slouží k zavolání nahraného programu pomocí čísla, pod kterým je uložen v paměti robota. Tato skutečnost by mohla pomoci s některými, často se opakujícími programy a usnadnit tak příkaz k zavolání. Dále se předpokládá, že se do paměti robota předem nadefinují body, které bude manipulátor obsluhovat nejčastěji. Takže se budou moci používat příkazy typu Move position (MP [číslo_pozice]). Tyto poziční body se dají nastavit buď pomocí programu RTToolbox, nebo pomocí ručního ovládače robota.
1.24.2 Implementace lexikálního analyzátoru: Lexikální analyzátor je programový modul, který je schopen ve vstupním řetězci rozpoznat prvky identifikátorů, reálných čísel, klíčových slov a dalších posloupností. Je tvořen automatem vzniklým sjednocením, zřetězením a iterací automatů pro jednotlivé jazyky (jazyk identifikátorů, jazyk čísel, jazyk zápisu konstant,
oddělovačů
a podobně).
Uvedenými operacemi nad
regulární-
mi gramatikami vzniká opět regulární gramatika, její implementace je tedy obdobná jako u dílčích gramatik. Rozdíl spočívá pouze v rozšíření akcí konečného automatu.
1.24.3 Kontrola tvaru příkazu: Jazyk Movemaster má přesný tvar příkazu, který se skládá z čísla řádku příkazu a parametru. Z toho plynou požadavky na automat, který bude kontrolovat správnost:
Číslo řádku má tyto parametry: musí být nezáporné a nesmí mít více než 5 míst. V případě přímého příkazu je číslo řádky nepodstatné, ale do implementovaného automatu byla aplikována tato pravidla: každý řádek musí mít vyšší hodnotu než předchozí a maximální hodnota je 99999, je to sice výrazně více než umí kontrolér robota použít, ale při vývoji složitějších aplikací se k tomuto číslu může dojít poměrně jednoduše (kvůli číslování podprogramů a skoků).
Příkazy jazyka Movemaster mají nejméně dvě písmena, maximálně však tři.
Parametr může obsahovat libovolné znaky včetně znaků jako &, $, #, @ apod.
Oddělovač mezi číslem řádku a příkazem je vždy mezera. 43
Z výše uvedených bodů vyplývají požadavky na automat, který bude příkaz kontrolovat. 1.24.4 Automat parse: Automat je navržen jako regulární deterministický a konečný, akceptuje jedním stavem a z každého stavu se může dostat do zamítajícího stavu. Automat je tedy totální. Díky tomu nehrozí zacyklení a nedeterministické chování. Viz obr. 5
Obrázek 6
q0 q1 q2
num ber q0 qErr q2
letter qErr q1 q2
spa-
char
eoln
q1 q2 q2
qErr qErr q2
qErr qAcc qAcc
ce
Tabulka 2
Princip fungování automatu je rovněž znázorněn v tabulce 2, která ukazuje přechodovou funkci formou tabulky. Tento automat neřeší, zda zadaný příkaz a parametr existuje, prověří pouze správnost zadání příkazu. Implementace
automatu
proběhla v jazyce
z několika metod:
44
Visual
C++.
Skládá
se
Samotné tělo, které je implementováno pomocí přepínače switch-case, kde jsou obsaženy jednotlivé stavy a čítače hlídající počet čísel, písmen a délku příkazu.
Metoda, která dodává z přijatého řetězce jeden znak, který se analyzuje. Po vyhodnocení automat vrací podle výsledku true, false a uloží jako ře-
tězce zvlášť příkaz a zvlášť parametr. Podle logické hodnoty na výstupu pak předá řetězce příkaz a parametr dalšímu automatu. 1.24.5 Automat checkParam: Tento automat obdrží při svém zavolání jako parametry řetězce příkaz a parametr. Pomocí příkazu zavolá další automat (většina má název check [příkaz], kde příkaz znamená jméno příkazu, pro který se má testovat parametr), který provede následné vyhodnocení parametru. Tento automat má naimplementovanou redukovanou sadu příkazů jazyka Movemaster Command. Nenaimplementované příkazy automat vyhodnotí jako chybné a vrátí hodnotu false, stejně jako při nesmyslném nebo neznámém příkazu. Případné rozšíření o další příkazy není těžké, jelikož se jedná o přepínač v podobě if else (stavy automatu jsou tedy jednotlivé příkazy if else). Tento způsob implementace nemusí být optimální, ale protože C++ neumožňuje case/switch s řetězci, byla toto jedna z možných implementačních metod. Byť se nejedná o optimální řešení, poskytuje rozumný přehled o implementovaných příkazech. Automaty testující parametry příkazu: Některé příkazy jazyka Movemaster mají stejný tvar parametru, čehož bylo využito při sdružování příkazů do skupin pro testování správnosti parametru, takže využívají stejný automat. Existují také dvě skupiny příkazů, u kterých se parametr liší pouze v jednom bodě (je to skupina příkazů kolem gripu a druhou skupinu tvoří příkazy DS, DW, MJ). Všechny automaty jsou regulární deterministické a konečné.
45
Obrázek 7
Na obrázku 6 je blokové schéma, které popisuje princip fungování a zřetězení automatů, které kontrolují správnost příkazu. Do schématu není zahrnut výstup chybových hlášení, která jsou do automatů implementována. Jednotlivá hlášení upozorňují uživatele na typ chyby, která způsobila přechod automatů do zamítajícího stavu. Chyby byla snaha co nejlépe popsat, aby bylo patrné, kde se nachází. 1.24.6 Implementace active X komponenty: Vzhledem k použití Visual Studia a jazyka C++ existuje několik možností, jak naimplementovat komponentu Active X. První je tvorba pomocí win32 API, tato varianta je nejpracnější a vše je jen na schopnostech programátora, jak si s tvorbou
poradí.
Tato
varianta má
nejvyšší
riziko
vzniku
chyb
při implementaci kódu. Lepší a pohodlnější je zvolení tvorby s pomocí některé z dostupných knihoven (MFC nebo ATL). Knihovna MFC se postará o vytvoření nejnutnější kostry kódu a zajistí alespoň základní funkčnost. Dále MFC implementuje i prvky grafického rozhraní ovládacími třídami, díky tomu zjednodušuje ovládání a umožňuje lepší řízení chování. Nevýhodou je poté velikost knihovny, a hlavně potřeba ji distribuovat jako dynamickou knihovnou s projektem nebo ji linkovat staticky, což zvyšuje objem výsledné aplikace, která má pak vyšší nároky na paměť. [7] 46
ATL je oproti MFC zjednodušená o grafické rozhraní, ale naproti tomu přidává několik podstatných výhod. Předně k aplikaci nemusí být připojena žádná knihovna a hlavně umožňuje jednoduché připojení hlavičkových soboru ATL knihovny pomocí #include. Hlavičkové soubory již obsahují vše potřebné a při kompilaci se potom vloží jen ty funkce, které byly opravdu použity. Zde je hlavní rozdíl oproti knihovně MFC, která má kódy tříd v běžných cpp souborech. [11] Jelikož nepotřebujeme u tvořené aplikace grafické rozhraní, je pak volba knihovny ATL jasná. 1.24.7 Vytvoření a nastavení projektu: Projekt byl vytvořen ve Visual studiu 2008, ve kterém byly psány i automaty na kontrolu příkazů v předchozí kapitole. Po volbě nového projektu se objeví nabídka s typy projektů. Zvolíme vlevo typ projektu ATL, v pravém okně pak vybereme Visual studio installed templates: ATL Project. Vyplníme jméno projektu a stiskneme OK. Po chvilce se objeví Project Wizard, kde stiskneme tlačítko next, vybereme položku Dynamic-link library (dll), pokud bychom potřebovali používat MFC, v tuto chvíli máme ještě možnost zaškrtnout podporu MFC, což v tomto případě nebude nutné. Nabídku pak potvrdíme stiskem tlačítka finish. Nyní se vygeneruje kostra našeho projektu pomocí knihovny ATL, která však neobsahuje rozhraní, přes které je možné volat komponenty, jenž budeme později v Control Webu volat (zde je dobře vidět použití principu klient-server). [11] Přepneme se do roletky Class view, abychom mohli vytvořit rozhraní, které je prezentováno jako třída. Nyní je potřeba tuto třídu vytvořit přes add class, kde se z kategorií vybere podobně jako před chvílí ATL a pak zvolíme v šablonách (templates) ATL Control, stiskneme tlačítko add. Po objevení formuláře zvolíme jméno třídy, které bude zaregistrováno do systému. Se stiskem tlačítka next se objeví nejdůležitější nabídka při tvorbě ATL rozhraní. V této chvíli z tabulky Control Type můžeme vybrat následující možnosti:
Standard control
Composite control
DHTML control Tyto přepínače nám určují, jaké bude mít komponenta grafické rozhraní.
První volba nebude mít žádné grafické rozhraní. Volba composite umožní použití 47
grafického rozhraní a třetí možnost je minimální množství rozhraní, které ještě může být hostováno v programu Internet Explorer. Pro použití v Control Webu je vhodnější použít rozhraní composite, už z toho důvodu, že díky ní bude prvek Active X vidět na panelu přístrojů. To nám umožní zobrazovat ladící informace. Ostaní volby zanecháme, jak byly, ale ještě je nutné zaškrtnout connection points, která umožní klientům COM serveru reagovat na událost vyvolanou na serveru. Ve volbě interfaces necháme vše ve výchozím stavu, jelikož toto nastavení je plně vyhovující. Klepneme na next. Nyní v kartě Appearance můžeme nastavit vlastnosti grafického rozhraní, které je díky použití volby composite control znemožněno. [11] Poslední karta je Stock properties, zde je možné definovat vlastnosti komponenty, ale pro tuto aplikaci tato karta nemá význam. Nyní je struktura zdrojového kódu připravena na naplnění kódem. Do složky source files vložíme soubor Automat.cpp, který obsahuje zdrojový kód výše zmiňovaného lexikálního analyzátoru. Zároveň do složky header files nakopírujeme hlavičkový soubor Automat.h. V kartě Class view najdeme ikonku rozhraní a dáme přidáto novou metodu. Zvolíme jméno metody a vybereme datový typ. V tomto bodě si musíme dát pozor, jelikož se zde pracuje s ukazateli (datový typ s ukazatelem, neboli * použijeme pro výstupní proměnné). Dále musíme zaškrtnout, zda je metoda jenom vstupní nebo i výstupní a zda vrací nějakou hodnotu. Po vytvoření metody a přepnutí na kartu solution explorer vložíme do systému požadovaný zdrojový kód. Najdeme ho v kartě source files pod názvem interface.cpp. Nyní můžeme celý projekt zkompilovat. Ve složce debug poté najdeme potřebnou knihovnu, kterou musíme zaregistrovat pomocí příkazu: regsvr32 automat.dll Nyní, pokud vše proběhlo jak má, je námi vytvořený Active X prvek zaregistrován v operačním systému a můžeme jej použít v sytému Control Web (prvek nalezneme pod příslušným CLSID, umístěném v souboru interface.rgs).
1.25 Závěr kapitoly: V této kapitole jsme vytvořili automat pro lexikální analýzu, který pracuje s redukovaným počtem příkazů programovacího jazyka Movemaster Command. 48
Důvodem pro redukci bylo zjištění, že můžeme nahradit výpočetní výkon kontroléru robota jednodušeji, použitelným stolním počítačem, který bude do řídící jednotky odesílat přímé příkazy, které budou ovládat pohyb manipulátoru. Lexikální analyzátor funguje jako bezpečnostní prvek. Chrání kontrolér před nechtěným odesláním nesmyslného nebo neznámého příkazu, který by mohl zapříčinit jeho přechod do chybového stavu. Automaty jsou nachystány na další rozšíření a mají v sobě zabudované chybové hlášení, které usnadňují identifikaci možné chyby. Dále byla třída Automat importována do prvku Active X se jménem demo3c (bohužel, toto jméno vzniklo při učení se s novou technologií a Visual C++ nepodporuje refaktoring, takže toto jméno muselo zůstat. Jméno však nemá na funkčnost Active X komponenty vliv.). Komponenta je bez problémů zaregistrována v operačním systému a má v sobě přichystané metody rozhraní k dalšímu použití. Metoda demo3c má v sobě implementován vstup a výstup, skrze který komunikuje s okolím. Do této metody se vkládá řetězec s příkazem, který se pak přes instanci Automatu otestuje, a na výstup rozhraní se vrátí logická hodnota, jenž ukazuje, zda přijatý řetězec s příkazem pro robota je validní či nikoliv. Při tvorbě metod rozhraní vznikl problém s nezvyklými datovými typy, které vyžadovaly převod do používaných datových typů u třídy Automat. Další úskalí představovala manipulace s ukazateli. Po pochopení tohoto faktu již s datovými typy u rozhraní nebyl problém. O odlišnostech datových typů v prvku Active X a prostředí Control Web se zmíníme v příští kapitole, která se bude věnovat právě Control Webu.
Aplikace Control Web Jak již bylo zmíněno v předchozích kapitolách, tak se aplikace Control Web dá rozšířit pouze pomocí komponenty Active X. V navrhované aplikaci bude komponenta zastupovat kontrolní mechanismus příkazů posílaných robotovi Melfa. Aplikace má demonstrovat možnosti systému Control Web a prozkoumat možnosti přímého ovládání robota Melfa bez použití programu RT-Toolbox.
49
1.26 Import Active X do Control Webu: Active X komponenta se do prostředí Control Webu vkládá pomocí přístroje Active_X, zpřístupňuje dostupné komponenty zaregistrované v počítači, na kterém systém běží. Již vytvořenou komponentu najdeme v nabídce pomocí CLSID pod nímž je komponenta zaregistrována. Po vybrání určené komponenty jsou přístrojem zpřístupněny metody a události, které jsou dostupné na rozhraní. Vzhled prvku je dán nastavením grafického rozhraní při tvorbě komponenty. Datové typy Active X a Control webu Jak bylo zmíněno v závěru předchozí kapitoly, tak rozhraní Active X používá jiné označení pro datové proměnné než je tomu v systému Control Web. Díky tomu, že je komunikace standardizována, tak se příslušné datové typy odlišují pouze v pojmenování, v seznamu metod komponenty je výpis datových typů podle značení Control Web. Control Web integer boolean longint real string
Rozhraní Active X SHORT VARIANT_BOOL LONG DOUBLE BSTR
1.27 Tvorba aplikace V předchozí kapitole byla do aplikace implementována Active X komponenta, která nám rozšířila funkčnost aplikace. Nyní tuto komponentu propojíme s přístroji, které jsou v aplikaci. Nejprve je pro proceduru SendString() potřeba nastavit ovladač AsciiDrv5, který zprostředkuje komunikaci přes rozhraní RS232. Použijí se parametry, které jsou uvedeny v analýze. Pomocí kanálů ovladače se budou vysílat a přijímat data, určená pro kontrolér. Pro odeslání dat stačí zapsat řetězec na kanál číslo 23. To znamená, že se bude vysílat v synchronním módu a bude se čekat na odpověď kontroléru. Aby mohl uživatel používat metody Active X komponenty, je potřeba, aby měl přístup k textovému editoru, do kterého bude vkládat příkazy a tento příkaz 50
po napsání mohl odeslat do komponenty. To se provede přidáním tlačítka, které tento krok zprostředkuje pomocí procedury OnPress(), jenž odešle zapsaný string do komponenty, která provede vyhodnocení a jako návratovou hodnotu vrátí boolean. Dále se v proceduře OnPress() provede vyhodnocení této návratové hodnoty. Pokud bude vše v pořádku, tak se pomocí uživatelsky definované procedury SendString(CMD_String) zahájí komunikace s robotem Melfa pomocí zápisu na kanál číslo 23 ovladače ASDRV5. Komunikace bude probíhat podle následujícího scénáře: odešle se příkaz k otevření portu, pokud se napojení zdaří, provede se dotaz na polohu ramene. Získaná data_(vyčtená z kanálu číslo_20) se uloží do proměnné position, která se odešle na terminálovou řádku, umístěnou nad řádkou příkazovou. V dalším kroku se provede aktivace robota a servomotorů a odešle se upravený string, který byl přijat z příkazové řádky. Před něj se ještě přiřadí příkaz EXEC, aby kontrolér vykonal požadovanou akci přímo. Poté se deaktivuje robot a servomotory (příkazy SRVOFF, CNTLOFF) a vydá se příkaz k uzavření portu. Tento mechanismus komunikace je zvolen proto, aby se předešlo neprozkoumaným stavům při komunikaci s kontrolérem. Jako kladný přínos tohoto přístupu je neustálý přehled o poloze ramene a malé vytížení komunikačního portu. Na závěr se ještě příkaz s odpovědí robota uloží do archivu, pomocí archivační funkce, která je v Control Webu k dispozici. Takto nachystaná aplikace umožní používání průmyslového robota Mitsubishi Melfa RV-2AJ bez pomoci programu RT-Toolbox ,a díky velké modularitě Control Webu je možné toto zařízení použít k dalším aplikacím.
51
Závěr 1.28 Shrnutí práce: V práci byla popsána výrobní linka FMS200 a pokus o začlenění robota Melfa do této linky pomocí technologie OPC. Bohužel se ukázalo, že kontrolér robota není schopen bez rozšiřující karty s touto technologií komunikovat. Jakékoliv další pokusy a analýzy pak vedly k závěrům, že bez patřičných ovladačů není možné komunikovat s OPC serverem. Dále se ukázalo, že standardní port na kontroléru komunikuje pouze s programem RT-Toolbox, který má však uzavřený komunikační protokol, a nedostatečnou dokumentaci, takže nebylo možné touto analýzou zjistit potřebné parametry komunikačního protokolu. Proto bylo přistoupeno k odposlechu komunikace mezi programem RTToolbox a kontrolérem CR571. Řízeným odposlechem a cílenou manipulací s robotem během tohoto odposlechu, byly zjištěny stěžejní parametry a informace o komunikačním rozhraní. Nabyté znalosti byly podrobeny opakované analýze, během níž byly vytyčeny limity pro uskutečnění vlastní komunikace, tentokrát bez programu RTToolbox. Zmíněná komunikace proběhla za pomocí terminálové aplikace putty, při níž byly zjištěny nedostatky ve znalosti komunikačního protokolu. Proto byl opakován
odchyt
dat
během
komunikace
robota s firemním
softwarem.
V průběhu opětovného odchytu, byly doplněny další informace, které napomohly k ucelení znalostí o tomto uzavřeném komunikačním protokolu. Tyto informace posléze vedly ke vzniku teorie o možnosti jednoduché komunikace s kontrolérem robota CR571. Tato komunikace by mohla plnit požadované účely na pokročilé ovládání manipulátoru bez nutnosti tvořit pro robota program, který by musel být uložen v paměti řídící jednotky robota. Při dalším studiu vznikl nápad na vytvoření externí komponenty, která by hlídla správnost odesílaných dat směrem k řídící jednotce robota. Při dalším studiu komunikačního protokolu vznikl nápad na vytvoření externí komponenty, která by hlídla správnost odesílaných dat směrem k řídící jednotce robota. Tato komponenta by zabraňovala přechodu robota mimo prozkoumané komunikační parametry. Analýzou tohoto požadavku vznikl lexikální analyzátor, který omezuje počet příkazů, které je možné posílat do kontroléru robota.
52
Integrováním tohoto prvku do technologie COM Active X, bylo možné analyzátor implementovat do systému Control Web, který převezme roli ovladače a terminálu pro odesílání přímých příkazů do kontroléru. Díky tomuto faktuk může vzniknout univerzálně použitelný stroj, který se dá poměrně snadno rozšiřovat podle různých potřeb. Po napsání potřebných ovladačů by se toto zařízení mohlo dát připojit i k OPC serveru, kvůli kterým nakonec připojení do této technologie selhalo. Zároveň je však třeba mít na paměti to, že standardní port RS232, který se nachází na řídící jednotce robota, nebyl na tento způsob komunikace navržen, takže může docházet k různým chybám a přechodům kontroléru do chybového stavu.
1.29 Zhodnocení výsledků: Při analýze možnosti začlenění robota Melfa do výrobní linky, se ukázalo, že není možné tyto zařízení připojit. Během další analýzy byly zjištěny možnosti komunikace robota Melfa s jiným než firemním softwarem, které byly experimentálně prověřeny. Na výsledcích tohoto experimentu je možné pokračovat s vývojem. Při vypracovávání této práce bylo zjištěno, že některé body nelze uspokojivě vyřešit, avšak provedený výzkum a získané výsledky je mohou kompenzovat. Při řešení zadaných bodů jsme provedli úkony potřebné ke splnění zadaných zásad, avšak ne u všech bodů bylo možné vyhovět zadání.
1.30 Budoucí využití a možná rozšíření: Výsledky analýzy komunikačního protokolu lze do budoucna využít jako základ pro jiné aplikace, které chtějí používat průmyslového robota Melfa. Zároveň tyto získané poznatky nabízí vývojový potenciál pro další rozvoj práce s tímto robotem.
53
Zdroje: [1] MITSUBISHI. Mitsubishi Industrial Robot - CR1/CR2/CR3/CR4/CR7CR8/CR9 Controller: Instruction Manual (Melfa). 1. vyd. Germany: Mitsubishi Electric Europe B. V. Germany, Oct. 2009, 463 s. [2] RYBIČKA, Jiří. Úvod do teorie formálních jazyků. 1. vyd. Brno: Konvoj, 1999, 39 s. Scriptum. ISBN 80-856-1525-8. [3] KAINKA, Burkhard. Využití rozhraní PC pod Windows: měření, řízení a regulace pomocí standardních portů PC. 1. vyd. Ostrava: HEL, 2000, 151 s. ISBN 80-861-67135. [4] NOVÁK, Petr. Mobilní roboty: pohony, senzory, řízení. Vyd. 1. Praha: BEN - technická literatura, 2004, 247 s. ISBN 80-730-0141-1. [5] STROUSTRUP, Bjarne. C programovací jazyk. 1. čes. vyd. Překlad Jaromír Šmejkal. Praha: Softwarové aplikace a systémy, 1997, 686 s. ISBN 80-901-5072-1. [6] VIRIUS, Miroslav. Programování v C. Vyd. 3., přeprac. V Praze: České vysoké učení technické, 2009, 453 s. ISBN 978-80-01-04371-4. [7] CHALUPA, Radek. Programování COM objektů, ActiveX a Win32 aplikací: s využitím knihovny ATL. 1. vyd. Praha: BEN - technická literatura, 2006, 405 s. ISBN 80730-0197-7. [8] Interfaces and Interface Implementations. In: Microsoft, 2012c. MSDN Library [online]. 2013 [cit.2013-05-01]. Dostupné z: http://msdn.microsoft.com/enus/library/ms694356(v=vs.85).aspx. [9] Moravské Přístroje a.s., 2013. Dokumentace Control Web. Zlín-Malenovice, 2013. Dostupné z: www.mii.cz. [10] COM Clients and Servers. In: Microsoft, 2012b. MSDN Library [online]. 2013 [cit. 2013-05-01]. Dostupné z: http://msdn.microsoft.com/cscz/ library/ms683835(v=vs.85).aspx. [11] ROUŠ, Robert. Řízení robotu KATANA v prostředí Conrol Web, Brno, 2012. Diplomová práce. Mendelova univerzita. Vedoucí práce Dr. Ing. Radovan Kukla. 54
