Budapesti Műszaki és Gazdaságtudományi Egyetem Irányítástechnika és Informatika Tanszék
Siemens PLC-k alkalmazástechnikája és programozása Félév végi beszámoló az önálló laboratórium tárgy keretében, a Gamma Digital Kft-nél végzett munkáról
Készítette: Konzulensek:
Németh Zoltán (ANYZ72), a 2012/2013-as tanév tavaszi félévében Nagy László Dr. Kiss Bálint
1. Bevezető, motivációk Bár az egyetemre úgy érkeztem, hogy nem volt egyértelmű számomra, hogy milyen irányba fejlődjek a villamosmérnöki szakmán belül, az ötödik félévre már körvonalazódott bennem, hogy mit csinálnék szívesen. Egyáltalán nem idegenkedek a programozástól, szívesen foglalkozok logikai feladatokkal, algoritmusokkal, folyamatok leírásával, részfolyamatok, események egymásra épülésével, ok-okozati viszonyaival. Szeretem az olyan feladatokat, amik nem elvontak, könnyen el lehet képzelni, hogy az adott mechanizmus hogy működik. Motivál, ha a munkám eredményét látom a gyakorlatban működni, összességében közelebb áll hozzám a gyakorlat, mint az elmélet. Igaz, hogy az önálló laboratóriumi témám kiválasztása előtt semmi kapcsolatom nem volt a PLC-kel, és nem is tudtam róluk túl sok mindent, éreztem, hogy az ipari irányítástechnikával, automatizálással nem nagyon nyúlhatok mellé. Így esett a választásom a Gamma Digital Kft.-nél (továbbiakban: cég) végezhető önálló laboratóriumra. Most a féléves munka után úgy gondolom, nem is választhattam volna ennél jobban.
2. A PLC és a LAD nyelv bemutatása Napjainkra az ipari automatizálás alapvető eszközévé a PLC (Programmable Logic Controller) vált. Térhódítása a 70-es években kezdődött, a General Motors ekkor írt ki pályázatot egy programozható vezérlőberendezés fejlesztésére. A pályázatban szereplő feltételek egy mai PLC-nek is alapvető jellemzői:
nagy megbízhatóság, nem tartalmaz mozgó alkatrészt, ezért hosszú az élettartama, a be- és kimenetek galvanikusan leválasztottak, egyszerű felépítés, kis méret, könnyű programozhatóság, valós idejű működés.
Ezek a tulajdonságok képessé teszik a PLC-t, hogy megfeleljen az ipari környezet elvárásainak. A vezérlési és folyamatirányítási feladatokat tárolt programmal valósítják meg, és képesek a technológiai folyamatok közvetlen irányítására. A PLC-re a ciklikus programvégrehajtás jellemző. Felépítésüket tekintve megkülönböztetünk moduláris, illetve kompakt PLC-ket. A kompakt PLC-k kisméretűek, de hardver struktúrájuk nem módosítható. A moduláris PLC-k különböző modulokból épülnek fel, ezek mindegyike egy meghatározott speciális funkciót lát el, pl. CPU egység, kommunikációs egység. A modulokat egy ún. rack-be (tartó, sín) dugaszolhatjuk, így a hardverkonfigurációt sokféleképp lehet összerakni (lásd: 1. ábra). A rack-et természetesen megfelelően védett műszerszekrénybe kell elhelyezni. A SIEMENS Simatic S7 család, aminek a programozásával a félév folyamán foglalkoztam, a moduláris PLC-k közé tartozik. A PLC-k hardvere univerzális, központi feldolgozóegységük egy általános célú mikroprocesszor. A fentiek alapján a PLC-ket a következő módon definiálhatjuk: „A PLC olyan ipari számítógépnek tekinthető, amely speciális hardveregységei és felhasználói
programja révén a technológiai folyamatok tárolt programú irányítására és intelligens kommunikációs felülete révén hierarchikus és/vagy osztott folyamatirányító rendszerek létrehozására alkalmas.”1 A PLC-k biztonsági szempontból is több kategóriába sorolhatók, eszerint vannak az „alap” PLC-k, valamint az Ex, F, H, FH, besorolásúak. Utóbbiak ára sokkal magasabb az alap PLC-k áránál. Az Ex robbanásbiztos berendezéseket jelöl, jellemzően csak a hardverkövetelmények szintjét emeli, a programmal szemben nem támaszt extra elvárásokat. Az F a hibatűrő rendszereket jelöli (fail-safety), fontos tulajdonságuk, hogy a SIL norma szerinti öt SIL szint közül melyiknek felelnek meg. A besorolást hatásanalízis előzi meg, magasabb szinteken csak független külső szakértő bevonásával állapítható meg a biztonsági szint. A H redundáns rendszereket jelöl, ez lehet szoftveres, vagy hardveres is. A SIEMES PLC-k közül jellemzően a Simatic S7 család S7-300-as és 400-as tagjait alkalmazzák. A leggyakoribb a 300-as, a 400-as általában a nagy üzembiztonságot igénylő rendszereket szolgálja ki. A moduláris felépítés miatt az egységeket a sínre lehet feltenni, sorrendjük valamennyire kötött. A feltöltött program a belső memóriába kerül, ez lehet többek között integrált RAM, vagy csatlakoztatható memóriakártya. A CPU-ba integrálva található a rendszermemória. Ide kerülnek a merkerek, timerek, számlálók, a hívott funkciók lokális adatai. Innen kerülnek 1. ábra: Simatic S7 PLC-k továbbításra a beolvasott bemenetek és a kimenetek. Akkumulátor használata esetén árammentes helyzetben is megőrzi az adatokat. A munkamemória is a CPU-ba van integrálva, a felhasználói program és a hozzá kapcsolódó DB-k innen kerülnek meghívásra. A rendszermemória és a munkamemória nem bővíthető. A PLC-n található kulcs kapcsoló állásai megtalálhatók a szimulációs programban is (lásd később), jelentésük a következő:
RUN-P: futtatás programozói módban, menet közben módosítható a program, RUN: futtatás védett módban: a program nem módosítható, STOP: a program leállítása, MRES: teljes törlés.
Ezen kívül a CPU-n vannak LED-ek (pl. különböző módok jelzésére), különféle csatlakozók típustól függően (pl. MPI, profinet). A CPU-n kívül sokféle Simatic S7 modul létezik, különféle I/O kártyák és funkciós kártyák (pl. számláló, pozicionáló, szabályzó). A PLC működéséhez azonban nyilván nemcsak hardverre, hanem megfelelő programra is szükség van. A PLC programnyelvek más elveken alapulnak, mint a magas szintű programnyelvek. A PLC programok teljesen szekvenciálisan futnak, a futásuknak 1
Lásd 2. forrás, 13. oldal
szintideje van. Az eseményvezéreltség nem értelmezhető a program futásánál, megszakításokat is csak egyedi megszorításokkal lehet alkalmazni. Jellemző, hogy egy adott gyártó eszközére írt program nem vihető át egy másik gyártóéra. A PLC-k hasonlóságából fakadóan azonban hasonlítanak egymásra. A következőkben a programok szerkezeti elemeiről, és a félév során használt LAD nyelvről szerzett ismereteket foglalom össze. A program néhány alap építőelemből (német: Baustein, angol: block, továbbiakban blokk) épül fel: OB: szervező blokk (Organisation Baustein), a főprogramot tartalmazza, innen hívjuk meg a program többi részét (pl.: FB, FC), legfontosabb az OB1, DB: kötetlen struktúrájú adatokat tartalmaz, az instanz DB-k egy FB-hez vannak hozzárendelve, míg a global DB-k adataihoz minden blokk hozzáfér, FC: paraméterekkel hívható funkcióblokk, FB-ből vagy OB-ból hívható, tárolt adatai minden híváskor újrainicializálódnak, FB: az FC-hez hasonló, de lehet értéktartó változója, a hozzárendelt DB-nek köszönhetően, SFC: zárolt rendszer FC, meghívható, de a kódja nem tekinthető meg, SFB: SFC-hez hasonló, de egy instanz DB-t kell hozzárendelni, UDT: felhasználó által definiált változó, VAT: változók követésére, állítására alkalmas, (további ismertetés a 3. és 4. fejezet egyes részeiben található). A félév során kapott feladatokat LAD (ladder diagram) nyelven oldottam meg, ez a grafikus rendszerű nyelvek közé tartozik. A létradiagram az áramúttervből alakult ki, szükségességét a relés hálózatok tervezéséhez értő szakemberek könnyebb átképzése indokolta. Az áramútterven a tápfeszültség párhuzamos vezetékei közé rajzoljuk a kapcsolást alkotó elemeket, ezek soros vagy párhuzamos kombinációit. A vezérelt és vezérlő elemek (pl. relé) nem feltétlenül egymás mellett helyezkednek el, inkább a működési sorrendben. Ezek a tulajdonságok a létradiagramra is igazak, de ez utóbbi csak logikai egyenletek leírására szolgál. Főbb elemcsoportjai: logikai, összehasonlító, számlálási, időzítési, számítási, ugrási vagy egyéb műveleteket megvalósító elemek. Létradiagram esetén az áramutakat (a „létra fokait”) két függőleges egyenes között ábrázoljuk vízszintesen, a bal oldali vezetékre csak logikai feltételen keresztül csatlakozhatunk. A LAD programozás lépései: bemeneti-kimeneti összerendelési táblázat készítése, logikai egyenletek meghatározása, létradiagram létrehozása, szimuláció.
3. A fejlesztőkörnyezet ismertetése A félév során a cégnél kapott fejlesztőkörnyezetet használtam. Ehhez szükség volt egy virtuális gép telepítésére, amin Windows XP operációs rendszer fut. A virtuális gépre telepített fejlesztőkörnyezetet tulajdonképpen három program alkotja: SIMATIC Manager, S7-PLCSIM és SIMATIC WinCC flexible 2008. Ezeket lehet használni a SIEMENS PLC-kre való fejlesztéshez. A SIMATIC Manager-ben folyik a program megírása. Itt a File/New gombra kattintva készíthetünk új projektet, ami a név megadása után létre is jön. Következő lépés a hardver
kiválasztása. Jobb kattintás a projektre, majd Insert New Object/SIMATIC 300 Station. Más lehetőségek is vannak, pl. S 400 Station, de a félévi munkához a 300-as bőven elegendő. Miután megjelenik a hardverünk, a menüjében meg kell határozni a konfigurációt. Elsőként a SIMATIC 300/Rack-300-ból a Rail elemre van szükségünk, ami a korábban említett sínnek felel meg moduláris PLC-k esetén. A félév során egyetlen modult használtam, a CPU egységet (CPU 315-2 PN/DP). További beállításokra nem volt szükség. A SIMATIC Manager oldalsávjában már láthatjuk a projekten belül a hardvert, valamint a programot (S7 Program), ezen belül a külső forrásokat (Sources) és a blokkjainkat (Blocks). A fejlesztés során gyakran használandó szimbólumtábla az S7 Programon belül érhető el. A szimbólumok használata sok előnnyel jár. Felvehetünk ide változókat, a nevükkel, címükkel, típusukkal, és kommentezhetjük őket. A szimbólumtáblában szereplő változókat bármikor használhatjuk a nevükkel. Ha szeretnénk, a LAD nyelvű programban a használt változóknak láthatjuk a nevét, címét, és a hozzájuk fűzött megjegyzéseket (beállítható, hogy pl. csak a nevük látszódjon). A szimbólumtáblában a létrehozott DB-k és VAT-táblák is megjelennek. Egy megfelelően elkészített szimbólumtábla nagyban növeli a program áttekinthetőségét, valamint a fejlesztést is megkönnyíti. A Blocks-on belül jobb kattintással hozhatunk létre új blokkot (Insert New Object, majd a típus kiválasztása, pl. Function Block). A félév során a LAD nyelvet használtam ez az új blokk létrehozásánál beállítható. Egy blokkot megnyitva láthatóvá válik a LAD program, az oldalsávból kiválaszthatjuk az elemeket és dupla kattintással vagy húzással elhelyezhetjük őket. Egy elemre kattintva az F1 gomb megnyomásával használható segítséghez jutunk. A legalapvetőbb feladatokat kivéve, egy blokkban több hálózatot (Network) is létrehozunk, ezeket elnevezhetjük, kommentezhetjük. Amint kész vagyunk a programmal, következhet az ellenőrzés, hibakeresés, ehhez szimulációra van szükség, amit a SIMATIC Managerből indítható S7-PLCSIM szimulációs programmal végezhetünk. A szimulációs program indulásakor ki kell választani a kapcsolat típusát (pl. MPI(1) addr: 2). Ezt követően a SIMATIC Managerben a PLC/Download segítségével letölthetjük a programunkat a szimulált eszközre. (Gyorsgomb az eszköztáron: ). A felugró üzenetekre értelemszerűen kell válaszolni, pl. tartalom felülírása a virtuális PLC-n. A futást a RUN-P-vel indíthatjuk. Amint fut a szimuláció, többféleképpen is monitorozhatjuk a működést a változóinkon keresztül. Egyrészt a szimulációs program is használható a változóink megfigyelésére, illetve futás közbeni módosítására. Van egy használhatóbb eszköz is, a VAT-tábla. A VAT-táblát a blokkokhoz hasonlóan hozhatjuk létre. Itt megadhatjuk, melyik változókat szeretnénk látni, vagy éppen azt, hogy értéküket milyen formátumban lássuk. A VAT-tábla használatára az első feladat leírásánál láthatunk példát. A félévi munka során a szimulációs program, illetve a VAT-tábla által nyújtott ellenőrzési lehetőségeket keveset használtam, ugyanis minden feladathoz készítettem HMI felületet is, ami még átláthatóbbá tette a programok működését, és könnyebbé az ellenőrzést. A SIMATIC WinCC flexible 2008 programmal HMI (human-machine interface) felületet készíthetünk a programhoz. Ez mind ellenőrzéshez, mind szemléltetéshez sokkal hasznosabb, mint a VAT tábla, vagy a szimulátor lehetőségei. Természetesen a szimulátornak futtatnia kell a programunkat, miközben a működést a HMI felületen ellenőrizzük. A WinCC-ben a Project/New gombbal hozhatunk létre új projektet. Ki kell választanunk az eszközt, pl. Multi Panels/270/MP 270 10" Touch. Amint ez megtörtént,
megjelenik a HMI felület alapja, valamint a Tools és a Project oldalsáv. A Project sávban először a Connections segítségével beállítjuk a kapcsolatot. Itt megadhatjuk a kapcsolat nevét, és be kell állítani a hardver felépítését (pl. azt, hogy a CPU a tartó (rack) melyik slotjában van). Ezt követően a Tags táblázatába fel kell vennünk azokat a változókat, amikre szükségünk van a HMI felület létrehozásához, bővítésre később is van lehetőség. Ezzel létrehoztunk minden szükséges kapcsolatot, beállítottuk az eszközöket, felvettük a változókat, felépíthetjük magát a HMI felületet. Az elemeket a Tools menüből választhatjuk ki. Az elemek tulajdonságait sokféleképp változtathatjuk, vannak elemtől függő speciális lehetőségek is, pl. input mezők. Többek között kiválaszthatjuk a színt, méretet, orientációt, láthatóságot, elhelyezési szintet (Layer, használatát lásd az utolsó feladatnál). Vannak változóhoz kapcsolható tulajdonságok, ilyen a szín megváltoztatása, a villogás, vagy épp az érték kijelzése. A beállítások megtétele egyszerű, nem igényel külön magyarázatot. A félévi munka során –mivel a hangsúlyt a LAD nyelv, és a HMI felület lehetőségeinek minél jobb megismerése kapta– nem tértünk ki a különböző kapcsolatok, eszközök részletes megismerésére, optimális kiválasztására. Ezeket a céges konzulensem javaslatát követve határoztam meg.
4. Első feladat: shiftelés A PLC-kel, és a fejlesztőkörnyezettel való megismerkedés után kaptam egy egyszerű feladatot, ezt a többi évfolyamtársamnak is meg kellett csinálni, akik a cégnél végezték az önálló laboratóriumot. A feladat az volt, hogy kétbájtnyi területet töltsünk fel 15 db nullával és egy db egyessel. Egy gombnyomás hatására egyel el kellett shiftelni az egyest, és a pozícióját kijelezni egy hétszegmenses számjegy segítségével. Ennek a vezérlését szegmensenként kellett megoldanunk. Egyéb kikötés nem volt, a saját ötleteink segítségével kellett megvalósítani a feladatot. A kész feladathoz VAT táblát, és HMI felületet is kellet csinálni, hogy a megfelelő működést ellenőrizni lehessen. Az új ismereteim alapján gyorsan eldöntöttem, hogy a program szerkezete milyen legyen. Az OB1-ből hívok egy FB-t (FB1) és a hozzá rendelt DB (DB1) tartalmazza a 16 bitet, amit egy wordben tárolok. A word típusú, 15 db nullát és egy db egyest tartalmazó változót bitsornak neveztem (továbbiakban így hivatkozok rá). A bitsor kezdőértéke: 00…01. Egyrészt a word típus mérete megfelelő, másrészt könnyű shiftelni. Ehhez egy beépített elemet, a „Shift Left Word” (SHL_W) blokkot lehet használni. Ez lényegében N-nel balra shifteli a kapott word bitjeit. Az alsó biteket pedig nullákkal tölti fel, ez kisebb problémát okoz, megoldását alább bemutatom. Az egység megismeréséhez a beépített helpet használtam. A nyomógomb 2. ábra: SHL_W felfutó éle engedélyezi a shiftelést, N-re egy konstans 1-et kötöttem, blokk mert mindig csak egyel shiftelek, az IN és OUT lábakra pedig a bitsort. Ezt még egy MOVE blokk követi, ami még megvalósít egy word-int konverziót, erre később a CMP blokknál lesz szükség. Ezzel tulajdonképpen elkészült a feladat első része, gombnyomásra shiftelhetjük a bitsort, aminek az értéke int típusú változóban is tárolódik (intsor), így könnyen felhasználható lesz a kijelzéshez.
Következő lépés a hétszegmenses kijelző vezérlése. Az ábrázolás tervezésénél megfordult a fejemben, hogy a 9-nél nagyobb számok esetén csak a kisebb helyiértéket írom ki, és a pontot használom a megkülönböztetésre. Végül azonban a hexadecimális ábrázolás mellett döntöttem, tehát az 1 értékű bit pozícióját a 0-F tartomány elemei adják. A kijelző vezérléséhez összesen 8 bitre lesz szükségünk, ezt egy byte típusú változóba (vez) írom be, az egyes helyétől függően. A vez bitjei egy-egy szegmensnek felenek meg (lásd 3. ábra). Az egyes helyének meghatározását a következőképpen oldottam meg. A bitsort már előzetesen átmásoltam az intsorba, így rendelkezésre áll int típusban is. Ennek lehetséges értékei pedig épp kettő hatványai, hiszen csak egy db egyest tartalmaz. A 16 lehetséges érték miatt 16 összehasonlító (CMP) blokkot alkalmaztam. Az IN1 3. ábra: szegmens bemenetükre az intsort, az IN2 bementekre pedig 2 megfelelő felosztás hatványát írtam (1-től 16384-ig, és az int definíciója miatt -32768-at). Ha valamelyik CMP blokk kimenete igaz lesz, engedélyeződik az adott MOVE egység, és egy előre meghatározott konstanst ír a vez változóba. Ezt a konstanst az alapján határoztam meg, hogy mit szerettem volna látni a kijelzőn. Pl. ha az intsor kettővel egyenlő, ez azt jelenti, hogy a bitsor egyese az 1. helyen van (a számozás nullától indul!), ezért egy egyest kell mutatnia a kijelzőnek. Ehhez a vez értéke binárisan 00000110, ami decimálisan 6, tehát ez kerül a vez változóba. Végül meg kellett oldanom azt, hogy az 10…00 shiftelése után a bitsorban csupa nulla lesz. Így az ehhez tartozó gombnyomásra egy csupa 0 helyzet jön létre. Sikerült úgy megoldanom a problémát, hogy az F érték utáni gombnyomásra rögtön a 0 érték jöjjön. Ehhez szükség volt még egy CMP egységre, ami a nullával való egyenlőséget vizsgálja. Ennek hatására (ha logikai 1 lesz a kimenete) a bitsorba egyet írunk, a vez-be pedig az ennek megfelelő vezérlést. Nincs tehát érvénytelen, csak nullákból álló bitsor egyik ciklus végén sem. Miután elkészültem a programmal, a helyes működést először egy VAT-tábla segítségével ellenőriztem le. Természtesen ennek készítése párhuzamosan folyt a program
4. ábra: a kijelző vezérlésének részlete
készítésével, hiszen segítségével követhető a működés, és kiszűrhetők az esetleges hibák. Mivel a HMI felülethez képest kevésbé szemléletes, a továbbiakban csak a hibakeresés egyik módjaként használtam, és nem feltétlenül hoztam teljesen kész állapotba, mikor elkészült a program. A VAT-tábla létrehozását a 3. fejezetben ismertettem. Egy változó felvételéhez csak be kell írni a táblázat következő sorába a változó címét, vagy nevét, majd a monitor value-vel (szemüveg rajz az eszköztáron) monitorozhatjuk a változót, valamint az is látszik, hogy fut a PLC. Új értéket a modify value oszlopba írhatunk, érvényesítéséhez a modify variable gombra kell kattintani. A gomb megnyomását például
úgy tudjuk szimulálni, hogy a nyomva sorában az utolsó oszlopba egyet írunk, és a modify variable gombra megyünk.
5. ábra: VAT-tábla használata
Végül a HMI felület készítését és működését ismertetem. A kapcsolat létrehozása után felvettem a bitsor, nyomva, és kimenet tageket, a kapcsolat és a cím megfelelő beállításával. A gombhoz egy Button elemet használtam, felirata: „Shiftelj!”. Az event menüben pedig a Press eseményre SetBit: ’nyomva’ következik, Release-re pedig ResetBit: ’nyomva’. Tehát a gomb lenyomásával egybe, elengedésével nullába állítjuk a ’nyomva’ változó értékét. Ezenkívül létrehoztam 16 db majdnem azonos tulajdonságú kis négyzetet. Ezek akkor lesznek zöldek, ha a bitsor hozzájuk rendelt bitje 1. Sorba rakva őket, láthatjuk az 1 db egyes mozgását a bitsorban. A digitális számot egyenesekből hoztam létre. Piros színűek, a láthatóságuk függ a ’vez’ megfelelő bitjének értékétől. A HMI összerakása után az eszköztár Start Runtime System gombbal próbálható ki a működés. A shiftelős feladat leírását néhány HMI képpel zárom.
6. ábra: A shiftelés HMI felülete
5. Második feladat: folyadékkeverés A shiftelős feladat befejezése után mindenki különböző feladatokat kapott. Nekem egy szakaszos üzemű folyadékkeverő berendezés vezérlését kell megoldani, a technológiai feladat két különböző folyadék összeelegyítése, és adott hőmérsékletre melegítése. A feladat illusztrálására a 7. ábra szolgál, ami a későbbi HMI felület részlete. Az összes többi, félév során megoldott feladat erre épül. Most csak az alapfeladatot ismertetem, a további bővítéseket a következő fejezetek feladatleírásai tartalmazzák. Az alapfeladat a következő: A berendezés szakaszos üzemben működik. Alapállapotban a tartály üres, a szelepek zárva vannak. A START nyomógomb megnyomására az MSZ1 nevű mágnesszelep nyit, az első folyadék beáramlik a tartályba. Ha az S2 szintérzékelő jelez, az MSZ1 szelep bezár, az MSZ2 szelep kinyit. Ekkor bekapcsol a keverés is, tehát már keverünk, miközben a 2. folyadék beáramlik. Ha megtelik a tartály (az S3 jelez), bezár az MSZ2, a keverés mellé pedig a fűtés is bekapcsol. Ha a tartályban lévő folyadék hőmérséklete elérte a kívánt értéket, jelez az S4 hőmérsékletérzékelő. Leáll a keverés és a fűtés, és kinyit az alsó mágnesszelep (MSZ3). Ha a tartályból kiürült a felmelegített
keverék, a START jelre elölről indulhat a folyamat. A kijelzőn található négy LED, amik azt jelzik, hogy épp melyik szakaszban van a folyamat. Látható, hogy a feladat már komolyabb logikát igényel, valamint a valósághoz is közelebb áll, mint az első feladat, és a félév során ez egyre inkább igaz lett, ahogy a működést fejlesztettem. A feladat megoldását egy szimbólumtábla létrehozásával kezdtem. A feladattal együtt a változók címét, logikai összerendelését is megkaptuk. Ahogy haladtam a feladat bővítésével, ugyan néhányat ezek közül nem, vagy módosított működéssel használtam fel, mindenesetre a nagyrészüket beleírtam a szimbólumtáblába. A 7. ábra: a folyadékkeverő illusztrálása szimbólumtáblát úgy tudom ismertetni a legegyszerűbben, ha megmutatom, továbbá fűzök hozzá néhány magyarázatot. A Symbol oszlop a szimbólumok nevét, az Address a címüket, a Data Type pedig a típusukat tartalmazza. A Commentbe megjegyzéseket írtam, néhányat részletesebben is kifejtek itt. A 6-19. sor tartalmazza a feladat által specifikált változókat, amiket az alapfeladat igényel. A FUT a fűtés, a KEV a keverés irányítására szolgál, a LEPn változók a kezelőfelületen található négy LED-et vezérlik, az MSZn változók pedig a mágnesszelepeket. A bekapcsoláshoz, illetve szelepnyitáshoz 1-et kell írni a címükre. Az S1, S2, S3 szintérzékelőktől, az S4 pedig a hőmérsékletérzékelőtől érkező jelek bemenetei. Az S1 akkor 1 értékű, ha üres a tartály, az S2 és S3 akkor, ha a folyadék elérte őket (a tartály félig, ill. tele van). Az S4 értéke pedig, akkor 1, ha felmelegedett a folyadék.
8. ábra: Szimbólumtábla a folyadékkeveréses alapfeladathoz
A feladatok megoldásához belső változókat is felvettem, amik szintén megtalálhatók a szimbólumtáblában (AA, BB, CC, DD, EE). Értékük 1, ha épp az adott állapotban vagyunk, egyébként 0. AA állapotban a tartály üres és minden szelep be van zárva. BBben az MSZ1 nyitva van, az első folyadék folyik be. CC-ben csak az MSZ2 van nyitva a szelepek közül, a keverést is bekapcsoljuk. DD-ben melegítjük a keveréket, EE-ben pedig leengedjük. Láthatjuk, hogy ha egymást követik ezek az állapotok a működés során, akkor megvalósul a feladatkiírás szerinti működés. A programot az OB1 tartalmazza. Ahogy elindítjuk a futást, elvileg minden változó logikai 0-ban van. Ez azonban nem megfelelő, mert AA, és S1 logikai 1 kell, hogy legyen. Ezt mégy egy kezdeti 0 ellenőrzéssel is összekötöttem, tehát ha minden változó értéke 0 (bekapcsolás után), az AA-t és S1-et 1-be állítom. A program szerkezete a következő: Az első szakaszban (Network 2-6) az állapotátmeneteket valósítom meg (pl. lásd 9. ábra). Az új állapotot mindig 1-be állítom, a régit 0-ba. AA állapotból a START megnyomására kerülünk BB-be. CC-be az S2 jelzésére jutunk, mivel ha a tartály félig megtelt, akkor engedhetjük a második folyadékot. S3 jelére, ha a tartály megtelt, DD állapotba jutunk, S4 jelére pedig EE-be. Végül 9. ábra: AA-BB állapotátmenet ha kiürült a tartály, S1=1-re kerülünk vissza az AA alapállapotba. A második szakaszban (Network 7-11) az aktuális állapotnak megfelelő működés valósul meg. A korábban ismertetett működésnek megfelelően itt történik a szelepek, a fűtés, keverés és a LED-ek vezérlése, BB-LED1, CC-LED2, DD-LED3, EE-LED4 párosítással. Például a BB állapotnál egy BB=1 feltétel után az MSZ1-et és a LED1-et 1-be állítom. A működés ellenőrzéséhez –valódi érzékelő jelek hiányában– nekünk kell az S1-S4 változókat futás közben állítgatni ahhoz, hogy egyik állapotból a másikba jussunk. (Erre a következő fejezet kínál megoldást). Ehhez a feladathoz is készítettem HMI felületet. Ez tartalmazza az elrendezés vázlatát, a felhasználó által látható felületet (4 LED és START gomb), valamint az ellenőrzéshez szükséges állapotjelzéseket, és az érzékelők értékbeállításának lehetőségét. A tartály, a szelepek, a fűtőtest és a keverőberendezés elemeit a Symbol Library-ből illesztettem be, a többi elem megtalálható Simple Object menüben. A szelepeket a nekik megfelelő bit vezérli, zárt állapotban pirosak, nyitottban zöldek. A keverő és fűtő berendezések kikapcsolt állapotban szürkék, a keverés bekapcsolva zöld, a fűtés pedig piros. Az érzékelőket úgy oldottam meg, mintha a tartályon kémlelőnyílások lennének, ennek megfelelően kékek, ha van folyadék a szintjükön. Ez az S1 esetén 0-t jelent (hiszen akkor 1, ha üres a tartály), S2 és S3 esetén 1-et. Az S4 világoskék, ha nem jelez („hideg”), és piros, ha jelez. A LED-ek és állapotvisszajelzések, valamint a START gomb működése magától értetődik. Az állapotok beállítására pedig switcheket használtam, működésük szintén egyszerű.
10. ábra: részletek a működésből (HMI)
6. Harmadik feladat: szimuláció Az előző feladat programjának futtatásakor elég kényelmetlen volt, hogy az érzékelőket kézzel kellett állítgatni. A folyadékkeverős feladat első kiegészítéseként ezért írtam egy szimulációs modult. A cél az volt, a START gomb lenyomására egy üzemi ciklus minden további beavatkozás nélkül végigfusson. Ezen kívül a korábbi kézi lehetőséget fenntartottam, így ki/bekapcsolható szimulációt hoztam létre. Első lépésként végiggondoltam, hogy mi történik egy valós elrendezésnél. Tulajdonképpen egy olyan idődiagram létrehozása volt a célom, ami jól tükrözi a valódi
érzékelőjelek beérkezésének sorrendjét. Ezt követően már „csak” egy FC-t kell létrehozni, ami ezt megvalósítja. Először az S1 vált nullába (a tartály nem üres), majd az S2 1-be, ezt követően pedig az S3, így „telítődik a tartály”. Ezután „felmelegszik a folyadék”, S4=1 lesz. A leengedéskor a hőmérő elhelyezkedését figyelembe véve először S3, majd S2, S4, és végül S1 vált vissza. A pontos idődiagramot a 11. ábra mutatja, egy osztás egy másodpercnek felel meg.
11. ábra: A szimuláció idődiagramja
Annak érdekében, hogy a szimulációt szétválasszam a program működésétől, egy külön FC-ben valósítottam meg, amit az OB1-ből hívok. A további fejlesztési fázisokban is ügyeltem arra, hogy az érzékelők jeleit csak az FC állítsa, maga a program (az OB1) ne férjen hozzájuk. A szimuláció vezérlésére felvettem egy új szimbólumot (SZIM), ennek 1 értéke engedélyezi a szimulációt, ez a feltétele az FC meghívásának. A START megnyomására a szimuláció automatikusan elindul. Az FC-t két network alkotja. A Network 1 a telítődést, és melegedést szimulálja, a Network 2 pedig a leeresztést. Mindkét network négy timer egymás után kapcsolásából áll. Több timer típus is rendelkezésünkre áll, én az S_ODTS típusút választottam. Működését az F1 megnyomására megjelenő Help menü ismerteti. Ha az S bemenetén 0-1 átmenet következik be, elindul a számlálás, és egy (szintén a 12. ábra: Hívási szerkezet bemeneten megadható) idő múlva 1-be vált a kimenet. Ez egy késleltetést jelent, ami megfelelő a feladathoz, hiszen az érzékelők egymás után váltanak (lásd. 11. ábra). Van egy reset bemenet is, ha itt 0-1 átmenet következik be, a kimenet nullába vált. A késleltetés értékét a TV bemeneten állíthatjuk be, ez S5Time típusú értéket vár. Ezt szintén megismerhetjük a Help menü segítségével, 1 másodpercet ’S5T#1s’ alakban állíthatunk be. A hívási szerkezet (12. ábra) alapján látható, hogy a program minden ciklusban belép az FC-be. Ha az egyik
timer számlálása elindul, a futás nem várja meg, hogy ez befejeződjön, hanem minden ciklusban „ránéz” a timerre, hogy lejárt-e a megadott idő. Az idődiagram megvalósításának részletét a 13. ábra mutatja. Ha a START jelre AA-ból BB-be jutottunk, telítődik a tartály: 1s múlva S1 nulla lesz (már nem üres), további 4s múlva S2 1-be vált, stb., mindig azt az időt adtam meg, aminek az egyik váltástól a másikig el kell telnie. A változásokat az OB1 dolgozza fel. S1 váltására épp nem történik semmi, azonban ahogy az S2 egy lesz, átkerülünk a CC állapotba. A Network1-ben az utolsó váltás a S4 egybe kapcsolása („felmelegedett” a keverék). Ennek hatására EE-be kerül a rendszer, és kezdődik a leeresztés, amit a Network2 szimulál. Az EE hatására a Network1 minden timere resetelődik. A leeresztés érzékelőjeleinek generálása hasonlóan működik, itt AA reseteli a timereket. Amint visszaérünk AA-ba, az érzékelők is alapállapotban vannak, a START megnyomására indul az újabb üzemi ciklus.
13. ábra: A szimulációs FC részlete
A HMI felületen is végeztem módosításokat, megjelent a SZIM-hez tartozó switch, így ki lehet kapcsolni, és akár kézzel is állíthatjuk az érzékelőket, mint az előző feladatnál. Ezen kívül az állapotkijelzők mellé egy újabb kijelző került, ami a SZIM aktuális állapotáról ad információt. Ezek persze nem tartoznak az előírt felhasználói felülethez, hiszen a program belső működésével kapcsolatosak, a működés ellenőrzéséhez, befolyásolásához szükségesek. Egyéb változtatást nem igényelt a feladat.
14. ábra: A szimulációs feladat HMI-je
A feladat megoldása közben gyakoroltam az FC hívást, megismertem több timer működését is (ahhoz, hogy a megfelelőt kiválaszthassam), és létrehoztam egy szimulációt, aminek hatására a programom már „külső” érzékelő jeleket kezel.
7. Negyedik feladat: Hibakezelés I. A folyadékkeverős feladat eddigi lépéseiben nem foglalkoztam azzal, hogy milyen hibák fordulhatnak elő működés közben, és ezeknek milyen hatása lesz a program futására. Egy ipari berendezésnél azonban fontos a hibák megfelelő kezelése, hiszen egy érzékelő elromlása nem okozhatja a rendszer összeomlását. A valóságban gyakran sérülésveszély, akár robbanásveszély is fennáll hibás működés esetén, a hibatűrő képesség meghatározására normákat hoztak létre, ezek meghatározzák, a rendszerrel szemben támasztott követelményeket. Első lépésként végiggondoltam, hogy a folyadékkeverés esetén milyen hibák léphetnek fel. Ezeket több típusba lehet sorolni, a program képes megkülönböztetni őket, a továbbiakban részhibaként hivatkozok rájuk. A szimbólumtáblában új változókat vettem fel minden részhibához, értékük akkor egy, ha fennáll az adott hiba, elnevezésüket (csupa nagybetűvel) és leírásukat a fejezet következő része tartalmazza. A szintérzékelők meghibásodása folytán láthatunk fizikailag nem létező szintállapotokat, pl. az S3 (felső) érzékelő jelez, az S2 (középső) nem. Az ilyen típusú hibákat SZINTHIBA-nak neveztem el, bármely hibás szintjelzés esetén ez a hibatípus lesz aktív. Vizsgálom azt is, hogy a folyamat megfelelő ütemben zajlik-e. Ennek részeként ellenőrizni kell, hogy a szelepeket sikerült-e kinyitni, vagy nem dugultak-e el a csövek. Ezt úgy tehetjük meg, hogy megadunk egy időkeretet, amin belül jeleznie kell a szintérzékelőknek. Így három újabb részhibát kapunk: MSZ1HIBA van ha S1, vagy S2 nem jelez adott időn belül, MSZ2HIBA, ha S3 nem jelez, és MSZ3HIBA, ha S1 nem lesz elég hamar újra 1 értékű (üres a tartály). Végül az S4-hez is kapcsolódhatnak hibák. Egyrészt hibát okoz, ha S4 magas hőmérsékletet jelez AA, BB és CC állapotokban, hiszen ekkor még be sem kapcsolt a fűtés (S4HIBA). FUTESHIBA-t kapunk, ha a fűtés bekapcsolása után S4 nem jelez adott időn belül. Ha a leengedéskor a meleg folyadék elhagyja az S4 érzékelőt, ennek le kell hűlnie, ha ez nem történik meg elég gyorsan, HULESHIBA-t okoz. Tehát összességében 7 db részhibát különböztettem meg. Ami a program működését illeti, ennél a feladatnál a szimulációs FC-t változatlanul hagytam. Hívásán pedig annyit változtattam, hogy a SZIM kikapcsolódik, ha végigért egy üzemi ciklus. Szimulációra tehát továbbra is van lehetőségünk, azonban hibák esetén még nem működik megfelelően, ezt az utolsó feladatban oldottam meg (következő fejezet.). Továbbá létrehoztam egy globális DB blokkot. Ennek szerepét és az OB1 módosításait a következő bekezdések tartalmazzák. Bármelyik részhiba 1 értéke esetén bekapcsolódik a HIBA állapot (értéke 1, ha van hiba). Ez általánosságban jelzi a hibát, mellette azonban a hiba bekövetkeztekor fennálló állapot továbbra is fennáll. A korábbi programszerkezetet 15. ábra: Biztonsági kiegészítés kiegészítettem biztonsági feltételekkel. Ezek szerint egyik állapotból csak akkor léphetünk egy másikba, ha nincs hiba (a normál
feltételen túl persze). Valamint az adott állapot csak akkor vezérelhet bármit, ha nincs hiba, pl. DD-ben a fűtés bekapcsolása. Hiba esetén –szintén biztonsági okból– minden szelep lezár, a keverés és a fűtés kikapcsol. A SZINTHIBA-k és S4HIBA-k vizsgálata egyszerű logikával megoldható. Nem ilyen magától értetődők azok a hibák, ahol egy maximális időn belül be kell következnie egy eseménynek. Ezt egy példán keresztül mutatom be, az összes többi fent ismertetett, időkerethez kapcsolódó részhiba figyelését hasonló módon oldottam meg. Vegyük a FUTESHIBA-t! Ez akkor lép fel, ha a DD-be kerülés (a fűtés bekapcsolása) után egy adott idő leteltével sem kapunk jelzést az S4-től. A korábban ismertett S_ODTS timert a DD=1 esemény indítja, ha lejár a megadott idő, és még mindig nem jelzett az S4, fűtéshiba van. Ha ez fellép, vagy sikeresen továbbjutottunk az EE-be, lenullázzuk az időzítő kimenetét. Látható, hogy a TV bemenetre most nem egy konstans érték került. A kapott feladat szerint ugyanis minden egyes időtartamnak paraméterként megadhatónak kellett lennie. Ennek érdekében létrehoztam egy global DB-t, ami megfelelő számú, S5Time típusú adatot tartalmaz. Ezeket az alapján neveztem el, hogy melyik időzítő paramétereként szolgálnak (pl. T12_param). Rendelkeznek egy inicializálási értékkel, aminek értékét úgy választottam meg, hogy nagyobb legyen, mint a szimuláció által használt időzítések. Például a szimuláció szerint az 16. ábra: FUTESHIBA vizsgálata MSZ1 nyitása után 5 másodperc múlva jelez az S2, időzítővel ezért az MSZ1HIBA-nál 10 másodperc az időkeret. Így a szimuláció alapállásban hiba nélkül végig tud futni. Az inicializált kezdőértékhez a View/Data view, majd ezt követően az Edit/Initialize Data Block beállításokat meg kell tenni. Az OB-ben az időzítő számára a képen látható formátumban érhetők el a paramérek: "DB1".T13_param. Ezzel rendelkezésre állnak az állítható időkeretek. Teszteléskor ezeket elég kicsi értékre átállítva könnyedén generálhatjuk bármelyik időkeretre alapuló részhibát. Végül meg kellett oldani, hogy hiba esetén valahogyan tovább működhessen a a rendszer. Erre ideiglenes megoldásként a TOVABB gombot használom. A probléma komolyabb megoldását a következő fejezet tartalmazza. A gombnak csak akkor van szerepe, ha hiba áll fenn, és nem az alapállapotban vagyunk. 17. ábra: A TOVABB működésének részlete Tulajdonképpen egy kényszerített továbblépést valósít meg. Szerepe az, hogy hiba esetén vissza tudjunk térni az alapállapotba, hogy újabb üzemi ciklust kezdjünk a hiba elmúltával. Felfutó élére, ha hiba van a következő állapotba lépünk. Az állapottal járó dolgok azonban nem valósulnak meg, mert hiba van (pl. nem fog bekapcsolni a keverés, ha így jutunk CC-be). Amikor az EE állapotból váltunk AA-ba, akkor pedig minden hibajelet (a részhibákat is) megszünteti.
A HMI felületet is továbbfejlesztettem. A részhibákkal együtt már nagyon zavarossá váltak a kapcsolók, illetve visszajelzők, ezért keretekkel három részre tagoltam a felületet: a technológiai elrendezés modelljére, a felhasználó által látott felületre, illetve a teszteléshez szükséges, belső állapotokat is visszajelző felületre. Nem tudtam megoldani az S5Time típus megfelelő kijelzését, decimális értékként írattam ki, „dekódolását” az input mezők melletti szöveg segíti. Hiba esetén a HIBA és a megfelelő részhiba pirosan világít. Ezen kívül természetesen még egy nyomógombot is elhelyeztem a TOVABB számára. Az első HMI képen a normál működés részlete látható, bekapcsolt szimuláció mellett. A második képen egy MSZ1HIBA látható, amit úgy lehetett létrehozni, hogy az s2max paramétert átírtam a 3 másodpercnek megfelelő 768-ra, ami kisebb mint a szimulációs 5 másodperc, így az S2 nem váltott az időkeretén belül, ami hibát okozott. A harmadik képen pedig egyszerűen átálítottam az S3-at, így lehetetlen szintjelzés alakult ki.
18. ábra: HMI képek a hibakezelés első verziójához
A hibakezelés első verziójának készítése közben végig az a gondolat vezérelt, hogy hiba esetén jussunk biztonságos állapotba. A hibát követően ne kapcsolhassunk be semmit, csak tudjunk eljutni az alapállapotba, ahol javítjuk a hibát, és ezt követően új ciklust kezdünk. Ez egyfajta védekező mechanizmus, ennél hatékonyabb hibakezelést ismertet a következő fejezet.
8. Ötödik feladat: Hibakezelés II. Bár az előző feladat már tudta kezelni a hibákat egy bizonyos szinten, még sok kisebb-nagyobb javításra szorult. Ezek közül a legfőbb dolog a nyugtázás bevezetése. Ez már közelebb áll a valósághoz. Általánosságban, ha hiba keletkezik, nyugtázni kell. Előfordulhat, hogy a hiba megszűnik, ekkor nyugtázásra folytatódhat a folyamat. Ha a hiba nyugtázás után is fennáll, nyugtázott hiba lesz, a javítást követően újra nyugtáznunk kell a folytatáshoz.
19. ábra: Nyugtázás folyamata
Ami a programot illeti, az előző verzió hiányossága volt még a szimuláció viselkedése. Megoldásra vár, hogy hibakezelés után folytatható legyen a szimuláció is.
A feladat megoldását ismét a szimbólumtábla felülvizsgálatával kezdtem. Felvettem a NYUGTAGOMB nevű bemenetet, a SZIMFOLYT változót, aminek értéke 0, ha meg kell szakítani a szimulációt. Valamint még két változót, amire szükségem volt a megoldáshoz, ezek a NYUGTAKELL és az NYHIBA. A program a következő módon működik. Bármely részhiba esetén logikai 1-be kerül a HIBA és a NYUGTAKELL. A NYUGTAKELL az a változó, ami a továbbfutást gátolja, ez mindaddig 1 értékű, amíg nem futhat tovább a program. Ha a HIBA megszűnik, a NYUGTAKELL továbbra is fennáll. Ezért addig, amíg nem nyugtázzuk azt, hogy egy ideig hiba állt fenn, nem folytatódhat a program. A NYUGTAGOMB megnyomása után ebben az esetben meg is oldottuk a hiba kezelését. Ha azonban látjuk, hogy hiba lépett fel és a nyugtázáskor ez még fennáll, nyugtázott hibánk lesz (NYHIBA). Ekkor a HIBA, NYUGTAKELL és NYHIBA érétke is 1. Ha a hibát megszüntetjük (HIBA=0, NYHIBA=1), majd nyugtázunk, folytatódhat a futás. Ahhoz, hogy ez a megoldás működjön, és a szimuláció is megszakítható majd folytatható legyen, számos kisebb változtatást kellett végeznem.
20. ábra: A nyugtázás megvalósításának részlete (ha a hiba megszűnik az első nyugta előtt)
A hibakezelés kivitelezését szolgáló kisebb módosítások az OB1-ben: a SZIMFOLYT változó kezdőértékét 1-be kellett állítani, hiszen a 0 értéke jelenti a szimuláció szüneteltetését, a szimuláció nem indul el automatikusan a START gombra, az állapotátmenetek feltételéhez bekerült a NYUGTAKELL=0 feltétel, hiszen most már előfordulhat olyan, hogy nincs HIBA (csak NYHIBA), de a folytatás előtt szükség van egy nyugtázásra, az időkereten alapuló részhibák időzítői csak akkor indulnak el, ha nincs szükség nyugtázásra. Ez kicsi, de fontos változtatás, hiszen egyébként az időkeret letelne, mialatt a nyugtázásra vár a program, és a folytatáskor azonnal újabb hiba keletkezne, ezen időzítők paramétereinek kezdőértékét egységesen 60 másodpercre állítottam, hogy kikapcsolt szimuláció mellett, a jelek kézi állítgatásánál ne kelljen kapkodni. (Az előző tapasztalatok alapján.), a HIBA állapot a részhibák felfutó élére kapcsol be (és nem a logikai 1 szintjükre, mint eddig). Ennek a HMI-nél lesz szerepe. Ha nyugtázott hiba van, akkor is szeretnénk látni, melyik részhiba okozta. Így nyugodtan hagyhatjuk őket bekapcsolva, a HIBA nem fog újra jelezni miattuk, a részhibák összegzésénél a HIBA-val párhuzamosan a NYUGTAKELL is bekapcsol,
a biztonsági állapotot (minden szelep zárva, fűtés, keverés kikapcsol) most a NYUGTAKELL kapcsolja be, a HIBA helyett, a tovább szerepe megszűnt, sehol sem használom (kikerült a szimbólumok közül is), ha folytatódhat a program, a részhibák kikapcsolnak. Módosítani kellett az FC-t is. Minden időzítő bemenetére további feltételként bekerült a SZIMFOLYT vizsgálata. Már említettem, hogy ennek kezdőértéke 1, ha a NYUGTAKELL 1 értékű, akkor a SZIMFOLYT 0 lesz, és akkor veszi fel újra az 1 érétket, ha a NYUGTAKELL 0-ba vált. Röviden a hiba megszűntével a szimuláció is folytatódik. Módosítottam a timerek resetelésén is a NETWORk 1-nél, korábban itt mindent az EE állapot resetelt, most pedig az n. timert tulajdonképpen az (n+1). reseteli.
21. ábra: SZIMFOLYT használata az FC-ben
A HMI felületen is sok változtatásra volt szükség. Az előző feladatnál a gombok körüli keretet egyenesekkel oldottam meg, ugyanis, ha egy átlátszó négyzetet helyeztem föléjük, akkor nem lehetett lenyomni a gombokat. Ezt a layerek használatával lehet megoldani. Ezek egyfajta rétegek, minden elemhez lehet rendelni egy layer szintet a beállításoknál. A kisebb szint alacsonyabb réteget jelent. A fenti problémához tehát nem kellett mást tennem, mint a gombokhoz nagyobb szintet rendelni, mint a keretet adó átlátszó téglalaphoz. A tovább gombot átírtam nyugtára. Ami a valódi gyakorlathoz való közelítést illeti, talán a legfontosabb módosítás az ábrán a színeknek a kicserélése volt. A piros színt a hiba jelzésére szokás használni. A korábbi HMI-ken viszont eddig pirossal jelöltem a zárt szelepeket, valamint az 1 értékű (meleg) S4-et és a bekapcsolt fűtőtestet. Az új színek: a zárt szelepek feketék, az S4 és a fűtőtest pedig narancssárga piros helyett. Az időzítőparaméterek tagjeinek típusát Timerre állítva, decimális számként kijelezve sikerült megjeleníteni őket úgy, hogy ténylegesen a másodperc értéket jelezzék ki. Végül a hibajelzést változtattam meg úgy, hogy nyugtázatlan hiba esetén piros-sárgán villog, nyugtázott hiba esetén pedig pirosan világít a HIBA feliratú LED. Ezt layerek segítségével oldottam meg, legalul egy HIBA esetén villogó elem van, felette egy olyan, ami csak akkor látható, ha NYHIBA van (piros), legfelül pedig szürke, ami akkor látható, ha nincs szükség nyugtázásra. A következő két képen a HMI felület szerepel, nyugtázott, illetve nyugtázatlan hiba esetén. A 22. ábrán látszik, hogy a HULmax értékét 1 másodpercre csökkentettem. Így egy HULESHIBA-t idéztem elő, mert EE-ben az S4 jelzése nem szűnt meg egy másodpercen belül. A 23. ábrán hasonló módon MSZ2HIBA-t hoztam létre, ekkor a HIBA feliratú jelzés piros-sárga színnel villog.
22. ábra: Nyugtázott HULESHIBA
23. ábra: Nyugtázatlan MSZ2HIBA
9. Tapasztalatok, köszönetnyilvánítás A félév során számos, a PLC-kel és LAD nyelvvel kapcsolatos ismeretet szereztem. Ebben részben a Programozható irányítóberendezések és szenzorrendszerek tantárgy és laboratórium is szerepet játszott, de főként a féléves önálló laboratóriumi munkának köszönhető. Az egyetemi órák és a cégnél tapasztaltak alapján látom, hogy ez egy szerteágazó téma, aminek még csak az elején vagyok, de a jövőben is szívesen foglalkoznék vele. Az, hogy a témát külső cégnél csináltam, további hasznos tapasztalatokhoz juttatott. Végül ezúton is szeretném megköszönni a féléves segítséget Nagy Lászlónak, a céges konzulensemnek, aki sok hasznos tanáccsal látott el, és segített megoldani a felmerülő problémákat.
Felhasznált források: 1) Dr. Ajtonyi István, Dr. Gyuricza István: Programozható irányítóberendezések, hálózatok és rendszerek (Műszaki Kiadó, Budapest) 2) Ajtonyi István: PLC és Scada-HMI rendszerek I. (AUT-INFO Kft., Miskolc, 2007.) 3) A www.ob121.com weboldalon található, témához kapcsolódó anyagok: http://www.ob121.com/plc_basic.html, http://www.ob121.com/soft_basic.html, http://www.ob121.com/hard_s7.html 4) A 12. ábra forrása: http://szirty.uw.hu/misc/S7-300_programozas.pdf
