Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Irányítástechnika és Informatika Tanszék
Tutor Gábor
Automatikus kodgeneralas PLC-re Önálló laboratórium Bsc.
KONZULENS
Kovács Gábor tanársegéd 2013
Tartalomjegyzék Kivonat 1. Bevezetés ............................................................................................................................................ 2 1.1. PLC-k az ipari irányítástechnikában ...............................................................................................2 1.2. Automatikus kódgenerálás ............................................................................................................2 1.3. A fejlesztő szoftver: Simulink Stateflow ........................................................................................3 2. PLC-k programozása ............................................................................................................................4 3. Simulink Stateflow bemutatása ..........................................................................................................6 4. Az algoritmus felvázolása ...................................................................................................................8 4.1. A feladat részletes ismertetése .....................................................................................................8 4.2. A megoldás elvi lépései .................................................................................................................8 5. Adatszerkezetek felépítése .................................................................................................................9 5.1. Adatszerkezetek ismertetése ........................................................................................................9 5.2. Adatszerkezetek megvalósítása ....................................................................................................9 5.2.1. Állapotok adattáblájának összeállítása ............................................................................... 10 5.2.2. Átmenetek adattáblájának összeállítása ............................................................................. 11 5.2.3. Események és változók adattáblájának összeállítása.......................................................... 12 6. A PLC-kód előállítása ........................................................................................................................ 13 6.1. Az állapotok PLC objektumai ...................................................................................................... 13 6.2. Az átmenetek PLC kódsorai ........................................................................................................ 13 6.3. Az állapotok PLC kódsorai........................................................................................................... 15 6.4. Az állapotok és átmenetek kódsorainak összefűzése ................................................................ 16 6.5. A kódsorok kimentése ................................................................................................................ 16 7. Tesztelés ............................................................................................................................................ 17 8. Összefoglalás ..................................................................................................................................... 20 8.1. Továbbfejlesztési lehetőségek.................................................................................................... 20 8.2. Értékelés ..................................................................................................................................... 20 9. Irodalomjegyzék ............................................................................................................................... 21 10. Ábrajegyzék..................................................................................................................................... 22
Kivonat Az iparban leggyakrabban előforduló, PLC-vel megoldott irányítási feladatok állapotgépekre épülnek. Az állapotgépeken alapuló irányítások tervezésére és szimulációjára kitűnő lehetőséget nyújt a Mathworks által kifejlesztett Simulink Stateflow modulja. A Simulink képességeit kihasználva az így megtervezett szabályozás tesztelhető a mellette megvalósított komplex szakaszmodelleken, illetve egyes platformokra a szabályozót megvalósító kód automatizáltan le is fordítható. Az automatikus kódgenerálás köztes C-kód generálásával készít futtatható állományokat különféle beágyazott platformokra, amely út PLC-kód esetében a platform specifikus tulajdonságai miatt nem járható. Ugyanakkor egy állapotgép, illetve az annak állapotaihoz tartozó egyszerű funkciók a PLC-k által használt utasításlista-nyelven is egyszerűen implementálhatók, mint ahogyan azt a mérnökök „kézi” módszerrel a mindennapokban meg is teszik. Az önálló laboratóriumi feladat kereteiben egy olyan algoritmus megtervezése és implementálása volt a feladatom, amely egy megfelelő Stateflow-modellből és a felhasználó által megadott be- és kimeneti táblázat alapján képes automatikusan utasításlistás PLC-kódot generálni. A feladat elvégzése során alaposan megismerkedtem a Simulink-Stateflow környezettel, illetve a Schneider Electric TWIDO PLC-család programozási lehetőségeivel. Az beszámoló
első felében kitérek az ipari irányítástechnikában napjainkban
leggyakrabban alkalmazott vezérlőegységek, a PLC-k felépítésére, alkalmazására illetve programozására, majd a Mathworks által kifejlesztett Simulink Stateflow környezetet ismertetem. A beszámoló leírásának második felében ismertetem az implementált kódgenerálási algoritmus elvét, a feladat megoldását, majd bemutatom a tesztelési eredményeket és az elkészült algoritmus továbbfejlesztési lehetőségeit.
1. Bevezetes 1.1.
PLC-k az ipari irányítástechnikában A mai világban a gyárak és a gyártóüzemek a termelés központjai. A folyamatosan
növekvő piaci igények kielégítésére az ipar egyre hatékonyabb és nagyobb kapacitású gyártósorok üzembe helyezésével válaszol. Ezen gyártósorok irányítását, vezérlését egy hierarchikus számítógépes rendszer látja el, amelynek sarokkövei a programozható logikai vezérlők. A PLC-k a '70-es évektől terjedtek el és nagyon gyorsan kizárólagos alkalmazást nyertek el az ipari folyamatok vezérlésében. A programozható vezérlőberendezések, a vezérlési funkciókat szoftver útján valósítják meg és beviteli, kiviteli egységeik révén a technológiai folyamatok tárolt programú vezérlésére közvetlenül alkalmasak.
1. ábra. Egy Schneider TWDLCAA24DRF-as PLC [1]
A PLC-ket, kivitelük alapján kompakt és moduláris felépítésű csoportba sorolhatjuk. A kompakt PLC hardverstruktúrája nem módosítható, csakis megfelelő védettségű ipari tokozásban készül és kis helyigényű. Felhasználási területei: sorozatban gyártott gépek, berendezések automatikai, illetve a PLC műszaki jellemzői által lefedhető egyedi vezérlések. A moduláris felépítésű PLC-k jellemzője, hogy a vezérlőberendezés valamely speciális funkciót önmagában ellátó modulokból épül fel. A modulok fizikai megjelenése 2
rendszerint az áramköri kártya, dugaszolható csatlakozóval. A modulok ún. rack-be (tartó) dugaszolhatók, ezért a rendszer konfigurációja tág határokon belül bővíthető. A rack-ek megfelelő védettségű műszerdobozba vagy műszerszekrénybe szerelhetők. A moduláris felépítésű PLC-ket közepes, ill. nagyméretű rugalmas gyártórendszerek vagy ipari folyamatok irányítására fejlesztették ki [1]. A beszámolóm a Schneider Electric által gyártott TWDLCAA24DRF gyártási számú TWIDO PLC-hez készít kódot. Ez egy alsó-középkategóriás kompakt felépítésű PLC, galvanikusan leválasztot kétállapotú ki- és bemenetekkel, valamint kimeneti LED-ekkel.
1.2.
Automatikus kódgenerálás Az informatikában a kódgenerálás a mechanikus forráskód generálást jelenti, ami
lehetővé teszi a fejlesztőknek, hogy a problémákat magasabb absztrakciós szinten definiálják. A generált kód gyorsabban elkészül, nem tartalmaz hibát, az igények változása esetén nincs szükség refactoringra, egyszerűen újragenerálható így a fejlesztők a "lényeges" dolgokra fókuszálhatnak, az automatizálható tevékenységek nem vonnak el szellemi tőkét a kreatív feladatoktól. [2] Az automatikus kódgenerálás egyre inkább elterjedőben van a számítógépes és beágyazott rendszerek világában, így ma már az ipari irányítástechnikában használt eszközökhöz is eljutott. Ennek pedig az a vonzata, hogy megjelent az igény a PLC kódok generálására..
1.3.
A fejlesztő szoftver: MATLAB Simulink Stateflow Magát a kódgenerálást számtalan szoftveren keresztül meg lehet valósítani, az én
személyes feladatom a Mathworks által készített MATLAB Simulink Stateflow szoftverrel történő megvalósítás volt. A Stateflow egy olyan modulja a MATLAB Simulinknek, amelyben állapotgépeket állíthatunk elő és szimulálhatjuk azokat. Az állapotgép maga és a PLC sok közös tulajdonságot mutat, tekintve, hogy mind a kettő elemi logikai feltételek, állapotok és állapotátmenetek hálózatából áll.
3
2. PLC-k programozasa A PLC-k fejlődése során számos programozási nyelvet fejlesztettek ki. Ezek közös jellemzője az „ahány gyártó, annyiféle programnyelv” volt. Napjainkra a különböző felhasználói programnyelvek széles körét alkalmazzák, ami az egyes gyártók eszközei közötti kompatibilitást lehetetlenné teszi. Ezért egyre nagyobb igény jelentkezik úgy a gyártók, mint a felhasználók részéről egységes nemzetközi szabványokban rögzített felhasználói programnyelvek kifejlesztésére. Az IEC 1131-3 számú nemzetközi szabvány az egész világra egységesíteni kívánja a felhasználói programnyelveket és ezek jelöléseit. Ez a szabvány nem új programnyelveket hoz létre, hanem a korábbi, közös jellemvonású nyelveket igyekszik egységesíteni. Az IEC 1131 szabvány a PLC felhasználói programnyelveket két osztályba sorolja: szöveges rendszerű és grafikus szimbólumokat alkalmazó programnyelvek.
2. ábra. Egy kódrészlet létra (LAD) nyelven [2]
A grafikus szimbólumokkal leírt és megszerkesztett vezérlési feladat a fejlesztőrendszerben egy letöltő program révén tölthető le a PLC-be. A 1131-3 szabvány háromféle grafikus szimbólumot alkalmaz: létradiagramos, funkcióblokkos és sorrendi folyamatábrán alapuló programnyelvet. A szöveges szimbólumokkal leírt vezérlési feladat rendszerint egy compiler (fordító) ré-vén kerül a programmemóriába letöltésre. A szöveges rendszerű programnyelveknek két megvalósítási formáját engedélyezik. Az egyik a magas szintű programnyelvekkel (Pascal vagy C) támogatott strukturált felhasználói programnyelv (ST). Ez esetben a vezérlési feladatot megvalósító felhasználói program leírása hasonlít a Pascal vagy C nyelven megírt program szintaktikájához.
4
3. ábra. Egy kódrészlet utasítás lista (IL) nyelven [3]
A másik szöveges programnyelv az utasításlistás felhasználói programnyelv, amely jelölése angolul Instruction List (IL). Ez a programnyelv az assembly nyelvű programozásból alakult ki, és a bitszervezésű PCL-knél erősen kötődött a hardver-struktúrához. A feladatom során a megadott állapotgépet IL nyelven kellett reprezentálnom [1]. Széles körben egyetértenek a mérnökök abban, hogy a létradiagramos (LAD) nyelv az amelyiken a legegyszerűbb a PLC-t programozni. Ennek okai nyilván abban keresendők, hogy az emberi agy jobban kedveli a grafikus kezelőfelületet az egyszerű kódsorokkal szemben, annak átláthatósága miatt. Az önálló feladatomban is ez játszik jelentős szerepet, hiszen ha a felhasználó tisztában van azzal, hogy milyen vezérlést óhajt készíteni, csupán minimális ismeretekre van szüksége az állapotgépek terén és a Stateflow használatát illetően, a megfelelő algoritmus pedig életképes PLC kódot készít az állapotgépéből.
5
3. Simulink Stateflow bemutatasa A Stateflow egy, State Chart-on alapuló, állapotgépek modellezésére és szimulálására szolgáló környezet. A Stateflow lehetővé teszi, hogy állapotgépek, igazságtáblák valamint folyamatábrák segítségével modellezzünk rendszereket, továbbá, hogy megvizsgáljuk, hogy adott eseményekre, idő alapú feltételekre és külső gerjesztésekre, hogyan reagál a modellünk. Magába a Simulink modellbe elhelyezhetünk különböző elemeket, modulokat. Ilyenre mutat példát a 4. ábra.
4. ábra. Simulink modell egy gépjármű sebességváltásáról, a shift_logic elem a Stateflow Chart [4]
A Stateflow alapeleme az ún. Chart. Ez nem más, mint a StateChart diagram, amit elhelyezünk a Simulink modellben. Másképpen fogalmazva, az adott folyamatot a Simulinkkel modellezzük le, a hozzá kapcsolt állapotgéppel modellezett irányítórendszert pedig a Chart jelenti. Ha bepillantunk a Chart-ba, akkor felfedezhetjük, hogy milyen állapotgép van mögötte, azaz, hogy mit is valósít meg. Egy állapotgép két fő részre bontható: állapotokra (states) és az azok közötti váltást biztosító átmenetekre (transitions). Ezeken kívül megtalálhatók csomópontok (junctions), események (events), változók (datas). Az állapotok közötti váltás csakis az átmeneteken keresztül lehetséges. Ezeket az átmeneteket köthetjük feltételekhez vagy események lezajlásához, továbbá rendelhetünk hozzájuk speciális utasításokat, ún. akciókat, amelyeket akkor hajtanak végre, amikor a feltétel igaznak bizonyult vagy az esemény, ami rájuk hivatkozik, lezajlott. Egy átmenet címkéje a következőképpen épülhet fel: 6
esemény [ feltételek ] { feltételes akciók} / akciók Az esemény egy pillanatszerű aszinkron változás, pl. egy lámpa felvillanása. A feltételekhez megadhatunk olyan kifejezéseket, amelyek befolyásolják az adott átmenet érvényességét (pl. az 5. ábrán a [speed > down_th ] feltétellel ellátott átmenet csak akkor érvényesül, ha a szögletes zárójelbe írt kifejezés igaznak bizonyul. A feltételes akciók csak akkor hajtódnak végre, amikor az imént említett feltételes kifejezés igaznak bizonyul. Ha nem szerepel feltétel, viszont szerepelnek feltételes akciók, akkor azok automatikusan végrehajtódnak, mert a feltétel hiánya logikai IGAZ-t jelent. Az akciók pedig mindig végrehajtódnak az átmenet érvényre jutása során.
5. ábra. A 4. ábrán szerplő Stateflow Chart[5]
Az eseményeknek és a változóknak is megadhatjuk az orientáltságát, vagyis, hogy kimeneti, bemeneti vagy lokális eseményről vagy változóról beszélünk. Bemeneti változó lehet pl. egy szenzor jele. Kimeneti változó lehet pl. egy szelep, amelyet a PLC irányít. A lokális változó pedig egy, a PLC-n belül érvényes változó. A fentebb említett orientáltságot szkópnak (scope) nevezzük és kulcsfontosságú lesz, mint ahogy látni fogjuk a későbbiekben. Események tekintetében megadhatjuk még azt, hogy milyen élre érzékenyek, ezt nevezzük az esemény triggerének. Ezek az opciók lényeges szerephez jutnak akkor, amikor a Stateflow modellünket egy PLC-nek feleltetjük majd meg. 7
4. Az algoritmus felepítse 4.1. A feladat részletes ismertetése Az algoritmus felvázolása előtt, a jobb megértés érdekében, szeretném részletezni a megoldandó feladatot. A felhasználó elkészíti az általa kívánt vezérlést megvalósító állapotgépet a Stateflow grafikus felületén. Megadja a szükséges állapotokat, eseményeket, változókatvalamint az átmeneteket azok feltételeivel, eseményeivel és
generált akcióival
együtt. Ha ezzel elkészült, akkor egy egyszerű szöveges fájlként egy pontosvesszővel elválasztott (csv) táblázatot készít a változókhoz és az eseményekhez. Ennek a táblázatnak az első oszlopában helyezkednek el a Stateflow diagramban is alkalmazott esemény- és változónevek, a második oszlopában pedig az adott eseményekhez és változókhoz tartozó PLC objektumok
nevei. A PLC objektumok a PLC változói. Ezek lehetnek kimeneti
(%Qx.y), bemeneti (%Ix.y) vagy lokális (%Mx) változók, amelyekkel a PLC dolgozik. Fontos, hogy a Stateflow-ban megadott tulajdonságok tükröződjenek a .csv táblázatban lévőkkel, azaz az adatok konzisztensek legyenek vagyis ne térjenek el egymástól, pl. egy kimeneti eseménynek deklarált ’lámpa’ esemény a .csv táblázatban %Qx.y PLC objektummal rendelkezzen. A feladat végrehajtása során néhány megkötést specifikáltam. Nem használtam ki a StateCharts által megendgedett állapot-hierarchiát, valamint csak bináris változókkal dolgoztam.
4.2. A megoldás elvi lépései A Stateflow chart, illetve annak elemei Matlab környezetben a Stateflow API-n keressztül is elérhatők. Ejtsünk néhány szót a Stateflow API működéséről. Az API egy olyan eszköz,aminek a segítségével matlab parancsokkal Stateflow Chart-okat tudunk létrehozni vagy módosítani. A Stateflow API hierarchiája a következő: legfelsőbb szinten áll a gyökér elem (root), ez tartalmazza a Simulink modellt, ami pedig a Stateflow Chart-ot. A Charton belüli elemek lehetnek változók, események, átmenetek, csomópontok és állapotok is.
8
6. ábra. A Stateflow API hierarchiája
Miután kinyertük ezeket a tulajdonságokat, felépítünk egy adatszerkezetet, ahol tárolni kívánjuk őket, és ahonnan a későbbi függvények könnyedén elérik a megfelelő adatokat. Ezek után meghívásra kerülnek azok a függvények, amelyek további adattáblák felépítésével kinyerik az adatszerkezeteinkből azokat az információkat, amelyek elengedhetetlenek a PLC kód felépítéséhez. A kódgenerálás nagyvonalakban úgy történik, hogy meghatározunk bizonyos primitív kódvázlatokat az állapotok és az átmenetek működésének megfelelően. Ezek primitívek általános modellt jelentenek, azaz lefednek minden eshetőséget, és erre modellre illesztjük rá az adott állapotgép részeit.
9
5. Adatszerkezetek felepítese 5.1. Adatszerkezetek ismertetése A feladat első fázisa a Stateflow-n belüli állapotok és átmenetek által alkotott állapotgép szükséges adatainak kimentése, egy olyan adatstruktúrába, amely kiinduló pontként szolgálhat az automatikus kódgenerálási feladat számára. Ahogy az előző fejezetben ismertettem négy főbb adattáblát kell létrehoznunk: az állapotoknak, az átmeneteknek, az eseményeknek és a változóknak. Maguk a táblák, illetve tartalmuk az 1. ábrán látható elrendezésben kerülnek megvalósításra.
7. ábra. Az adatszerkezetek felépítése [6]
5.2. Adatszerkezetek megvalósítása A Stateflow objektumokat az őket reprezentáló Stateflow API objektumokkal irányíthatjuk, ezeket pedig egy MATLAB változóval, a handle-el érhetjük el. Elsőnek ki kell nyernünk a gyökér(root) handle-t, azaz ahhoz a szülőelemhez kell handle-t adnunk, ami minden más elem fölött áll. Ezután következik a Simulink modellhez rendelt handle, majd a Stateflow alapeleméhez a Charthoz. Amint rendelkezünk handle-el a Chart-hoz, meg tudjuk kezdeni azon handle-ök előállítását, amelyek a Chart-ban előállítható elemeket reprezentálják, azaz az állapotokat, átmeneteket, csomópontokat, eseményeket és változókat. Ezen handle-ök definiálása létfontosságú feladatunk szempontjából, hiszen ezek a handle-k mutatóként szolgálnak, az általuk reprezentált elemetípusokhozl.
10
A 6. ábrán vázolt adatstruktúrák kialakításában egy-egy tábla egy MATLAB struktúra (struct), melynek elemei stringek vagy egész számok.
5.2.1. Állapotok adattáblájának összeállítása Az állapot az egyik leglényegesebb Stateflow Chart elem (nélküle se állapotgépet, se PLC kódot nem lehet generálni). Egy átmenet vezethet egyik állapotból a másikba, de megesik, hogy kényelmi szempontokból csomópontokat használunk, ekkor egy vagy több átmenet egy csomópontba érkezik illetve indul onnan ki. Ezeket, PLC programozási szempontból, állapotként definiáltam, tehát az állapotok struktúrája valójában két Stateflow Chart elemet fog tartalmazni: először az állapotokat, majd a csomópontokat.
8. ábra. A csomópontok és az állapotok viszonya [7]
Az állapotok számunkra lényeges tulajdonságai:
Name (az állapot neve)
Entry (belépéskor végrehajtandó akciók)
During (az állapotban végrehajtandó akciók)
Exit (kilépéskor végrehajtandó akciók)
On_event_name (egy adott esemény hatására végrehajtandó akciók) Ezeket a tulajdonságokat egy adott állapot LabelString jellemzője foglalja magába,
mint egy string. Innen ki kell nyernünk a különböző akcióneveket, illetve az állapot nevét. Ebben segítségünkre van a MATLAB regexp (regular expression) függvénye, mellyel reguláris kifejezések segítségével könnyen ki tudjuk válogatni a számunkra fontos részeket egy karaktersorozatból. Az állapot neve közvetlenül is elérhető, az állapotokhoz tartozó handle-n keresztül.
11
Az így kialakított struktúra, a States névre hallgató adattáblázat foglalja magába az összes állapotot és csomópontot. A csomópontok nem rendelkeznek névvel, csupán azonosítóval, ezért egy névgenerátor függvénnyel automatikus neveket generáltam nekik.
5.2.2. Átmenetek adattáblájának összeállítása Az állapotgép másik fontos alkotóeleme az átmenet. Az általános átmenet LabelString-jének alakja, mint korábban említettem a következő : esemény [ feltételek ] { feltételes akció } / az átmenet akciói Ezekre az adatokra szükségünk lesz a továbbiakban, így ki kell mentenünk őket az átmenetek adattáblájába.
9. ábra. Állapotok és átmenetek a Stateflow-n belül [8]
Egy állapotból több átmenet is kiindulhat, más állapotokba, illetve hurkok esetén önmagába. Ebben az esetben megszabhatjuk az adott átmenetek kiértékelési sorrendjét, az úgynevezett ExecutionOrder-t. Ez fontos szerepet játszat egy olyan állapotgépben, ahol pl. prioritást élvező átmenetek helyezkednek el. Végül, de nem utolsósorban, beszélnünk kell az adott átmenet forrás és nyelő állapotáról.
Ezek fontosságát nem kell részleteznünk,
egyszerűen szükséges annak ismerete, hogy egy átmenet mely állapotok között helyezkedik el. A fentiek alapján az átmenetek struktúrája a következő: Az állapotok jellemzői:
Event (az esemény)
Conditions (a feltétel, ami alapján érvényre juthat az átmenet)
ConditionActions (a feltétel érvényre jutásakor végrehajtandó akciók)
TransitionActions (az átmenet érvényre jutásakor végrehajtandó akciók) 12
Source (az átmenet forrásának azonosítója)
Destination (az átmenet nyelőjének azonosítója)
ExecutionOrder ( kiértékelési sorrend)
5.2.2. Események és változók adattáblájának összeállítása Az események lényeges tulajdonságai közé tartozik az esemény neve, az, hogy bemeneti, kimeneti vagy esetleg helyi esemény (Scope), valamint, hogy mire triggerel maga az esemény (felfutó- vagy lefutó él). Ezeket a jellemzőket könnyedén kinyerhetjük az eseményeket modellező handle-ből közvetlenül. Esemény lehet egy folyamatban például egy lámpa felvillanása, egy gomb megnyomása, minden, ami pillanatszerű aszinkron változás. Hasonló a helyzet a változókkal is, ahol szintén fontos a változó neve, típusa illetve a kezdeti értéke, mely adatokat szintén a változókat reprezentáló handle segítségével érhetünk el. Változó értéke lehet például egy jel magas vagy alacsony feszültségértéke, azaz, hogy pl. be van-e nyomva egy gomb. A fentiek alapján az események illetve a változók adattáblái: Az események jellemzői:
Name (az esemény neve)
Scope (az esemény forrása)
Trigger (az esemény triggere)
A változók jellemzői:
Name (az változó neve)
Type (a változó típusa)
InitialValue (a változó kezdeti értéke)
Scope (a változó forrása)
13
6. A PLC-kod eloallítasa A következőekben látni fogjuk, hogy az összeállított adatszerkezetekből, a megfelelő primitívek megalkotásával, hogyan áll elő a Stateflow-n belül létrehozott állapotgép IL-kódja illetve a kódgenerálást milyen Matlab-függvények végzik.
6.1. Az állapotok PLC kódsorai Elsőként az állapotoknak kell megfeleltetnünk a megfelelő állapotváltozókat. A memória bitek azonosítóit
%Mx
módon
képezzük, ahol az x 0-tól számozódik. A
’states_to_memorybits’ függvény legenerál egy olyan cell-t, amely annyi memóriabit azonosítót tartalmaz, ahány állapot van, mégpedig úgy, hogy ezen cell-ben elhelyezkedő elemek indexe megegyezik a States adattáblában lévő állapotok indexével. Vagyis a 3. állapothoz a 3. cell elem tartozik, és mivel a cell elemei %M100-tól számozódnak (azért, hogy a felhasználónak álljon elég memóriabit a rendelkezésére egyéb elemek számára) ez a %M102 lenne.
10. ábra. Az általános állapothoz tartozó primitív IL nyelven [12]
Egy állapotba való belépéskor, azaz az állapot aktívvá válásakor elsőnek az entry akció fut le, így ennek esetén az állapotregiszter (memóriabit)
felfutó élét érdemes a
feltételbe helyezni. Az entry akciót, ami lehet esemény generálás (azaz pl. egy kimeneti esemény- egy lámpa felkapcsolása- aktívvá tétele) vagy változó módosítás (pl. egy motor leállítása vagy elindítása . Az események generálását Set vagy Reset tekerccsel modelleztem, mert ez felel meg legjobban az események viselkedésének. A változókat egyszerű tekercsnek vettem. 14
Ezekután következnek azok az akciók, amelyek akkor jutnak érvényre, amikor az állapot aktív. Ilyenek a
a during akciók
illetve az on event_name akciók. Az előbbi
végrehajtásának feltétele, hogy az adott állapot aktív legyen, míg az utóbbinak az, hogy az adott állapot legyen aktív és hajtódjon végre az az esemény ami ezt az akciót kiváltja. Ezért ebben az esetben az állapotnak a jelszintje számít, így egy kontaktusnak vettem, az on event_name esetében pedig az esemény felfutó vagy lefutó élét tettem a feltételbe. Végül az entry akciók végrehajtása következik. Ez akkor lép érvénybe, amikor az állapotból ki akarunk lépni, ezért érdemes a feltételbe az állapot lefutó élét tenni, az exit akciót pedig a „szokásos” tekercs/negált tekercs vagy Set /Reset tekerccsel érdemes modellezni.
11. ábra. Az általános állapot LAD nyelven [11]
A feladatom során a states_PLC.m matlab script segítségével végzem el az állapotokhoz tartozó IL-kód generálását. A 10. ábrán látható az általános állapothoz tartozó primitív felépítése. Az első sorban szereplő ’LDR ALLPOT’ az ALLAPOT nevű memóriaváltozó felfutó élét teszi egy kontaktusba. Az ezután következő ’ST ENTRY’ az entry akció, amely ebben a példában egy változó módosítása, pl. lampa=1. Ezek után követezik az ’LD ALLAPOT’, amely az ALLAPOT nevű memóriaváltozót teszi egy feltételkontaktusba, majd az ’S DURING’ a during akció következik. A during akció mellett az on event_name is lejátszódhat, ha az ’ANDR EVENT’ EVENT nevű eseményhez tartozó feltétel igaznak bizonyul. Végül az exit akció feltétele az ALLAPOT nevű változó lefutó éle, ezt az ’LDF ALLAPOT’ IL kóddal valósítom meg. 15
6.2. Az átmenetek PLC kódsorai Az átmenetek esete az előzőnél már jóval bonyolultabb. Meg kell alkotni azt a primitívet, azt az általánosított esetet, ami minden átmenetre igaz. Ez egy olyan átmenet, amelynek van feltétele, feltétel és egyéb akciói, továbbá eseményekre is érzékeny. A következő szint az, amikor az előbb említett komponensek eseteit vesszük. Például egészen más egy ’csengő’ esemény felfutó élére triggerelő átmenet mint ennek az eseménynek a lefutó élére triggerelő. Ez pedig minden komponensre igaz.
12. ábra. Az általános átmenethez tartozó primitív IL nyelven [10]
Egy átmenetnek, hogy végrehajtódhasson lennie kell forrás állapotának. Ezért ezt egy kontaktussal érdemes modellezni (’LD ALLAPOT1’). Továbbá lehet, hogy az átmenetünket egy esemény engedélyezi, ez az esemény hirtelen történik meg, ezért érdemes egy felfutó és/vagy lefutó élű kontaktussal modellezni (’ANDR EVENT’), attól függően, hogy milyen az esemény triggere. Ahogy már többször is említettem egy átmenetnek lehet feltétele, amelyet egy kontaktussal vagy negált kontaktussal érdemes modellezni (’AND FELTETEL’). A feltételek után következnek az átmenet hatásai, akciói. Ezek között szerepelnek a feltételes akciók (’STN AKCIO1’)
és az akciók (’ST AKCIO2’) ezek lehetnek eseménygenerálások vagy
változó módosítások,ahogy az állapotok esetében, így az esemény generálást Set vagy Reset tekerccsel, a változó módosítást pedig egyszerű tekerccsel modelleztem. Végül a forrás állapotot kell inaktívvá tenni (’R ALLAPOT1’) és a nyelő állapotot aktiválni (’S ALLAPOT2’), ezeket is Set, Reset tekercsekkel modelleztem.
16
13. ábra. Egy általános átmenet LAD nyelven [9]
A kódgenerálás folyamata a következő: 1. Kimentjük az összes esemény és adat nevét és Scope-ját egy táblázatba 2. Beolvassuk a felhasználói objektumtáblát, amely tartalmazza minden egyes változó és esemény nevét, scope-ját és PLC objektumát 3. Átmásoljuk a megfelelő helyekre a PLC objektumokat 4. A fenti IL nyelvű kód kialakítása minden lehetőséget lefedve Ezzel lesz egy olyan struktúránk, amelynek az elemei olyan cellák, melyek elemei egyértelműen leírnak egy állapotátmenetet.
6.4. Az állapotok és átmenetek kódsorainak összefűzése Most már rendelkezünk az állapotok és az átmenetek kódsoraival, az utolsó feladatunk ezeknek a helyes összefűzése. Gondot egyedül az átmenetek kiértékelési sorrendjei okoznak. Ezeket a felhasználó tetszése szerint állíthatja, azaz prioritási sorrendet tud adni az átmeneteknek, ezért fontos, hogy ezeket is figyelembe vegyük a modellezés során. Az osszefuz.m matlab függvény megoldja ezt a problémánkat, egyszerűen összerendeli a megfelelő kódsorokat, kihasználva azt, hogy az állapotok kódsorainak azonosítója egyezik az állapotok azonosítóival, illetve az átmenetek kódsorainak azonosítója egyezik az átmenetek azonosítóival. Ezek után egy struktúrába kerül, most már helyes sorrendben, az állapotok és átmenetek kódsorozata. A végső feladat az elkészült kódsorozatok kimentése egy .txt fájlba, amit majd a későbbiekben egyszerűen importálhatunk az adott PLC fejlesztőkörnyezetébe, ami jelen esetben a Schneider cég TWIDO PLC-je.
17
7. Teszteles A vegyipari és gyógyszeripari folyamatokban gyakran alkalmaznak keverőtartályokat, amelyek egy vagy több anyag elegyítését vagy oldását szolgálják. Az elkészült alkalmazást egy ilyen vegyipari keverőtartály modelljével teszteltem.
14. ábra. Egy vegyipari keverőtartály működési modellje [13]
A modell a következő állapotokból áll:
Betöltés1 (%M100): az első szelep nyitva van és betöltjük az első anyagot Betöltés2 (%M101): a második szelep nyitva van és betöltjük a második anyagot, továbbá ez az induló állapot Keverés (%M102): beindítjuk a keverőgép motorját és összekeverjük a két anyagot Ürítés (%M103): az alsó szelep megnyitásával kiengedjük az elegyet
Az egyes állapotokhoz tartozik egy-egy lámpa, ami jelzi, hogy épp milyen fázisban van a folyamat.
18
15. ábra. A vegyipari keverőtartály Stateflow modellje [14]
A 14. ábrán látható a Stateflowban megvalósított modell. Az egyes események (betoltes_1, betoltes_2, keveres, urites) segítik a felhasználót abban, hogy könnyebben megérthetővé teszik a modellt.
16. ábra. Az események és változók PLC objektumai .csv táblázatban
Az alkalmazás a futtatás után a 15. ábrán láthatóak az állapotok, 16. ábrán az átmenetek működésének megfelelő utasítás lista kódsorok: ######################################## LDN %M101 ANDN %M100 ANDN %M102 ANDN %M103 S %M101 19
-----------------------------------------LDR %M100 ST %Q0.4 LD %M100 ST %Q0.1 LDF %M100 STN %Q0.1 -----------------------------------------LD %M100 ANDR STN %Q0.4 S %M101 R %M100 -----------------------------------------LDR %M101 ST %Q0.5 LD %M101 ST %Q0.2 LDF %M101 STN %Q0.2 -----------------------------------------LD %M101 ANDR STN %Q0.5 S %M102 R %M101 -----------------------------------------LDR %M102 ST %Q0.6 LD %M102 ST %Q0.8 LDF %M102 STN %Q0.8 -----------------------------------------LD %M102 STN %Q0.6 S %M103 R %M102 -----------------------------------------LDR %M103 ST %Q0.7 LD %M103 ST %Q0.3 LDF %M103 STN %Q0.3 -----------------------------------------LD %M103 ANDR STN %Q0.7 S %M100 R %M103 ------------------------------------------
A keletkezett kódsorokat értelmezve belátható, hogy azt a folyamatot hajtják végre amit a Stateflow-diagram is leír. 20
8. Összefoglalas 8.1. Értékelés A féléves munkám során alaposan megismerkedtem a Mathworks Simulink Stateflow környezetével, az állapotgépekkel és az automatikus kódgenerálás lényegével. Továbbá ismereteket sajátítottam el az ágazati laboratóriumban található TWIDO PLC programozását tekintve, valamint megtapasztaltam, hogy mivel jár egy konkrét alkalmazás megtervezése, megvalósítása és implementálása.
8.2. Továbbfejlesztési lehetőségek Az elkészült MATLAB scriptet számos területen érdemes továbbfejleszteni. A fejlesztés során a változókat például 1 bitesnek vettem, a specifikáció szerint, de természetesen nem csak 1 bites változókkal dolgoznak az ipari folyamatok, pl. három állású kapcsolók vagy szelepek. A fejlesztési lehetőségek között szerepelhet még az átmenetek és az állapotok primitíveinek részletesebb kidolgozása, ezzel is közelítve a legáltalánosabb, minden esetet lefedő kódot. Beszélnünk kell még a más gyártó, más PLC-jére való fejlesztésről. A Schneider egy eléggé elterjedt családot gyártó cég, de a tényleges piacot, főképpen az európait, a Siemens uralja. A Siemens S7-es sorozatának legtöbb helyen alkalmazott tagjai (s7-300, s7-400, s71200) megtalálhatók szinte minden gyárban, üzemben, ezért érdemes lenne ebben az irányban is továbbléptetni az alkalmazást.
21
9. Irodalomjegyzek [1]: Ajtonyi, István és Gyuricza, István. Programozható irányítóberendezések, hálózatok és rendszerek. Budapest : Műszaki Könyvkiadó Kft., 2007. [2]: Getting started with Simulink Stateflow [3]: Simulink Stateflow Properties and Methods [4]: Overview of the Stateflow API [5]: Stateflow and Stateflow Coder [6]: https://en.wikipedia.org [7]: TWIDO Szoftver referencia kézikönyv [8]: http://en.wikipedia.org/wiki/Automatic_programming
22
