Rockwell PLC-k alkalmazástechnikája Önálló laboratórium beszámoló Szőke Máté Konzulens: Divényi András, Kovács Gábor 2013
Bevezető: A Rockwell Automation cégről .............................................................. 1
I.
Első feladat: ismerkedés a fejlesztő környezettel ................................................. 1
II.
RSLogix 5000 ............................................................................................................. 2 Felhasználói felület ................................................................................................. 2 Task-ok, Programok felépítése................................................................................ 3 Létradiagramok ....................................................................................................... 4 RSLogix Emulate 5000 ............................................................................................... 4 Felépítés .................................................................................................................. 5 Kapcsolódás az RSLogix 5000-el ........................................................................... 5 A feladat létradiagramjának bemutatása ................................................................. 6 FactoryTalk View Studio – Machine Edition ............................................................. 7 Felépítés .................................................................................................................. 7 Interfész elemek ...................................................................................................... 8 Hozzáférési Biztonság ............................................................................................. 9 A feladat kezelői felületének bemutatása .............................................................. 10 III.
Második feladat: ismerkedés a mintaprogramokkal ........................................... 11
Malthouse mintaprogram .......................................................................................... 12 Animált elemek ..................................................................................................... 12 HMI TAG-ek ......................................................................................................... 13 InstantFizz mintaprogram ......................................................................................... 14 FactoryTalk View Studio – Site Edition ............................................................... 14 IV.
Harmadik feladat: vagontöltő berendezés .......................................................... 15
Szétválasztott folyamat szimuláció és vezérlés ........................................................ 16 Add-on instruction .................................................................................................... 16 A vezérlés megvalósítása sorrendi folyamatábrával ................................................. 16 A vizualizáció bemutatása ........................................................................................ 18 V.
Szisztematikus hibakeresés ................................................................................ 20
VI.
Felhasznált irodalom .......................................................................................... 21
VII.
Ábrák jegyzéke ............................................................................................... 22
I.
Bevezető: A Rockwell Automation cégről
A Rockwell International cég 1985 óta folyamatosan bővíti az automatizálási üzletágát az Amerikai Egyesült Államokban az ezen a területen vezető vállalatokkal, amelyeket a Rockwell Automation cégcsoportban egyesített. A csoporthoz tartozik a programozható vezérlők területén piacvezető, 1903-ban alapított Allen-Bradley, az 1905-ben alapított Reliance Electric a kiváló motorjaival és motormeghajtó eszközeivel, a Dodge a mechanikus meghajtások széles választékával, valamint az ipari automatizáláshoz programozó, adatkezelő, felügyeleti és SCADA szoftvereket készítő 1995-ben alapított Rockwell Software. [1] A félév során a Gamma Digital KFT-nél meg kellett ismerkednem részletesen a Rockwell szoftverekkel, amik lehetővé teszik az Allen-Bradley PLC-k programozását. Az alábbiakban bemutatom milyen feladatokon keresztül értem ezt el, illetve hogy milyen megoldásokat találtam ki rájuk.
II.
Első feladat: ismerkedés a fejlesztő környezettel
Első feladatomat a céges konzulensem találta ki, melynek szövege az alábbi volt: „PLC Emulátor és vizualizáció segítségével készítsd el a következő programot kultúrált kinézettel, Menüvel, runtime ablakkal. Cél: Megismerkedés a PLC adattípusokkal. A vizualizáción 1 , 2 és 3 jelű gombok megadott logikájára az emulátor PLC kimeneti kártyájának 1. , 2. és 3. kimenetét mozgatni. BOOL Ha egyik gomb sincsen benyomva, az 1-es kimenet aktív. Egyéb esetben nem. Ha 1-es és 2-es gomb van benyomva, a 2-es kimenet aktív. Ha 1-es és 3-as gomb van benyomva, 3-as kimenet aktív. Ha 2-es és 3-as gomb van benyomva, 4-es kimenet aktív. Bármilyen más esetben az 5-ös kimenet aktív. ( Plusz pontért villogtathatod 1sec-enként 50%-os kitöltési tényezővel) STRING Ugyanezen az ablakon készíts egy string kijelzőt, ahol a PLC-ből felszívott string-et jelzed ki. PLC-ben a logika az legyen, hogy a fenti gomb kombinációkra egy string-be a saját string-edet helyezed. Sorrendben a feliratok a következők legyenek: NoPressedButton 1 and 2 1 and 3 2 and 3 Invalid state. INTEGER A fenti kombinációkat használva egy INT típusú változóba a következő értékek kerüljenek, sorrendben: 10 20 30 40 100 Az értéket jelezd ki a képernyőn. Timer Amennyiben az integered az utóbbi két állapot valamelyikét felveszi, indíts egy 5 sec-es timert.
1
Amennyiben a bemeneti állapot 5sec-ig fent áll, utána egy piros teli kört kezdj el villogtatni a kijelzett INT érték mellett. A kör tűnjön el a feltétel megszűnésével. Az INT kijelző közelében egy INT beviteli mezőt helyezz el, ahol 20 és 200 közötti számot írhatsz be. 35 fölötti értéknél az előbb villogtatott piros kör szintén villogjon.”
A feladat megoldásához a konzulens azt javasolta, hogy használjam a fejlesztő környezet segítség menüpontját, melyet az F1 billentyűvel kényelmesen el lehet érni.
RSLogix 5000 A fejlesztő környezet központi eleme az RSLogix 5000. Ebben lehet a PLC-k konfigurációját és programjait implementálni, továbbá azokat az eszközökbe letölteni. A környezet lehetőséget biztosít futó PLC-kre csatlakozni, és azok programjain hibakeresést végezni. Felhasználói felület
1. ábra: Az RSLogix 5000 szerkesztő ablaka - A: PLC-vel való kapcsolat állapota - B: szerkesztő panel eszköztára - C: Vezérlő beállításait és programjainak szervezését kezelő panel - D: Program szerkesztő panel
Az ábrán az A-val jelölt rész szolgál az adott project-hez tartozó PLC-vel való kapcsolat kezelésére. Itt tudjuk elindítani a kapcsolatot, illetve innen kezdeményezhetjük a program letöltését a PLC-be, valamint itt kaphatunk visszajelzést az eszköz állapotáról. Az ábrán az ’Offline’ felirat helyett ’Online’ jelenik meg, ha a kapcsolat létrejön az eszközzel. Ilyenkor a ’RUN’ mező helyén ’Run mode’ jelenik meg, ha a PLC futó állapotban van, valamint ’Program mode’, ha a PLC-t programozó állapotba állítottuk. A felirat mellett álló négyzet színekkel is jelzi ezt az állapotot. Zöld kitöltésű futó állapot esetén, világos kék programozó mód esetén, és piros ha a PLC hiba miatt leállt (például, ha a Watchdog timer futás közben lejárt). A B-vel jelölt rész egy eszköztárat nyújt a programok szerkesztéséhez. Attól függően, hogy melyik nyelvben szerkesztünk éppen, annak megfelelő elemeket húzhatunk be a D-vel jelölt részbe. Az ábrán a leggyakrabban használt létradiagram elemek eszköztára szerepel éppen. 2
A C részben kezelhetjük a project legfontosabb részleteit: a futtatandó programokat, valamint a PLC beállításait. Szintén innen lehet elérni a memóriában tárolt objektumok szerkesztésére szolgáló ablakokat. Task-ok, Programok felépítése A felhasználói programok a tanult három kategóriába tartozhatnak: ciklikus, periodikus, valamint esemény-vezérelt. Ciklikus programból csupán egy lehet, és ezt létre is hozza a szerkesztő alapértelmezetten ’MainTask’ néven. Ez nem törölhető, és hozzáadás esetén csak a másik kettő fajta egyike hozható létre:
2. ábra: Task hozzáadása
Az Allen-Bradley PLC-kben az egyes objektumokat, melyek a memóriában helyet foglalnak, TAG-eknek nevezik. A legegyszerűbb TAG típus a BOOL. A programok írása során ezeket kezelhetjük a digitális bemenetekhez vagy kimenetekhez hasonlóan. Az INT, DINT változók egész típusú számok tárolására valók. A DINT-nek a D betűje a double szóra utal, ami azt jelenti, hogy ez a sima, 16 bites INT-hez képest kétszer annyi, azaz 32 biten ábrázolja az egész számokat. Mindkét típus előjeles számokat kezel, és az egyes bitjeiket is fel lehet használni, mint független logikai változókat. TAG-eket különböző hatókörre definiálhatunk. Először is, a vezérlőnek vannak globálisan elérhető TAG-jei, amiket bármelyik program használhat. Ezen felül minden egyes programnak van egy saját hatóköre, melyhez más programok nem férhetnek hozzá. Ha mégis szükség lenne más programok által kezelt értékekre, akkor globális TAG-eken keresztül kell ezeket átadni.
3. ábra: TAG hozzáadása (a project neve, és ezzel együtt a PLC-nek adott név is ’Introduction’)
TAG hozzáadása esetén meg kell adjuk az objektum nevét, leírását, típusát, illetve hozzáférési hatókörét, valamint külső elérési jogosultságát (írás/olvasás). 3
Létradiagramok Létradiagramot úgy hozhatunk létre, ha a project kezelőben (1. ábra - C rész) jobb gombbal kattintunk egy program nevén, majd az ’Add routine’ menüpontot kiválasztjuk. Ezen az ablakon tudunk nevet adni az új program szegmensnek, illetve írhatunk hozzá rövid leírást. Kiválasztható az is, hogy milyen programozási nyelven szeretnénk a szegmenst szerkeszteni.
4. ábra: Program szegmens hozzáadása
Mint minden gyártónál, úgy az RSLogix5000 esetén is láthatunk érdekes specialitásokat a létradiagram programozásában. A Schneider esetén megszokott pozitív és negatív élre érzékeny kontaktus például nem taláható meg a létra diagram eszköztárában. Ehelyett létezik egy ONS típusú kontaktus, ami egy ciklus erejéig vezet, ha a bemenetén nem vezetőből vezetőbe vált a létrafok. ( [2] 102. oldal) Ehhez szükség van egy külön BOOL TAG-re, mellyel összeveti minden ciklus erejéig az előző bemeneti értéket. Ezzel az elemmel könnyedén megoldható a pozitív élérzékenység: be kell tegyünk egy alapértelmezetten nyitott szintérzékeny kontaktust egy ilyen ONS típusú kontaktus elé. A negatív élérzékenység ehhez hasonló módon oldható meg: csupán annyi a különbség a fenti megoldáshoz képest, hogy alapértelmezetten zárt kontaktust kell az ONS elé tennünk.
RSLogix Emulate 5000 A tesztelhetőség kiemelt fontossággal bír az ipari folyamatok esetében. Programozói hiba esetén katasztrófális méretű károk keletkezhetnek. Ezek legtöbbször emberi áldozatokat is követlehetnek, mivel általában életveszélyes mennyiségeket vezérelnek a PLC-k. Az ilyen hibák elkerülése végett használandó a Rockwell termékek esetén az RSLogix Emulate 5000. Ez egy különálló szoftver, mely egy PLC operációs rendszerét emulálja Windows alatt. Nem része az RSLogix 5000-nek, de szoros kapcsolatban áll vele, és a később tárgyalt HMI szerkesztővel is. Emiatt nevezik ezt emulator-nak, nem pedig szimulátornak. Természetesen nem kezelhető egy kategóriában a rendes vezérlőkkel. A program fejlesztői annyira hangsúlyosnak ítélték meg ezt a kérdést, hogy a súgójában a főoldalon elhelyeztek egy linket, amely a valódi PLC-k és az emulátor közötti különbségek oldalára mutat. Ezen az oldalon egy fontos eltérésként kiemelik, hogy valódi bemenetek/kimenetek használatára nem alkalmas az emulátor. Valamint felhívják arra is a figyelmet, hogy az emulátor feladat végrehajtási ideje nem egyeztethető össze a valódi PLC-kével, mivel bizonyos utasításokat máshogy hajt végre. Egyéb hátrányok: 16 helyett csak 3 task prioritási szint, hálózati és analóg bemeneti/kimeneti kártya nem adható hozzá. Mindamellett, hogy ezekkel a hátrányokkal együtt kell élni mindenképp az emulátor környezetben, számos előnyös szolgáltatást is igénybe vehetünk, amik nem érhetőek el valódi PLC-n. Például ilyen a létra hálózathoz hozzáadható töréspont (break point), vagy az egyszeri 4
ciklus végrehajtás (single-scan mode). Ezek mind olyan eszközök a fejlesztő kezében, melyek a részletes hibakeresést és a program pontos működésének átlátását segítik. Mindebből jól látható, milyen koncepcionális különbség van egy emulátor és egy valódi PLC között. Az emulátor a részletes tesztelés elengedhetetlen eszköze, míg a valódi PLC feladata kifejezetten a biztonságos és megbízható folyamatvezérlés. Felépítés A program felhasználói felülete az úgynevezett Chassis Monitor. Ez 17 darab modul számára tartalmaz helyet, melyek közül 15 konfigurálható szabadon. A 0-ás és az 1-es sorszámon található modul nem távolítható el, ezek a kommunikációért felelősek.
5. ábra: RSLogix Emulate 5000 Chassis Monitor
Összesen két fajta modult állíthatunk be a szabad helyekre: Emulátor PLC-t és digitális I/O modult. Mindkettőből egyetlen fajta áll rendelkezésre, és a beállítási lehetőségeik sem túl bőségesek. Emulátor PLC esetén állítható a verzió szám, a memória mérete és opcionálisan egy periodikus mentés intervallum. Ez utóbbi beállítás esetén a PLC teljes állapota és konfigurációja fix időközönként elmentődik a PC háttértárára. Az I/O modulon csupán a kijelzett futó szöveg, valamint az egyes bemenetek állapotai állíthatók. Kapcsolódás az RSLogix 5000-el A fejlesztő környezet az úgynevezett RSLinx kommunikációs szerver segítségével képes kapcsolódni az emulátorhoz, és valódi PLC-khez egyaránt. Minden Rockwell PC-s fejlesztő szoftver, ami kommunikál PLC-kkel, rendelkezik az úgynevezett RSWho interfésszel, mely segítségével képes feltérképezni a hálózaton elérhető eszközöket, és azokra csatlakozni is.[3] Az RSLogix 5000-ben is ez az interfész teszi lehetővé a PLC-kkel való kapcsolat felvételét.
6. ábra: RSWho kapcsolatfelvétel az RSLogix 5000-ben
5
Előzetesen szükséges a létrehozott project-ben a PLC típusának, verzió számának, hátlap típusának, és azon elfoglalt sorszámának (slot) a beállítása. Mindezen az információkat még az RSLinx-en keresztüli csatlakozás megkezdése előtt meg kell adnunk. Az emulátor PLC külön típusként kezelendő. Amennyiben digitális I/O modul szimulátort is alkalmazunk, úgy azt is külön kell konfigurálni. Ezekhez a beállításokhoz az emulátor segítség menüje részletes leírást tartalmaz. Ahhoz, hogy a kommunikáció megkezdődjön, szükséges, hogy a hálózaton elérhető legyen egy RSLinx gateway. Ezt esetünkben az emulátor Chassis Monitor-án található első két modul valósítja meg, emiatt nem távolíthatóak el a konfigurációból. Ha sikerült az RSWho interfészen keresztül kiválasztani az eszközt, akkor az 1. ábra A részének 1. sorában a PLC ikonra kattintva lehetőségünk van a ’Go Online’ paranccsal kapcsolódni rá. Ez után, ha minden jól ment, egy dialógus ablakot láthatunk, aminél felajánlja a fejlesztő környezet a project letöltését a PLC-be, illetve lehetőséget ad az éppen futó project feltöltésére is. Ekkor már az előbb említett sorban a szürke négyzet színe átváltozik a PLC állapotának megfelelőre. Amennyiben letöltjük a PLC-re a project-et, és ez sikeresen lezárul, akkor alap helyzetben csatlakozva maradunk a PLC-hez, és létra diagramon megvizsgálhatjuk a program működését. Ehhez fontos kritérium, hogy a PLC futó (Run) állapotban legyen, különben az egyes létrafokok nem kerülnek kiértékelésre. Az egyes logikai értékeket az adott kontaktus szempontjából mutatja a szerkesztő ablak: ha vezet, akkor zöld csík látható a két végén, egyéb esetben ugyan úgy néz ki, mint offline szerkesztés során.
7. ábra: Egy létrahálózat részlete. A logikai értékek jelölése: bIn1 zárt, bIn2 nyitott, bIn3 nyitott
A feladat létradiagramjának bemutatása Első lépésként a BOOL változókhoz tartozó feladatot oldottam meg. Egyenlőre csupán az emulator I/O moduljának be- és kimenetei között, nem belső BOOL TAG-ek között. Ez után létrehoztam egy saját változó típust, amihez egy STRING és egy INT TAG-et adtam hozzá. Mivel a feladat leírásában csupán a három bemeneti kapcsoló értékétől függnek az egyes állapotok, és mind a BOOL, mind a STRING és az INT értékek ugyan azon állapotokhoz vannak rendelve, ezért itt még nincs szükség állapotgép leírására. Ezek az „állapotok” nem épülnek egymásra, egymástól függetlenek, és csupán a bemeneti kombináció alapján kell kiválasztani, hogy melyik legyen az aktuális. Abban az esetben felmerül a sorrendiség, amikor két állapotnak is megfelelő kombináció van kiválasztva (pl. ha 1 és 2 és 3 is be van kapcsolva), de ebben az esetben nem volt definiálva, hogy mi történjen, így az helyes megoldásnak tekinthető, ha a legutóbb érvényre jutott érték lesz jelezve a STRING és az INT értékek esetében. A BOOL értékeknél ilyen gond nincs, mivel két lámpa világíthat egyszerre gond nélkül. Az előbb említett saját típusból minden egyes állapothoz egy-egy konstans objektum lett deklarálva, melyek az állapotoknak megfelelő értékeket tartalmazzák. Ezek mellett egy nem konstans objektum is létezik ebből a típusból. Az egyes állapotok érvényre jutásakor ebbe a változtatható objektumba a CPS (Synchronous Copy File) parancs bemásolja a
6
megfelelő konstanst. Így egy meghatározott helyen mindig megtalálható a megfelelő érték páros.
FactoryTalk View Studio – Machine Edition Gyakorlatilag minden automatizált folyamat esetén szükséges a hozzáférés biztosítása olyan személyzet számára is, aki nem tartozik a fejlesztők közé. Elsősorban a folyamat közelében dolgozók számára kritikus ez, nekik adott esetben feladatuk lehet közbeavatkozni is. Ilyen esetekben nem merülhet fel a fejlesztői beavatkozás lehetősége. Ezek mellett pedig nem elhanyagolható a folyamatról szerezhető információk kijelzése sem. Ilyen adatok nélkül nem tudhatja a kezelő, hogyan és milyen módon kell beavatkoznia a folyamatba. Valamint a vezetők számára is fontos, hogy friss információk alapján hozzák meg döntéseiket, és figyeljék a termelés haladását. Ezen funkciók fejlesztését segíti a FactoryTalk View Studio a Rockwell fejlesztő szoftverek családjából. Más szóval ez ebben a családban a HMI (Human-Machine Interface, ember-gép kapcsolat) tervező szoftver. Elsőként ennek a szoftvernek a Machine Edition (ME) változatával ismerkedtem meg. Ez arra biztosít lehetőséget, hogy érintőképernyős állomásokra fejlesszünk alkalmazásokat, ellentétben a később tárgyalt SE (Site edition) változattal, amely kliens PC-kre ad fejlesztési lehetőséget. Felépítés A szoftver alapvető felépítése a 8. ábrán látható.
8. ábra: A FactoryTalk View Studio Machine Edition felépítése: A - képernyő (Display) kezelésével, szerkesztésével kapcsolatos eszközök, B - Képernyőn használható elemek eszköztára, C - a megnyitott project beállításai, D - Képernyő szerkesztő, E - státusz üzenet mező
7
A C jelzésű rész a project böngésző. Ezen állíthatjuk be a projectünk tulajdonságait, a kommunikációt a PLC-vel, illetve itt hozhatunk létre és nyithatunk meg egyéb eszközöket is, mint például a képernyő terveket. Az alsó részen található a Communication Setup gomb. Ennek segítségével nyílik meg az RSWho ablak, amin keresztül kiválaszthatjuk a hálózaton található PLC-t, és csatlakozhatunk rá. A Graphics menüpont alatt található a Displays csoport. Itt jelennek meg a létrehozott képernyőtervek, melyek az ablak D részében szerkeszthetőek. Az A részben található egy pár hasznos eszköz ehhez, mint például az elemek csoportosítása, síkokban előre-hátra küldése, stb. Kiemelten fontos ezen az eszköztáron a képernyő kipróbálása interakciókkal, ami a szerkesztőben állva létesít kapcsolatot a PLC-vel. Ez a funkció nagyban segíti a gyors fejlesztést. A jobbra mutató nyíl (Play) gombbal aktiválhatjuk ezt a funkciót, és a mellette található négyzettel (Stop) léphetünk ki belőle. Szintén a D részhez kötődik szorosan a B, amely a fő eszköztárat jelenti a képernyők szerkesztéséhez. Innen választhatóak ki azok az elemek, amiket elhelyezhetünk rajtuk. Az E részen visszajelzéseket láthatunk a fejlesztő környezet állapotáról. Ha hibát észlelünk, akkor itt általában hasznos információt szerezhetünk arról, hogy hol keressük az okát. Interfész elemek A teljesség igénye nélkül ismertetem a legfontosabb elemeket, és azok tipikus fehasználási lehetőségeit. Image Ez az elem egy egyszerű kép megjelenítésére alkalmas. Igen sokszor fordul elő általában egy project-ben. A képek megjelenítése a project képtárából lehetséges egyedül. Ebbe a képtárba természetesen importálhatunk ábrákat saját forrásból is, de gyakran hasznos és elegendő lehet a beépített Symbol Factory (szimbólum gyár) eszköz.
9. ábra: A Symbol Factory eszköz
8
Ebben rengeteg előre gyártott képet találhatunk, ami kapcsolódik az ipari folyamatokhoz. A bal oldali listában számos kategóriát látunk, amikhez több kép is megjelenik a jobb oldali nézetben. Ezek mind konfigurálhatóak az Options gomb segítségével. Így például adott háttérhez lehetséges igazítani az egyes képeket, vagy a kitöltésük színét meg lehet változtatni. Az így legyártott képeket a Copy gomb segítségével a vágólapra lehet másolni, majd beilleszteni a project képtárába. A kép elemeket átváltoztathatjuk textúrává is, ami azt fogja ereményezni, hogy ezeket az elemeket innentől kezdve nem tudjuk kijelölni, amíg a megfelelő menüpontokkal vissza nem konvertáljuk őket rendes képekké. Ez a fejlesztés során hasznos lehet, ha az ízléses megjelenítés érdekében be szeretnénk állítani egy háttérképet. Így nem történhet meg, hogy véletlenségből egy félrekattintás következtében a háttérképen végzünk műveletet. Momentary Push Button Ez az elem egy érintőgombnak feleltethető meg. Egy BOOL TAG rendelhető hozzá, melynek értékét megnyomáskor egy meghatározott ideig beállítja. Az, hogy milyen értéket állít be, az konfigurálható: viselkedhet alapértelmezetten nyitott vagy zárt kontaktusként is. A PLC-ben érdemes lehet erre élérzékeny logikát alkalmazni. Multistate Push Button A többállapotú nyomógomb segítségével egy állítható gombot kapunk. Az egyes állapotai között változtatja a hozzá kapcsolt TAG értékét, ami ezúttal már egész szám is lehet. Az egyes állapotokhoz külön lehet beállítani a kinézetet, minden egyes részük egymástól függetlenül konfigurálható. Számos felhasználási lehetősége van ennek az elemnek, de elsősorban két vagy három állapotú kapcsolóknál célszerű alkalmazni. Multistate Indicator Belső változók állapotainak megjelenítésére használható a többállapotú indikátor. Ez sokban hasonlít a többállapotú nyomógombra, de kizárólag visszajelzésre alkalmas. Kattintás hatására nincs háttérben történő akció TAG-eken. Hozzáférési Biztonság Jogos elvárás az interfészre nézve, hogy jogosultságokat kezeljen, azaz kizárólag azonosított felhasználók legyenek képesek bizonyos funkciókat ellátni. A FactoryTalk View Studio ME-ban lehetőségünk van alapvető jogosultság kezelésre a Runtime Security beállítások segítségével. Minden egyes képernyő beállításai közt található egy úgynevezett Security Code opció, vagyis biztonsági kód. Ehhez az angol ábécé betűi közül, A-tól P-ig választhatunk értéket. Amennyiben nem kívánunk biztonsági korlátokat alkalmazni, vagy mindenki számára hozzáférhetővé szeretnénk tenni egy képernyőt, akkor a * karakter választható. A project böngésző System menüpontja alatt találjuk a ’Runtime Security’ pontot. Erre kétszer kattintva megjelenik a project-hez tartozó jogosultságokat kezelő ablak, ami a 10. ábrán látható.
9
10. ábra: Egy FactoryTalk View Studio project Runtime Security ablaka
Az Add gomb segítségével hozzáadhatunk egy felhasználó csoportot vagy individuális felhasználót a project jogosultság kezelési hierarchiájához. Az így létrehozott egységekhez meghatározhatjuk milyen jogosultsági kódok érvényesek. Akinek egy bizonyos kód nincs megadva, nem tekintheti meg az ilyen kóddal ellátott képernyőket. Ha ilyen próbálkozást tenne, akkor erről megfelelő hibaüzenet jelenik meg, és ez az üzenet naplózásra kerül. Amikor elindítjuk az első képernyő elemet, akkor a DEFAULT felhasználó jogosultságaival rendelkezünk. Ez a felhasználó emiatt nem törölhető. Felhasználó váltására szolgál egy külön elem a képernyők elemkészletében, a Login Button. Vállalati környezetben kifejezetten hasznos lehet az, hogy a felhasználókat nem kell egyesével létrehozni, hanem lehetőség van Windows-os környezet esetén Active Directoryból importálni felhasználókat. Így jelszavuk szinkronizált marad a hálózaton belül ezen az interfészen is. A feladat kezelői felületének bemutatása A program indulásakor a MAIN képernyő jelenik meg, ennek a biztonsági kódja *, vagyis bárki elérheti.
11. ábra: Az első feladat ’MAIN’ képernyője
A DEFAULT felhasználónak nincs megadva az A jelű kód, viszont a gombok felületéhez, amit a ’Buttons’ gombbal lehet elérni, ez van hozzárendelve. A ’Login’ gomb a bejelentkezéshez vezet minket, míg a ’Shut down’ kiléptet a programból.
10
Ha elvégeztük a bejelentkezést egy olyan felhasználóra, aki rendelkezik A jelű jogosultsággal, akkor a ’Buttons’ gombra kattintva megjelnik a gombok kezeléséhez tartozó ablak, ami a 12. ábrán látható.
12. ábra: Az első feladat 'Buttons' képernyője
Ezen az ábrán az összes gomb be van nyomva, tehát az 1 és 2, az 1 és 3, valamint a 2 és 3 állapotoknak megfelelő lámpák világítanak. A lámpák Multistate Indicator-ok, a gombok pedig Multistate Push Button-ok. Mindegyik egy neki megfelelő TAG-hez van kapcsolva a PLC-n belül. Ezúttal a bemenetek és a kimenetek nem az I/O modul egy-egy portját módosítják, hanem TAG-eket a memóriában. A képről megállapítható az is, hogy a 2 és 3 állapot jutott legutóbb érvényre, mivel a szöveges kijelző értéke erre utal. A kijelzők karakterlánc, illetve szám megjelenítők. Ezek szintén egy-egy TAG-hez vannak kapcsolva a PLC-ben, méghozzá azon saját típusú objektumhoz, amelybe mindig bele másolja az adott CPS parancs az állapotnak megfelelő változót. Ezen belül értelemszerűen a STRING változóhoz csatlakozik a karakterlénc kijelző, és az INT-hez a szám kijelző. Az már csupán megjelenítésbeli trükk, hogy maguk a megjelnítők áttetsző háttérrel rendelkeznek, és a betűtípusuk úgy van beállítva, hogy nagyon pixeles legyen, amitől mátrix kijelző hatását adják vissza. A háttér pedig mögéjük van helyezve egy kép formájában. Ez az LCD kijelző ábra megtalálható a Symbol Factory-ban. A feladat kiírásában meg volt adva az, hogy abban az esetben, ha egyik specifikált eset sem áll fenn, akkor az 5. lámpát villogtatni kell 50%-os kitöltéssel. Ez a villogtatás a PLC-n belül történik időzítők segítségével. Ugyanakkor a piros körnek a szám kijelző mellett csupán az szerepel a specifikációjában, hogy villogjon. Ezt már úgy oldottam meg, hogy a kör egy Multistate Indicator és az aktiválását jelző TAG 0 értéke esetén teljesen átlátszó a kinézete, és 1 érték esetén pedig a kép jelenik meg, de az ’Image Blink’ opció be van állítva hozzá. Így ezt a villogtatást a megjelnítő szoftver végzi el.
III.
Második feladat: ismerkedés a mintaprogramokkal
Második feladatom az volt, hogy tanulmányozzam a FactoryTalk Studio-ban található mintaprogramokat, melyekhez RSLogix 5000 project is tartozik. Az alábbiakban bemutatom, milyen tanulságokra tettem szert ennek során.
11
Malthouse mintaprogram Animált elemek A könnyebb érthetőség érdekében megfontolandó animációkat alkalmazni a HMI project-ekben. Ezek segítségével mozgásba hozhatók a képernyő elemei és interaktívabb élményt nyújthatunk a kezelők számára. Viszont nem minden esetben szükséges és indokolt a használatuk, óvatosak kell legyünk az alkalmazásukkor. A túlzott mennyiségű animációk használata elvonhatja a kezelő figyelmét a folyamat lényegi részéről, ami hibához, esetleg balesethez vezethet. A FactoryTalk Studio animáció készletét a 13. ábra szemlélteti.
13. ábra: Egy animált elem és annak animációs beállításai
A fenti ábráról látható, hogy több módon is animálható egy elem. Animálható a vízszintes/függőleges pozíciója, a forgása, a láthatósága, a kitöltésének színe, a kitöltöttsége oldal irányban vagy függőlegesen, valamint a szélessége és hosszúsága. Mindezek TAG-ek értékeinek függvényében határozhatóak meg. A 13. ábrán a ventillátor forog a középpontja körül, és ehhez az egyik rendszer változót használta fel a tervező, méghozzá a BlinkFast-et, ami 100 ms-onként váltja a kimenetét, vagyis ez egy 5 Hz-es négyszögjel. A helyes konfiguráció elérése érdekében be kell állítani a megadott kifejezés minimum és maximum értékeit, valamint az animáció mértékét ebben a két szélső értékben. A fenti féldában ez a forgás úgy valósul meg, hogy 0° és 360°-ot állíott be a tervező a két szélső értékhez. Így ha a BlinkFast változó éppen 0 értéket vesz fel, akkor 90°-ot forgat a képen, valamint 180°-ot ha 1 az értéke. A felsorolt animációk ehhez hasonló módon valósíthatóak meg a nekik megfelelő menü használatával. A fentiek mellett két különleges animációs lehetőséget biztosít a fejlesztő környezet: függőleges és vízszintes csúszka (Vertical/Horizontal Slider). Ha ezek közül az egyiket kiválasztjuk, akkor az elem egy beviteli eszközzé alakul, és pozíciója alapján frissíti a hozzá kapcsolt TAG értékét. A 14. ábrán láthatunk egy mintát függőleges csúszkára. Beállításait tekintve hasonló a feljebb tárgyaltakkal, viszont fontos tudatában lennünk, hogy ez már bemenetként funkcionál a PLC számára.
12
14. ábra: Egy függőleges csúszka elem, és annak animálciós beállításai
Egy fontos, nem elhanyagolható részlet, hogy ilyen animációkat csupán geometriai elemeken hajthatunk végre (például téglalap, kör, poligon, szabad kézzel rajzolt körvonalak), ami azt jelenti, hogy kép objektumokon, vagy gombokon nincs ilyenre lehetőségünk. Ezeknek csak a láthatóságát (Visibility) lehet egy BOOL kifejezéssel állítani. HMI TAG-ek A FactoryTalk View Studio-ban is definiálhatunk TAG-eket, ezeket a project böngésző HMI Tags csoportja alatti Tags menüpontból előjövő ablak segítségével szerkeszthetjük. Ezek a Tag-ek egészen más funkcióval rendelkeznek a PLC-ben definiáltakhoz képest. Saját memória területtel nem rendelkeznek, csupán arra szolgálnak, hogy a PLC-ben létező TAG-eket más néven érhessük el a HMI szerkesztőből.
15. ábra: HMI Tag szerkesztő
Első ránézésre talán úgy tűnik, nem túl fontos ezeknek a HMI Tag-eknek a használata, ezek nélkül is kiválóan tud működni a vezérlés és a megjelenítés is. Azonban fejlesztés során fontos, hogy amely szerkesztendő elemek egy logikai egységhez tartoznak, ne hivatkozzanak egy másik egység elemeire. Amennyiben ilyen kapcsolatra van szükség, egy ennek megfelelő interfészt kell biztosítani, különben a másik logikai egység elemeinek változása hatással lenne az adott egység struktúrájára is. Fejlesztés során előfordulhat, hogy miután elvégeztük a PLC programozását, és a HMI felületet tervezzük, kiderül, hogy szükséges még a PLC program módosítása annak érdekében, hogy a felületen elérjük azt a hatást, amit szeretnénk (például animálni szeretnénk egy elemet máshogyan, mint eddig tettük, és ehhez szükséges egy újabb 13
változó kezelése, és egy előző lecserélése). Ebben az esetben a PLC program módosítása után csak a HMI Tag-ekben kell a megfelelő hivatkozást beállítani, és az összes elem az összes képernyőn az eddig megszokottnak megfelelően fog működni. Ha nem használtuk volna a HMI Tag-eket, akkor meg kellett volna keresni minden olyan elemet, amely hivatkozik a módosított TAG-re, és egyesével elvégezni a módosítást. Így viszont központilag, nagyobb erőfeszítések nélkül sikerült a változtatást elvégezni. A HMI környezethez alakítható struktúra érdekében saját csoport hierarchiát hozhatunk létre, melyen belül elkülöníthetőek a különböző típusú Tag-ek. Így nincs szükség arra, hogy az eredeti Taskok szerinti hierarchiához igazodjunk, mint ami a PLC-hez kapcsolódik. A példában a parancsok jól elkülönülnek a ’Commands’ csoportba sorolva a többi jelzéstől, amiket a többi felületen használ a program.
InstantFizz mintaprogram FactoryTalk View Studio – Site Edition A FactoryTalk View Studio másik változata a Site Edition. Ebben már Windows platformon futtatható programok szerkesztésére van lehetőségünk. Így a vállalat alkalmazhat kommersz számítógépeket is a folyamatba való beavatkozásra, ahelyett, hogy drága megjelenítőket kelljen beruháznia a gyártótól. A fejlesztő szoftver felhasználói felületének felépítése megegyezik a Machine Editionel teljes mértékben. Ami igazi különbség, az csupán néhány alkalmazható elemben lelhető fel. Ilyen például a Windows stílusú gomb, és a képernyő terv maga. A képernyő beállításaiban sok különbség van. Megjeleníthetünk több ablakot is egyszerre, ezek hierarchiába szervezhetőek. A mintaprogram esetén látható egy ötletes megoldás navigációs panel használatára az alábbi ábrán.
16. ábra: Az InstantFizz mintaprogram fő képernyője, alul a navigációs panellel
14
IV.
Harmadik feladat: vagontöltő berendezés
A harmadik feladatom egy vagontöltő berendezés programozása volt. „A vagont szilárdanyag tárolóból (siló), adagolócsiga és szállítószalag segítségével töltik fel. Az adagolást a START gomb megnyomásával engedélyezik. A START jel csak akkor hatásos, ha a vagon töltési helyzetben van (S2 jelez). Ekkor az adagolandó anyag feltorlódásának elkerülése érdekében először a szállítószalagot kell elindítani, és 3s-ig üresen járatni. Az idő letelte után bekapcsolható az adagolócsiga motorja is. Ha megtelt a vagon, vagy a vagon elmozdult a töltési pozíciójából, vagy megnyomták a STOP gombot, az adagolócsigát azonnal le kell állítani. Ekkor a szállítószalag még 5s-ig bekapcsolva marad, hogy teljesen leürüljön. Újabb adagolást a START gomb ismételt benyomásával lehet elindítani.”
M
K2
M S2 K1 S3 17. ábra: A 3. feladat vázlatos ábrája
Összerendelési táblázat Bemenetek START gomb STOP gomb Rámpaérzékelő Súlyérzékelő Kimenetek Szállítószalag motor Adagolócsiga motor
Jel START STOP S2 S3
Logikai összerendelés benyomva: START = 1 benyomva: STOP = 1 a vagon töltési pozícióban: S2 = 1 a vagon tele: S3 = 1
K1 K2
bekapcsolva: K1 = 1 bekapcsolva: K2 = 1
Ez a feladat eredeti formája, amit kiegészített a konzulensem több részfeladattal. Ezek elsősorban a folyamat szimuláció és vezérlés szétválasztását, a motorok add-on instruction-el való megvalósítását és a vezérlés sorrendi folyamatábrával és létra diagrammal egyaránt megoldását jelentették. A vizualizáció iránt támasztott különleges követelmények annak tárgyalásánál kerülnek ismertetésre. 15
Szétválasztott folyamat szimuláció és vezérlés Mivel a valós folyamat nem áll rendelkezésünkre, ezért szükség van annak emulátorban történő megvalósítására. Ezt meg lehet oldani a ciklikus task-ban is, de sokkal célszerűbb egy periodikus task-ot létrehozni, és abban implementálni minden olyan program részletet, ami kizárólag a folyamat szimulációját szolgálja. Így ha valós folyamathoz akarjuk csatlakoztatni a programot, akkor csupán a periodikus task futását kell letiltani, és a megfelelő bemeneteket és kimeneteket átirányítani. A vezérlés szempontjból ami kimenet, az a folyamat számára bemenet lesz, és fordítva. Az egyetlen dolog, amire oda kell figyelnünk, az a TAG-ek helyes elhelyezése. A vezérlő szintjén létre kell hoznunk TAG-eket annak érdekében, hogy a két task kommunikálni tudjon egymással. A fent említett jogosultságokat a Cross Reference (kereszt referencia) eszközzel ellenőrizhetjük, de helyes meghajtásukat nekünk kell észben tartani az implementálás során.
Add-on instruction Amennyiben egy folyamatban több hasonló eszközt alkalmaznak, melyeket mind egyforma módon kell vezérelni vagy szimulálni, akkor célszerű a programozás során egyszerűsítéseket tenni, ahelyett, hogy egyesével hoznánk létre a nekik megfelelő TAG-eket és programokat. Ha mégis így tennénk, akkor egy esetleges módosítással az eszköz modellében sok helyen át kéne írni a programot, ami rengeteg hibalehetőségre ad okot. Egy ilyen egyszerűsítési lehetőség, ha egy saját adatstruktúrát definiálunk, melyben egy eszköz modellének TAG-jeit írjuk le, és abból egy tömböt deklarálunk. Így csupán a létrasorokat kell implementálnunk minden egyes elemhez. Viszont ezzel csupán az új elemek hozzáadását segítettük elő, a módosítást nem. Ha az adatstruktúra változik, valószínűleg a logikán is változtatni kell. Így megintcsak sok helyen változtatnunk kell a programon, csupán a szükséges adatok lefoglalását sikerült leegyszerűsíteni. Egy másik megoldás az Add-on instruction használata. Ezek olyan összefüggő struktúrák, melyek saját adatterülettel rendelkeznek, és saját logika a is rendelhető hozzájuk, melyek parametrizálhatóak. Vagyis ha ilyet alkalmazunk, akkor a logikában történő változás is könnyedén kivitelezhető az összes implementált elemre. Nincs más dolgunk ekkor, mint az Add-on instruction elem logikáját megváltoztatni. Ebben az esetben viszont már nem lesz lehetőségünk a teljes rendszeren hibakeresést használni. Az Add-on instruction ugyanis teljesen elrejti az adott kiértékelt létrasort az egyes elemek esetében. A feladatomban a két Motornak a működtető kétállapotú bemenetén kívül még van a készenlétet jelző, valamint a bekapcsolt állapotot jelző kétállapotú kimenete is. Mivel két motor szerepel a feladatban (melyeket azonos elemeknek tekinthetünk), ezért az ilyen állapotokra külön TAG-eket és logikát kellene alkalmazni. Azonban megoldásomban Add-on instruction-t választottam, az esetleges későbbi fejlesztési plusz munkák elkerülése végett. Ez hasznosnak is bizonyult, mert elsőre rossz kimeneteket rendeltem hozzá a motorokhoz. Ezt a hibát így nagyon könnyedén és gyorsan ki lehetett javítani.
A vezérlés megvalósítása sorrendi folyamatábrával Ez a feladatot már mindenképp állapotgéppel kell megoldani, mivel a leírásból jól látszik a sorrendiség. 16
START
áll
K2
járat
tölt
S2 és (S3 vagy STOP)
kifuttat
￢K1
￢S2 és ￢S3 és ￢STOP
￢S2
kifuttat hibával
￢K1
18. ábra: A 3. feladathoz megvalósított állapotgép állapotgráfja
Az eredeti feladathoz a konzulensem hozzátette, hogy amennyiben a kocsi kimozdul a helyéről, jelezzen hibát a rendszer. Ezeket azon állapotok esetén vezettem be, mely során a kocsi még biztosan nem volt feltöltve. Amennyiben már fel volt töltve, és úgy mozdul ki a helyéből, akkor a kocsi töltöttsége szempontjából nem történik hiba. Ilyenkor felesleges lenne még egyszer kifuttatni a szállítószalagot, mivel a kocsi úgysincs a helyén. Ezen kívül még azt a kiegészítő utasítást kaptam, hogy legyen még lehetőség kézi vezérlésre is, és gondoljam át, mely állapotok esetén engedhetjük meg ezt az átváltást. Azt gondolom, a kézi vezérlés célja, hogy ha az operátor hibát észlel, legyen lehetősége azonnal közbeavatkozni, és azt elhárítani. Ez minden állapot esetén előfordulhat, ezért mindig engedélyeznünk kell ezt a lehetőséget. Bajt igazából csak az okozhat, ha az adagolócsiga megy, de a szállítószalag nem, vagy a vagon nincs a helyén, vagy az teli van. Ezeknek a lehetőségét viszont mindenképp meg kell akadályoznunk. Úgyhogy ha ezeket a limitációkat beállítjuk a kézi vezérlés üzemmódjában, akkor biztonsággal átléphetünk erre minden esetben. A kézi vezérlés a 18. ábrán nem látszik külön állapotként, mert túlságosan kusza lenne, ha az is fel lenne tűntetve. Mivel létra diagramban is meg kellett valósítani a vezérlést, és sorrendi folyamatábrában is, ezért célszerűnek láttam külön létra diagramban implementálni a kézi részt. Így a folyamatábrán sem jelenik az meg. Úgy gondolom, fontos alapelv, hogy a kézi beavatkozás logikája ne tartalmazzon sorrendiséget, azaz kizárólag kombinációs logikával legyen megvalósítva. A sorrendi hálózat magában hordozza azt a lehetőséget, hogy egy program ágról megfeledkezünk, és ebbe lépve indefinit állapotba viszi a berendezést, vagyis elveszíthetjük az irányítást felette. A kombinációs logikák jól átlátható diagramokat eredményeznek, így az ilyen jellegű balesetek elkerülhetőek. A fő létra hálózat és a sorrendi folyamatábra közötti váltást egyetlen változó segítségével lehet kiválasztani, melyet konstansként definiáltam a ciklikus task TAG-jei között. Annak érdekében, hogy ne legyen túl sok memória lefoglalva a kétféle megoldás miatt, a létra is ugyan azokat az állapotjelző TAG-eket használja, mint a folyamatábra. Az utóbbihoz tartozó akciók sajnos nem használhatóak újra a létra diagramban. Ugyan ez elmondható azokra a számlálókra is, melyeket a létra diagramban használok: ezek nem alkalmazhatóak a folyamatábrán.
17
19. ábra: A megvalósított sorrendi folyamatábra. Automatikus normál működés esetén a bal ág fut végig, hiba esetén átlép a jobb oldalira.
A vizualizáció bemutatása Ahogy a működéssel, úgy a vizualizációval szemben is voltak plusz elvárásai a konzulensemnek. Ezek közé az alábbiak tartoznak: legyen egyértelmű visszajelzés arról, ha hiba történt legyen visszajelzés arról, hogy automata vagy kézi módban vagyunk kézi módban legyen külön szerv a szállítószalag és az adagolócsiga kezelésére legyen megjelenítő a motorok extra kimeneteiről (kész, megy/áll) minél barátságosabb, esztétikusabb kinézet Sok próbálkozás után az alábbi két képernyő készült el:
18
20. ábra: A 3. feladat fő vizualizációja
Ha a feladatban leírt kezdeti feltételek megfelelőek, és automatikus módban vagyunk, majd megnyomjuk egyszer a START gombot, akkor a folyamat elindul a leírtaknak megfelelően. Minden egyes kétállapotú változó mellett található egy lámpa, amely zölden jelzi, ha az épp aktív, valamint pirosan, ha nincs meghajtva. Ezen felül a szállítószalag két fajta színkonfiguráció között váltogat folyamatosan, amivel a mozgás hatását kelti. Az adagolócsiga esetén is van némi animáció: ha működik, akkor a tükörképe között váltogat folyamatosan, amivel a forgás hatását kelti. Ha a szállítószalag és az adagolócsiga egyszerre működik, akkor a szalagon megjelennek a feltöltő anyag darabkái. A vagon pozíciója az S2 jelzés felett található nyíllal állítható. Töltési pozícióban teljesen rajta áll a mérlegen, egyéb esetben félig lelóg róla. Ha nincs teli, valamint töltési pozícióban van, és mind az adagoló, mind a szállítószalag működik egyszerre, akkor a vagon belsejében a fehér tároló rész elkezd kitöltötté válni. Az ezt lekezelő logika a PLC folyamat szimulációs task-jában van kialakítva. A feladatban nem szerepel, de ha rendelkezésünkre állna egy analóg jel a mérleg aktuális mért értékéről, akkor valós folyamat esetén lehetne azt alkalmazni a töltöttség szintjéhez. Ez kiváló példa a HMI Tag-ek hasznosságára: ezt a változtatást megtenni csupán annyiból állna, hogy a HMI Tag-ek felületén a kitöltöttséget reprezentáló Tag-hez tartozó értéket átállítjuk a mérleg bemenetére, és az annak megfelelő maximum és minimum értékekre skálázzuk azt. Ha a vagont kibillentjük a pozíciójából töltés közben, akkor a HIBA jelzés kigyullad, és megjelenik alatta egy ’Nyugtázás’ feliratú gomb. A folyamat ekkor azonnal kifuttatja a szállítószalagot és leáll. A hibajelzés addig fennáll, amíg az nincs nyugtázva. Amennyiben kézi vezérlésre állítjuk át az erre szolgáló kapcsolót, akkor ennek érvényre jutásáról a felette található lámpa értesít minket. Ekkor egyenként állíthatjuk a szállítószalag és az adagolócsiga futását. Mindkét gomb Multistate Push Button, vagyis ha benyomjuk a gombot, akkor a háttérben beállít egy neki megfelelő TAG-et. Ezek az értékek közül azonban kizárólag a szállítószalag állítja közvetlenül a motor állapotát. Az adagolócsiga 19
működésének feltétele, hogy a szállítószalag működjön. A helyes visszajelzés érdekében ezért az adagolócsiga gombja egy átlátszó felületű, két állapotú gomb, és mögé van helyezve egy négy állapotú indikátor. Ez a konfiguráció így azt a hatást kelti, hogy ha megnyomtuk a gombot, akkor az benyomódottnak látszik. E mellett pedig világít, ha teljesülnek a működés előfeltételei, és megy is a motor. A negyedik állapot – amikor nincs benyomva a gomb, de világít – nem fordulhat elő, ez a PLC logikájában le van tiltva. A kézi vezérlés beállítása tehát nincs feltételhez kötve. Azonban az automatikus vezérlés csak akkor választható ki, ha a szállítószalag, és az adagolócsiga sem megy. Erre azért van szükség, hogy az állapotgépnek mindenképp egy definit állapotába kerüljünk vissza a kézi vezérlésből. A motorhoz tartozó pulsz kimenetek inkább diagnosztikai okokból lehetnek szükségesek. A folyamat szempontjából csupán kiegészítő információk, ezért nem szükséges hogy folyamatosan lássuk ezeket az értékeket. Emiatt egy külön gombon keresztül érhetőek ezek el, ami a bal alsó sarkában található a képernyőnek.
21. ábra: A 3. feladat motor tulajdonságok képernyője
V.
Szisztematikus hibakeresés
Hiba esetén fontos, hogy el tudjuk dönteni, milyen jellegű a hiba eredete. Minden esetben ennek kell lennie az első lépésnek, különben az időnket vesztegetjük azzal, hogy nem ott próbáljuk meg orvosolni a problémát, mint ahol az valójában fellépett. Sok esetben nem triviális ennek a kérdésnek a megválaszolása. Ilyen esetben érdemes egy rétegezett struktúrát felállítani, amelyben jól elkülöníthetőek a problémák okai, azoknak hatásai. Az észlelt hibajelenség alapján lehet egy elsődleges becslésünk, ami alapján kiválaszthatunk egy réteget, majd ha azon a szinten mindent rendben találtunk, akkor tovább léphetünk alsóbb, esetleg felsőbb rétegek irányába. Az 1. táblázat tartalmaz egy lehetséges felosztást a működési rétegekre. Tapasztalatom csupán a Futási rétegtől kezdődően felfelé van. Ezeknek mindegyike esetén sikerült az emulátorral kapcsolatban hibajelenségekre bukkannom. A többi réteget tanulmányaim során szerzett tudásom alapján igyekeztem elkülöníteni.
20
Réteg neve
Jellemző
A HMI megjelenítő egyértelmű, és hihető visszajelzést ad a folyamat állapotáról.
A PLC programjára vonatkozó jellemzők.
A program hiba nélkül végzi el a folyamat irányítását.
A felprogramozott PLC programjának futtatására vonatkozó jellemzők.
A felprogramozott PLC operációs rendszere megfelelően van felkonfigurálva, és megfelelően futtatja a programot. A PLC és a szenzorok, beavatkozók, illetve a fejlesztő környezet közötti fizikai kontaktus biztosított a megfelelő csatlakozókon keresztül. Zavarjelenségek nem befolyásolják a folyamat jeleit. A folyamatirányítás szempontjából minden fontos fizikai jellemzőt mérünk, és ahol szükséges, ott be tudunk avatkozni.
Megjelenítési réteg
Logikai réteg
Futási réteg
Fizikai réteg
Folyamatbeli réteg
Helyes működés
A HMI megjelenítővel kapcsolatos jellemzők
A szenzorokkal és beavatkozó egységekkel, valamint a fejlesztő eszközökkel és a HMI megjelenítővel való kapcsolat jellemzői.
A folyamat fizikai modelljére vonatkozó jellemzők.
Lehetséges hibák Hibás, vagy megtévesztő adatok közlése a HMI megjelenítőn, rosszul kezelt animáció, nem megfelelően kezelt HMI Tag. Állapotgép nem mindegyik ágának lekezelése, rossz sorrend meghatározása, hibás kombinációs logika implementálása. A vezérlő nem futás módba van állítva, a PLC operációs rendszere meghibásodott, vagy egy task futási paraméterei nem megfelelőek. Egy kontaktus egyáltalán nem, vagy nem megfelelően van bekötve.
Hibásan megtervezett folyamatirányítás.
1. táblázat: Egy folyamatirányítás elkülöníthető rétegei
VI.
Felhasznált irodalom
[1] Dr. Ajtonyi István, Dr. Gyuricza István: Programozható irányítóberendezések, hálózatok és rendszerek [2] Logix5000 Controllers General Instructions Reference Manual http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756rm003_-en-p.pdf [3] Automation Wiki: RSLinx http://automationwiki.com/index.php?title=Rockwell_Automation_Software/RSLi nx
21
VII.
Ábrák jegyzéke
1. ábra: Az RSLogix5000 szerkesztő ablaka .................................................................. 2 2. ábra: Task hozzáadása ................................................................................................ 3 3. ábra: TAG hozzáadása ................................................................................................ 3 4. ábra: Program szegmens hozzáadása.......................................................................... 4 5. ábra: RSLogix Emulate 5000 Chassis Monitor .......................................................... 5 6. ábra: RSWho kapcsolatfelvétel az RSLogix 5000-ben .............................................. 5 7. ábra: Egy létrahálózat részlete. ................................................................................... 6 8. ábra: A FactoryTalk View Studio Machine Edition felépítése .................................. 7 9. ábra: A Symbol Factory eszköz .................................................................................. 8 10. ábra: Egy FactoryTalk View Studio project Runtime Security ablaka .................. 10 11. ábra: Az első feladat ’MAIN’ képernyője .............................................................. 10 12. ábra: Az első feladat 'Buttons' képernyője ............................................................. 11 13. ábra: Egy animált elem és annak animációs beállításai .......................................... 12 14. ábra: Egy függőleges csúszka elem, és annak animálciós beállításai .................... 13 15. ábra: HMI Tag szerkesztő ...................................................................................... 13 16. ábra: Az InstantFizz mintaprogram fő képernyője, alul a navigációs panellel ...... 14 17. ábra: A 3. feladat vázlatos ábrája ........................................................................... 15 18. ábra: A 3. feladathoz megvalósított állapotgép állapotgráfja ................................. 17 19. ábra: A megvalósított sorrendi folyamatábra.. ....................................................... 18 20. ábra: A 3. feladat fő vizualizációja ......................................................................... 19 21. ábra: A 3. feladat motor tulajdonságok képernyője ................................................ 20
22
