Siemens PLC-k alkalmazástechnikája és programozása - Budapesti ...

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
2. ábra: SHL_W
blokk
megismeréséhez a beépített helpet használtam. A nyomógomb
felfutó éle engedélyezi a shiftelést, N-re egy konstans 1-et kötöttem,
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
bemenetükre az intsort, az IN2 bementekre pedig 2 megfelelő
hatványát írtam (1-től 16384-ig, és az int definíciója
3. ábra: szegmens
felosztás
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
szimbólumtáblát úgy tudom ismertetni a 7. ábra: a folyadékkeverő illusztrálása
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
9. ábra: AA-BB állapotátmenet
állapotba jutunk, S4 jelére pedig EE-be. Végül
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
12. ábra: Hívási szerkezet
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
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
16. ábra: FUTESHIBA vizsgálata
időzítővel
használt időzítések. Például a szimuláció szerint az
MSZ1 nyitása után 5 másodperc múlva jelez az S2,
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