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

1. rész: Hibakezelés

Ebben a sorozatban szeretnék megfogalmazni néhány olyan - szerintem fontos - gyakorlati tanácsot, ami irányvonalat adhat berendezések működésének, funkcióinak tervezéséhez és programozásához.
A mérnöki munka és a programozás során rengeteg kompromisszumot kell kötni, hiszen sem a rendelkezésre álló idő, sem az anyagi erőforrások nem szoktak korlátlanok lenni.
Sőt ennek ellenkezője a jellemző (tegnapra kell ingyen). Ugyanakkor a megrendelőnek a készülékkel vagy berendezéssel szemben komoly (olykor szinte irreális) elvárásai vannak a termelékenység, a karbantartás igény és az üzembiztonság terén.

A kompromisszumra az egymásnak ellentmondó követelmények és körülmények miatt van szükség. Szerintem sokan ismerik a "reklám szlogent" ami remekül rávilágít ennek lényegére:
"Cégünk jól, gyorsan és olcsón dolgozik. Ön ebből kettőt választhat"

A kompromisszumot természetesen mindenkinek magának kell megkötnie ott és akkor, hiszen a helyes döntés mindig függ az adott helyzettől. Én úgy gondolom, hogy döntsünk ésszerűen és lehetőleg válasszuk az arany középutat. A sorozat nem a kompromisszumokról fog szólni, hanem olyan fogásokról, amikkel növelhetjük a rendszer hatékonyságát és elkerülhetünk bizonyos zsákutcákat remélhetőleg a megrendelő és saját megelégedésünkre.

Hibakezelés

A hibák kezelésére sokszor nem fordítanak elég figyelmet a programban. Egy rendszer hibakezelés teljes hiánya mellett is képes üzemelni egészen addig, amíg valami baj nem történik. Amikor valami nem úgy történik ahogy kellene, vagy ahogy a program várja.
Mindig van valamiféle hibakezelés, olyat összetettebb rendszerben még nem láttam hogy egyáltalán nincs. De az sem mindegy, hogy milyen az a hibakezelés.
A programozó gyakran legyint, hogy "áhh az úgy sem fog soha bekövetkezni" és ezzel elsiklik a lehetőség fölött. (az optimisták nem túl jók a kockázat elemzésben).
A gyakorlat azonban igazolja, hogy nem hogy az a hiba is bekövetkezhet amire legyintett hogy nem fog, de olyan helyzet is kialakul, amit álmában sem gondolt volna soha.

Mi is az a hibakezelés és minek kell az nekünk?
A hibakezelés az, amikor a program fel van készítve olyan helyzetekre, ami nem üzemszerű és ezekre képes megfelelően reagálni. Általában azzal, hogy leáll és hibát jelez. Miért kell leállni? Hogy ne csináljon hülyeséget (kárt).
Az ilyen nem üzemszerű helyzeteket úgy lehet felismerni, hogy a környezetből (bemenetekről, érzékelőkről) érkező jelek ellentmondásos információkat, vagy nem kívánt helyzetekre jellemző jelzéseket közölnek és a program figyeli ezeket. Sajnos ez nem mindig lehetséges, mert bizonyos redundanciára van szükség, ami nem mindig adott. Mindenesetre ha adott, akkor érdemes vele foglalkozni, sok bajt lehet így megelőzni.
Megpróbálom ezt példával is alátámasztani:
Képzeljünk el egy víztartályt, amit tölteni kell egy szelep kinyitásával. A tartály szintjét két szintkapcsoló érzékeli. ha a szint az alsó szint alá csökken, a szelepet a program kinyitja, ha eléri a felső szintkapcsolót, akkor a töltő szelepet elzárja.


Amíg minden működik, nincs baj. De mi történik, ha tönkre megy valamelyik szintkapcsoló, vagy a szelep? Két dolog történhet:
A rendelkezésünkre álló két bejövő információ alapján (a két szintkapcsoló állapota) nem tudunk minden hibás állapotot felismerni, de kettőt igen:
  1. Ha a felső szintkapcsoló vizet érzékel, miközben az alsó szintkapcsoló nem, az olyan hibás állapot, ami valamelyik szintkapcsoló hibájára utal, hiszen a tartály nem lehet úgy tele, hogy közben üres is.
  2. Egyik szintkapcsoló sem érzékel vizet, a vezérlés bekapcsolja a töltő szelepet, de egy meghatározott időn belül a szintkapcsolók állapota nem változik meg.
    Ez arra utal, hogy nincs víz a töltő rendszerben, vagy a töltő szelep hibás (nem nyitott ki) és a tartály nem töltődik.
A 2. hibaállapot biztonságos érzékelése nehezebb, mert feltételezi, hogy a tartályba beáramló töltő vízmennyiség mindig nagyobb mint amennyi a tartályból fogy. Az időkorlát meghatározása kritikus. A leghátrányosabb helyzetet feltételezve tudni kell, hogy a tartály a töltés megkezdése után legkésőbb mennyi idő alatt éri el a víz újra az alsó vagy a felső szintkapcsolót. Ha az időt rosszul határozzuk meg, akkor vagy fals hibajelzést kapunk, vagy a hibaállapot érzékelése túlságosan sok késleltetést szenved.
Nem vitás, hogy a fenti hibakezelés nélkül a tartály észrevétlenül le tud ürülni vagy túl tud töltődni egy hiba miatt. A példában szereplő helyzetben a vezérlés nem képes közvetlenül a hiba következményeit elkerülni, de képes a hibát jelezni lehetőséget adva a kezelő személyzetnek a probléma orvoslására.

Ha a fenti hibák valamelyike előreláthatólag komoly (és persze negatív) technológiai vagy környezeti következményekkel jár, akkor tervezéskor ezt figyelembe veszik és további redundanciát iktatnak a rendszerbe (ami természetesen további költséggel jár). Pl. biztonsági (vész) szintkapcsoló beépítése, vagy megduplázzák a töltő szelepet, áramlás érzékelőt terveznek a töltő csőbe, stb. Ezek már csak a hibakezelésben vesznek részt Ezek az intézkedések növelik a hiba felismerésének esélyét (pontosságát) és lehetővé teszik a rendszer számára, hogy a hiba következményeit elkerülje (a tartály teljes leürülését vagy túltöltését).

A tartályos dolog csak egy példa. Hasznos lehet a tartályos példához hasonló elveken alapuló olyan hiba figyelés, ami a berendezés károsodása ellen védhet. Pl. sok gép rendelkezik külön kenőolaj szivattyúval. A gép üzemelésének alapvető feltétele hogy a szivattyú nem csak hogy üzemeljen, de a tartályban olaj is legyen, és a szivattyú olajat is szállítson. Fölösleges lenne részletezni miért fontos ez. Gyakori, hogy olajnyomás érzékelő van a szivattyú nyomó ágában, ami egy kontaktust zár, amikor az olajnyomás megfelelően nagy. Ennek jelét a PLC természetesen figyeli, a rendszert csak akkor engedi működni ha a nyomáskapcsolóról jelzés jön, hogy a nyomás megfelelő. ha a szivattyú meghibásodik vagy elfogy az olaj, nem lesz megfelelő nyomás amit így a rendszer érzékelhet. De mi van akkor, ha maga a nyomáskapcsoló hibásodik meg és állandóan "nyomás megfelelő" jelet produkál? Az hogy innentől a szivattyút az olajjal együtt haza is vihetjük a gép menni fog (egy darabig).
Feltéve hogy a szivattyú nem üzemel állandóan (pl. amikor a gép sem üzemel) a nyomáskapcsoló hibáját is detektálhatjuk. Amikor a szivattyú ki van kapcsolva, a nyomáskapcsoló nem adhat "nyomás megfelelő" jelzést (néhány másodperces késleltetés után) mert akkor csal!

A véghelyzet hiba figyelése

Nézzünk még egy, szintén gyakori példát.
Modern technika ide, XXI. század oda, ma sem csinálnak mindent robotok nincs minden mozgó elemen szervó hajtás. Főleg mert drágák és bonyolultak, nincs szükség rájuk minden áron. Ezért nem ritka (sőt!) hogy gépek mozgó részeinek helyzetét egyszerű végálláskapcsolókkal érzékeli a vezérlés (esetleg induktív érzékelőkkel).
Az ilyen gépeken gyakori feltétel egyes mozgásokhoz, egy másik mozgás véghelyzetének megléte. Pl. palettázót nem praktikus oldal irányba mozgatni ha nincs felemelve, különben dűt-borít. Természetes, hogy a programban ilyenkor, az oldal irányú mozgatás feltétele a másik hajtás fent helyzete. Na de mi van akkor, ha egy mechanikai hiba miatt az induktív érzékelőt a működtető vas kissé megskalpolja és onnantól folyamatosan érzékel (úgy marad)? (Az induktív érzékelőkre jellemző, hogy sérüléskor állandóan érzékelő állapotban maradnak). Ha ez történetesen az emelő hajtás fent helyzetét érzékeli, akkor a vezérlés azt fogja hinni, hogy fent helyzetben van (hiszen az érzékelő ezt jelzi) és elindul oldalra akkor, amikor valójában még nincs is fent helyzetben és kész a baj.
Egy jól irányzott hibakezeléssel az ilyen baj egyszerűen elkerülhető, ahol a gép mozgó részét egynél több érzékelő, végálláskapcsoló is figyeli. Egyszerűen generálunk egy hibajelzést és leállítjuk a gépet olyankor, amikor a két (vagy több) véghelyzet érzékelőről egymásnak ellentmondó információk érkeznek (egyszerre van lent és fent, elöl is van, meg hátul is, stb). Az ilyen állapot egyértelműen hibára utal.


Ha a rendszerben nincs operátor panel, vagy egyéb lehetőség a hibák megkülönböztetésére (elkülönítésére) akkor egy hibajelző bitben is kezelhetjük az összes ilyen véghelyzet hibát:



Egyszerűbb gépeknél az ilyesmi előfordul, de nagyobb rendszereknél megoldott a hibajelzések elkülönítése. Ezeken nem csak egyetlen hibajelző lámpa van, mert egy hiba bekövetkezésekor a gép megállna a hiba miatt, de a kezelő nem tudná milyen hiba van, merre keresse a bajt.

Bizonyos véghelyzet érzékelésnél, pl. nagyon rövid löketű munkahengereknél előfordulhat, hogy a két (vagy több) véghelyzet érzékelő átfedésben van egymással. Vagyis a henger mozgása közben van olyan helyzet, amikor egyszerre két véghelyzet érzékelő is érzékel. Ilyennél a fenti RS tárolós megoldás minden mozdulatnál hibát jelezne, pedig ez üzemszerű állapot ebben az esetben.
Ilyenkor időzítést alkalmazhatunk, vagyis megengedjük hibajelzés nélkül, hogy egyszerre két véghelyzet legyen, de csak egy bizonyos ideig. Néhány másodperces bekapcsolás késleltető időzítés általában megfelel az átfedés áthidalására:



Így ha több mint egy másodperc ideig érzékel egyszerre a fent és a lent helyzet érzékelője, akkor a gép leáll.

A mozgás hiányának érzékelése

Előfordul, hogy a gép mozgó részének a helyzetét folyamatosan kell mérni. Pl. mert valamilyen körülménytől függően számtalan meghatározott pozícióba kell megállítani, vagy más, szintén mért helyzetű mozgó résszel kell szinkron helyzetet felvennie.. Ilyenkor általában olcsóbb valamilyen útmérést alkalmazni, mint minden egyes lehetséges megállítási pozícióba külön véghelyezet érzékelőt szerelni.
Az útmérés lehet egyszerű és elnagyolt, amikor a hajtás egy fogas tárcsa segítségével impulzusokat ad forgás közben. Nem érhető el így nagy pontosság (mert az impulzusok állapotváltozásai közötti idő - ha nem alkalmazunk megszakításos bemenetet - nem lehet kevesebb mint a PLC ciklus idő) de sok helyen a célnak ez is megfelel és olcsó megoldás.
A precízebb útméréshez encodert alkalmaznak. Az útmérés működését és programból való kezelését itt nem részletezem, a lényeg hogy mindkét esetben lesz egy számszerű értékünk (aktuális pozíció érték), ami a hajtás pillanatnyi helyzetével arányos, így a hajtás mozgása közben természetesen változik.
Ha a hajtás mozgásának ellenőrzésére nem írunk hibakezelést, akkor adott pozícióba mozgatás a programból kb úgy fog kinézni, hogy miután a mozgás minden feltétele megvan, a program bekapcsolja a hajtó motort az adott irányba és várja mikor éri el a cél pozíciót. Amikor eléri, a hajtást megállítja, jelzést ad a program más részeinek, hogy a kívánt művelet végrehajtásra kerüljön.
De mi van akkor, ha a hajtás forog, de a koordinátánk nem változik. Pl. kábelszakadás miatt, vagy mert az impulzus adó eltört, vagy az encoder hajtását végző bordás szíj/lánc vagy kuplung elszakadt, eltört?
Ilyenkor alakul ki a "megy  a nehéz vas, ki tudja hol áll meg" helyzet. Gépe válogatja, hogy ebből mekkora baj lesz, de mindenképp valamilyen baj lesz.

Az ilyen eset ellen is lehet hibakezeléssel védekezni.
Az impulzus adós megoldás esetén, amikor a fogas tárcsa impulzusai egy közönséges PLC bemenetre érkeznek (és nem alkalmazunk gyors számlálót) egy időzítőt újraindítunk minden alkalommal, amikor az impulzus adó bemeneten egy fel vagy lefutó él érzékelhető, pl. így:



A példában az #Imp_BE az impulzus adó bemenet, az #IMPTMP valósítja meg az él figyelést, a #Start akkor aktív, amikor a hajtás start parancsot kap.
Az él figyelés nagyon fontos, mert ha anélkül oldanánk meg a figyelést és az impulzus adó tartósan épp olyan állapotba kerülne a hiba miatt ami nem engedi meg az időzítő letelését (a példa esetében ez a FALSE állapot), akkor a hibakezelés nem venné észre az impulzusok hiányát.
De miért is éppen ez a "csodálatosan agyafúrt impulzusos" megoldás ne tudna visszaütni ha épp kedvezőek a feltételek a szíváshoz?
Pl. amikor az impulzus adó tönkremegy a vasárnapi éjszakás műszak közepén és persze hogy nincs már másik hasonló sem a raktárban, akkor van a baj. Mert az él figyelés miatt nem lehet csak úgy átkötni, de kikötni sem a bemenetet hogy addig "had menjen a gép", majd reggel megoldják a karbantartók. Hiszen átkötve vagy kikötve sem fogja engedni az üzemelést, hibajelzés lesz belőle!
Ha ez egy olyan hajtás forgás figyelése, aminél a figyelés csak biztonsági okokból lett megvalósítva, akkor anélkül is üzemelhet a gép. Ennek negatív következménye csakprobléma esetén lehet.
Hogy a hiba érzékelés hibája ne okozzon termelés kiesést, biztosíthatjuk, hogy a forgásimpulzusok figyelése kikapcsolható legyen (nyilván HMI-vel rendelkező gépen könnyen megvalósítható az ilyesmi). Persze ennek is van sötét oldala, mert ha egy működést akadályozó tényezőtől a kezelő meg tud szabadulni, akkor azt valószínűleg előbb-utóbb meg is teszi! Persze ez ellen is védekezhetünk a beállítás jelszavas védésével, hogy a kezelő ne tudja kikapcsolni a figyelést, csak a műszakvezető, vagy egyéb illetékesnek kikiáltott személy. Tapasztalat, hogy a jelszavak előbb-utóbb kiszivárognak és szájhagyomány útján terjedve a gépkezelők birtokába is eljutnak.
Ez ellen is védekezhetünk szigorú jogosultsági szabályok bevezetésével és szankciók kilátásba helyezésével. De ez is visszaüthet, mert végső soron minden, a zökkenőmentes működés érdekében hozott közvetlen korlátozó intézkedés előbb-utóbb közvetve a zökkenőmentes működést fogja akadályozni.

Bocsánat, kissé elkalandoztam....
Szóval az enkóderes változatnál ha a hajtás forog (illetve forognia kellene, mert kapja a start parancsot) bizonyos időközönként mintát veszünk az útmérés szerinti helyzetéből (a hajtás aktuális pozíciójából). Ha két egymást követő minta közötti eltérés nulla vagy túl kicsi, akkor a gépet leállítjuk és hibát jelzünk, mert a vezérlés nem érzékeli a hajtás forgását.



A blokk hívása:


A fenti kód az "áll" jelet állítja elő M82.2 merker bitben, ami egy néhány másodperces időzítővel egy RS tárolót kapcsol be ha aktív amikor a hajtásnak forognia kellene.
Az ilyen megoldás okozhat fals hibajelzéseket, ha a hajtás frekvenciaváltós és a mozgási sebességet nagyon lassúra állítják. Persze ez megfelelően kompenzálható tolerancia csökkentésével, azonban ha az túl kicsi, akkor előfordulhat hogy hiba esetén sem jelez hibát.

A futásidő mérése és a hibakezelés programblokkba szervezése

A fenti megoldások keveréke a futásidő mérés.
A lényege igen egyszerű: A legtöbb folyamatnak egy rendszerben ismert véges időn belül be kell fejeződnie. Ha ezen időn belül nem fejeződik be, akkor baj van. Pl. pneumatikus munkahengerek mozgása nem történik meg. A szelep kinyit, de a munkahenger nem mozdul, a vezérlés pedig várja a következő mozzanathoz szükséges feltételek között azt, hogy a munkahenger a kívánt véghelyzetbe érjen (rendszerint bemenetre kötött reed relés vagy hall elemes érzékelővel). Ilyenkor ha ez a hiba nincs kezelve, akkor végtelen hosszú várakozás alakul ki.
Balesetveszélyes is lehet, mert tudjuk ugyan, hogy bekapcsolt gépbe nem nyúlkálunk, de a kezelők leleményessége szinte végtelen. Belemászik, piszkálja, seprűnyéllel bökdösi és az enyhén görbe szár miatt szoruló, vagy a túl kis levegőnyomás miatt gyenge erőt kifejtő henger egyszer csak átvált a vezérlés által kívánt helyzetbe, akkor a gép azonnal működésbe lendül talán épp a kezelővel a hátán.
Az ilyen esetek kezelése nélkül gyakoribb baj az, hogy a gép megáll, de nem tudja senki miért és csak tanakodnak körülötte, az idő meg megy.
Az ilyen hibák egyszerű időméréssel kezelhetők. A folyamat kezdetekor elindítunk egy időtagot, a folyamat leállásakor leállítjuk. Ha a folyamat vége előtt le tud telni, akkor gépet leállítjuk és a programból hibát jelzünk.Az időtag idejét úgy határozzuk meg, hogy normál körülmények között a megadott idő alatt a folyamat garantáltan véget érjen. Érdemes valamekkora ráhagyással (20-50%) számolni, hogy ne okozzon fals hibajelzéseket.

A futásidő mérése sokféleképpen megoldható. Pl. közönséges S7 timerrel is. ha nincs túl sok olyan mozgás, folyamat amit így akarunk figyelni.



A fenti programrészlet úgy működik, hogy ha be van kapcsolva az irány szelep és 12 másodpercen belül nincs abban a véghelyzetben a munkahenger amelyik irányba éppen mennie kell, akkor bekapcsolja M2003.7-es hibajelző merkert. Az időtag előtti két ág a mozgatás két iránya. Mivel ugyanaz a hajtás vagy munkahenger nem mozoghat egyszerre mindkét irányba üzemszerűen, egy időzítővel mindkét irányú mozgatás futásideje mérhető anélkül, hogy a fals hibajelzés esélyét ezzel növelnénk.

A pneumatikánál maradva (hidarulikára is érvényes lehet) ha a kialakítás olyan, hogy egy szelep pár nem csak egy munkahengert, hanem többet is működtet, melyek mindegyike rendelkezik véghelyzet érzékeléssel, akkor  az alábbi módon ugyancsak egy időzítőt használva mérhetjük a futásidőt:



Ha a rendszer bonyolult, sok a mozgatás, érdemes lehet írni egy program blokkot, ami elvégzi a futásidő mérést és a véghelyzet hiba kezelését.
Ez a megoldás talán áttekinthetőbbé teszi a hibakezelést, mert logikai feltétel sorok helyett csak a blokkokat és azok paramétereit látjuk, de egy programhiba keresését éppen ez nehezítheti meg.
Az alábbi példa bemutat egy ilyen megoldást, a véghelyzet és időtúlfutás hibák kezelésére:

A blokk interface része:




A blokk hívása az alábbi módon fest:



Ha a futásidő mérését nem timerekkel szeretnénk megoldani, akkor mérhetjük impulzus számlálással is. Ehhez csak egy "órajelre" és egy számláló változóra van szükség. Ilyet még érdemesebb külön blokkban megírni, mert a hibakezelést végző programrész már elég nagy ahhoz, hogy sokszor ismétlődve áttekinthetetlenebbé (és persze hosszabbá) tegye a PLC programot.

Közvetlen hibajelzések

Ezalatt azt értem, amikor nem kell külön programot írni a hibaállapot felismerésére, mert közvetlenül bemenetek jelzik azt. Ugyanis egyes jelzések már a vezérlés HW-ében kerülnek észlelésre. Ilyen pl. a motorvédő hiba a biztosíték kiolvadása, feszültség, fázis hiány, hajtásvezérlőkről érkező hibajelzések, vészleállítás, stb. Ezeket nem a PLC érzékeli, hanem a vezérlésbe épített készülékek, eszközök.
Az ilyenekkel van a legkevesebb munka, amikor az adott bemenet ammi a hibás állapotot jelzi aktív lesz, akkor létrejön a hibaállapot.

Összefoglaló

A nhibakezelés lehetőséget ad arra, hogy a vezérlés (célszerűen egy operátor panel segítségével) külön szöveges üzenettel jelezze az összes kezelt hibát. Tehát nem csak azt arja ki, hogy időtúlfutás vagy véghelyzet érzékelési hiba van, hanem azt is, hogy konkrétan melyik mozgatásnál. Munkaigényes megoldás a programozónak, de hosszú távon megtérül a rövidebb hibaelhárítással megspórolt időben.

A hibakezeléssel tehát szabályokat alkottunk, korlátokat állítottunk fel, amiken kívül a rendszer működése leáll.
Ha már vannak szabályok, nézzük hogyan hághatjuk át őket! :)
Miért? Mert a szabályok célja az, hogy az életünket könnyebbé tegyék, de ugyanakkor egyik alapvető tulajdonságuk, hogy bizonyos helyzetekben éppen nehezebbé teszik azt! Hogy miképpen könnyítenek rajtunk a szabályok, azt fentebb körvonalaztam, most nézzünk egy példát arra amikor nem:

Bekövetkezik egy véghelyzet hiba. Pl. eltörik egy végállás, megnyomva marad, a gép mozgó része pedig a másik véghelyzetben van. Hála  a hibakezelésünknek a program észreveszi hogy baj van, mert mindkét véghelyzet jele egyszerre aktív, ezért a gép hibajelzéssel leáll. Jön a karbantartó elhárítani a hibát. Látja mi történt, szeretne hozzáférni a mechanika hibás részéhez, de nem tud, mert a mozgó rész épp olyan helyzetben van, ami lehetetlenné teszi a megközelítést. Át kellene mozgatni a másik helyzetbe, nosza átváltja a gépet kézi üzemmódba, vagy karbantartás módba, ami kifejezetten azért van, hogy a gép egyes részeit külön a kezelőpultról egyesével lehessen mozgatni ilyen esetben. De nem tudja a hiba elhárításához megmozdítani éppen a hiba miatt.
A kígyó a farkába harapott, visszanyalt a fagylalt. Lehet hozni a pajszert...


Így már meg is fogalmazódott a közelgő jó tanács: Amennyiben a gépnek van ilyen kézi vagy karbantartás üzemmódja, gondoljuk át, hogy ebben az üzemmódban a program melyik hibakezelést ne végezze el!

Itt a teljesség igénye nélkül, csak néhány példán igyekeztem bemutatni, hogy mi a hibakezelés, a program hogyan ismerheti fel a problémákat és miért fontos hogy megtegye.
Az adott rendszer jellegétől, feladatától és felépítésétől függően rengeteg más hibaforrás is lehet (sőt, van). A program tervezésekor, át kell gondolni hogy a rendszer milyen hibalehetőségeket rejt és azok kezelése, felismerése mennyire lehetséges  és mennyire fontos.
Pl. terepi busszal rendelkezik, analóg mérések vannak, azok hibaállapotait is kezelni kell. Vagy ha a kezelő ellentmondó beállításokat alkalmazott az operátor panelen, stb. Sokszor a már beüzemelt rendszer működése közben alakul ki olyan helyzet, amire a programozó nem gondolt. Az ilyesmit utólagos program módosítással lehet (illik) megoldani.
A jó hibakezelés megvalósítása nehéz és időigényes.

Az írás második része itt olvashaó.

Kapcsolódó írások:
Tartály töltés
Az idő mérése
Blokk hívás, változók és paraméter átadás
Az encoder



Szirty