Gyakorlati tanácsok gépek programozáshoz és tervezéshez

2. rész: Hibakezelés (folytatás)

Az első rész a hibák felismerésével foglalkozott, a második rész azzal, hogy a program hogyan és milyen intézkedéseket tehet amikor egy hiba bekövetkezik.

Arról már volt szó, hogy az egyik teendő a kezelő értesítése a hibáról. Ezt a program egy jelzőlámpa bekapcsolásával teheti, de ha a rendszerben operátor panel vagy egyéb HMI (Pl. PC) is van, akkor egy szöveges hibaüzenet sokkal informatívabb. Legalábbis akkor, ha az egyes hibákra külön jelzést biztosítunk. Minél részletesebben tájékoztatja egy üzenet a kezelőt a hibáról, annál több lehetősége lesz a hatékony intézkedésre.
A HMI-k messzemenően támogatják a hibakezelést. Arhívumban tárolják a hibát, hogy később visszakereshető legyen mi történt, jegyzik a hiba keletkezésének, a kezelő nyugtázásának, a hiba megszűnésének az időpontját, stb.

Statikus és dinamikus hibaállapot, a tárolók szerepe

Egy hibaállapot kétféle jelleget ölthet. Az egyik esetben a jelzés, amiből a hibára következtetünk állandó és hosszan tart. A vezérlés legtöbb állapot jelzése ilyen. Motorvédő, biztosíték hiba, feszültség hiány, fázis hiány, vészleállítás tényét közlő jelzés, hajtásvezérlő hiba, stb. A jelzés aktív lesz amikor a hiba bekövetkezik, annak megszűnéséig aktív marad. Pl. a motorvédő visszakapcsolásáig, a hajtásvezérlő hibatörléséig...
A dinamikus hibállapot működés közben következik be, leállítja a gépet, de a leállás miatt megszűnik. Ilyenre is volt példa az első részben.. A forgás (mozgás) figyelés, az időtúlfutás figyelés tipikusan ilyen.
Az ilyen hibajelzésekre RS tárolót kell használni. A hiba "bebillenti" a tárolót, a nyugtázó gomb visszaállítja. RS tároló nélkül is megállítaná a berendezést a jelzés, mivel az akkor is létrejön, de a megállás miatt azonnal meg is szűnik így nem lenne lehetőség a hibaüzenet megjelenítésére (a Siemens HMI-k alapbeállítással másodpercenként kérdezik le a hiba bitek állapotát). Az RS tároló úgy marad a kezelő általi nyugtázásig, van mód az üzenet megjelenítésére.

Hang és fényjelzés hiba esetén

A gépeken hibajelző lámpa is szokott lenni, amit akkor is lát a kezelő ha nem pont az operátor panel előtt vagy a gép közvetlen közelében áll. Sokszor a hibajelzéskor hangjelző kürt, csengő, zümmer is jelzi a hibát és nyugtázó gomb is van. A nyugtázó gomb több funkcióval is bír. A kezelő azzal veszi tudomásul a hibajelzést, elhallgattatja vele a hangjelzést, illetve a hiba elhárítása után törli a hibaállapotot hogy a berendezést újra üzembe helyezze.
Biztonsági okokból, amikor a gép hiba miatt megáll, a kezelő közreműködésére van szükség az újraindításhoz. Pl. meg kell nyomnia a nyugtázó gombot (vagy egyéb interaktív tevékenységet kell elvégeznie) hogy a gép a hiba megszűnésekor magától ne induljon el, csak és kizárólag akkor amikor azt a kezelő akarja. Így elkerülhető az olyan váratlan indítás, ami a kezelő akaratától független.

A hibajelző lámpa és a hangjelzés kezelésének egy egyszerű módja:



A NW1 bekapcsolja a hibajelző lámpát ha bármilyen hiba aktív. A jelzőlámpa a hiba megszűnéséig világít. Megszólal a hangjelzés is, de az I2.0 nyomógombbal az elhallgattatható. A hangjelzés nem szólal meg újra csak akkor, amikor a nyugtázott hiba (vagy hibák mindegyike) elmúlt és újabb hiba keletkezik.
(A fenti példa csak a hibajelző lámpával és a hangjelzéssel foglalkozik (amennyiben operátor panelen is kell üzenetet megjeleníteni azt külön programrész végzi).

Sok esetben ez a módszer megfelel, de az egyszerűsége hátrányokat is rejt. Nosza bonyolítsuk! De ne ész nélkül, lássuk mik a hátrányok:
  1. Ha a kezelő kitámasztja a nyugtázó gombot, akkor soha nem fog hangjelzést adni, a dinamikus hibák pedig semmilyen jelzést nem fognak produkálni, mert a kitámasztott gomb azonnal törli őket.
  2. A hangjelzés nem szólal meg újra amikor az előző hiba mellé egy újabb hiba csatlakozik, csak akkor ha a hiba a gép hibamentes állapotában érkezik.
Mindkét problémán segíthetünk él figyeléssel. Ha a hangjelzést felfutó impulzussal tiltjuk le, akkor a tiltás csak a gomb (I2.0) 0->1 átmenete alkalmával tud életbe lépni, ha kitámasztják, akkor nem.
Ha a második hátrányt is fontos kiküszöbölni, akkor az M1.6-os S/R tároló ágában el kell helyezni minden egyes hibára egy felfutó él impulzust generáló -(P)- utasítást.
Ha nincs sok hibajelzés ez elfogadható megoldás lehet, ám ha sok van, akkor időt és bitet pazarló tevékenység megírni. Ilyenkor használhatunk olyan megoldást, amiben nem bitenként történik az él figyelése. Lásd: Fel és lefutó él detektálása.

A kezelő számára további információt közölhetünk azzal, ha a hibajelző lámpa folyamatosan világít amíg van aktív hiba és villog ha már nincs hiba, de a hibát még nem nyugtázták. Így látja, hogy ha megnyomja a nyugtázó gombot, akkor (amikor villog) a gép üzemkész lesz és indíthatóvá válik, vagy csak a hangjelzést fogja elhallgattatni (világít).
Ennek megvalósítására egy megoldás az, hogy minden egyes hibajelzés külön-külön egy bitet bekapcsol (R/S tároló vagy SET utasítás). Ilyen bitekre egyébként is szükség lesz ha operátorpanelen is kell hibánként külön hibaüzenetet küldeni. Ezeket a biteket egyszerre a hibanyugtázó impulzus törli.
Minden ilyen bitet összefogunk egy VAGY kapcsolattal (ha nagyon sok jelzés van és a bitek címfolytonosak, akkor byte, word vagy dword nullával való összehasonlítása hatékonyabb a sok VAGY kapcsolatál). Ez a bit lesz a "gyűjtött hiba", TRUE állapotba fog kerülni bármelyik hibajelzésnél és mindaddig TRUE marad, amíg a hiba megszűnése után nem nyugtázták a hibát.

Mit tegyen a gép amikor hibajelzés keletkezik?

Álljon le. Az álló gép több bajt nem csinál mondhatnánk. Ez általában igaz is, de nem mindig. Egy teljes leállás olykor komoly technológiai vagy környezeti kárt is okozhat. Az ilyesmit szeretnénk elkerülni, hiszen a hibakezelés (és a gép leállítása egy hiba miatt) épp a negatív következmények elkerülését célozza.
Nagyobb rendszerekben, ahol pl. a fenti eset is előfordulhat, a hibákat csoportosítják. A csoportosítás szempontja lehet fontossági, vagy funkcionális, vagy akár mindkettő is.

A csoportosítás arra jó, hogy így a program többféleképpen tud reagálni az egyes csoportokba tartozó hibákra. Pl. egyes hibák csak jelzést adnak, de nem állítják le a gép semmilyen részét. Pl. előjelzés, amikor egy hőmérséklet, szint stb közelít egy kritikus értékhez, a vezérlés hibajelzést ad és közli a kezelővel a hibaüzenetben a kritikus értéket, aki beavatkozhat hogy elkerülje a kritikus érték átlépését ami már egy másik csoportba tartozó hibát generál és a gép leállását okozza.
A csoportosítás hasznos akkor is, ha a rendszer egymástól funkcionálisan jól elkülöníthető részekből áll.
Ilyenkor egy hiba csak arra az egy gépcsoportra van hatással (csak azt állítja meg) amelyikben a hiba keletkezett,a gép többi részét engedi tovább üzemelni. Az majd megáll azon a technológiai feltételhiányon, ami az egyes részek között van kailakítva.
Pl. komplett csomagoló gép vezérlés. A raklapokat pakoló palettázót nem szükséges megállítani ha a terméket oda szállító szalag környezetében van valamilyen kritikus hiba. A szalag azonnal megáll a hiba miatt, a palettázó üzemel tovább és majd az is megáll ha nem lesz mit pakolnia.

A hibaüzenetek megfogalmazásáról

Én a magam részéről nem javaslom a szöveges hibaüzenetek olyan fajta megfogalmazását, amikor az üzenet a hiba elhárításához szükséges konkrét lépéseket írja le a kezelő vagy a karbantartó számára (hova menjen, mit nyomjon meg, milyen vasat görbítsen vissza, hova üssön a kalapáccsal).
Az olyanokat sem, amikor az üzenet a hiba lehetséges okait latolgatja.
Lássunk ezekre néhány példát:
Motor túlterhelés! Q10.4 motorvédő hiba!
Kapcsolja vissza a Q10.4 motorvédőt!

Nem, ne kapcsolja vissza! Előbb tájékozódjon mi a kialakult helyzet oka! A motorvédő kioldásának valóban az egyik leggyakoribb oka a motor túlterhelése. A problémát valószínűleg nem oldja meg az, ha nem veszünk róla tudomást.
Ugyanakkor számtalan más oka is lehet a kioldásnak.
Felsorolok néhányat: Fázis hiány, fázis aszimmetria, kábel szakadás, kábel zárlat, motor beázás, a motor leégése, motor csere után nagyobb teljesítményű motor felszerelése, a motorvédő kapcsoló hibája, motorvédő kapcsoló után annak túl kicsi értéke, a motorvédő kapcsoló helytelen beállítása, nem megfelelő motor bekötés (csillag/delta), a csatlakozó kapcsok vagy a bekötés elégése a motornál kötődobozban vagy a vezérlő szekrényben, mechanikai hiba (szorulás).
A PLC nem tudja melyik következett be, csak egyet tud: A motorvédő kioldott. Még az is lehet hogy nem magától, hanem kikapcsolta valaki, pl. mert éppen szerelik a motort. Ha a másik kezelő eközben odajön a géphez és erről nem tud, de látja az üzenetet hogy "Kapcsolja vissza a Q10.4 motorvédőt!" akkor...

Véleményem szerint a hibaüzenet csak pontosan annyi információt közöljön, amennyit a PLC "tud" a hibáról és semmi többet, kerüljük a feltételezéseket. A lehetséges okok, vagy a szükséges teendők legyenek leírva a géphez mellékelt kezelési utasításban, ott a helyük és nem a hibaüzenetben! A túl sok feltételezést, vagy a túl sok választási lehetőséget tartalmazó üzenetet a kezelő félreértheti és a félreértés miatt azzal a szilárd meggyőződéssel okozhat még nagyobb bajt, hogy tudja mit csinál.
Persze ez alól is lehet kivétel. Pl. technológiai üzenet, ami a kezelőt utasítja valamilyen tevékenységre ami az üzenettel kapcsolatos következmények elhárítását célozza. Ilyennek akkor van létjogosultsága, amikor az a tevékenység feltétel nélkül elvégzendő és PLC-ben a szükségessége kétségek nélkül detektálható.
Az üzenet legyen tárgyilagos és pontos: "Q10.4 motorvédő kioldva". Ha a vezérlés nem képes kideríteni mi okozta a hibát, nem tehet mást mint hogy ezt az emberre bízza.

Be careful!This machine has no brain, use your own!

A hibaüzenetek a HMI-n

Amikor operátor panelt, PC-t használunk a rendszerben, szinte korlátlan mennyiségű üzenetet használhatunk (persze az üzenetek maximális száma sosem végtelen, de nem szokott kevés lenni). A sok üzenet hátránya hogy sok a munka velük, hiszen mindegyiket ki kell dolgozni. Előnye, hogy ha jól csináljuk, akkor az üzenetek segítenek a kezelőnek és/vagy a karbantartónak megtalálni a hibát.
A sok üzenet viszont vissza is üthet. Ha a gép túl gyakran és fölöslegesen üzen vagy egyszerre túl sok üzenetet produkál, az túlterheli a gép kezelőjét. A gyakori, nem eléggé megalapozott vagy teljesen fals üzenetekre pedig a kezelő úgy fog reagálni, hogy nem törődik vele ("Aki túl sokszor kiált farkast..." esete).

Fals hibaüzenetek gyakran úgy keletkeznek, hogy nem kellő gondossággal kidolgozott a jelzést ébresztő bit előtti feltételsor. Lássunk erre egy klasszikus példát.
A biztosítékok (kismegszakítók) segéd érintkezővel vannak ellátva és a segéd érintkezők záró (NO) érintkezői sorbakötve, csoportonként egy-egy PLC bemenetre jutnak. Amikor minden kismegszakító be van kapcsolva, az ellenőrző bemenet aktív. A soros kapcsolás miatt ha bármelyik kiold, a bemeneten megszűnik a jel, a PLC ezt észleli és biztosíték ellenőrzéssel kapcsolatos hibaüzenetet küld, közben megállítva a gép érintett részét, vagy az egész berendezést.



A rajz részlet 24V DC bemenetre felfűzött segédérintkezőket mutat.
Az ilyen jelzéshez tartozó hiba bit (aminek a bekapcsolásával a HMI-n megjelenik az üzenet) kezelésével sok dolgunk nincs, egyszerűen Az E50.4 bemenet negálva kapcsolja a hibajelző bitet, az E50.5 bemenet pedig a másik hibajelző bitet:



Ha a bemeneten a jel megszűnik, megjelenik a hibaüzenet.
Miért nem jó ez így? Azért, mert ha a "P1" jelű 24V-os feszültség szűnik meg, akkor mindkét hibaüzenet meg fog jelenni a HMI-n, mivel az E50.4 és E50.5 bemenetek is inakítvvá válnak annak ellenére, hogy az ott felfűzött érintkezők egyike sem kapcsolt ki! Tehát olyan üzeneteket fog kiírni amik hamisak!
ha a vezérlés tervezője körültekintő volt és a bemeneteken nem kellett neki spórolni, akkor valószínűleg van olyan bemenet, amivel ellenőrizhető a "P1" feszültség megléte. Ha a vezérlést is mi tervezzük (és nem csak a programot írjuk hozzá, vagy van kapcsolatunk a tervezővel) akkor intézzük úgy, hogy minden működtető feszültség meglétéről legyen közvetlen információja a PLC-nek. Azzal elkerülhetjük az ilyen esetet oly módon, hogy csak akkor kapcsoljuk be a hibajelző biteket ha a "P1" feszültség jelenlétét érzékelő bemenet aktív!

Hasonlóan klasszikus esete a fals hibajelzéseknek az, amikor az egyik hibaesemény következtében további (nem ritkán több további) hibaállapot is létrejön. Pl amikor a rendszer több frekvenciaváltót is tartalmaz. A frekvenciaváltók üzemkészségét természetesen a programnak valamilyen módon figyelnie kell, hogy kezelni tudja azt az esetet ha a hajtás körül történik valami váratlan hiba (pl. a frekvenciaváltó hibát jelez).
Ugyanakkor a biztonsági körök lekapcsolják a frekvenciaváltók tápellátását, akkor egy vészleállítás annyi fals frekvenciaváltó hibaüzenetet fog okozni ahány frekvenciaváltó van a gépben.
A frekvenciaváltó hiba kezelésénél tehát bele kell kombinálni a feltételsorba, hogy csak akkor vegye figyelembe a frekvenciaváltók üzemkész jelzésének a hiányát, ha azok feszültség alatt vannak (figyelembe véve a bekapcsoláskor szükséges éledési időt is).
 
Kapcsolódó írások:
Fel és lefutó él detektálása
WinCC Flexible és az üzenetek
Siemens simatic operátorpanelek programozása (3)
WinCC Flexible: Analog Alarm




Szirty