Energetické úspory v simulaci digitální továrny

ˇ ´ VYSOKE ´ UCEN ˇ Í TECHNICKE ´ V PRAZE CESK E

Fakulta elektrotechnická

Diplomov´ a pr´ ace

Bc. Martin Ron Energetick´ eu ´ spory v simulaci digit´ aln´ı tov´ arny

Katedra ˇ r´ıdic´ı techniky Vedouc´ı práce: Ing. Pavel Burget, Ph.D.

Podˇ ekov´ an´ı Dˇekuji sv´ ym rodiˇc˚ um, kteˇr´ı mˇe podporovali v pr˚ ubˇehu celého studia a v dobˇe psan´ı této práce obzvláˇst’. Chci také podˇekovat svému vedouc´ımu Ing. Pavlu Burgetovi Ph.D. za jeho veden´ı a cenné rady.

Abstrakt Tato práce se zab´ yvá návrhem pluginu pro digitáln´ı továrnu Tecnomatix - konkrétnˇe pro jej´ı prostˇred´ı Process Simulate. Popisuji zde postup návrhu architektury pluginu pro modelován´ı a simulaci profilu PROFIenergy, jeho programován´ı a jeho pouˇzit´ı pˇri virtuáln´ım zprovoznˇen´ı modelového pˇr´ıpadu. V popisu návrhu architektury pluginu se zab´ yvám návrhem stavového automatu pro simulaci profilu PROFIenergy, ideou jeho pouˇzit´ı v Process Simulate a jeho napojen´ı na jiˇz existuj´ıc´ı komponenty tohoto prostˇred´ı. V ˇca´sti o programován´ı mimo jiné vysvˇetluji chován´ı vybran´ ych funkc´ı knihovny Tecnomatix.NET API, návrh simulaˇcn´ıho stavového automatu a jeho zaˇclenˇen´ı do prostˇred´ı Process Simulate. Zab´ yvám se dvˇema funkˇcn´ımi strukturami prostˇred´ı Process Simulate CEE - logick´ ym blokem a uˇzivatelskou funkc´ı. V závˇereˇcné ˇca´sti práce popisuji postup pˇri virtuáln´ım zprovozˇ nován´ı modelu v´ yrobn´ı buˇ nky robotu, jej´ı simulaci a v´ ystupn´ı data ze simulace za pouˇzit´ı vytvoˇreného pluginu.

Kl´ıˇ cov´ a slova: Tecnomatix, Process Simulate, stavov´ y automat, Tecnomatix.NET API, virtuáln´ı zprovoznˇen´ı, PROFIenergy

Abstract The scope of this thesis is about design of plugin for digital manufacturing tool Tecnomatix - with focus on its suite Process Simulate. I describe here procedure of designing architecture of plugin for modeling and simulation of PROFIenergy profile, its programming and its usage for virtual commissioning of demonstrative robotic cell. During description of design of the plugin architecture I develop system of state automata for simulation of PROFIenergy profile, I explain way of its usage in Process Simulate suite and integration with its existing components. In the part about programming beside other I describe behavior of functionalities I picked up from library Tecnomatix.NET API, I describe design of code implementing state automata and integration of its components with Process Simulate. I furthermore explain the two functioning structures of Process Simulate CEE used in my program - the logic block and the user functions. In the last part of thesis I describe procedure used for virtual commissioning of demonstrative model of production cell of robot, simulation of example and outputted data gained from simulation using developed plugin.

Keywords: Tecnomatix, Process Simulate, state automata, Tecnomatix.NET API, virtual commissioning, PROFIenergy

OBSAH

Obsah ´ 1 Uvod

1

2 Metodologick´ y rozbor

3

2.1

PROFIenergy profil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

Tecnomatix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

Objektovˇe orientované programován´ı a C# . . . . . . . . . . . . . . . . . .

5

ˇ sen´ı 3 Reˇ

8

3.1

Formulace pˇredstavy ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.2

Stavov´ y automat PROFIenergy . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3

V´ yvoj architektury pluginu . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.4

Uˇzivatelská funkce - implementace stavového automatu . . . . . . . . . . .

17

3.4.1

Obecné vlastnosti a ˇzivotn´ı cyklus uˇzivatelské funkce . . . . . . . .

17

3.4.2

Pouˇzit´ y stavov´ y automat . . . . . . . . . . . . . . . . . . . . . . . .

18

Process Simulate Command . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.5.1

Pˇriˇrazen´ı logického bloku . . . . . . . . . . . . . . . . . . . . . . . .

28

3.5.2

Záznam PE stav˚ u robot˚ u. . . . . . . . . . . . . . . . . . . . . . . .

34

3.5.3

Záznam polohy kloub˚ u robot˚ u . . . . . . . . . . . . . . . . . . . . .

35

3.5.4

Grafické uˇzivatelské rozhran´ı . . . . . . . . . . . . . . . . . . . . . .

36

Postup pˇri aplikaci pluginu . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3.6.1

Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

3.6.2

Pouˇzit´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3.5

3.6

i

OBSAH

4 Virtu´ aln´ı zprovoznˇ en´ı

46

4.1

Konverze VKRC ˇr´ıdic´ıch signál˚ u na PE-ID . . . . . . . . . . . . . . . . . .

47

4.2

Vnitˇrn´ı odliˇsnosti VKRC PE stavového stroje . . . . . . . . . . . . . . . .

48

4.3

Demonstraˇcn´ı PLC program . . . . . . . . . . . . . . . . . . . . . . . . . .

50

4.4

Modelován´ı pˇr´ıpadu v Process Simulate . . . . . . . . . . . . . . . . . . . .

50

4.5

Pˇripojen´ı signál˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.6

Simulovaná spotˇreba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5 Z´ avˇ er

57

ii

´ U ˚ SEZNAM OBRAZK

Seznam obr´ azk˚ u 1

Základn´ı tˇr´ıvrstvá architektura Tecnomatixu podle [1] . . . . . . . . . . . .

4

2

Základn´ı architektura pluginu . . . . . . . . . . . . . . . . . . . . . . . . .

10

3

Diagram definice PROFIenergy standardu . . . . . . . . . . . . . . . . . .

12

4

Zadáván´ı uˇzivatelsk´ ych funkc´ı do logick´ ych blok˚ u . . . . . . . . . . . . . .

16

5

Diagram upraveného stavového automatu pluginu . . . . . . . . . . . . . .

19

6

V´ yvojov´ y diagram simulace stavového automatu v uˇzivatelské funkci . . .

24

7

Prototyp logického bloku . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

8

UML diagram commandu . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

9

Postup vytvoˇren´ı uˇzivatelské funkce pomoc´ı API . . . . . . . . . . . . . . .

33

10

GUI - záloˇzka nastaven´ı ˇci vytvoˇren´ı logického bloku pro PE . . . . . . . .

37

11

GUI - chybová hláˇska - cesta k souboru neexistuje . . . . . . . . . . . . . .

38

12

GUI - záloˇzka k ovládán´ı záznamu dat ze simulace . . . . . . . . . . . . . .

39

13

Registrován´ı commandu pluginu . . . . . . . . . . . . . . . . . . . . . . . .

41

14

Zaˇrazen´ı tlaˇc´ıtka pluginu v PS . . . . . . . . . . . . . . . . . . . . . . . . .

42

15

Workflow pro uloˇzen´ı záznam˚ u. . . . . . . . . . . . . . . . . . . . . . . . .

43

16

Workflow pro pˇriˇrazen´ı ˇci znovunastaven´ı PE funkˇcnosti . . . . . . . . . .

44

17

Workflow pro aktivaci záznamu - stejn´ y postup pro klouby i PE stavy robotu 44

18

Pˇrehled logického bloku VKRC PE standardu . . . . . . . . . . . . . . . .

49

19

Struktura operac´ı v sekvenˇcn´ı editoru . . . . . . . . . . . . . . . . . . . . .

51

20

Nastaven´ı pˇrechodov´ ych podm´ınek operace . . . . . . . . . . . . . . . . . .

51

21

Nastaven´ı pˇripojen´ı k OPC serveru . . . . . . . . . . . . . . . . . . . . . .

53

22

Pˇripojen´ı signál˚ uv Process Simulate k OPC . . . . . . . . . . . . . . . . .

54

iii

´ U ˚ SEZNAM OBRAZK

23

Graf simulované spotˇreby . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

24

Graf zmˇeˇrené spotˇreby . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

iv

SEZNAM TABULEK

Seznam tabulek 1

PROFIenergy data z dokumentace pouˇzitého kontroleru KRC . . . . . . .

14

2

PE ˇcasován´ı a mapován´ı názv˚ u parametr˚ u uˇzivatelské funkce . . . . . . . .

23

3

Názvy stav˚ u ve v´ yˇctu enStates a jejich ekvivalent v diagramu 5 . . . . . .

25

4

Konverzn´ı funkce VKRC vstup˚ u na ID PE stavu . . . . . . . . . . . . . . .

48

5

Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

v

´ ˚ KODU ´ SEZNAM VYPIS U

Seznam v´ ypis˚ u k´ odu 1

Pˇr´ıklad obsahu .csv souboru s PE ˇcasován´ım . . . . . . . . . . . . . . . . .

30

2

Pˇredloha prázdné uˇzivatelské funkce . . . . . . . . . . . . . . . . . . . . . .

45

vi

´ 1 UVOD

1

´ Uvod V souˇcasnosti se pozornost v naˇs´ı spoleˇcnosti hodnˇe obrac´ı na efektivitu vyuˇzit´ı zdroj˚ u.

Pl´ ytván´ı je nˇeco, co si pˇri rostouc´ı spotˇrebˇe nem˚ uˇzeme z dlouhodobého hlediska dovolit. Obzvláˇst’ to plat´ı o pl´ ytván´ı energi´ı. I kdyˇz zat´ım je neefektivn´ı nakládán´ı s energiemi postiˇzeno jen ekonomick´ ymi ztrátami, je to dostateˇcná motivace pro oblast automatizované v´ yroby, kde spotˇreba elektrické energie hraje nezanedbatelnou roli. Energetická krize moˇzná nenastoup´ı, kdyˇz budeme schopni dostateˇcnˇe pos´ılit v´ yrobu energie, ale ekonomické hledisko zde z˚ ustane v kaˇzdém pˇr´ıpadˇe. Energeticky u ´sporn´ y reˇzim elektrick´ ych spotˇrebiˇc˚ u nen´ı nic nového a zvláˇstˇe v soukromém sektoru je u komplikovanˇejˇs´ıch zaˇr´ızen´ı vyˇzadovan´ ym standardem. V automatizaci v´ yroby se vˇsak dlouhodobˇe klade v´ ykon na prvn´ı m´ısto a energetická efektivita je ˇcasto odsouvána do pozad´ı. V posledn´ı dobˇe vˇsak zájem o zefektivnˇen´ı distribuce a nakládán´ı s energi´ı v´ yraznˇe vzrostl. PROFINET & PROFIBUS International (PI) se rozhodl vytvoˇrit profil, kter´ y by unifikoval principy v u ´sporn´ ych opatˇren´ıch. Mnoho v´ yrobc˚ u zaˇr´ızen´ı se zaˇc´ıná postupnˇe pˇripojovat k tomuto novému v´ yvojovému proudu. Nejsp´ıˇs je PI jednou z prvn´ıch organizac´ı, která se t´ımto smˇerem vydává. Technologie zab´ yvaj´ıc´ı se touto problematikou je rozhodnˇe perspektivn´ı a dá se pˇredpokládat, ˇze kdo nasmˇeruje své snaˇzen´ı t´ımto smˇerem ted’, z´ıská brzy náskok v rychle se rozv´ıjej´ıc´ım odvˇetv´ı automatizované v´ yroby. Projekt, na kterém jsem v rámci ˇreˇsen´ı své diplomové práce spolupracoval, je zamˇeˇren právˇe na optimalizaci automatizované v´ yroby z hlediska spotˇreby energie. Zab´ yvá se optimalizac´ı robotick´ ych cest pˇri zachován´ı provádˇen´ ych operac´ı, plánován´ım pohybu materiál˚ u ve v´ yrobn´ı lince a optimalizac´ı sekvenc´ı v´ yrobn´ıch u ´kon˚ u a také vyuˇzit´ım profilu PROFIenergy k u ´spoˇre energie ve chv´ıl´ıch neˇcinnosti zaˇr´ızen´ı. K simulaci a modelován´ı zkouman´ ych problém˚ u vyuˇz´ıváme software digitáln´ı továrny Tecnomatix. Odtud vzeˇslo zadán´ı mé diplomové práce, protoˇze Tecnomatix jeˇstˇe nepodporuje modelován´ı a simulaci zm´ınˇeného profilu PROFIenergy a pro testován´ı navrˇzen´ ych optimalizac´ı je tato funkˇcnost zapotˇreb´ı. 1

Hlavn´ım c´ılem tedy bylo naprogramovat pro prostˇred´ı Process Simulate (souˇca´st digitáln´ı továrny Tecnomatix) plugin, kter´ y by umoˇznil modelovat a simulovat PE profil, tento plugin otestovat a vytvoˇrit pro nˇej základn´ı energetick´ y model robota, kter´ y je pro testován´ı pouˇzit.

2

´ ROZBOR 2 METODOLOGICKY

2

Metodologick´ y rozbor V této kapitole pop´ıˇsu základn´ı pouˇzitou terminologii a objasn´ım volbu prostˇredk˚ u

k ˇreˇsen´ı práce.

2.1

PROFIenergy profil

ˇ ızen´ı a monitorován´ı spotˇreby energie je poˇra´d d˚ R´ uleˇzitˇejˇs´ı ve vˇsech ˇca´stech automatizované v´ yroby. Z toho d˚ uvodu vznikl na základech standardu PROFINET profil ´ PROFIenergy (dále v textu PE). Ukolem profilu PE je standardizovat rozhran´ı pro z´ıskáván´ı dat o mˇeˇrené energetické spotˇrebˇe a definovat sadu pˇr´ıkaz˚ u, které umoˇzn´ı pˇrevádˇet spotˇrebiˇce do energeticky u ´sporn´ ych reˇzim˚ u. V souˇcasnosti existuje mnoho zaˇr´ızen´ı, která nˇejak´ ym zp˚ usobem mˇeˇr´ı svoji energetickou spotˇrebu a mohou b´ yt pˇrevedena do u ´sporn´ ych mód˚ u, ale tyto pˇrevody jsou ˇcasto pˇr´ıliˇs ˇcasovˇe nároˇcné ˇci nespolehlivé. PE profil by mˇel tyto nedostatky odstranit a dát do rukou uˇzivatel˚ u spolehliv´ y nástroj k mˇeˇren´ı a managementu energetick´ ych spotˇreb. PE profil je zamˇeˇren jak na autonomn´ı rozhodován´ı o pˇreveden´ı do u ´sporného reˇzimu zaˇr´ızen´ı, tak na extern´ı ˇr´ızen´ı spotˇreby. [2]

2.2

Tecnomatix

Digitáln´ı továrna (Digital factory) je obecnˇe soubor programov´ ych nástroj˚ u, které umoˇzn ˇuj´ı modelovat a simulovat pr˚ umyslovou v´ yrobu. Zab´ yvá se ˇca´stmi v´ yroby nebo i cel´ ymi továrnami. Umoˇzn ˇuje tak rychle vyv´ıjet nové pracovn´ı postupy a nasazovat je do praxe rychleji, t´ım, ˇze prototyping v´ yroby m˚ uˇze prob´ıhat v simulovaném prostˇred´ı, stejnˇe jako testován´ı ˇci validace. Odpadá tak nutnost odstavovat reálnou v´ yrobnu pro d´ılˇc´ı testy a zkracuje v´ yraznˇe dobu potˇrebnou na zprovozˇ nován´ı linky napˇr´ıklad pˇri zmˇenˇe technologick´ ych postup˚ u apod.[1][3] Tecnomatix se snaˇz´ı tomuto ideálu pˇribl´ıˇzit. Jedná se o bal´ık velkého mnoˇzstv´ı nejr˚ uznˇejˇs´ıch nástroj˚ u rozˇclenˇen´ ych do nˇekolik aplikac´ı oznaˇcovan´ ych jako prostˇred´ı. Dále 3

2.2 Tecnomatix

v sobˇe integruje datovou základnu a tzv. eMServer, kter´ y zprostˇredkovává pˇr´ıstup k datové základnˇe, spravuje pˇr´ıstupy a zpˇr´ıstupˇ nuje nˇekteré nástroje ke zmˇenám na datech. Data jsou tak pˇr´ıstupná pro vˇsechna prostˇred´ı, která v sobˇe Tecnomatix integruje a je tak usnadnˇena kooperace v´ yvojáˇr˚ u na vˇsech dotˇcen´ ych u ´rovn´ıch plánován´ı a návrhu v´ yroby. Základn´ı architektura podle [1] je zobrazena na obrázku 1. Ve stˇredn´ı vrstvˇe je zobrazeno

Obrázek 1: Základn´ı tˇr´ıvrstvá architektura Tecnomatixu podle [1]

jeˇstˇe datové u ´loˇziˇstˇe SystemRoot, které je pˇreruˇsovanou ˇcarou spojeno s vrstvou klient˚ u. V SystemRootu jsou ukládána 3D modelovac´ı data k objekt˚ um, strojová data pro simulace apod., obvykle b´ yvá SystemRoot na sd´ıleném u ´loˇziˇsti, ale jeho um´ıstˇen´ı pro klienty nen´ı pevné a ˇcasto klientské aplikace vyuˇz´ıvaj´ı lokáln´ı kopii jen ˇca´sti této datové základny oznaˇcované jako SystemRoot. Zm´ın´ım zde dva hlavn´ı stavebn´ı kameny Tecnomatixu, a totiˇz Process Simulate a Process Designer. Process Designer je nástroj urˇcen´ y pˇredevˇs´ım k plánovac´ım u ´kol˚ um ve v´ yrobˇe, umoˇzn ˇuje rychle zobrazovat a analyzovat data t´ ykaj´ıc´ı se v´ yroby a podporuje také 3D zobrazen´ı oblast´ı zájmu. Zprostˇredkuje tedy pˇredevˇs´ım pˇr´ıstup k dat˚ um na eMServeru a umoˇzn ˇuje kombinovat informace z´ıskané z 3D zobrazen´ı s dalˇs´ımi plánovac´ımi nástroji eMServeru. [4] Process Simulate (dále v textu ˇcasto jen PS) je pak urˇcen pro designován´ı, analyzován´ı, simulaci a optimalizaci v´ yrobn´ıch proces˚ u, a to od té nejvyˇsˇs´ı u ´rovnˇe - hlediska celé továrny - aˇz po tu nejniˇzˇs´ı - u ´roveˇ n v´ yrobn´ı buˇ nky ˇc´ıtaj´ıc´ı tˇreba jediného robota. Obsahuje nástroje 4


pro 3D modelován´ı v´ yrobn´ıch zdroj˚ u, simulaci v závislosti na ˇcase a také v závislosti na událostech v modelu - jako napˇr´ıklad signál odeslan´ y z virtuáln´ıho senzoru.[3] Prostˇred´ı PS disponuje reˇzimem naz´ yvan´ ym CEE (Cyclic Event Evaluation), kde ˇr´ıd´ıc´ı entitou nen´ı ˇcas, ale simulované signály a události, napˇr´ıklad signál senzoru pˇribl´ıˇzen´ı apod. Naˇs´ım c´ılem je simulovat novˇe se rozˇsiˇruj´ıc´ı standard PROFIenergy, a to na u ´rovni jednotliv´ ych zaˇr´ızen´ı, a proto je simulaˇcn´ı prostˇred´ı PS v reˇzimu CEE vhodná volba. Simulace profilu PE je v souˇcasné dobˇe do jisté m´ıry implementována v programu Plant Simulation. V prostˇred´ı PS se objevuj´ı prvn´ı náznaky zájmu o problematiku energetick´ ych spotˇreb. Napˇr´ıklad KUKA RCS controller v8.3 pro PS umoˇzn ˇuje v rámci anal´ yzy pohybu KUKA robot˚ u zobrazovat simulovanou energetickou spotˇrebu. Odtud tedy vycház´ı motivace pro programován´ı rozˇs´ıˇren´ı PROFIenergy funkˇcnosti pro Process Simulate.

2.3

Objektovˇ e orientovan´ e programov´ an´ı a C#

V textu zab´ yvaj´ıc´ım se ˇreˇsen´ım práce ˇcasto pouˇz´ıvám term´ıny z objektového programován´ı. Je to v´ yhodn´ y postup i pro vysvˇetlen´ı hierarchie datové struktury studie v Tecnomatixu, protoˇze i ta je navrˇzena ve smyslu objektového programován´ı. Uvedu tedy jen velice povrchovˇe pouˇzité pojmy. Objektov´ y pˇr´ıstup k programován´ı se snaˇz´ı o dosaˇzen´ı podobnosti struktury modelovaného problému s programem. Objekt v ˇreˇseném problému, napˇr´ıklad robot, obvykle dostane pˇriˇrazen objekt v programu, napˇr´ıklad tˇr´ıdu názvu robot. Robot se um´ı h´ ybat, tedy i tˇr´ıda bude obsahovat funkce názvu pohyb, která bude mˇenit vnitˇrn´ı promˇennou ˇ robotu. Reknˇ eme, ˇze máme typ robota KUKA a máme od nˇej v továrnˇe tˇri kusy, pak objektovˇe modelovaná paralela bude m´ıt tˇr´ıdu KUKA a budeme od této tˇr´ıdy vytváˇret tˇri instance (lze chápat jako realizace). Vztah tˇr´ıda - instance lze tedy chápat jako vztah typ - realizace. Instance tˇr´ıdy mus´ı b´ yt vytvoˇrena tzv. konstruktorem - speciáln´ı metodou pro generaci instance. Pokud je konstruktor u ´myslnˇe znepˇr´ıstupnˇen, obvykle je nˇekde jinde vytvoˇrena tzv. továrn´ı metoda, která má ke konstruktoru zprostˇredkovan´ y pˇr´ıstup a zajiˇst’uje proveden´ı nˇejak´ ych pˇr´ıdavn´ ych u ´kon˚ u pˇri vytváˇren´ı instance. Dalˇs´ı uˇziteˇcnou vlastnost´ı 5

2.3 Objektovˇe orientované programován´ı a C#

je tzv. dˇediˇcnost. Tˇr´ıda m˚ uˇze dˇedit od jiné tˇr´ıdy, jako pˇr´ıklad mˇejme tˇr´ıdu robot a od n´ı dˇed´ı tˇr´ıda KUKA. Teprve aˇz kdyˇz máme ve v´ yrobn´ı buˇ nce konkrétn´ı kusy robot˚ u KUKA, jedná se o instance. Tˇr´ıda také m˚ uˇze b´ yt statická a m´ıt statické metody. Taková tˇr´ıda dokáˇze vykonávat své funkce (poskytovat hodnoty statick´ ych promˇenn´ ych, nechat na sobˇe volat statické metody apod.) aniˇz by mˇela vygenerovanou svoji instanci. Dalˇs´ım nástrojem pro zpˇrehlednˇen´ı kódu je tzv. implementován´ı rozhran´ı. Rozhran´ı je zvláˇstn´ı datov´ y typ, kter´ y neobsahuje naprogramovanou funkˇcnost, ale pouze v´ yˇcet metod a promˇenn´ ych. Kdyˇz nˇekterá tˇr´ıda implementuje rozhran´ı, znamená to, ˇze je zaruˇceno, ˇze tato tˇr´ıda má v sobˇe naprogramovanou funkˇcnost vˇsech metod a obsahuje vˇsechny promˇenné, které jsou deklarovány v rozhran´ı. Kontrolu existence hlaviˇcek metod a promˇenn´ ych provád´ı pˇrekladaˇc kódu. Je tˇreba upozornit na term´ın vlastnost tˇr´ıdy. Je to zvláˇstn´ı druh metody, která z´ıskává nebo nastavuje hodnoty promˇenné v tˇr´ıdˇe. Navenek pˇritom vypadá jako promˇenná a pouˇz´ıvá se jako promˇenná. Jej´ım pouˇzit´ım jsou tak zapouzdˇreny obˇe metody, které jsou pro z´ıskán´ı a nastaven´ı promˇenné zapotˇreb´ı. Vlastnost tˇr´ıdy zpˇrehledˇ nuje a zjednoduˇsuje pouˇz´ıván´ı soukrom´ ych promˇenn´ ych t´ım, ˇze programátor s vlastnost´ı manipuluje stejnˇe jako kdyby se jednalo o obyˇcejnou promˇennou. Dále se jeˇstˇe zm´ın´ım o událostech tzv. events. Jedná se o jakési vlajky, které ˇr´ıkaj´ı, ˇze se v programu stalo nˇeco, na co jsme chtˇeli dostat upozornˇen´ı. Událostem se pak pˇriˇrazuj´ı posluchaˇci - metody, které v okamˇziku vzniku události nˇejak reaguj´ı. Napˇr´ıklad kdyˇz uˇzivatel stiskne tlaˇc´ıtko v uˇzivatelském rozhran´ı, vznikne událost a obsluˇzná nebo téˇz naslouchaj´ıc´ı metoda tuto událost obslouˇz´ı nˇejakou reakc´ı. V´ yhoda spoˇc´ıvá v niˇzˇs´ım v´ ypoˇcetn´ım zat´ıˇzen´ı, protoˇze dokud nevznikne událost, ˇzádné obsluˇzné v´ ypoˇcty se neprovád´ı. Nakonec k dˇediˇcnosti. Typicky vˇsechny tˇr´ıdy maj´ı svého pˇredka krom jediné, od které zprostˇredkovanˇe dˇed´ı vˇsechny tˇr´ıdy. Podobnˇe je tomu u datové struktury Tecnomatixu, kde je nejvyˇsˇs´ı u ´roveˇ n projekt, a vˇse ostatn´ı patˇr´ı pod nˇej. Mohou zde b´ yt paraleln´ı projekty, ale nemohou b´ yt naˇcteny najednou v jednom prostˇred´ı. Dalˇs´ı otázkou byla volba programovac´ıho jazyka. Tecnomatix.NET API nás omezuje na 6


jazyky pro platformu .NET, tu vˇsak podporuj´ı v základˇe tˇri programovac´ı jazyky, které jsou zároveˇ n dokumentovány v [5], jedná se o jazyky: • Visual Basic .NET • C++ • C# Kdyˇz jsem procházel dokumentaci [5], nejlépe zdokumentována byla syntaxe C#, proto jsem zvolil pro v´ yvoj pluginu tento jazyk. Jako v´ yvojové prostˇred´ı jsem pouˇzil MS Visual Studio. Pouˇzil jsem zde pojem API, to znamená Application Programming Interface, v pˇrekladu rozhran´ı pro programován´ı aplikac´ı. Je to obvykle knihovna tˇr´ıd a metod, které zprostˇredkuj´ı unifikovan´ y pˇr´ıstup do ucelené aplikace, aby mohla b´ yt obohacena o nˇejakou rozˇsiˇruj´ıc´ı funkˇcnost.

7

ˇ sen´ı Reˇ

3

Nástroje pro ˇreˇsen´ı jsou dány zadán´ım práce. Nejprve jsem tedy prozkoumal moˇznosti, které nab´ız´ı knihovny softwaru Tecnomatix. Ukázalo se, ˇze API pro v´ yvoj aplikac´ı pro Tecnomatix je velmi rozsáhlé, a pˇresto nepokr´ yvá vˇsechny prostˇredky, které bych pro programován´ı pluginu rád vyuˇzil. Tecnomatix je uzavˇrená aplikace bez moˇznosti zkoumán´ı jej´ıho zdrojového kódu, tato softwarová politika v´ yrobce na mˇe kladla v´ yrazná omezen´ı, která bylo nutno obcházet ˇci jinak redukovat. Pro v´ yvoj pluginu jsem postupnˇe navrhl celkem tˇri ˇreˇsen´ı, pˇriˇcemˇz prvn´ı dvˇe se dostala do slepé uliˇcky teprve v pr˚ ubˇehu jejich v´ yvoje. Poˇzadovaného v´ ysledku jsem dosáhl aˇz ve tˇret´ı generaci pluginu.

3.1

Formulace pˇ redstavy ˇ reˇ sen´ı

Pˇri návrhu ˇreˇsen´ı jsem ale vˇzdy pouˇzil základn´ı ideovou strukturu, kterou nyn´ı pop´ıˇsu. Protoˇze profil PROFIenergy (dále jen PE) v základu popisuje stavov´ y automat, je páteˇr´ı mého pluginu vˇzdy stavov´ y automat. Tento automat mus´ı m´ıt nastavitelné ˇcasové podm´ınky pˇrechodu mezi stavy, pˇriˇcemˇz ˇcas se uvaˇzuje jako podm´ınka jen mezi pevnˇe dan´ ymi stavy. Zároveˇ n je zde pˇrirozenˇe poˇzadavek na to, aby pouˇzit´ı stavového automatu hladce zapadalo do struktury simulace v prostˇred´ı Process Simulate (dále jen PS), protoˇze plugin by mˇel b´ yt pouˇzit na jiˇz existuj´ıc´ı projekty a studie. Z toho také vypl´ yvá nutnost zachovat konzistenci jiˇz existuj´ıc´ıch datov´ ych struktur studie. Tento poˇzadavek nelze s ohledem na ostatn´ı poˇzadavky stoprocentnˇe uspokojit. Pokud pouˇziji kv˚ uli poˇzadavku na kompatibilitu pouze datové struktury, které jsou v Tecnomatixu jiˇz vytvoˇreny, nelze s jistotou urˇcit, zda v´ıcenásobné pouˇzit´ı v nˇekteré studii nepovede k naruˇsen´ı funkce studie. Pˇr´ıkladem m˚ uˇze b´ yt tˇreba ˇreˇsen´ı pomoc´ı operac´ı. V prostˇred´ı PS operace mohou reprezentovat nesimulované ˇcasové u ´seky (tzv. non-sim operace), nab´ız´ı se tedy moˇznost vyuˇzit´ı tˇechto operac´ı k simulován´ı pˇrechodu mezi jednotliv´ ymi PE stavy. Non-sim operace vˇsak v nˇekter´ ych studi´ıch uˇz mohly b´ yt k simulován´ı pouˇzity a mohlo by se stát, ˇze by m˚ uj plugin pojmenoval operaci stejnˇe a vznikla by tak duplicita, která m˚ uˇze 8

ˇ SEN ˇ Í 3 RE

vést k nestabilitˇe PS. Kaˇzd´ y objekt ve studii má sice vlastn´ı unikátn´ı ID, jenˇze naˇc´ıtán´ı tohoto ID z eMServeru je pomalé, obzvláˇst’ pokud je provádˇeno na vzdálené klientské stanici. Takové ˇreˇsen´ı nen´ı nejvhodnˇejˇs´ı. Samotn´ y PS nejsp´ıˇse vyuˇz´ıvá nˇejak´ y zp˚ usob indexován´ı objekt˚ u, ale nen´ı moˇzné k tomuto indexován´ı pˇristupovat pomoc´ı API, a tak jediné spolehlivé ˇreˇsen´ı za pouˇzit´ı Tecnomatix API je skuteˇcnˇe pouˇz´ıt unikátn´ı jméno operace. Lze samozˇrejmˇe pouˇz´ıt dostateˇcnˇe komplikované jméno, takˇze se duplicita stane sp´ıˇse otázkou pravdˇepodobnosti. To je jen jedna ukázka toho, jaké problémy z posledn´ıho poˇzadavku vypl´ yvaj´ı. Dalˇs´ı v´ yrazn´ y poˇzadavek je hromadné pouˇzit´ı pluginu. Uˇzivatel pˇred sebou m˚ uˇze m´ıt des´ıtky zaˇr´ızen´ı ve studii. U kaˇzdého tohoto zaˇr´ızen´ı chce modelovat a simulovat pomoc´ı pluginu profil PE a vzniklá reˇzijn´ı data mus´ı z˚ ustat v mez´ıch pˇrehlednosti typick´ ych pro zaˇzitou praxi. Komplexita prostˇred´ı Tecnomatix pˇrirozenˇe vede k ohromnému mnoˇzstv´ı dat uˇz jen v prostˇred´ı PS, a to pro kaˇzdou studii. Tato data se tˇr´ıd´ı podle r˚ uzn´ ych kritéri´ı a uˇzivatelé by mˇeli b´ yt zvykl´ı pracovat s pomˇernˇe rozsáhlou mnoˇzinou jednotliv´ ych typ˚ u dat. Ovˇsem na nejvyˇsˇs´ı u ´rovni tˇr´ıdˇen´ı dat by nemˇel plugin vytváˇret v´ıce neˇz pár datov´ ych entit pro jedno zaˇr´ızen´ı, které by mˇelo disponovat PE funkcionalitou. Tento poˇzadavek vyplynul z okolnost´ı aˇz ˇcasem, kdy se ukázal v té dobˇe zvolen´ y postup jako nevhodn´ y právˇe kv˚ uli velkému mnoˇzstv´ı vytváˇren´ ych datov´ ych objekt˚ u na jedno zaˇr´ızen´ı, se kter´ ymi se musel uˇzivatel pot´ ykat ve studii, aniˇz by je potˇreboval pˇr´ımo upravovat. Plugin má nejen simulovat chován´ı zaˇr´ızen´ı podle PE standardu, ale mus´ı umoˇzn ˇovat i zaznamenávat pr˚ ubˇeh pˇrechod˚ u a setrváván´ı v jednotliv´ ych PE stavech. Je tedy nutné umoˇznit vytvoˇren´ı nˇejakého druhu databáze, v n´ıˇz by kaˇzdé dotˇcené zaˇr´ızen´ı mˇelo uchováno záznam sv´ ych stav˚ u v závislosti na simulovaném ˇcase. Tato databáze mus´ı b´ yt na poˇzadavek uˇzivatele zpˇr´ıstupnˇena prostˇrednictv´ım souboru, aby bylo moˇzné v extern´ım programu analyzovat v´ ysledky simulace. Vˇsechny v´ yˇse zm´ınˇené poˇzadavky na tomto m´ıstˇe shrnu.

• Integrovatelnost do prostˇred´ı Tecnomatix 9

3.1 Formulace pˇredstavy ˇreˇsen´ı

• Stavov´ y automat zahrnuj´ıc´ı ˇcasové podm´ınky pˇrechodu • Konzistence dat • Hromadné pouˇzit´ı V souˇcasné verzi pluginu jsem tedy vzhledem k tˇemto poˇzadavk˚ um sledoval následuj´ıc´ı rozdˇelen´ı. Zamˇeˇril jsem se na prostˇred´ı Process Simulate (PS), protoˇze v nˇem je studie simulována, je tedy logické, ˇze na tomto m´ıstˇe by se mˇela funkˇcnost PE standardu zaˇr´ızen´ım pˇriˇrazovat. Základn´ı ˇcást´ı pluginu je stavov´ y automat. Tato ˇca´st mus´ı b´ yt co nejlépe integrována do PS a mus´ı s n´ım co nejménˇe interferovat. Dalˇs´ım stavebn´ım kamenem je ˇca´st pro záznam stav˚ u v ˇcase pro kaˇzdé dotˇcené zaˇr´ızen´ı. Tato ˇca´st bude napojena na stavov´ y automat a na simulátor integrovan´ y v PS. Nav´ıc bude podporovat export záznam˚ u do souboru. Tˇret´ı souˇcást´ı pluginu je správce pˇredchoz´ıch dvou ˇcást´ı, kter´ y má za u ´kol pˇriˇrazovat zaˇr´ızen´ım ve studii PE funkˇcnost realizovanou stavov´ ym automatem a dále má za u ´kol spravovat záznam stav˚ u. Konfigurace stavového automatu pro konkrétn´ı ˇcasován´ı automatu naˇctené ze souboru také spadá do jeho pole p˚ usobnosti. Vˇsechny tˇri souˇcásti mus´ı b´ yt zastˇreˇseny uˇzivatelsk´ ym rozhran´ım. Popsaná architektura pluginu je vidˇet na obrázku 2. Pˇreruˇsovaná spojnice mezi blokem Stavový automat a Záznam PE stav˚ u zaˇr´ızen´ı znaˇc´ı v´ ymˇenu dat.

Obrázek 2: Základn´ı architektura pluginu

10

ˇ SEN ˇ Í 3 RE

Pˇri vytváˇren´ı pˇredstavy o realizaci této architektury jsem se pro splnˇen´ı poˇzadavku na integrovatelnost drˇzel myˇslenky, ˇze datová struktura mus´ı b´ yt alespoˇ n ˇca´steˇcnˇe vytvoˇritelná manuáln´ım zadáván´ım pˇr´ıkaz˚ u v prostˇred´ı PS. Zkombinován´ı jiˇz existuj´ıc´ıch stavebn´ıch kamen˚ u by mˇelo vést k integrovatelnému ˇreˇsen´ı. Pokusil jsem se tedy vˇzdy nejdˇr´ıve sestavit funkˇcn´ı prototyp datové struktury manuálnˇe v PS a pomoc´ı nˇej simulovat PE funkcionalitu. Kdyˇz jsem dospˇel k funkˇcn´ımu prototypu, pˇreˇsel jsem k programován´ı automatického sestaven´ı této struktury. Uˇzivatel ve v´ ysledku mus´ı m´ıt k dispozici nástroj, kter´ y bude s rozumnou nároˇcnost´ı umoˇzn ˇovat vytváˇren´ı a konfiguraci této struktury. Podobnˇe jsem pak zaˇcal programovat také záznamovou ˇcást pluginu. Pak je na ˇradˇe refaktoring kód˚ u a ladˇen´ı.

3.2

Stavov´ y automat PROFIenergy

Profil PROFIenergy je v [2] rozsáhle popisován do detail˚ u. Jsou zde popsány protokoly komunikace, zp˚ usob ovládán´ı a mnoho dalˇs´ıch d˚ uleˇzit´ ych aspekt˚ u, které jsou d˚ uleˇzité pro v´ yrobce, jenˇz chce ve svém zaˇr´ızen´ı implementovat funkci PE standardu. Pro potˇreby simulace a modelován´ı tohoto standardu v prostˇred´ı Process Simulate je pro mˇe vˇsak esenciáln´ı právˇe definice stavového automatu PE a ˇcásteˇcnˇe také protokol ovládán´ı - konkrétnˇe popis zp˚ usobu, jak´ ym má b´ yt zaˇr´ızen´ı pˇrevádˇeno do jednotliv´ ych energetick´ ych mód˚ u. Ostatn´ı aspekty profilu PE tedy nebudu zmiˇ novat. Standard PROFIenergy (PE) definuje podle [2] mód Operate, Ready to operate, 31 adresovateln´ ych Energy-saving mód˚ u, Sleep mode a Power off mód. Diagram mód˚ u a povolen´ ych pˇrechod˚ u mezi nimi je znázornˇen na obrázku 3. Ve stˇredn´ım sloupci se nacház´ı PE módy, kter´ ych zaˇr´ızen´ı m˚ uˇze dosáhnout. Kdyˇz zaˇr´ızen´ı pˇrecház´ı mezi módy, nevrac´ı na vyˇza´dán´ı ID, které by popisovalo tento jeho stav. Z hlediska aplikace PE standardu to ani nen´ı bezpodm´ıneˇcnˇe nutné a benefity, které by z této informace vypl´ yvaly, jsou zanedbatelné, pˇr´ıpadnˇe nahraditelné. Aby PE standard byl samostatn´ y modulárn´ı celek, jsou tyto postupy v´ıce neˇz pochopitelné. Standard jako takov´ y nav´ıc modeluje ve svém stavovém automatu i pˇrechodové stavy mezi jednotliv´ ymi PE módy. Jak je na diagramu 3 11

3.2 Stavov´ y automat PROFIenergy

Obrázek 3: Diagram definice PROFIenergy standardu

vidˇet, standard pˇredpokládá moˇznost pˇrecházen´ı i mezi pˇrechodov´ ymi stavy. Také z jednotliv´ ych Energy-saving mód˚ u je moˇzno pˇrej´ıt zpˇet do stav˚ u Pˇrechod do Energy-saving. Velké mnoˇzstv´ı pˇrechod˚ u je vˇsak podle standardu pouze voliteln´ ych. Je nutné splnit podm´ınku, ˇze alepsoˇ n jeden pˇrechod vede do nˇekterého z Energy-saving mód˚ u a alespoˇ n jeden pˇrechod vede z Energy-saving módu do Ready to operate módu. Nav´ıc jsou pak volitelné pˇrechody mezi jednotliv´ ymi Energy-saving módy, to uˇz záleˇz´ı na v´ yrobci zaˇr´ızen´ı. Dalˇs´ım voliteln´ ym módem je jeˇstˇe Sleep mode WOL. Ten má oproti standardn´ım Energysaving mód˚ um zvláˇstn´ı chován´ı. Jedná se o u ´sporn´ y mód vyvinut´ y p˚ uvodnˇe pro pr˚ umyslové 12

ˇ SEN ˇ Í 3 RE

poˇc´ıtaˇce [2]. Zaˇr´ızen´ı do tohoto módu m˚ uˇze pˇrej´ıt, ale v pr˚ ubˇehu pˇrechodu dojde k odpojen´ı sbˇernice a zaˇr´ızen´ı tak nem˚ uˇze pˇrij´ımat ˇza´dné pˇr´ıkazy profilu PE po sbˇernici. Sbˇernice se zapne aˇz po pˇrijet´ı speciáln´ıho probouzec´ıho packetu, tzv. Magic Packet. Po probuzen´ı je definováno v PE standardu, ˇze zaˇr´ızen´ı automaticky pˇrejde do stavu Ready to operate. Profil PE poˇc´ıtá i se stavem Power off, je to pˇrirozen´ y stav zaˇr´ızen´ı, kdy je zcela odpojeno od pˇr´ıvodu energie. Tento stav je termináln´ı a podobnˇe jako v pˇr´ıpadˇe stavu Sleep mode WOL nen´ı napájená sbˇernice a nen´ı moˇzné komunikac´ı pˇres PROFINET zaˇr´ızen´ı zapnout. Tento stav tedy do stavového automatu nen´ı zahrnut, nepˇredpokládá se ani moˇznost vypnout zaˇr´ızen´ı pomoc´ı nˇejakého pˇr´ıkazu PE profilu, protoˇze by taková moˇznost postrádala smysl pro PE. Formálnˇe je ale tento stav alespoˇ n uveden a má i své Mode ID. Ovládán´ı pˇrechod˚ u je realizováno pomoc´ı kombinace nˇekolika signál˚ u. Prvn´ım je pˇr´ıkaz, ten m˚ uˇze nab´ yvat tˇr´ı hodnot, a totiˇz Start Pause, End Pause a Go Sleep Mode WOL. Pˇri pouˇzit´ı prvn´ıho pˇr´ıkazu Start Pause je oˇcekáván jeˇstˇe signál s ID poˇzadovaného Energysaving módu. V pˇr´ıpadˇe prvn´ıch dvou ˇr´ıdic´ıch pˇr´ıkaz˚ u signál poˇzadovaného módu nehraje roli, pˇri pˇr´ıkazu Go Sleep Mode WOL se pˇrejde do módu Sleep mode WOL, pˇri pˇr´ıkazu End Pause se zaˇcne pˇrecházet pˇr´ımo do módu Ready to operate. Pro pˇr´ıkaz Start Pause je jeˇstˇe d˚ uleˇzit´ y parametr pˇr´ıkazu, v nˇemˇz by mˇela b´ yt pˇredána doba, na kterou je poˇzadovaná pauza zaˇr´ızen´ı, neˇz jej bude potˇreba pˇrevést do stavu Ready to operate. V pˇr´ıpadˇe, ˇze se zaˇr´ızen´ı dokáˇze autonomnˇe rozhodovat, kter´ y Energy-saving mód je pro tuto dobu nejvhodnˇejˇs´ı, pouˇzije se pˇredan´ y parametr jako rozhodovac´ı kritérium. Zaˇr´ızen´ı, které máme k dispozici, je kontroler KUKA RCS v8.2. Tento kontroler podporuje profil PROFIenergy ve velmi základn´ı podobˇe. Podporuje jeden Energy-saving mód a podporuje i mód Sleep mode WOL. Krom toho pˇrirozenˇe podporuje i Ready to operate a Operating. Mezi módy jsou implementovány jen základn´ı nutné pˇrechody, ˇza´dn´ y z voliteln´ ych nen´ı implementován. Je sice moˇzné vyslat poˇzadavek na nepodporované pˇrechody mezi stavy, ale taková akce vede k nepˇredv´ıdatelnému chován´ı kontroleru, proto jsem nepovolené pˇrechody neuvaˇzoval. Náˇs kontroler také nedisponuje autonomn´ım rozhodován´ım o Energy-saving módech, volba u ´sporného reˇzimu záleˇz´ı pouze na ˇr´ıdic´ım PLC. V doku13

3.3 V´ yvoj architektury pluginu

mentaci kontroleru jsou uvedena data k jednotliv´ ym energetick´ ym mód˚ um, jak je vidˇet v tabulce 1. Jméno módu

Drive Bus OFF

Hibernate

Ready to operate

Jméno dle PE

Energy-saving

Sleep mode WOL

Ready to operate

Trván´ı pˇrechodu do módu

5s

50s

0

Trván´ı pˇrechodu do Operate

20s

50s

0

0

10s

0

150W

30W

220W

Minimáln´ı doba setrván´ı Energetická spotˇreba

Tabulka 1: PROFIenergy data z dokumentace pouˇzitého kontroleru KRC

Pozdˇeji se pˇri mˇeˇren´ı spotˇreby v jednotliv´ ych stavech ukázalo, ˇze reálná spotˇreba se od té v dokumentaci m´ırnˇe liˇs´ı, jak je znát z grafu 24.

3.3

V´ yvoj architektury pluginu

Postup popisovan´ y v podkapitole 3.1 jsem stavˇel na myˇslence, ˇze veˇskeré pˇr´ıkazy, které jsou umoˇznˇeny zadávat uˇzivateli manuálnˇe, je moˇzné zadávat i prostˇrednictv´ım API prostˇred´ı PS. Tato myˇslenka se ukázalá b´ yt z ˇca´sti chybná. V prvn´ı generaci pluginu jsem modeloval stavov´ y automat pomoc´ı non-sim operac´ı, které umoˇzn ˇovaly vynutit v simulaci ˇcasovou prodlevu. Podm´ınky pˇrechodu mezi stavy pak zajiˇst’ovaly Transition condition, které se kontroluj´ı na konci operace. Záznam o dobˇe strávené v jednotliv´ ych PE stavech byl poˇrizován na základˇe informace, která operace je právˇe aktivn´ı. Toto ˇreˇsen´ı mˇelo samo o sobˇe uˇz v prototypu slabá m´ısta. Nˇekteré operace mˇely nulovou délku trván´ı a pouˇz´ıvaly se jako pomocné operace k rozhodován´ı, do které z alternativn´ıch operac´ı se pˇrejde v dalˇs´ım kroku simulace. V takovém pˇr´ıpadˇe operace byla pˇri simulaci v aktivn´ım stavu, aˇckoliv uˇz byla aktivn´ı i jiná operace. Záleˇzelo zˇrejmˇe na vnitˇrn´ım poˇrad´ı 14

ˇ SEN ˇ Í 3 RE

vyhodnocován´ı operac´ı v simulátoru. Toto chován´ı by bylo jeˇstˇe moˇzné odfiltrovat anal´ yzou vznikl´ ych dat, vyvstal vˇsak jin´ y problém. Pomoc´ı API nelze nastavovat Transition condition operac´ı tak, jako to lze udˇelat manuálnˇe v prostˇred´ı PS. Tato skuteˇcnost nebyla zpoˇca´tku známá kv˚ uli nedostateˇcné dokumentaci API, zjistil jsem ji aˇz v pr˚ ubˇehu ˇreˇsen´ı. V dobˇe, kdy jsem vyv´ıjel prvn´ı generaci pluginu, byla vypuˇstˇena verze Tecnomatix 10. V této verzi pokus o nastaven´ı zˇretˇezen´ı operac´ı pˇres API zp˚ usoboval pád prostˇred´ı PS. V následuj´ıc´ı verzi Tecnomatix 11.0 sice tento problém byl odstranˇen, stále ovˇsem chyb´ı moˇznost nastavovat Transition condition operac´ı, takˇze jsem musel hledat jiné ˇreˇsen´ı. Druhá generace pluginu byla postavena na tzv. logických bloc´ıch. To je struktura, která umoˇzn ˇuje v PS pˇriˇrazovat urˇcit´ ym objekt˚ um jisté logické chován´ı. Dokonce umoˇzn ˇuje pouˇz´ıvat vnitˇrn´ı promˇenné pro jednotlivé bloky. Z mého hlediska pak nejpodstatnˇejˇs´ı vlastnost´ı logick´ ych blok˚ u byla moˇznost pozdrˇzet v´ ystupn´ı hodnotu o pˇresnˇe definovan´ y ˇcasov´ y u ´sek. V´ ystup byl pak vˇzdy opoˇzdˇen o tento ˇcas. Vytvoˇril jsem tedy prototyp s ˇretˇezcem logick´ ych blok˚ u, kde jeden logick´ y blok reprezentoval jeden PE stav. Musel jsem se tak vzdát moˇznosti pˇriˇrazen´ı stavového automatu pˇr´ımo pod zaˇr´ızen´ı, jehoˇz PE chován´ı simuluje. Pro jeden stavov´ y automat bylo zapotˇreb´ı celkem 9 logick´ ych blok˚ u. Je jasné, ˇze se vzr˚ ustaj´ıc´ım poˇctem zaˇr´ızen´ı, na které by byl plugin pouˇzit, by ne´ unosnˇe rostl i poˇcet blok˚ u, které by musel uˇzivatel procházet pˇri své práci se studi´ı. Nevhodné smazán´ı nebo odpojen´ı kteréhokoli bloku by naruˇsilo funkcionalitu stavového automatu. Toto ˇreˇsen´ı vedlo k funkˇcn´ımu prototypu a bylo i moˇzné tento prototyp zreprodukovat za pouˇzit´ı API, ale ze zjevn´ ych d˚ uvod˚ u jsem od nˇej upustil. Tˇret´ı generace pluginu uˇz plnˇe odpov´ıdá poˇzadované architektuˇre, jak je znázornˇena v diagramu na obrázku 2. Stavov´ y automat je realizován pomoc´ı uˇzivatelské funkce. Prostˇred´ı Process Simulate umoˇzn ˇuje pouˇz´ıvat takzvané logické bloky - objekty, které umoˇzn ˇuj´ı simulovat jistou omezenou logiku. V rámci tˇechto objekt˚ u mohou b´ yt nastaveny vnitˇrn´ı parametry nebo v´ ystupy na základˇe v´ ysledku v´ ypoˇctu této uˇzivatelské funkce. Prostˇred´ı PS uˇz od prvotn´ı instalace obsahuje nˇekolik základn´ıch uˇzivatelsk´ ych funkc´ı, jsou jimi detekce nábˇeˇzné hrany (RE ( X ) - rising edge), detekce sestupné hrany (FE ( X ) - falling 15

3.3 V´ yvoj architektury pluginu

edge), dvˇe verze bistabiln´ıho klopného ˇclenu (SR ( X Y ) - set-reset a RS ( X Y ) - resetset), generátor náhodného ˇc´ısla (RANDOM ( minValue maxValue )) a v´ ypoˇcet absolutn´ı hodnoty (ABS ( Num )). Pˇri pouˇz´ıván´ı RS funkce jsem zjistil, ˇze nefunguje správnˇe - pˇri nastaven´ı prvn´ıho jej´ıho parametru X na hodnotu true nespadne jej´ı v´ ystup na false, jak by mˇel. Funkce SR naproti tomu funguje správnˇe a liˇs´ı se od RS jen poˇrad´ım vstupn´ıch parametr˚ u. Stejnˇe jako je tomu u RS a SR ˇclen˚ u, i pro náˇs plugin je zapotˇreb´ı vnitˇrn´ı pamˇeti. Uˇzivatelská funkce toto zjevnˇe umoˇzn ˇuje a zároveˇ n nezveˇrejˇ nuje nikde v PS své vnitˇrn´ı promˇenné, a tak nevzniká problém s nepˇrehlednost´ı studie pro uˇzivatele. Uˇzivatelská funkce se tedy jev´ı jako ideáln´ı nástroj k realizaci stavového automatu. Na tomto m´ıstˇe mus´ım vˇsak upozornit na u ´skal´ı pouˇzit´ı uˇzivatelsk´ ych funkc´ı v PS. Jak

Obrázek 4: Zadáván´ı uˇzivatelsk´ ych funkc´ı do logick´ ych blok˚ u

je vidˇet na obrázku 4, parametry uˇzivatelsk´ ych funkc´ı se zadávaj´ı ve volnˇe textové podobˇe. To m˚ uˇze svádˇet k pˇripodobˇ nován´ı funkce k nˇekter´ ym programovac´ım jazyk˚ um, kde jako vstupn´ı parametr funkce m˚ uˇze b´ yt pouˇzit v´ yraz, ˇci jiná vnoˇrená funkce. Tuto funkˇcnost zde 16

ˇ SEN ˇ Í 3 RE

ale PS nepodporuje a vstupn´ım parametrem sm´ı b´ yt jedinˇe samotn´ y ˇcist´ y parametr. Kombinován´ı funkc´ı a vytváˇren´ı v´ yraz˚ u je jinak ale v poli Value Expression umoˇznˇeno a funguje v poˇra´dku. Jak je vidˇet na obrázku 4, lze toto omezen´ı obej´ıt vytvoˇren´ım pomocného parametru, jehoˇz hodnota je poté dosazena do uˇzivatelské funkce. Na stejném obrázku je vidˇet, ˇze jsem tuto metodu pouˇzil u parametru requestedStateID, kter´ y je prvn´ım vstupn´ım parametrem funkce PEStateMachine v ˇcervenˇe zv´ yraznˇené oblasti. Pˇri tomto postupu je nutné brát v u ´vahu, ˇze vnitˇrn´ı parametry logického bloku jsou vyhodnocovány postupnˇe podle hodnoty v pol´ıˇcku Index. Na obrázku 4 je vidˇet, ˇze nejdˇr´ıve je vypoˇctena hodnota vnitˇrn´ıho parametru requestedStateID s indexem 1, a aˇz poté je poˇc´ıtána hodnota parametru currentState s indexem 2 a pˇri jej´ım v´ ypoˇctu je pouˇzit v´ ysledek nyn´ı uloˇzen´ y v requestedStateID.

3.4

Uˇ zivatelsk´ a funkce - implementace stavov´ eho automatu

Kdyˇz jsem vyv´ıjel uˇzivatelskou funkci, aby plnila roli stavového automatu, prozkoumal jsem nˇekolik cest, jak se k tomuto c´ıli dostat, a ne kaˇzdá cesta byla vhodná. Abych mohl navrhnout u ´ˇcinné algoritmy, ˇcasto jsem musel testovat, jak funguje prostˇred´ı PS, aby bylo moˇzné pochopit, proˇc nˇekteré postupy selhávaj´ı. Nejd˚ uleˇzitˇejˇs´ımi body tohoto procesu se zab´ yvá tato kapitola.

3.4.1

Obecn´ e vlastnosti a ˇ zivotn´ı cyklus uˇ zivatelsk´ e funkce

Uˇzivatelská funkce má pˇredepsanou strukturu, d´ıky n´ıˇz m˚ uˇze b´ yt zaˇclenˇena do funkˇcnosti prostˇred´ı PS. Implementuje rozhran´ı Tecnomatix.Engineering.ITxPlcLogicBehaviorFunction knihovny Tecnomatix.Engineering.dll. Toto rozhran´ı ale vynucuje pouze funkci Evaluate(), coˇz samo o sobˇe nedostaˇcuje. Funkce Evaluate() je volána kaˇzd´ y krok simulace ve chv´ıli, kdy dojde k vyhodnocován´ı Expression Value, kde je uˇzivatelská funkce pouˇzita. Je-li pouˇzita na v´ıce m´ıstech, pochopitelnˇe je Evaluate() volána v´ıcekrát v jednom kroku simulace. T´ım se dostávám k otázce ˇzivotn´ıho cyklu tˇr´ıdy uˇzivatelské funkce. V pr˚ ubˇehu v´ yvoje pluginu se ukázalo, ˇze pˇri inicializaci pˇri startu programu Process Simulate je vytvoˇrena 17

3.4 Uˇzivatelská funkce - implementace stavového automatu

jediná instance od kaˇzdé tˇr´ıdy uˇzivatelské funkce, a to se stane jeˇstˇe pˇred naˇcten´ım jakékoli studie, tedy nezáleˇz´ı, jestli je nˇekde uˇzivatelská funkce pouˇzita. Pˇri startu je volán tedy konstruktor tˇr´ıdy (v kódu 2 je to JmenoTridyUzivatelskeFunkce(), ˇra´dek 12). Dále je pˇri naˇcten´ı nˇejaké studie, v n´ıˇz je uˇzivatelská funkce pouˇzita, zavolána metoda ParametersTypes(), a to právˇe jednou, nezávisle na poˇctu parametr˚ u. Tatáˇz metoda ParametersTypes() je volána i v okamˇziku, kdy uˇzivatel otevˇre rozhran´ı pro prohl´ıˇzen´ı a editaci logick´ ych blok˚ u (viz obrázek 4) a pˇrejde na záloˇzku, na n´ıˇz je vidˇet pouˇzit´ı této uˇzivatelské funkce. Toto volán´ı probˇehne jen poprvé, pˇri opakovaném zobrazen´ı jiˇz volána nen´ı. Metoda ReturnValueType() je volána na zaˇcátku kaˇzdého kroku simulace, a to pˇred volán´ım metody Evaluate(). Kaˇzdá uˇzivatelská funkce také mus´ı m´ıt pro svou tˇr´ıdu zaveden´ y atribut (viz ˇra´dek 5 v´ ypisu kódu 2) se jménem této funkce, které se pak zobraz´ı v prostˇred´ı PS. Zobrazen´ı jména funkce je jen vedlejˇs´ı role atributu, pˇredevˇs´ım umoˇzn ˇuje pomoc´ı reflexe v bˇeˇz´ıc´ım programu (v mém pˇr´ıpadˇe bˇeˇz´ıc´ım PS) pouˇz´ıvat atributem indexovanou tˇr´ıdu. T´ım jsou popsány vˇsechny formáln´ı náleˇzitosti uˇzivatelské funkce.

3.4.2

Pouˇ zit´ y stavov´ y automat

Stavov´ y automat popsan´ y na obrázku 3 nen´ı pro programován´ı simulace PROFIenergy vhodn´ y. Na jednu stranu je pˇr´ıliˇs sloˇzit´ y a popisuje i moˇznosti, které v´ yrobce naˇseho robotického kontroleru neimplementuje. Na druhou stranu je tento stavov´ y automat o trochu jednoduˇsˇs´ı neˇz aby bylo moˇzné jej pˇr´ımo implementovat v pluginu. Nav´ıc ID stav˚ u tak, jak jsou v profilu PE definována, nenechávaj´ı prostor pro zaveden´ı ID pˇrechodov´ ym stav˚ um a pro implementaci je potˇreba oznaˇcit kaˇzd´ y simulovan´ y stav unikátn´ım ID. Náˇs kontroler podporuje jen jeden Energy-saving mód, mód Sleep mode WOL a mód Ready to operate, jak je uvedeno v tabulce 1. Vypustil jsem tedy ze stavového automatu vˇsechny dalˇs´ı hypotetické Energy-saving módy s t´ım, ˇze jsem strukturu programu udrˇzoval tak, aby bylo moˇzné s rozumnou nároˇcnost´ı pozdˇeji pˇridat dalˇs´ı simulovatelné Energysaving módy. 18

ˇ SEN ˇ Í 3 RE

Dále model na obrázku 3 nemodeluje pomoc´ı stavu fázi, kdy je zaˇr´ızen´ı v Energysaving módu bezprostˇrednˇe po dosaˇzen´ı tohoto stavu a nem˚ uˇze jeˇstˇe reagovat na pˇr´ıkazy k pˇrechodu do jiného stavu. Pro potˇreby v´ yvoje pluginu jsem tento stav ve své uˇzivatelské funkci zavedl a naz´ yvám ho jako Nezbytný Energy-saving respektive Nezbytný Sleep mode WOL. Zjednoduˇsuje se tak sada podm´ınek kontrolovan´ ych pˇri obdrˇzen´ı pˇr´ıkazu k pˇrechodu mezi stavy a eventuáln´ı pˇridán´ı dalˇs´ıch stav˚ u se t´ım také stává procedurálnˇejˇs´ı ˇcinnost´ı. Vznikl tak model stavového automatu, kter´ y je moˇzné elegantnˇe implementovat bez naruˇsen´ı poˇzadavk˚ u na omezen´ı ˇci integrovatelnost PE stavového automatu. Jeho diagram je na obrázku 5. Jak je z diagramu patrné, kaˇzd´ y stav má zavedené ID, které se neshoduje

Obrázek 5: Diagram upraveného stavového automatu pluginu

s ID definovan´ ym v PE standardu. Jsou zde také vidˇet podm´ınky pˇrechod˚ u. Tam, kde je ˇ jako podm´ınka uveden Cas, tam dojde k pˇrechodu právˇe tehdy, kdyˇz uplyne definovan´ y ˇcasov´ y u ´sek. Tyto ˇcasové u ´seky se liˇs´ı zaˇr´ızen´ı od zaˇr´ızen´ı a je nutné umoˇznit uˇzivateli 19


jejich nastaven´ı na správnou hodnotu. Rozhodl jsem se, ˇze seznam tˇechto ˇcasov´ ych konstant bude pˇredáván uˇzivatelské funkci jako parametr v kaˇzdém kroku simulace. Tento postup byl vynucen ˇzivotn´ım cyklem uˇzivatelsk´ ych funkc´ı. Jedna a tatáˇz instance je pouˇzita pro simulaci mnoha zaˇr´ızen´ı a kaˇzdé m˚ uˇze m´ıt jiné ˇcasové konstanty pˇrechod˚ u mezi stavy, takˇze nen´ı moˇzné uloˇzit ˇcasován´ı nastálo v této instanci. Nen´ı ani moˇzné s jistotou urˇcit poˇrad´ı, v jakém budou jednotlivá zaˇr´ızen´ı simulována, takˇze ani nˇejak´ y vnitˇrn´ı indexovan´ y seznam konstant nen´ı ˇreˇsen´ım. Dostávám se tak k problému simulován´ı v´ıce zaˇr´ızen´ı v jednom bˇehu simulace. Je uˇz jasné, ˇze stavov´ y automat m˚ uˇze b´ yt simulován jen pokud dokáˇzeme uchovávat informaci o stavu pro kaˇzdé dotˇcené zaˇr´ızen´ı zvláˇst’. P˚ uvodnˇe jsem intuitivnˇe pˇredpokládal, ˇze pro kaˇzdé pouˇzit´ı uˇzivatelské funkce je vytvoˇrena jej´ı samostatná instance. Jak jsem popsal dˇr´ıve, tento pˇredpoklad byl myln´ y. Musel jsem hledat cestu, jak toto omezen´ı obej´ıt. Pokud by bylo moˇzné v jediné databázi udrˇzovat informaci o stavu kaˇzdého zaˇr´ızen´ı a tuto databázi spravovat v instanci uˇzivatelské funkce, bylo by to ˇreˇsen´ı. K tomu je potˇreba nˇejak´ ym zp˚ usobem indexovat jednotlivá zaˇr´ızen´ı. V prostˇred´ı Tecnomatix na eMServeru je pˇridˇeleno ke kaˇzdému objektu tzv. external ID - unikátn´ı ˇretˇezec znak˚ u generovan´ y pˇri vytvoˇren´ı tzv. plánovac´ıho objektu v databázi. Nast´ın´ım, co je plánovac´ım objektem myˇsleno. Objekty v PS potaˇzmo v Tecnomatixu jsou bud’to plánovac´ı, nebo modelovac´ı, nebo oboj´ı. Plánovac´ı objekt je reprezentace napˇr´ıklad robotu, která ˇr´ıká jen to, ˇze robot je zde pouˇzit a má nˇejaké vlastnosti, ale nic neˇr´ıká o jeho 3D modelu ˇci kinematice. Tyto fyzické vlastnosti jsou zahrnuty v modelovac´ım objektu. Právˇe pouˇzit´ y pˇr´ıklad robotu je pˇr´ıklad objektu zároveˇ n plánovac´ıho i modelovac´ıho. I modelovac´ı objekt má unikátn´ı popisovaˇc - object ID - také ˇretˇezec znak˚ u. Zde vzniká m´ırné zmaten´ı. Prostˇred´ı PS je stavˇeno jako objektovˇe orientované modelovac´ı prostˇred´ı, existuj´ı tˇr´ıdy objekt˚ u a z nich se vytváˇr´ı instance, pˇr´ıkladem je tˇreba tˇr´ıda robot KUKA KRC5 a z nˇej je vytvoˇreno nˇekolik kus˚ u robot˚ u tohoto typu. Pro tˇr´ıdu objektu existuje také unikátn´ı ID, a to je v atributu eMSType. Je jasné, ˇze toto posledn´ı ID je pro mé potˇreby nepouˇzitelné. Zformuloval jsem pˇredstavu, ˇceho chci dosáhnout. V logickém bloku pˇriˇrazeném konkrét20

ˇ SEN ˇ Í 3 RE

n´ımu zaˇr´ızen´ı v PS je zavolána uˇzivatelská funkce a této funkci je pˇredán unikátn´ı popisovaˇc zaˇr´ızen´ı, podle kterého instance uˇzivatelské funkce vyhledá ve své vnitˇrn´ı databázi stav, v nˇemˇz se dané zaˇr´ızen´ı nacház´ı. Bylo by logické pouˇz´ıt jedno nebo druhé z vhodn´ ych ID v´ yˇse popsan´ ych jako identifikátor. Zde vyvstávaj´ı dvˇe pˇrekáˇzky, které v takovém pouˇzit´ı brán´ı. Zaprvé v logickém bloku mohou b´ yt pouˇzity parametry, vstupy a v´ ystupy jen a pouze ˇc´ıseln´ ych typ˚ u. Logickou hodnotu boolean povaˇzuji za ˇc´ıslo 1 nebo 0 vzhledem k tomu, ˇze v logickém bloku je moˇzné násobit booleanovskou hodnotou ˇc´ıselnou hodnotu ve smyslu true = 1 a f alse = 0. Toto chován´ı logické hodnoty je pˇrekvapivé, ale ˇcasto velmi uˇziteˇcné. V pˇredchoz´ım odstavci jsem uvedl, ˇze ID objekt˚ u jsou ˇretˇezce znak˚ u, tedy nesluˇciteln´ y datov´ y typ. Nen´ı ani moˇzné jednoduˇse pˇred vstupem ˇretˇezce do logického bloku pˇrevést ˇretˇezec nˇejak´ ym prost´ ym zobrazen´ım na ˇc´ıslo, protoˇze i vstup logického bloku uˇz mus´ı b´ yt ˇc´ıslo. Odtud pak vycház´ı druhá pˇrekáˇzka, a totiˇz ˇze nelze hodnotu ID dostat do signálu, aby tento signál pak mohl b´ yt pˇredán na vstupu logického bloku, kam lze pˇripojit jen signály. A opˇet zde vyvstává omezen´ı, ˇze signál sm´ı b´ yt jedinˇe ˇc´ıselná hodnota, prostˇred´ı PS nic jiného neumoˇzn ˇuje. T´ım je vylouˇceno pouˇzit´ı jiˇz existuj´ıc´ıch ID objekt˚ u kv˚ uli nekompatibilitˇe datov´ ych typ˚ u. Je nutné tedy generovat vlastn´ı ID zaˇr´ızen´ı pro potˇreby hledán´ı jejich stav˚ u pˇri simulaci. Toto ID mus´ı b´ yt unikátn´ı alespoˇ n po dobu bˇehu simulace. Jak se pozdˇeji ukázalo, doˇcasná unikátnost ID je bohuˇzel to nejlepˇs´ı, ˇceho lze dosáhnout. Jsou dvˇe moˇznosti, jak zaˇr´ızen´ı ID pˇriˇrazovat. Prvn´ı moˇznost´ı je pouˇz´ıt signál v prostˇred´ı PS. V tom pˇr´ıpadˇe by pˇri simulaci musel b´ yt kaˇzd´ y signál pevnˇe nastaven´ y na unikátn´ı ID zaˇr´ızen´ı, tato hodnota se pˇri kaˇzdém spuˇstˇen´ı simulace mus´ı zkontrolovat a vˇetˇsinou znovu nastavit. Toto ˇreˇsen´ı se jev´ı b´ yt tˇeˇzkopádné, kromˇe toho také pˇridˇelává uˇzivateli starosti s nov´ ymi signály, které mus´ı spravovat. Druhou moˇznost´ı je uloˇzit ID v kaˇzdém logickém bloku v podobˇe konstanty. Na obrázku 18 v pˇrehledu konstant v zeleném rámeˇcku je vidˇet konstanta s názvem blockID, která pln´ı pˇresnˇe tuto u ´lohu. Jeˇstˇe je nutné zajistit unikátnost této konstanty. T´ım se zab´ yvá PS command, kter´ y popisuji v následuj´ıc´ı kapitole. Dále je na ˇradˇe vyˇreˇsit databázi stav˚ u jednotliv´ ych zaˇr´ızen´ı. Bude existovat jen jedna 21


databáze uloˇzená v instanci tˇr´ıdy uˇzivatelské funkce. Jako vhodn´ y nástroj pro realizaci takové databáze se jev´ı slovn´ık (generická tˇr´ıda jazyka C# - Dictionary), kter´ y umoˇzn ˇuje s kl´ıˇcem mapovat libovolné datové typy. Vytvoˇril jsem v´ yˇctov´ y typ enStates (energetic states) pro jednoznaˇcn´ y popis PE stavu. Databázi stav˚ u zaˇr´ızen´ı tak tvoˇr´ı slovn´ık deklarace Dictionary myActualStatesDict;. V kaˇzdém volán´ı funkce Evaluate(), tedy v kaˇzdém kroku simulace, je ve slovn´ıku vyhledán stav podle kl´ıˇce, kter´ ym je blockID. Pˇri prvn´ım hledán´ı jeˇstˇe nen´ı ve slovn´ıku ˇza´dn´ y záznam, a tak je pˇridán s pˇredan´ ym blockID. D´ıky tomu, ˇze byl pouˇzit slovn´ık, nemus´ı b´ yt ID ˇrazena vzestupnˇe, ale mohou b´ yt r˚ uznˇe zpˇreházena. Dále je potˇreba zaznamenávat okamˇzik, kdy zaˇr´ızen´ı vstoupilo do nˇekter´ ych stav˚ u, aby tak mohlo b´ yt simulováno ˇcasován´ı PE. K tomu jsem vyuˇzil dalˇs´ı slovn´ık, kter´ y k jednotliv´ ym blockID pˇriˇrazuje ˇcasovou známku (timestamp) vstupu do stavu. Pouˇzit´ım ˇcasov´ ych známek se pˇredejde moˇzn´ ym komplikac´ım pˇri mˇeˇren´ı ˇcasu, kdyˇz je pˇred uplynut´ım ˇcasového intervalu simulace pozastavena. Omezil jsem se na rozhodován´ı o ˇcasovˇe závisl´ ych událostech jen na základˇe ˇcasu simulace. Pozdˇeji jsem rozˇs´ıˇril uˇzivatelskou funkci jeˇstˇe o jeden slovn´ık, kter´ y udrˇzoval informaci o tom, zda robot pˇreˇsel v tomto kroku ze stavu Operating do stavu Ready to operate, aby bylo moˇzné realizovat virtuáln´ı zprovoznˇen´ı VKRC standardu, o tom podrobnˇeji pojednávám v kapitole 4.

Stejnˇe jako blockID vstupuje do uˇzivatelské funkce i sada vˇsech ˇcasov´ ych konstant náleˇzej´ıc´ıch konkrétn´ımu zaˇr´ızen´ı. Jejich hodnoty jsou uloˇzeny v konstantách logického bloku a jsou nastaveny pˇri sestavován´ı logického bloku. Pozdˇeji je ovˇsem moˇzno je upravit. V tabulce 2 uvád´ım seznam názv˚ u ˇcasov´ ych konstant v uˇzivatelské funkci, jejich ekvivalenty v diagramu 5 a hodnoty pro náˇs kontroler. Podle názv˚ u v této tabulce je pak uloˇzen extern´ı seznam konstant v csv souboru. Po vystavˇen´ı vstupn´ıch parametr˚ u uˇzivatelské funkce jsem z´ıskal hlaviˇcku PEStateMachine ( requestedStateID blockID timeToPsaving timeMustPsaving timeToReadyFromPsaving timeToSleep timeMustSleep timeToReadyFromSleep ), která je pomˇernˇe dost dlouhá, ale to je jen malá daˇ n za pˇrehlednost, kterou zapouzdˇren´ım vˇseho ostatn´ıho uˇzivateli tato funkce pˇrináˇs´ı. Hned prvn´ım parametrem je requestedStateID, o kterém jsem se jeˇstˇe nezm´ınil. Jak název dává tuˇsit, v tomto parame22

ˇ SEN ˇ Í 3 RE

Název parametru

Popis ˇci PE ekvivalent

Hodnota [s]

timeToPsaving

Pˇrechod do Energy-saving

5

timeMustPsaving

Nezbytný Energy-saving

0

timeToReadyFromPsaving

Pˇrechod do Ready to operate

20

timeToSleep

Pˇrechod do Sleep mode WOL

50

timeMustSleep

Nezbytný Sleep mode WOL

10

timeToReadyFromSleep

Pˇrechod do Ready to operate

50

Tabulka 2: PE ˇcasován´ı a mapován´ı názv˚ u parametr˚ u uˇzivatelské funkce tru se uˇzivatelské funkci pˇredává poˇzadovan´ y PE stav, do nˇehoˇz se má pˇrej´ıt. V tuto chv´ıli je na m´ıstˇe pˇredstavit rozhodovac´ı kritéria, podle kter´ ych je stavov´ y automat simulován. Definoval jsem celkem 10 stav˚ u a 1 chybov´ y stav pro u ´ˇcely ladˇen´ı, jejich v´ yˇcet je v tabulce 3. Základn´ı u ´kony jsem zobrazil ve v´ yvojovém diagramu 6. Pˇredposledn´ı blok je popsán jako Podle aktuáln´ıho stavu a ˇcasu simulace uloˇz do databáze nový stav. V´ ykon této operace je nejnároˇcnˇejˇs´ı a nejd˚ uleˇzitˇejˇs´ı, proto se budu nyn´ı zab´ yvat jej´ım popisem. Pˇredpokládejme, ˇze v pˇredchoz´ım kroku jsem z´ıskal z databáze informaci o tom, v kterém PE stavu se tento logick´ y blok potaˇzmo zaˇr´ızen´ı nacházel v minulém simulaˇcn´ım kroku. Podle toho se pak liˇs´ı reakce uˇzivatelské funkce na poˇzadovan´ y stav. Pop´ıˇsu ted’ tyto reakce. V programu jsem pouˇzil názvy stav˚ u, jak jsou uvedeny v tabulce 3 ve sloupci Název stavu. Pro stav Operating: • poˇzadovan´ y stav 6= Operating ⇒ nastav aktuáln´ı stav na Ready Pro stav Ready jsou 3 moˇzné v´ ystupy: • nastav ˇcasovou známku na aktuáln´ı ˇcas simulace • poˇzadovan´ y stav = PSaving ⇒ nastav aktuáln´ı stav na toPSaving 23


Obrázek 6: V´ yvojov´ y diagram simulace stavového automatu v uˇzivatelské funkci

• poˇzadovan´ y stav = Sleep ⇒ nastav aktuáln´ı stav na toSleep • poˇzadovan´ y stav = Operating ⇒ nastav aktuáln´ı stav na Operating Pro stav toPSaving: • (ˇcas simulace - ˇcasová známka) ≥ timeToPsaving ⇒ – nastav aktuáln´ı stav na mustPSaving – nastav ˇcasovou známku na aktuáln´ı ˇcas simulace Pro stav mustPSaving: • (ˇcas simulace - ˇcasová známka) ≥ timeMustPsaving ⇒ nastav aktuáln´ı stav na PSaving Pro stav PSaving: • poˇzadovan´ y stav = Ready ⇒ nastav aktuáln´ı stav na toReadyFromPSaving 24

ˇ SEN ˇ Í 3 RE

Název stavu

Název v PE diagramu

Operating

Operating

1

Ready

Ready to operate

0

toPSaving

Pˇrechod do Energy-saving

2

mustPSaving

Nezbytn´ y Energy-saving

3

PSaving

Energy-saving

4

toReadyFromPSaving

Pˇrechod do Ready to operate (z ID=4)

5

toSleep

Pˇrechod do Sleep mode WOL

6

mustSleep

Nezbytn´ y Sleep mode WOL

7

Sleep

Sleep mode WOL

8

toReadyFromSleep

Pˇrechod do Ready to operate (z ID=8)

9

errorState

ID v programu

10

Tabulka 3: Názvy stav˚ u ve v´ yˇctu enStates a jejich ekvivalent v diagramu 5 • poˇzadovan´ y stav = Sleep ⇒ nastav aktuáln´ı stav na toSleep • nastav ˇcasovou známku na aktuáln´ı ˇcas simulace Pro stav toReadyFromPSaving: • (ˇcas simulace - ˇcasová známka) ≥ timeToReadyFromPSaving ⇒ nastav aktuáln´ı stav na Ready Pro stav toSleep: • (ˇcas simulace - ˇcasová známka) ≥ timeToSleep ⇒ – nastav aktuáln´ı stav na mustSleep – nastav ˇcasovou známku na aktuáln´ı ˇcas simulace 25


Pro stav mustSleep: • (ˇcas simulace - ˇcasová známka) ≥ timeMustSleep ⇒ nastav aktuáln´ı stav na Sleep Pro stav Sleep: • poˇzadovan´ y stav = Ready ⇒ nastav aktuáln´ı stav na toReadyFromSleep • nastav ˇcasovou známku na aktuáln´ı ˇcas simulace Pro stav toReadyFromSleep: • (ˇcas simulace - ˇcasová známka) ≥ timeToReadyFromPSaving ⇒ nastav aktuáln´ı stav na Ready Pro pˇr´ıpadné pˇridáván´ı stav˚ u do stavového automatu je vhodné dodrˇzovat pravidlo, ˇze pˇri pˇrechodu do stavu, v nˇemˇz se následnˇe bude kontrolovat ˇcasová známka, je nutno ˇcasovou známku nastavit na aktuáln´ı ˇcas. Tak je zajiˇstˇeno, ˇze ˇcasovˇe závislá operace bude aktivn´ı jen po definovanou dobu. Jak je vidˇet, vˇsechny kontroly ˇcasové známky pˇredpokládaj´ı, ˇze ˇcas simulace bude neklesaj´ıc´ı. V prostˇred´ı PS je moˇzné v Sequence Editoru spustit simulaci pozpátku v reˇzimu CEE (cyclic event evaluation), coˇz m˚ uˇze b´ yt nejsp´ıˇs v nˇekter´ ych situac´ıch prospˇeˇsné, nicménˇe ve vˇetˇsinˇe pˇr´ıpad˚ u se tato funkce nevyuˇzije a implementace stavového automatu tak, aby fungoval i takto zpˇetnˇe, by se nevyrovnala vynaloˇzenému u ´sil´ı. Nav´ıc by kód pˇriˇsel do velké m´ıry o svoji pˇrehlednost. Pˇr´ıpady, kdy uˇzivatel pˇrejde v jiˇz jednou spuˇstˇené simulaci zpˇet, mus´ı uˇzivatel opravit manuálnˇe nastaven´ım stavového automatu do správného stavu, a pak opˇetovn´ ym spuˇstˇen´ım simulace. Pˇri takovém jednán´ı je ovlivnˇen i záznam stav˚ u, pokud byl pˇri této události aktivován, a jeho v´ ystup je tˇreba analyzovat. V záznamech bude v´ıce u ´daj˚ u ve stejném ˇcasovém intervalu, a to je znalost, kterou lze pˇri korekci dat vyuˇz´ıt. Záznamem stav˚ u se zab´ yvám podrobnˇe v kapitole 3.5.2. T´ım je uzavˇren blok Stavový automat v obrázku 2. Vzhledem k tomu, ˇze funkˇcnost stavového automatu pˇricház´ı do prostˇred´ı PS aˇz s uˇzivatelskou funkc´ı, nen´ı moˇzné dodrˇzet 26

ˇ SEN ˇ Í 3 RE

postup v´ yvoje pluginu, jak byl popsán v u ´vodu kapitoly. Konkrétnˇe se jedná o krok, kdy je nejprve prototyp funkˇcn´ı datové struktury manuálnˇe sestaven v prostˇred´ı PS, aby tak byla dokázána integrovatelnost a kompatibilita s PS. Sestavován´ı funkˇcn´ıho prototypu tedy pˇriˇslo na ˇradu aˇz po naprogramován´ı uˇzivatelské funkce. Po vyladˇen´ı uˇzivatelské funkce jsem pak mohl uˇz pˇristoupit k automatizaci sestaven´ı funkˇcn´ı struktury - logického bloku, v nˇemˇz je uˇzivatelská funkce pouˇzita. Na tomto m´ıstˇe je vhodné upozornit, ˇze tuto funkci lze k simulován´ı PE standardu pouˇz´ıt samostatnˇe bez dalˇs´ıch nástaveb, pokud uˇzivatel v´ı, jak tato funkce funguje. K praktickému hromadnému pouˇzit´ı je ale zapotˇreb´ı spravuj´ıc´ı nadstavbová aplikace, kterou popisuji v kapitole 3.5.

3.5

Process Simulate Command

Pˇredstava, ˇze by uˇzivatel mˇel provést manuálnˇe des´ıtky mal´ ych krok˚ u pro kaˇzdé zaˇr´ızen´ı, kterému chce pˇriˇradit chován´ı podle PROFIenergy standardu, je pˇrinejmenˇs´ım odrazuj´ıc´ı. Pro pohodlné pouˇzit´ı pluginu je také nutné uˇzivateli dodat uˇzivatelské rozhran´ı konzistentn´ı s tˇemi, na které je v rámci nadˇrazené aplikace zvykl´ y. Na programu Process Simulate je znát, ˇze je sloˇzen z velkého mnoˇzstv´ı d´ılˇc´ıch aplikac´ı, které p˚ uvodnˇe stály samostatnˇe, a konzistence uˇzivatelsk´ ych rozhran´ı nen´ı ani v nˇem plnˇe dodrˇzena. Má vˇsak spoleˇcné prvky a zdá se b´ yt logické, ˇze jeho v´ yvojáˇri maj´ı tendenci smˇeˇrovat k urˇcitému sjednocen´ı vzhledu a ovládán´ı. Jedn´ım z bod˚ u zadán´ı práce také bylo naprogramovat SW modul pro pˇrenáˇsen´ı extern´ıch dat z a do prostˇred´ı Process Simulate. V pr˚ ubˇehu ˇreˇsen´ı práce vznikl konkrétnˇejˇs´ı poˇzadavek na umoˇznˇen´ı exportovat ˇcasov´ y záznam otoˇcen´ı kloub˚ u vybran´ ych robot˚ u ze simulace do souboru. Vˇsechny tyto poˇzadavky lze splnit v rámci moˇznost´ı Tecnomatix.NET API pomoc´ı tzv. command. Je to funkce typická pro tlaˇc´ıtko - uˇzivatel klikne na tlaˇc´ıtko, a to vyvolá sled nˇejak´ ych akc´ı. Kdyˇz je akce jednou dokonˇcena, nen´ı command aktivn´ı, dokud uˇzivatel opˇet neklikne na tlaˇc´ıtko. Command také umoˇzn ˇuje vytváˇret komplexnˇejˇs´ı uˇzivatelské rozhran´ı neˇz jen jedno tlaˇc´ıtko, umoˇzn ˇuje pouˇz´ıt vˇetˇsinu GUI (graphical user interface) prvk˚ u, které v prostˇred´ı PS najdeme. 27

3.5 Process Simulate Command

3.5.1

Pˇ riˇ razen´ı logick´ eho bloku

Pro simulován´ı PE standardu je nutné pouˇz´ıt logick´ y blok, kter´ y umoˇzn´ı pouˇz´ıt uˇzivatelskou funkci na sv˚ uj vnitˇrn´ı parametr ˇci na sv˚ uj v´ ystup. V PS lze logick´ y blok vytvoˇrit zcela samostatnˇe bez návaznosti na kter´ ykoli objekt ve studii. Z objektového hlediska nelze m´ıt samostatnˇe stoj´ıc´ı paraleln´ı strom objekt˚ u s nezávisl´ ym koˇrenem, vˇsechny objekty mus´ı m´ıt spoleˇcného pˇredka, ˇci majitele. Logick´ y blok je povaˇzován za modelovac´ı objekt a pˇri jeho samostatném vytvoˇren´ı se zaˇrad´ı jako potomek ˇci majetek statické vlastnosti LogicalRoot náleˇzej´ıc´ı statické tˇr´ıdˇe TxDocument. Takto samozˇrejmˇe lze také v logickém bloku simulovat PE standard, a t´ım simulovat nˇejak´ y virtuáln´ı objekt, kter´ y nen´ı ve studii vidˇet. Praktiˇctˇejˇs´ı je vˇsak pouˇz´ıt moˇznost pˇriˇradit logick´ y blok objektu, kter´ y tuto moˇznost podporuje. Obecnˇe kaˇzd´ y objekt implementuj´ıc´ı rozhran´ı ITxPlcLogicResource m˚ uˇze dostat logick´ y blok pˇriˇrazen. Prakticky toto rozhran´ı poˇzaduje pouze dvˇe vˇeci - zaprvé implementaci vlastnosti LogicBehavior, v n´ıˇz se ukládá reference na objekt logického bloku, a zadruhé implementaci veˇrejné metody CopySelfLogicToOtherLogicResource. Logick´ y blok je v API zastoupen tˇr´ıdou TxPlcLogicBehavior. Pro potˇreby programován´ı pluginu nás vˇsak nebude pˇr´ıliˇs zaj´ımat, které objekty mohou logick´ y blok pojmout, ani nebudeme mnoˇzinu takov´ ych objekt˚ u rozˇsiˇrovat. V zadán´ı práce je urˇceno, ˇze standard PROFIenergy má b´ yt aplikován na model robota v PS, takˇze stˇredem naˇseho zájmu je tˇr´ıda TxRobot, která rozhran´ı ITxPlcLogicResource implementuje, ˇc´ımˇz je základn´ı poˇzadavek splnˇen a dále se o nˇej nen´ı tˇreba starat. Pro logick´ y blok plat´ı jeˇstˇe dalˇs´ı zvláˇstnost, a totiˇz dokud nen´ı jeho vstup ˇci v´ ystup pˇripojen na signál, nen´ı blok se zárukou simulována a je v jakési latentn´ı fázi. Kdyˇz uˇzivatel chce simulovat PE standard, stejnˇe mus´ı k bloku pˇripojit ˇr´ıdic´ı signály, ˇc´ımˇz simulaci bloku aktivuje. Prototyp logického bloku je zobrazen v diagramu na obrázku 7. Zde zobrazené parametry, vstupy a v´ ystupy jsou jen poˇzadované minimum, uˇzivatel m˚ uˇze logick´ y blok rozˇs´ıˇrit o libovolnou dalˇs´ı funkˇcnost (vstupy, parametry atd.), dokud se zmˇeny nedotknou zde uveden´ ych prvk˚ u, nebude dotˇcena ani PE funkˇcnost. Máme tedy prototyp, command mus´ı jen tento prototyp sestavit, správnˇe propojit vnitˇrn´ı promˇenné a nastavit konstanty 28

ˇ SEN ˇ Í 3 RE

Obrázek 7: Prototyp logického bloku

na poˇzadované hodnoty. Tady uvedu zjednoduˇsen´ y UML diagram tˇr´ıd pluginu 8. Neuvád´ım v´ yˇcet metod tˇr´ıd, pouze v´ yˇcet vnitˇrn´ıch promˇenn´ ych tˇr´ıd.

Obrázek 8: UML diagram commandu

Pˇriˇrazen´ı logického bloku objektu robotu prob´ıhá následovnˇe. Nejprve je zkontrolováno, zda robot uˇz má pˇriˇrazen´ y logick´ y blok. Pokud ano, pracuje s t´ımto logick´ ym blokem, pokud ne, je vytvoˇren nov´ y logick´ y blok (instance tˇr´ıdy TxPlcLogicBehavior ). Vytvoˇren´ı instance tˇr´ıdy TxPlcLogicBehavior nelze provést prost´ ym volán´ı kontruktoru tˇr´ıdy. Instanci lze vytvoˇrit jen pomoc´ı továrn´ı metody CreateLogicBehavior( TxPlcLogicBehaviorCreationData data ) zavolané na instanci objektu implementuj´ıc´ıho rozhran´ı ITxPlcLogicBehaviorCre29


ation. Vstupn´ım parametrem je instance tˇr´ıdy TxPlcLogicBehaviorCreationData, kterou uˇz lze vytvoˇrit obvykl´ ym volán´ım konstruktoru tˇr´ıdy. V této instanci je nutné pˇred jej´ım pouˇzit´ım nastavit vˇsechny parametry, které chceme nastavit instanci TxPlcLogicBehavior, pozdˇejˇs´ı zmˇeny parametr˚ u jiˇz existuj´ıc´ı instance tˇr´ıdy TxPlcLogicBehavior vedou k nestabilitˇe prostˇred´ı PS. Tento postup vytváˇren´ı objekt˚ u, kdy se nejprve vytvoˇr´ı datov´ y objekt, kter´ y vnáˇs´ı do továrn´ı metody inicializaˇcn´ı informace, je v Tecnomatix.NET API zaveden´ ym standardem a principiálnˇe je vˇzdy stejn´ y. Pouˇzit´ı továrn´ıch metod zde má zajistit, ˇze uˇzivatel nebude vytváˇret sirotˇc´ı objekty - tedy objekty, které by nemˇely svého majitele. Poté se otevˇre .csv soubor, v nˇemˇz jsou uloˇzeny ˇcasy pˇrechod˚ u mezi PE stavy a naˇctou se hodnoty ˇcasov´ ych konstant s pevnˇe dan´ ymi jmény, jak jsou uvedena v tabulce 2 v prvn´ım sloupci Název parametru. Soubor je ve formátu .csv, hodnoty jsou oddˇelené ˇcárkou a pro neceloˇc´ıselné hodnoty je pouˇzita desetinná teˇcka. V prvn´ım sloupci je pevnˇe dan´ y název ˇcasové konstanty, v druhém sloupci pak jej´ı hodnota. Dalˇs´ı sloupce na ˇra´dku jsou ignorovány. Poˇrad´ı ˇrádk˚ u m˚ uˇze b´ yt libovolné a v pˇr´ıpadˇe, ˇze se na ˇra´dku vyskytuje neznám´ y název ˇcasové konstanty, je tento záznam ignorován. Vˇsechny nenalezené ˇcasové konstanty jsou v logickém bloku nastaveny na hodnotu 0. Pˇr´ıklad obsahu souboru je vidˇet ve v´ ypisu 1. V logickém bloku se pak hledaj´ı podle jména v´ yskyty konstant (instance tˇr´ıdy TxPlcLo

timeToPsaving, 5.3 timeMustPsaving, 0 timeMustSleep, 10.0 timeToReadyFromSleep, 50

V´ ypis 1: Pˇr´ıklad obsahu .csv souboru s PE ˇcasován´ım

gicBehaviorConstant), procház´ı se pole konstant, jehoˇz adresa je uloˇzena ve vlastnosti logického bloku Constants. Pokud je nalezen prvn´ı v´ yskyt daného jména konstanty, které odpov´ıdá názvu konstanty z .csv souboru s ˇcasován´ım, pˇriˇrad´ı se jej´ı vlastnosti Value pˇr´ısluˇsná hodnota ze souboru. Pokud konstanta nen´ı v logickém bloku nastavena, je vytvoˇrena jej´ı nová instance s názvem, kter´ y nebyl nalezen. Opˇet mus´ı b´ yt pouˇzita továrn´ı funkce instance tˇr´ıdy TxPlcLogicBehavior s názvem CreateConstant za pouˇz´ıt´ı Creation30

ˇ SEN ˇ Í 3 RE

Data, ve stejném smyslu, jako pˇri vytváˇren´ı instance logického bloku. Stejn´ ym zp˚ usobem se pak vyhledává konstanta blockID, a pokud nebyla nalezena, vytvoˇr´ı se s nulovou hodnotou. Nastaven´ı konstanty blockID je tenké m´ısto pluginu v souˇcasném stavu. Jak jsem vysvˇetlil dˇr´ıve, mus´ı to b´ yt unikátn´ı hodnota alespoˇ n v rámci jednoho kaˇzdého bˇehu simulace. Pˇripomenu také, ˇze PS je objektovˇe orientované modelovac´ı prostˇred´ı. Aby bylo moˇzné manuálnˇe vytvoˇrit logick´ y blok a pˇriˇradit ho zaˇr´ızen´ı, které to umoˇzn ˇuje, mus´ı b´ yt toto zaˇr´ızen´ı pˇrepnuto do tzv. modelovac´ıho módu. V tomto módu jsou umoˇznˇeny zmˇeny 3D modelu objektu a zmˇeny logického bloku, to jsou oboj´ı data uloˇzená v souboru .cojt na sd´ıleném u ´loˇziˇsti digitáln´ı továrny (Tecnomatixu), a m˚ uˇzeme vyuˇz´ıt pˇredstavu, ˇze otevˇren´ım objektu pro modelován´ı se upravuje lokáln´ı doˇcasná kopie tˇechto dat. Uzavˇren´ım modelován´ı objektu tato data pak pˇrep´ıˇs´ı ta p˚ uvodn´ı zdrojová. Protoˇze by bylo datovˇe nároˇcné ukládat do samostatného .cojt souboru kaˇzdou instanci modelovac´ıho objektu v PS, naˇc´ıtaj´ı se pro vˇsechny instance 3D data a pˇriˇrazen´ y logick´ y blok z jednoho rodiˇcovského souboru. Kdyˇz se ted’ vrát´ım zpˇet a zopakuji, ˇze potˇrebuji pro kaˇzdou instanci robota jednoho typu unikátn´ı konstantu, která je uloˇzena v .cojt zdrojovém souboru, je jasné, ˇze pˇri manuáln´ım vytvoˇren´ı a uloˇzen´ı logického bloku (ukonˇcen´ım modelovac´ıho módu objektu) se pˇrep´ıˇs´ı vˇsem ostatn´ım v´ yskyt˚ um instanc´ı tohoto objektu hodnoty konstant blockID na tu posledn´ı nastavenou hodnotu. U ˇcasov´ ych konstant je to vhodné chován´ı, ale pro ID je to problém. Pˇrijal jsem tedy fakt, ˇze po uloˇzen´ı jsou hodnoty blockID pro vˇsechna zaˇr´ızen´ı s PE funkˇcnost´ı stejné. Musel jsem tedy vytvoˇrit funkci, která projde dotˇcená zaˇr´ızen´ı a zajist´ı unikátn´ı blockID. Zjistil jsem, ˇze pomoc´ı API lze mˇenit nastaven´ı logick´ ych blok˚ u, aniˇz by bylo zaˇr´ızen´ı otevˇreno pro modelován´ı, a po dokonˇcen´ı nastaven´ı si kaˇzdé zaˇr´ızen´ı drˇz´ı ID, které mu bylo nastaveno. Je to t´ım, ˇze sjednocen´ı hodnot je vyvoláno aˇz pˇr´ıkazem k ukonˇcen´ı modelován´ı, a protoˇze objekt v˚ ubec nebyl pro modelován´ı otevˇren, ke sjednocován´ı nedojde. Prostˇred´ı PS si pro obdob´ı, kdy má naˇctenou studii, vytvoˇr´ı v pamˇeti doˇcasné kopie objekt˚ u a data v nich uchovává v kaˇzdém tomto objektu zvláˇst’, proto je toto chován´ı moˇzné. 31


Napsal jsem tedy skript, kter´ y projde vˇsechny instance tˇr´ıdy TxPlcLogicBehavior ve studii a pokud v nich nalezne konstantu s názvem blockID, pˇrenastav´ı jej´ı hodnotu tak, ˇze ˇc´ısluje tato zaˇr´ızen´ı od nuly vzestupnˇe. Dokud uˇzivatel neotevˇre pro modelován´ı a opˇet nezavˇre nˇekter´ y dotˇcen´ y objekt, z˚ ustávaj´ı ID unikátn´ı. Tento skript probˇehne pˇred kaˇzd´ ym spuˇstˇen´ım simulace, ale pro pˇr´ıpad ˇspatného pouˇzit´ı pluginu jsem umoˇznil uˇzivateli toto pˇreˇc´ıslován´ı vyvolat i nezávisle na simulaci. T´ım jsou hotovy konstanty logického bloku. Dalˇs´ı se vyhledá parametr s názvem requestedStateID, nen´ı-li nalezen, je vytvoˇren obdobn´ ym postupem, jako konstanta nebo logick´ y blok. To, ˇze poˇzadovaný PE stav v diagramu na obrázku 7 je vstup, kter´ y nevede pˇr´ımo do uˇzivatelské funkce PEStateMach, má sv˚ uj d˚ uvod. Obecnˇe m˚ uˇze uˇzivatel doj´ıt k v´ yslednému poˇzadovanému PE stavu i za pomoci sestaven´ı nˇejaké vnitˇrn´ı logiky v logickém bloku. Kdyby vstup pˇr´ımo vedl do PEStateMach, vedlo by to k jeho vˇetˇs´ımu omezen´ı. Dalˇs´ı je na ˇradˇe parametr currentState, pokud nebyl nalezen, vytvoˇr´ı se a do nˇej se vloˇz´ı uˇzivatelská funkce. Postup pro to je komplikovanˇejˇs´ı, jeho schématické zobrazen´ı je na obrázku 9. Pro pouˇzit´ı uˇzivatelské funkce pomoc´ı API je tˇreba pˇripravit pomˇernˇe komplikovan´ y datov´ y objekt, kter´ y slouˇz´ı jako nosiˇc parametr˚ u pro továrn´ı funkci vytváˇrej´ıc´ı instanci uˇzivatelské funkce. V popisu budu postupovat zvnˇejˇsku struktury dovnitˇr. Pˇredpokládejme, ˇze mám instanci parametru logického bloku. Tato instance má vlastnost názvu Expression, typu TxPlcExpression. Do této vlastnosti se ukládá objekt, kter´ y lze z´ıskat jedinˇe z vlastnosti Expression objektu typu TxPlcExpressionBuilder. Tento objekt lze vytvoˇrit pˇr´ımo konstruktorem a jeho vlastnost Expression je naplnˇena pomoc´ı volán´ı jeho metody Add. T´ım se sestav´ı cel´ y matematickologick´ y v´ yraz. Potˇrebujeme do expressionBuilderu dosadit naˇsi uˇzivatelskou funkci. To se provede pˇret´ıˇzenou verz´ı metody Add( ”PEStateMach”, seznamParametru ). Prvn´ı parametr metody Add je atribut, kter´ y jsme pˇriˇradili naˇs´ı uˇzivatelské funkci v kapitole 3.4.1, PS engine podle nˇej vyhledá pˇr´ısluˇsnou tˇr´ıdu a pouˇzije ji k v´ ypoˇctu. Druh´ ym parametrem metody Add je seznamParametru typu ArrayList. ArrayList je podobnˇe jako Dictionary generická tˇr´ıda a nezáleˇz´ı j´ı na typu objektu v n´ı uloˇzeném, ale pˇresto v tomto pˇr´ıpadˇe v nˇem mus´ı b´ yt uloˇzen´ y typ TxPlcFunctionPara32

ˇ SEN ˇ Í 3 RE

Obrázek 9: Postup vytvoˇren´ı uˇzivatelské funkce pomoc´ı API

meterData, jehoˇz instance je moˇzno vytvoˇrit pˇr´ım´ ym volán´ım jeho konstruktoru. Instance této tˇr´ıdy disponuj´ı deseti metodami, které j´ı nastavuj´ı funkci. M˚ uˇze to b´ yt funkce vstupu, konstanty, parametru, ˇci v´ ystupu logického bloku a dalˇs´ı. Vˇsechny potˇrebné konstanty a parametry jsou zaˇrazeny do ArrayListu oznaˇcenému jako seznamParametru, a pak je Expression vyvolán v jediném volán´ı vlastnosti expressionBuilderu. Je na m´ıstˇe upozornit na zvláˇstnosti chován´ı vlastnosti Expression, a totiˇz ˇze v okamˇziku vyvolán´ı jej´ı hodnoty je jej´ı obsah smazán, takˇze tuto hodnotu lze vyvolat pouze jednou, o jej´ı zachycen´ı se mus´ı programátor postarat. Druhé u ´skal´ı spoˇc´ıvá v pouˇzit´ı instanc´ı tˇr´ıdy TxPlcFunctionParameterData - pro kaˇzd´ y ”symbol”mus´ı b´ yt vytvoˇrena nová instance této tˇr´ıdy, jinak by v ArrayListu byl uloˇzen´ y jen seznam ukazatel˚ u na stejnou instanci a vˇsechny vstupn´ı parametry uˇzivatelské funkce by byly stejné jako posledn´ı pˇridan´ y parametr. 33


Na konci provádˇen´ı celé sekvence se do stavového ˇra´dku prostˇred´ı PS vyp´ıˇse zpráva o dokonˇcen´ı u ´lohy. D´ıky tomu, jak je tato sekvence napsána, se pˇri jej´ım opakovaném spouˇstˇen´ı neduplikuj´ı ˇza´dné vnitˇrn´ı parametry logického bloku, a pouze se pˇrenastavuj´ı hodnoty konstant a pˇr´ıpadnˇe se oprav´ı naruˇsené pospojován´ı uvnitˇr bloku.

3.5.2

Z´ aznam PE stav˚ u robot˚ u

P˚ uvodnˇe jsem zam´ yˇslel zaznamenávat PE stavy pˇr´ımo v m´ıstˇe, kde se o nich rozhoduje v pr˚ ubˇehu simulace, to je v tˇr´ıdˇe uˇzivatelské funkce, abych pˇr´ıliˇs nezvyˇsoval v´ ypoˇcetn´ı nároky na kaˇzd´ y krok simulace. Takové ˇreˇsen´ı naráˇz´ı na zásadn´ı problém, a totiˇz nen´ı moˇzné na okamˇzit´ y pˇr´ıkaz uˇzivatele tento záznam uloˇzit do souboru. Bylo by sice moˇzné zavést do uˇzivatelské funkce dalˇs´ı vstupn´ı parametr, kter´ y by spouˇstˇel akci uloˇzen´ı do souboru, ale tato akce by mohla probˇehnout jedinˇe v pr˚ ubˇehu bˇeˇz´ıc´ı simulace, jindy funkce nen´ı vyhodnocována. Ukládán´ı pˇri bˇeˇz´ıc´ı simulaci se rozcház´ı s filozofi´ı prostˇred´ı PS, takˇze tento postup jsem zavrhl. Pˇri zkoumán´ı chován´ı událost´ı jsem na tomto m´ıstˇe také zjistil, ˇze v API nefunguj´ı události vyvolané koncem ˇci zaˇca´tkem simulace. Pˇristoupil jsem tedy k jinému ˇreˇsen´ı. Idea je taková, ˇze databáze vˇsech záznam˚ u PE stav˚ u bude uloˇzena v objektu commandu, a uˇzivatel tak bude moci se záznamy manipulovat obvykl´ ym zp˚ usobem, nejen pˇri bˇeˇz´ıc´ı simulaci. Bude se ovˇsem muset kaˇzd´ y krok simulace jednak simulovat PE stavov´ y automat a jednak zachytávat na v´ ystupu logického bloku informaci o aktuáln´ım PE stavu v daném kroku simulace. To ale nen´ı pˇr´ıliˇs v´ yznamné zv´ yˇsen´ı v´ ypoˇcetn´ı zátˇeˇze, pˇri testován´ı na tˇrech robotech simulovan´ ych souˇcasnˇe nebyl rozpoznateln´ y rozd´ıl v zat´ıˇzen´ı pouˇzitého hardwaru. Protoˇze v bˇeˇz´ıc´ım PS m˚ uˇze existovat pouze jedna instance commandu, bude uchovávaná databáze také jediná a záznamy vˇsech robot˚ u v této datábázi mus´ı b´ yt indexovány pro jednotlivé roboty. Protoˇze command pˇristupuje k cel´ ym objekt˚ um a nemus´ı se podˇrizovat ˇzádn´ ym omezen´ım datov´ ych typ˚ u na rozhran´ı, m˚ uˇze pouˇz´ıt jako popisovaˇc robot˚ u jejich atribut z eMServeru - jejich external ID. D´ıky tomu je indexován´ı logiˇctˇejˇs´ı a také pˇrehlednˇejˇs´ı. Databázi stav˚ u v commandu realizuje opˇet instance generické tˇr´ıdy Dictionary s deklarac´ı typové dvojice hkl´ıˇc, prveki jako 34

ˇ SEN ˇ Í 3 RE

hstring, ArrayListi. Pˇritom v pol´ıˇcku kl´ıˇc je zmiˇ nované extern´ı ID a v ArrayListu je uloˇzen seznam záznam˚ u ve formˇe instanc´ı mé tˇr´ıdy PEStatesRecord. V kaˇzdé instanci záznamu je uloˇzena ˇcasová známka a k n´ı pˇr´ısluˇsn´ y PE stav, respektive jeho ID. Seznam jmen PE stav˚ u a jejich ID je vidˇet v tabulce 3. Metoda, v n´ıˇz se záznam v kroc´ıch simulace provád´ı, je zaregistrována jako posluchaˇc události SimulationPlayer.TimeIntervalReached, pˇriˇcemˇz vlastnost SimulationPlayer typu TxSimulationPlayer je dostupná ze statické tˇr´ıdy TxApplication - z vlastnosti ActiveDocument. Registrován´ım a odregistrován´ım metody jako posluchaˇce této události je ovládáno zahájen´ı a ukonˇcen´ı nahráván´ı PE stav˚ u. Naplnˇenou databázi je pak moˇzné uloˇzit do souboru, aby simulovaná data mohla b´ yt pˇredána dále k extern´ı anal´ yze. Dohodli jsme se na formátu .csv, pˇriˇcemˇz pro kaˇzd´ y robot je vytvoˇren samostatn´ y .csv soubor. Jednotlivé soubory jsou pojmenovány extern´ım ID pˇr´ısluˇsn´ ych robot˚ u, ˇc´ımˇz je zachována filozofie soubor˚ u prostˇred´ı PS. Prvn´ı ˇra´dek souboru obsahuje ˇca´rkou oddˇelené popisy sloupc˚ u. Dále pak jsou v prvn´ım sloupci ˇcasové známky a v druhém sloupci ID PE stavu podle tabulky 3. Pro neceloˇc´ıselné hodnoty je pouˇzita desetinná teˇcka. Uˇzivatel si m˚ uˇze pˇri vyvolán´ı pˇr´ıkazu uloˇzen´ı vybrat um´ıstˇen´ı souboru, pˇr´ıpadnˇe je uloˇzen záznam automaticky do osobn´ı sloˇzky uˇzivatele momentálnˇe pˇrihláˇseného do systému Windows. V osobn´ı sloˇzce je vytvoˇren adresáˇr s názvem TecnomatixPEpluginData a v nˇem je vytvoˇrena sloˇzka s aktuáln´ım datem, pokud uˇz tam pˇredt´ım tato adresáˇrová struktura nebyla, uloˇz´ı se do této sloˇzky vˇsechny .csv soubory s názvy extern´ıch ID sledovan´ ych robot˚ u. Pokud uˇz tam adresáˇrov´ y strom se sloˇzkou s aktuáln´ım datem existoval, .csv soubory se stejn´ ym jménem se pˇrep´ıˇs´ı.

3.5.3

Z´ aznam polohy kloub˚ u robot˚ u

Záznam poloh kloub˚ u robot˚ u jsem ˇreˇsil stejn´ ym pˇr´ıstupem jako záznam PE stav˚ u. Princip se liˇs´ı v nˇekolika detailech. Zaznamenávaná data nejsou typu signálu vystupuj´ıc´ıho z logického bloku, ale typu TxPoseData. Instance této tˇr´ıdy má jen jednu vlastnost - JointValues - a v této vlastnosti ukládá ArrayList se seznamem aktuáln´ıch hodnot poloh kloub˚ u robota. Tyto hodnoty maj´ı typ double a pro u ´hlové hodnoty maj´ı rozmˇer v radiánech. 35


Vytváˇren´ı záznamu jsem ˇreˇsil opˇet v metodˇe, která je registrována jako posluchaˇc události SimulationPlayer.TimeIntervalReached. Aktivuje se také registrován´ım a deaktivuje odregistrován´ım metody jakoˇzto posluchaˇce, stejnˇe jako pˇri záznamu PE stav˚ u. V kaˇzdém kroku simulace se ukládá do databáze tvoˇrené pomoc´ı Dictionaryhstring, ArrayListi do seznamu u kl´ıˇce extern´ıho ID robota instance datového záznamu mé tˇr´ıdy JointsRecord, která v sobˇe uchovává dvˇe vlastnosti - ˇcasovou známku a ArraList, do nˇehoˇz se ukládá v´ yˇse zm´ınˇen´ y seznam JointValues s hodnotami natoˇcen´ı kloub˚ u robotu. Uloˇzen´ı dat z databáze je opˇet velmi podobné principu z pˇredchoz´ı kapitoly 3.5.2. Rozd´ıl je v tom, ˇze robot m˚ uˇze m´ıt obecnˇe r˚ uzn´ y poˇcet kloub˚ u, a tak .csv soubor, do nˇehoˇz data ukládám, m˚ uˇze m´ıt r˚ uzn´ y poˇcet sloupc˚ u. Soubor na prvn´ım ˇrádku obsahuje ˇca´rkami oddˇelené popisky sloupc˚ u a v dalˇs´ıch ˇra´dc´ıch data. V prvn´ım sloupci je vˇzdy ˇcasová známka a v dalˇs´ıch sloupc´ıch jsou pak hodnoty jednotliv´ ych kloub˚ u seˇrazené tak, jak jsou seˇrazené v seznamu JointValues v prostˇred´ı PS. Desetinn´ y oddˇelovaˇc je desetinná teˇcka. Pro upevnˇen´ı pˇredstavy o architektuˇre programu doporuˇcuji nahlédnout do pˇriloˇzené dokumentace programu pluginu, kde je funkce kaˇzdé metody popsána. Zde uvedené vysvˇetlen´ı doprováz´ı UML diagram na obrázku 8.

3.5.4

Grafick´ e uˇ zivatelsk´ e rozhran´ı

Kdyˇz je funkˇcnost programu implementována a byla navrˇzena i pˇredstava o postupu uˇzivatele pˇri pouˇzit´ı programu, je dalˇs´ım krokem vytvoˇren´ı uˇzivatelského rozhran´ı. Pro pouˇzit´ı standardn´ıch grafick´ ych ovládac´ıch prvk˚ u v prostˇred´ı PS je v Tecnomatix.NET API dostupná knihovna Tecnomatix.Engineering.Ui.dll. Tento soubor lze naj´ıt v instalaˇcn´ım adresáˇri ../Tecnomatix/eMPower a po nastaven´ı reference na nˇej v programovac´ım prostˇred´ı MS Visual Studio je pak zpˇr´ıstupnˇen GUI Designer, s jehoˇz pomoc´ı lze efektivnˇe vytváˇret GUI commandu. Upozorn´ım zde ale, ˇze GUI Designer pro knihovnu komponent Tecnomatix.UI je dostupn´ y jen pro 32bitovou verzi knihovny, tedy jen pro 32bitovou verzi Tecnomatixu. V rámci testován´ı jsem vyzkouˇsel, jak m˚ uj plugin funguje na 64bitové verzi Tecnomatix, kdyˇz byl zkompilován s 32bitov´ ymi knihovnami. Plugin fungoval normálnˇe, 36

ˇ SEN ˇ Í 3 RE

jen nˇekteré grafické prvky nebyly zcela správnˇe napozicovány, ovˇsem rozd´ıl byl minimáln´ı. Co se t´ yˇce vnitˇrn´ı funkˇcnosti pluginu, funguje bez problém˚ u, ale takovéto pouˇzit´ı kˇr´ıˇzem 32bit na 64bit je samozˇrejmˇe funkˇcn´ı bez jak´ ychkoli záruk. Tuto komplikaci jsem obeˇsel tak, ˇze kdyˇz jsem dokonˇcil veˇskeré grafické u ´pravy rozhran´ı, pˇripojil jsem ke kódu 64bitovou knihovnu Tecnomatixu a pˇreloˇzil jsem plugin naslepo bez zobrazen´ı GUI. T´ım by mˇela b´ yt vnitˇrn´ı funkˇcnost opˇet zaruˇcena, dan´ı za to je nutnost kompilovat dvˇe verze v´ ysledného pluginu. Uˇzivatelské rozhran´ı pluginu do znaˇcné m´ıry respektuje navrˇzenou architekturu z obrázku 2. Na stranˇe commandu má plugin dvˇe základn´ı funkce - nastaven´ı vlastnost´ı zaˇr´ızen´ı pro simulaci PE standardu a záznam simulace. Záznam simulace má pak dva pododd´ıly - záznam kloub˚ u robot˚ u a záznam PE stav˚ u. Na obrázku 10 je vidˇet formuláˇr pluginu. Záloˇzka Setting

Obrázek 10: GUI - záloˇzka nastaven´ı ˇci vytvoˇren´ı logického bloku pro PE

& Creating obsahuje nástroje po pˇriˇrazen´ı PE standardu vybran´ ym robot˚ um. Sekce PE 37


logic controls obsahuje pole pro hromadné vyb´ırán´ı objekt˚ u popsané titulkem Objects, v textu budu tento typ grafické komponenty oznaˇcovat jako Picking List. Toto pole funguje tak, ˇze uˇzivatel do nˇej nejprve klikne kurzorem, t´ım se zamkne zamˇeˇren´ı na toto pole, a pak zaˇcne klikat kdekoli v prostˇred´ı PS na roboty, kter´ ym bude cht´ıt pˇriˇradit PE funkˇcnost. Vˇsechny zakliknutné objekty se pˇridávaj´ı do tohoto pole. Pˇri vyb´ırán´ı se aplikuje na oznaˇcené objekty filtr, kter´ y umoˇzn ˇuje pˇridávat pouze roboty. Kdyˇz jsou vybráni vˇsichni roboti, uˇzivatel pomoc´ı tlaˇc´ıtka Browse... v doln´ı ˇca´sti okna vybere .csv soubor s PE ˇcasován´ım. Stiskem tlaˇc´ıtka Assign PE module pak spust´ı pˇr´ıkaz k vygenerován´ı ˇci pˇrenastaven´ı logického bloku, pˇriˇcemˇz ˇcasové konstanty jsou nastaveny podle vybraného souboru s PE ˇcasován´ım. Pokud soubor s ˇcasován´ım nebyl vybrán nebo na dané cestˇe neexistuje, objev´ı se chybová hláˇska (obrázek 11) oznamuj´ıc´ı, ˇze ˇcasové konstanty byly nastaveny na nulové hodnoty, PE funkˇcnost je ale pˇresto vytvoˇrena. Jeˇstˇe zde je zaˇskrtávac´ı

Obrázek 11: GUI - chybová hláˇska - cesta k souboru neexistuje

pol´ıˇcko Apply on selected only - pokud je zaˇskrtnuté, aplikuje se pˇriˇrazen´ı PE funkˇcnosti jen na roboty oznaˇcené v Picking Listu, roboti, co se nacház´ı v Picking Listu, ale nejsou tam oznaˇceni, jsou ignorováni. Posledn´ı je tlaˇc´ıtko Overwrite IDs, stiskem tohoto tlaˇc´ıtka se provede pˇrepsán´ı konstant blockID ve vˇsech logick´ ych bloc´ıch tak, aby byla zajiˇstˇena jejich unikátnost - tuto funkci jsem popisoval v kapitole 3.4.2. Nen´ı nutné m´ıt oznaˇcené ˇza´dné roboty, aby tato funkce v poˇra´dku probˇehla. Druhá záloˇzka obsahuje nástroje pro ovládán´ı záznamu simulace. Jsou zde vidˇet dvˇe sekce - Robot Joints logging controls, v n´ıˇz jsou nástroje k ovládán´ı záznamu poloh kloub˚ u robot˚ u, a PE States logging controls pro záznam PE simulace. Obˇe sekce funguj´ı velice po38

ˇ SEN ˇ Í 3 RE

Obrázek 12: GUI - záloˇzka k ovládán´ı záznamu dat ze simulace

dobnˇe. Obsahuj´ı Picking List pole pro v´ ybˇer robot˚ u, které se maj´ı sledovat v záznamu, trojici tlaˇc´ıtek a nˇekolik zaˇskrtávac´ıch pol´ıˇcek. Tlaˇc´ıtka Start Capturing... zapne naslouchán´ı dat˚ um, ale nespust´ı samo simulaci, tu mus´ı uˇzivatel bˇeˇzn´ ym zp˚ usobem spustit sám. Kdyˇz je toto tlaˇc´ıtko stisknuto, znepˇr´ıstupn´ı se a naopak vedlejˇs´ı tlaˇc´ıtko Stop se povol´ı. Podle pˇr´ıstupnosti tlaˇc´ıtka uˇzivatel pozná, zda je záznam aktivovan´ y, ˇci nikoli. Stiskem Stop se záznam deaktivuje, ale simulace se nezastav´ı, pokud v dobˇe stisku bˇeˇzela. Doporuˇcuji simulaci nejprve zastavit a aˇz potom stisknout tlaˇc´ıtko Stop - v tomto duchu se nese filozofie ovládán´ı PS, je vhodné ji dodrˇzovat. Nicménˇe nen´ı nezbytnˇe nutné se t´ımto doporuˇcen´ım ˇr´ıdit, záznam je v poˇrádku i kdyˇz se deaktivuje pˇri bˇeˇz´ıc´ı simulaci. 39

3.6 Postup pˇri aplikaci pluginu

Dalˇs´ı tlaˇc´ıtko Save... se chová podle zaˇskrtnut´ı pol´ıˇcka Save in Documents - pokud je pol´ıˇcko zaˇskrtnuto, pak stisk tlaˇc´ıtka uloˇz´ı záznamy do automatické adresáˇrové struktury v osobn´ı sloˇzce pˇrihláˇseného uˇzivatele Windows. Pokud pol´ıˇcko zaˇskrtnuté nen´ı, stisk tlaˇc´ıtka vyvolá dialogové okno pro v´ ybˇer sloˇzky, v n´ıˇz se uloˇz´ı sada soubor˚ u se záznamy. Zaˇskrtávac´ı tlaˇc´ıtka Focus only on selected jsou brány v potaz jen v okamˇziku aktivován´ı záznamu dat. Rozhoduj´ı o tom, zda se záznam aktivuje jen pro vybranou podmnoˇzinu robot˚ u v pˇr´ısluˇsném Picking Listu, nebo jestli se aktivuje pro vˇsechny roboty v pˇr´ısluˇsném Picking Listu. V sekci pro záznam natoˇcen´ı kloub˚ u robot˚ u je jeˇstˇe zaˇskrtávac´ı pol´ıˇcko Save in degrees, které v okamˇziku ukládán´ı dat o kloubech rozhoduje, zda se zaznamenané hodnoty pˇrevedou z implicitn´ıch radián˚ u na u ´hlové stupnˇe, informace o pouˇzité jednotce je uloˇzena v hlaviˇckovém ˇrádku .csv souboru a nav´ıc je zaznamenána na konci názvu souboru. Obˇe záloˇzky maj´ı jeˇstˇe spoleˇcné tlaˇc´ıtko v zápat´ı okna - Lose Focus in Picking List. Toto tlaˇc´ıtko jsem pˇridal, abych tak vyˇreˇsil komplikaci s pouˇzit´ım Picking List˚ u, t´ım, ˇze umoˇzn ˇuj´ı vybrat v´ıce objekt˚ u ve studii najednou a v libovoln´ ych zobrazovac´ıch oknech - tzv. Viewerech, nerozpoznaj´ı, kdy uˇzivatel uˇz v´ ybˇer objekt˚ u dokonˇcil a chce nˇejak´ y jin´ y objekt jen upravit. M´ısto oznaˇcen´ı tak uˇzivatel objekt znovu pˇridává a zbavit se zamˇeˇren´ı Picking Listu je obt´ıˇzné. V´ yhody pouˇzit´ı tˇechto GUI prvk˚ u jsou vˇsak velké, takˇze jsem radˇeji vytvoˇril tlaˇc´ıtko, které na stisk odebere zamˇeˇren´ı vˇsem tˇrem Picking List˚ um pouˇzit´ ym v mém pluginu. Usnadˇ nuje se t´ım ovládán´ı pluginu.

3.6

Postup pˇ ri aplikaci pluginu

Plugin se skládá z nˇekolika soubor˚ u a aby mohl b´ yt v prostˇred´ı Process Simulate pouˇzit, je tˇreba jej nainstalovat a nˇekteré souˇcásti zaregistrovat v Tecnomatixu. Kdyˇz je pak uˇzivatel obeznámen s GUI a funkcemi jednotliv´ ych prvk˚ u pluginu, m˚ uˇze dle svého uváˇzen´ı plugin aplikovat se vˇs´ı volnost´ı, která je mu v prostˇred´ı PS dopˇrána. Aby mohl ale ihned aplikovat plugin ve smyslu, pro jak´ y byl navrˇzen, sestavil jsem nˇekolik v´ yvojov´ ych diagram˚ u, podle nichˇz uˇzivatel rychle zavede plugin do své studie. 40

ˇ SEN ˇ Í 3 RE

3.6.1

Instalace

Nejprve je tˇreba zkop´ırovat soubor userFcn stateMach.dll do adresáˇre v instalaˇcn´ı sloˇzce Tecnomatixu, typicky na adrese ../Program Files/Tecnomatix/eMPower/UserLBFunc, kde jsou uloˇzeny knihovny se vˇsemi uˇzivatelsk´ ymi funkcemi v PS. Od pˇr´ıˇst´ıho spuˇstˇen´ı PS je uˇzivatelská funkce pˇr´ıstupná. Dále je nutné zkop´ırovat soubor PEpl3g.dll do adresáˇre v instalaˇcn´ı sloˇzce Tecnomatix na adrese ../Tecnomatix/eMPower/DotNetCommands, v této sloˇzce jsou uloˇzeny vˇsechny commandy, které jsou do PS pˇridány, ˇcasto uˇz od implicitn´ı instalace Tecnomatixu.

Obrázek 13: Registrován´ı commandu pluginu

Pak je zapotˇreb´ı zaregistrovat command pro pouˇzit´ı v PS. To se provede pomoc´ı miniaplikace Register Command na adrese ../Tecnomatix/eMPower/CommandReg.exe. Na obrázku 13 je vidˇet rozhran´ı této miniaplikace. V ˇra´dku Assembly uˇzivatel vybere um´ıstˇen´ı souboru PEpl3g.dll, v poli oznaˇceném jako Product(s): vybere prostˇred´ı, v nichˇz chce plugin pouˇz´ıvat - plugin je vytvoˇren pro Process Simulate, zaˇskrtne tedy jen toto pol´ıˇcko. V posledn´ım ˇrádku File: bud’to vybere .xml soubor jiˇz existuj´ıc´ı, nebo vytvoˇr´ı nov´ y. Tento .xml soubor je uloˇzen ve sloˇzce ../Tecnomatix/eMPower/DotNetExternalApplications a je moˇzné jej distribuovat spolu se soubory pluginu nam´ısto manuáln´ıho registrován´ı pomoc´ı 41


Obrázek 14: Zaˇrazen´ı tlaˇc´ıtka pluginu v PS

miniaplikace Register Command. Pokud chce uˇzivatel této moˇznosti vyuˇz´ıt, mus´ı zajistit, aby .xml soubor byl uloˇzen v pˇr´ısluˇsném adresáˇri. Jakmile jednou zaregistrován´ı probˇehlo, je plugin nainstalován a uˇzivatel jej m˚ uˇze v prostˇred´ı PS pˇridat jako tlaˇc´ıtko na libovolnou nástrojovou liˇstu. Tlaˇc´ıtko nalezne v PS Tools → Customize, zobraz´ı se okno na obrázku 14. V záloˇzce Commands v Categories vybere API a zde uˇz je vidˇet jeho command v poli Commands. Pˇretaˇzen´ım na nástrojovou liˇstu si uˇzivatel um´ıst´ı tlaˇc´ıtko pluginu, kam potˇrebuje. Nastaven´ı nástroj˚ u si uˇzivatel m˚ uˇze tlaˇc´ıtkem Save Customization uloˇzit pro pˇr´ıˇst´ı relace. Stisknut´ım tlaˇc´ıtka se otevˇre GUI pluginu.

3.6.2

Pouˇ zit´ı

Pro pouˇzit´ı pluginu jsem pro nové uˇzivatele vytvoˇril v´ yvojové diagramy, podle nichˇz se m˚ uˇzou ˇr´ıdit. Jejich sledován´ım uˇzivatel zvládne provést vˇsechny základn´ı operace, které plugin poskytuje. Protoˇze kroky pro aktivován´ı záznamu otoˇcen´ı kloub˚ u robot˚ u a aktivován´ı záznamu PE stav˚ u jsou témˇeˇr stejné, vytvoˇril jsem pro nˇe spoleˇcn´ y v´ yvojov´ y diagram. Pro pˇriˇrazen´ı ˇci pˇrenastaven´ı PE funkˇcnosti jsem vytvoˇril diagram na obrázku 16. Pro aktivaci záznamu diagram na obrázku 17 a pro uloˇzen´ı záznam˚ u diagram na 42

ˇ SEN ˇ Í 3 RE

Obrázek 15: Workflow pro uloˇzen´ı záznam˚ u

obrázku 15. Diagram popisuj´ıc´ı postup uloˇzen´ı záznamu pˇredpokládá, ˇze uˇzivatel v pr˚ ubˇehu záznamu nezavˇre okno pluginu. Tento pˇredpoklad mus´ı b´ yt splnˇen pro správnou funkˇcnost záznamu. Pokud uˇzivatel v pr˚ ubˇehu záznamu okno zavˇre, ztrat´ı se aktuáln´ı instance pluginu a s n´ı i vˇsechna doposud vygenerovaná data ze simulace - tedy ztrat´ı se aktuáln´ı databáze záznam˚ u. Znovuotevˇren´ım okna pluginu se vytvoˇr´ı nová instance pluginu s prázdn´ ymi databázemi. Tuto funkˇcnost jsem v pluginu zachoval, protoˇze ji lze i vyuˇz´ıt.

43


Obrázek 16: Workflow pro pˇriˇrazen´ı ˇci znovunastaven´ı PE funkˇcnosti

Obrázek 17: Workflow pro aktivaci záznamu - stejn´ y postup pro klouby i PE stavy robotu

44

ˇ SEN ˇ Í 3 RE

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

using System; using System.Collections; using Tecnomatix.Engineering; namespace userFcn_stateMach{ [TxPlcLogicBehaviorFunctionAttribute("Nazev_funkce_v_prostredi_PS")] public class JmenoTridyUzivatelskeFunkce : ITxPlcLogicBehaviorFunction { ArrayList m_typesArray = new ArrayList(); ArrayList m_namesArray = new ArrayList(); TxPlcSignalDataType m_returnValueType; public JmenoTridyUzivatelskeFunkce() { m_typesArray.Add(TxPlcSignalDataType.Bool); m_namesArray.Add("VstupniParametr1"); m_returnValueType = TxPlcSignalDataType.Int; } public TxPlcValue Evaluate(ArrayList parameters) { TxPlcValue navratHodnota = new TxPlcValue(); return navratHodnota; } public ArrayList ParametersNames() { return m_namesArray; } public ArrayList ParametersTypes() { return m_typesArray; } public TxPlcSignalDataType ReturnValueType() { return m_returnValueType; } } }

V´ ypis 2: Pˇredloha prázdné uˇzivatelské funkce 45

4

Virtu´ aln´ı zprovoznˇ en´ı V pr˚ ubˇehu vytváˇren´ı ˇca´sti pluginu, která pln´ı funkci stavového automatu, jsem co

nejpˇresnˇeji sledoval definice dané PROFIenergy (PE) standardem. Naprogramoval jsem tak stavov´ y automat ovladateln´ y pˇres rozhran´ı, do nˇehoˇz vstupuje pouze ID poˇzadovaného stavu a automat do tohoto stavu pˇrejde tak rychle, jak podle definovan´ ych ˇcasován´ı pˇrechod˚ u m˚ uˇze. Nicménˇe náˇs projekt je zamˇeˇren na v´ yrobn´ı linku, kde jsou pouˇzity robotické kontrolery KUKA VKRC, a tyto kontrolery nepodporuj´ı standardn´ı formu PE. Maj´ı zpracovan´ y vlastn´ı standard uspáván´ı robot˚ u do energeticky u ´sporn´ ych stav˚ u. M˚ uj plugin by mˇel umoˇzn ˇovat efektivnˇe modelovat primárnˇe tento VKRC standard. Pro potˇreby virtuáln´ıho zprovoznˇen´ı jsem musel tedy pozmˇenit chován´ı automatu a implementovat konverzn´ı rozhran´ı, které pˇrevád´ı zadané ˇr´ıd´ıc´ı signály na ID poˇzadovaného stavu. V dalˇs´ım kroku jsme ve spolupráci s kolegou Vojtˇechem Pavl´ıkem navrhli demonstraˇcn´ı program pro PLC, které v jednoduchém sledu pˇr´ıkaz˚ u provede robota dvˇema demy v´ yrobn´ıch robotick´ ych program˚ u a pˇrevede robota do energeticky u ´sporného reˇzimu a opˇet jej z nˇej probud´ı. Tento program jsme otestovali na reálném robotu a z´ıskali jsme data o spotˇrebách energie v pr˚ ubˇehu demonstrace. Tato data jsem pak pouˇzil pro v´ ypoˇcet simulované energetické spotˇreby. Pro pˇr´ıpravu virtuáln´ıho zprovoznˇen´ı jsem pak stáhl pouˇzité robotické programy z kontroleru robota a nahrál je do prostˇred´ı Process Simulate (PS) a vytvoˇril jsem tak operace, které lokacemi odpov´ıdaj´ı lokac´ım fyzického robota v pr˚ ubˇehu tˇechto program˚ u. V prostˇred´ı PS jsem pak vygeneroval vˇsechny signály, které byly pouˇzity v reálném pˇr´ıpadˇe k ovládán´ı robotického kontroleru pˇres PLC. Vytvoˇril jsem logick´ y strom operac´ı reprezentuj´ıc´ı jednotlivé programy a pomoc´ı svého modifikovaného pluginu jsem pˇriˇradil robotu v simulaci VKRC PROFIenergy funkˇcnost. Nakonec jsem vˇse propojil pomoc´ı dˇr´ıve vytvoˇren´ ych signál˚ u. Signály jsem pˇripojil k OPC serveru, kter´ y byl pˇripojen k ˇr´ıdic´ımu PLC. Naneˇstˇest´ı prostˇred´ı Process Simulate na stanici s pˇripojen´ım k PLC bylo z neznám´ ych d˚ uvod˚ u 46

´ Í ZPROVOZNEN ˇ Í 4 VIRTUALN

poˇskozené - nejsp´ıˇs instalac´ı OPC serveru na tent´ yˇz poˇc´ıtaˇc - takˇze jsem sp´ınán´ı signál˚ u simuloval manuáln´ım zadáván´ım signál˚ u ve smyslu vytvoˇreného programu. Ze simulace jsem z´ıskal jednak data o energetick´ ych stavech, v nichˇz se robot nacházel, a jednak videozáznam simulovaného pohybu robota. Z tˇechto dat jsem sestavil graf simulované spotˇreby robota a demonstraˇcn´ı videosekvenci.

4.1

Konverze VKRC ˇ r´ıdic´ıch sign´ al˚ u na PE-ID

Standard VKRC má definované rozhran´ı v základˇe jako dva jednobitové vstupn´ı signály. • Drive Bus OFF • Hibernate Tyto dva signály jsou reálnˇe pˇritomny v KRC kontrolerech. Krom nich jsem jeˇstˇe pro potˇreby simulace musel zavést tˇret´ı jednobitov´ y signál: • Operate Tento signál zde mus´ı b´ yt, protoˇze oproti reálnému kontroleru, má simulace kontroler rozdˇelen´ y v podstatˇe na dvˇe ˇca´sti - jedna simuluj´ıc´ı PROFIenergy ˇcinnost a druhá ˇca´st je zcela extern´ı a nezapouzdˇrená, jedná se o simulace robotick´ ych program˚ u, které kv˚ uli architektuˇre prostˇred´ı Process Simulate mus´ı b´ yt reprezentovány jako operace, a jsou tedy nutnˇe mimo logické bloky, ve kter´ ych je simulováno PE. Kdyˇz PLC vydává pˇr´ıkaz ke spuˇstˇen´ı robotického programu, je t´ımto signálem Operate pˇredána informace PE stavovému automatu informace o pˇrechodu do módu Operating. Pro takto popsané rozhran´ı jsem implementoval uˇzivatelskou funkci pro PS, jej´ımiˇz vstupy jsou tˇri v´ yˇse uvedené signály typu boolean, a jej´ım v´ ystupem je ID v´ ysledného stavu. Funkce má vstupy mapovány podle tabulky 4. Tuto funkci jsem zasadil do logického bloku a jej´ı v´ ystup pouˇzil jako vstup pro funkci simuluj´ıc´ı stavov´ y automat, takˇze stavov´ y automat pˇrij´ımá aˇz zprostˇredkovanˇe pˇreloˇzené ID stavu. 47

4.2 Vnitˇrn´ı odliˇsnosti VKRC PE stavového stroje

Vstupy

V´ ystup

Drive Bus OFF

Hibernate

Operate

Jméno stavu

ID stavu

0

0

0

Ready-to-operate

0

0

0

1

Operating

1

1

0

x

Power-saving

4

0

1

x

Sleeping

8

1

1

x

Sleeping

8

Tabulka 4: Konverzn´ı funkce VKRC vstup˚ u na ID PE stavu

4.2

Vnitˇ rn´ı odliˇ snosti VKRC PE stavov´ eho stroje

Kontrolery VKRC se od korektn´ıho PE standardu liˇs´ı i ve vnitˇrn´ı struktuˇre stavového automatu, konkrétnˇe v pˇrechodov´ ych podm´ınkách. Korektn´ı PE standard jsem popsal v pˇredchoz´ıch kapitolách, jeho redukovanou nicménˇe korektn´ı verzi jsem implementoval jako prvn´ı generaci ˇcásti pluginu se stavov´ ym automatem. Oproti zmiˇ novanému modelu nemá VKRC standard zautomatizovány nˇekteré pˇrechody mezi stavy a veˇskerá zodpovˇednost za správné veden´ı kontroleru vhodnou cestou k poˇzadovanému stavu je zodpovˇedné ˇcistˇe programován´ı PLC. Napˇr´ıklad oˇcekávaná funkˇcnost kontroleru robotu je, ˇze kdyˇz se nacház´ı v Power-saving módu a pˇrijde poˇzadavek na pˇrechod do módu Operating, kontroler se sám postará, aby nejprve pˇreˇsel do módu Ready-to-operate a aˇz potom do módu Operating. Standard VKRC nicménˇe v pˇr´ıpadˇe poˇzadavku na pˇrechod z módu Power-saving pˇr´ımo do Operating jednoduˇse neprovede ˇza´dnou akci a z˚ ustane v p˚ uvodn´ım stavu. Je na zodpovˇednosti PLC, aby byl zaslán vˇzdy v dan´ y ˇcas poˇzadavek na pˇrechod do bezprostˇrednˇe navazuj´ıc´ıho módu. Druh´ ym v´ yrazn´ ym omezen´ım je zde, ˇze pro pˇrechod ze stavu Operating je nutné poslat informaci o dokonˇceném robotickém programu do PLC a poˇckat na pˇr´ıchod potvrzen´ı z PLC. Tato komunikace je provedena pomoc´ı signál˚ u so konec práce a si konec práce, prvn´ı je poslán z kontroleru do PLC, druh´ y je potvrzen´ı z PLC do kontroleru. Tyto signály 48


jsem pˇridal jako vstupn´ı parametry uˇzivatelské funkce pro PE stavov´ y automat. Nakonec bylo nutné pˇridat v´ ystupn´ı promˇennou logickému bloku, která bude znaˇcit, kdy je PE stavov´ y automat v módu Operating, coˇz je signál, kter´ y jsem pouˇzil jako jednu podm´ınku ke spuˇstˇen´ı robotické operace, ˇc´ımˇz je simulované spuˇstˇen´ı robotického programu ve fyzickém kontroleru. Za zm´ınˇen´ı stoj´ı také to, ˇze VKRC standard má umoˇznˇen´ y pˇrechod ze stavu Powersaving pˇr´ımo do stavu Hibernate. Tento pˇrechod je v PE standardu uveden jako voliteln´ y. Na obrázku 18 je pˇrehled vnitˇrn´ı struktury v´ ysledného logického bloku, kter´ y jsem pˇriˇradil robotu v simulaci.

Obrázek 18: Pˇrehled logického bloku VKRC PE standardu

49

4.3 Demonstraˇcn´ı PLC program

4.3

Demonstraˇ cn´ı PLC program

Pro demonstraci funkˇcnosti PE standardu a jeho zaˇclenˇen´ı do v´ yrobn´ıho procesu jsme vytvoˇrili snadno pochopitelnou jednoduchou sekvenci operac´ı. Nejprve obsluha spust´ı robota a provede pˇr´ıpadnˇe poˇzadované kalibrace a testy (brzd, motor˚ u apod.). Potom pˇrevede robotick´ y kontroler do extern´ıho reˇzimu, to znamená, ˇze od té chv´ıle bude kontroler pˇrij´ımat pˇr´ıkazy z pˇripojeného PLC. Tyto prvn´ı kroky jsou na reálné lince provedeny standardnˇe. Od té chv´ıle robot cyklicky kontroluje, zda po nˇem nen´ı vyˇzadováno spuˇstˇen´ı programu, a pokud ano, pak podle pˇredaného ˇc´ısla programu vybere ve své pamˇeti pˇr´ısluˇsn´ y program a vykoná jej. Po dokonˇcen´ı programu odeˇsle kontroler signál do PLC a ˇceká na potvrzovac´ı signál, jak je zm´ınˇeno v´ yˇse. Sekvenci jsme urˇcili tak, ˇze nejprve robot vykoná prvn´ı robotick´ y program (ID programu je 2), pak pˇrejde do Power-saving módu, v nˇem setrvá po dobu nˇekolika sekund, a pak se vyˇsle povel k probuzen´ı do módu Ready-to-operate, a pak se spust´ı druh´ y robotick´ y program (ID druhého programu je 9). T´ım sekvence konˇc´ı a lze ji opakovat na základˇe povelu uˇzivatele.

4.4

Modelov´ an´ı pˇ r´ıpadu v Process Simulate

Jak jsem nast´ınil v´ yˇse, v prostˇred´ı Process Simulate nen´ı moˇzné modelovat robotick´ y kontroler jako jeden zapouzdˇren´ y celek, kter´ ym v reálu je. Nen´ı moˇzné simulovat robotické programy jinak neˇz pomoc´ı robotick´ ych operac´ı a zároveˇ n nelze dostateˇcnˇe elegantnˇe simulovat energetické stavy PE standardu pomoc´ı operac´ı. Kontroler je tedy rozdˇelen na dvˇe základn´ı ˇcásti. • PE stavov´ y automat • Robotické operace Pˇritom je jeˇstˇe nutné zajistit, ˇze se v simulaci spust´ı vybran´ y robotick´ y program ze sady vˇsech dostupn´ ych. To jsem realizoval pomoc´ı vˇetven´ı operac´ı a pomocné operce s roz50


hodovac´ım kritériem, jak je vidˇet na 19. Operace PG PICK se vˇetv´ı do dvou moˇznost´ı

Obrázek 19: Struktura operac´ı v sekvenˇcn´ı editoru

podle signálu RQ PGNO. Tento signál z PLC spouˇst´ı v kontroleru robotick´ y program se zadan´ ym ˇc´ıslem. Nastaven´ı operace a kritéria je vidˇet na obrázku 20. Na obrázku

Obrázek 20: Nastaven´ı pˇrechodov´ ych podm´ınek operace

19 je také vidˇet, ˇze vˇsechny robotické operace u ´st´ı do non-sim operace praceEnd. To je pomocná operace, která pˇri svém konci vygeneruje signál napojen´ y na vstup logického bloku si konec prace. Pˇr´ıpadné rozˇs´ıˇren´ı mnoˇziny robotick´ ych operac´ı potaˇzmo program˚ u pouˇzit´ ych ve virtuáln´ım zprovoznˇen´ı by se vyˇreˇsilo následovnˇe. Rozˇsiˇruj´ıc´ı robotické operace se pˇridaj´ı do studie a napoj´ı se na pomocnou non-sim operaci PG PICK a do vˇetvic´ıcho 51

4.5 Pˇripojen´ı signál˚ u

kritéria této pomocné operace se pˇridá jako alternativn´ı následovn´ık s pˇr´ısluˇsn´ ym RQ PGNO. Pak se vˇsechny alternativn´ı operace pˇripoj´ı k ukonˇcovac´ı non-sim pomocné operaci praceEnd, t´ım je rozˇs´ıˇren´ı hotové.

4.5

Pˇ ripojen´ı sign´ al˚ u

ˇ ıdic´ı signály pouˇzité ve studii v Process Simulate je moˇzné pˇripojit k OPC serveru R´ nebo aplikaci SIMIT a ˇr´ızen´ı jejich hodnot pˇrenechat PLC pˇr´ıpadnˇe simulaˇcn´ımu softwaru. My jsme zvolili moˇznost ovládat signály z PLC a tedy pˇripojit signály k OPC serveru, kter´ y by byl pˇripojen k PLC. K tomu jsme nainstalovali poˇc´ıtaˇc nejbl´ıˇze PLC OPC server SIATIC NET a namapovali vˇsechny potˇrebné signály z PLC na OPC a pak jsem v Process Simulate simulované signály pˇripojil k OPC. K tomu je tˇreba provést nastaven´ı v Options v PS v záloˇzce PLC v odd´ılu Simulation. Pˇrepnout na PLC, a pak External Connection. Okno s nastaven´ım je vidˇet na obrázku 21. Kliknut´ım na tlaˇc´ıtko Connection Settings... se otevˇre dialog, v nˇemˇz pˇridáme OPC Connection a zadáme pro nˇe pˇr´ısluˇsná nastaven´ı. Poté je jeˇstˇe zapotˇreb´ı pˇripojit pˇr´ısluˇsné signály v oknˇe Signal Viewer k OPC. Jak je vidˇet na obrázku 22, zvol´ı se signál a ve sloupci PLC Connection se zaˇskrtne zaˇskrtávac´ı pol´ıˇcko, a dále se ve sloupci External Connection vybere pˇr´ısluˇsn´ y OPC server, v nˇemˇz maj´ı b´ yt signály pˇripojeny. Pˇri spuˇstˇen´ı simulace v PS vˇsechny signály správnˇe reagovaly na zmˇeny v PLC potaˇzmo v OPC sereveru, ale vznikl zde jin´ y problém. V sequence editoru se nespustila ˇza´dná operace a nebylo moˇzné spustit robotické operace. Prostˇred´ı Process Simulate také od té chv´ıle nebylo schopné uloˇzit na eMServer zmˇeny ve studii. Domn´ıvám se, ˇze nejsp´ıˇs pˇri instalaci OPC serveru na stejn´ y poˇc´ıtaˇc nˇekterá komponenta PS musela b´ yt ovlivnˇena a funkˇcnost PS t´ım byla naruˇsena. Moˇznost, ˇze by chyba byla v nastaven´ı studie ˇci projektu, jsem vylouˇcil, protoˇze stejná studie se stejn´ ym nastaven´ım ˇcerstvˇe naˇctená z eMServeru na jiném poˇc´ıtaˇci fungovala, jak bylo plánováno, zat´ımco i pˇri odpojen´ ych signálech na poˇc´ıtaˇci s OPC serverem PS nefungoval, jak má. 52


Obrázek 21: Nastaven´ı pˇripojen´ı k OPC serveru

Protoˇze v závˇeru nezb´ yval ˇcas na hledán´ı ˇreˇsen´ı tohoto problému, upustili jsme od zprovoznˇen´ı s pˇripojen´ım na OPC server a pˇr´ıkazy pˇricházej´ıc´ı z PLC jsem simuloval manuáln´ım zadáván´ım. Jedná se o jednoduch´ y PLC program, takˇze zastoupit funkci PLC nebyl problém. 53

4.6 Simulovaná spotˇreba

Obrázek 22: Pˇripojen´ı signál˚ uv Process Simulate k OPC

4.6

Simulovan´ a spotˇ reba

Pˇri fyzickém testován´ı demonstraˇcn´ı sekvence byla mˇeˇrena hodnota okamˇzitého pˇr´ıkonu kontoleru robota a z tˇechto dat jsme vypoˇcetli pr˚ umˇerné spotˇreby v jednotliv´ ych reˇzimech. V´ ystup ze záznamu o PE stavech ze simulace se skládá z pár˚ u ˇcasové známky a PE stavu v pˇr´ısluˇsnou dobu. Tento ˇretˇez dat je generován pro kaˇzdého sledovaného robota v simulaci zvláˇst’ a je uloˇzen v csv souboru. Pˇriˇrazen´ı simulovan´ ych hodnot spotˇreby jsem provedl externˇe v programu MATLAB. Hodnoty spotˇreby pro jednotlivé PE módy jsou uvedeny v dokumentaci robota, stejnˇe tak i ˇcasován´ı tˇechto mód˚ u (jak dlouho trvá pˇrechod mezi jednotliv´ ymi módy, jaká je minimáln´ı doba setrván´ı v dan´ ych módech apod.). Jeˇstˇe ovˇsem zb´ yvá odhadnout spotˇrebu robota pˇri vykonáván´ı jednotliv´ ych robotick´ ych operac´ı. Tato hodnota je silnˇe závislá na spotˇrebˇe motor˚ u robota a je tedy závislá na jeho pohybech. Energetická funkce, která by na základˇe u ´daj˚ u o pohybu kloub˚ u robota urˇcila pˇredpokládanou spotˇrebu dané operace, je v projektu ve v´ yvoji a nen´ı jeˇstˇe pouˇzitelná. Nicménˇe pro moje potˇreby pro demonstraci virtuáln´ıho zprovoznˇen´ı lze pouˇz´ıt pr˚ umˇernou spotˇrebu v pr˚ ubˇehu operace. Celková vynaloˇzená energie na proveden´ı operace bude ekvivalentn´ı. Tuto pr˚ umˇernou spotˇrebu operace jsem vypoˇcetl z namˇeˇren´ ych dat. Podobnˇe také pˇrechod mezi jednotliv´ ymi stavy nen´ı konstantn´ı funkce z hlediska spotˇreby energie, ale opˇet souhrn spotˇrebované energie lze rovnomˇernˇe rozprostˇr´ıt na ˇcasov´ y interval 54


Obrázek 23: Graf simulované spotˇreby

Obrázek 24: Graf zmˇeˇrené spotˇreby

55

4.6 Simulovaná spotˇreba

trván´ı pˇrechodu - tedy pouˇz´ıt pr˚ umˇernou spotˇrebu na tomto intervalu. Po proveden´ı mˇeˇren´ı jsme ale zjistili, ˇze spotˇreba uvedená v dokumentaci se m´ırnˇe liˇs´ı od skuteˇcné spotˇreby v jednotliv´ ych PE stavech. To si vysvˇetluji t´ım, ˇze u ´daje v dokumentaci jsou nejsp´ıˇse z´ıskány mˇeˇren´ım jen malého mnoˇzstv´ı r˚ uzn´ ych kontroler˚ u a také za r˚ uzn´ ych podm´ınek, jako je teplota ve skˇr´ıni kontroleru, uplynulá doba od zapnut´ı v okamˇziku mˇeˇren´ı apod. Dalˇs´ı nesrovnalosti tvoˇr´ı ˇcasován´ı PE pˇrechod˚ u. Podle namˇeˇren´ ych pr˚ ubˇeh˚ u energetické spotˇreby je pˇrechod proveden za kratˇs´ı dobu, neˇz jaká je uvádˇena v dokumentaci ke kontroleru. Tyto odliˇsnosti lze ovˇsem zahrnout do modelu zpr˚ umˇerován´ım spotˇreby pˇres cel´ y ˇcasov´ y interval uveden´ y v dokumentaci. Nevad´ı pˇritom, ˇze se do pˇrechodu zapoˇcte ˇ i chv´ıle, kdy uˇz kontroler pˇretrvává v c´ılovém stavu. Casov´ an´ı z dokumentace chápu jako korektn´ı a bezpeˇcné, a proto se ho drˇz´ım v simulaci. V´ ysledkem jsem z´ıskal simulaci, která je vidˇet na obrázku 23. Pro orientaˇcn´ı srovnán´ı uvád´ım na obrázku 24 i graf z namˇeˇren´ ych hodnot. ˇ Casov´ an´ı se liˇs´ı i proto, ˇze graf z namˇeˇren´ ych hodnot je sestaven z mˇeˇren´ı sekvence ˇr´ızené pomoc´ı PLC, zat´ımco simulace byla ˇcasována manuálnˇe. Dále je vidˇet, ˇze robotické operace se vyznaˇcuj´ı ˇspiˇckami ve spotˇrebˇe, coˇz jsem uˇz vysvˇetlil v´ yˇse.

56

´ ER ˇ 5 ZAV

5

Z´ avˇ er C´ılem práce bylo rozˇs´ıˇrit prostˇred´ı Process Simulate o funkˇcnost profilu PROFIenergy,

aby bylo moˇzné tento profil modelovat a simulovat. Následuj´ıc´ım logick´ ym krokem bylo otestován´ı této funkˇcnosti na zaˇr´ızen´ı, které je v rámci projektu k testovac´ım u ´ˇcel˚ um urˇcené. Podaˇrilo se mi postupnˇe vyvinout plugin, kter´ y tyto poˇzadavky splˇ nuje, a otestovat ho na modelové studii. Provedl jsem v rámci virtuáln´ıho zprovoznˇen´ı také simulaci uvádˇen´ı robotu do u ´sporného reˇzimu a v´ ysledky mˇeˇren´ı ze skuteˇcného robota jsem srovnal se svou simulac´ı se slibn´ ymi v´ ysledky. Moje práce byla jen jedn´ım stavebn´ım kamenem celého projektu a závis´ı na v´ ysledc´ıch práce dalˇs´ıch lid´ı. V souˇcasnosti je PE plugin také jen prvn´ı funkˇcn´ı verz´ı s omezen´ ymi moˇznostmi, i kdyˇz ani v´ yrobci zaˇr´ızen´ı jeˇstˇe nedosáhli u ´plné implementace vˇsech souˇca´st´ı profilu PROFIenergy. PE plugin momentálnˇe pokr´ yvá schopnosti robotu, na kter´ y bude aplikován a jeho v´ yvoj nejsp´ıˇs jeˇstˇe nen´ı u konce. I na to jsem pˇri jeho programován´ı myslel a snaˇzil jsem se udrˇzovat vˇsechny vrstvy program˚ u co nejjednoduˇsˇs´ı a nejpˇrehlednˇejˇs´ı, aby se v´ ysledek mého snaˇzen´ı neuzavˇrel sám do sebe a byl snadno modifikovateln´ y. ˇ PE plugin mˇel b´ yt p˚ uvodnˇe aplikován na model v´ yrobn´ı linky v továrnˇe SKODA AUTO, ale tento plán se nepodaˇrilo splnit kv˚ uli komplikac´ım s datovou kompatibilitou jimi dodan´ ych PS studi´ı v´ yrobn´ı linky. Pˇrevod studi´ı je práce rozsahem srovnatelná s prac´ı na implementaci PE pluginu a bude vyˇzadovat pro naplnˇen´ı c´ıl˚ u projektu jeˇstˇe pozornost. Vˇeˇr´ım vˇsak, ˇze splnˇen´ı hlavn´ıch c´ıl˚ u diplomové práce se mi podaˇrilo dosáhnout.

57

REFERENCE

Reference [1] Siemens Industry Software. Tecnomatix 11.1 Administration Guide, 2013. [2] PROFIBUS & PROFINET International. Common Application Profile PROFIenergy, v1.1, August 2012. Technical Specification for PROFINET. [3] Siemens Industry Software. Process Simulate version 11.1 Reference Manual, 2013. [4] Siemens Industry Software. Process Designer 11.1 Reference Manual, 2013. [5] Siemens Industry Software. Tecnomatix.NET version 11.1, 2013.

58

Appendix Obsah pˇ riloˇ zen´ eho CD V tabulce 5 jsou uvedena jména vˇsech koˇrenov´ ych adresáˇr˚ u pˇriloˇzeného CD s popisem obsahu.

Jm´ eno adres´ aˇ re

Popis

diplomova prace

diplomová práce ve formátu .pdf

installable

pˇreloˇzené knihovny programu k instalaci

multimedia

videoprezentace Tabulka 5: Obsah CD

Energetické úspory v simulaci digitální továrny

Recommend Documents