Vezérléstechnika egyszerűen

Eddigi ismereteimet, tapasztalataimat szeretném az alábbi rovatban összeszedni, hogy inspiráljam az olvasókat saját megoldások fejlesztésére, és azok megvalósításra. Különféle trükkök, praktikák is olvashatók lentebb, melyek az Arduino vezérlőkkel eredményesen használhatók. 5V-os TTL rendszertől a 12V, 24V MOSFET-es ipari rendszerekig különféle alkalmazásokra volt már alkalmam készíteni áramköröket, kapcsolódobozokat.

Nyílt forrás és arduino

Mint legtöbbünk, én is a google keresőben kerestem legelőször a megoldást, és elég sokak megosztását láttam az arduino kísérletező áramkörökkel. Nagyon megtetszett a dolog, mivel elég egyszerűen programozható. Nekem azelőtt az ABB root RAPID programnyelvén volt a legtöbb tapasztalatom, illetve időnként felmerült pár másik C++ vagy BASIC-hez hasonló programnyelv, mint például a PC alapon működő kamera rendszerek vagy más robotok, mint KUKA KRC4 vagy KRC2, illetve FANUC RJ2. Persze a robotos munkák során sok-sok egyéb kihívással és érdekes megoldással is találkoztam, vagy magam készítettem megoldásokat, melyek nem a programozáshoz, hanem inkább a mozgáshoz, jelkezelésekhez kapcsolódnak.

Minden esetre, mint minden nyílt forrású témában, ebben is nagyon sok információ, tapasztalat és program könyvtárak elérhetők a világhálón és személyes felhasználásra ingyen használhatóak. Vagyis inkább arról van szó, hogy az ingyen használható könyvtárak nem értékesíthetőek. Ezért is és mivel jómagam is nagyon hasznosnak tartom ezt  a fajta eljárást, osztom meg én is a fejlesztéseimet, továbbfejlesztéseimet. Vagyis az itt elérhető információk szintén nem értékesíthetőek. Tehát, amikor más részére készítesz egy berendezést, vezérlést, csak munkadíjra, anyagra kérhetsz térítést, az ingyen szerzett programokra nem.

Vas és logika

Angol nyelven ezt hardware-nek és software-nek hívjuk, ami elég köztudott is, bár sokan nincsenek képben, melyik kifejezés mit is takar. Ezért adtam a vas és logika címet ennek a fejezetnek, hogy közelebb kerüljünk a megvalósításhoz, de követhető legyen a gondolatmenet.

Minden vezérlő egység egyszerű félvezetőkből áll, amiből ugyan rengetek bele van zsúfolva, de attól még azok csak annyit tudnak, hogy 0,2÷0,6V-fölött kinyitnak, illetve ezalatt bezárnak. Nagyon fontos, ezzel tisztában legyünk, amikor készítünk egy új rendszert, vagy programot írunk, mert minden igaz (TRUE) jelent 1-et, illetve nem biztos, hogy a 0 érték hamisat (FALSE) jelent a működés során. Minden relatív, így a potenciál különbség is relatív, ami alapján működnek a mikrovezérlők is. Vagyis a 0V-hoz képest adhatok 5V-ot, de van amikor ez nem sikerül és csak 3,6V lesz belőle. Na most a hardver, amire adjuk a feszültségeket illetve jeleket, ezekkel a kis félvezetőkkel és passzív elemekkel határolja el a 0 és 1 logikai értékeket egymástól. Egy 100kHz-nél gyorsabb jelnél és mondjuk a Vcc (tápfeszültség) 6V-nál ez a 3,6V már észrevétlen is maradhat, vagyis túl gyenge a jel ahhoz, hogy egyáltalán a hardver fel tudja dolgozni. Holott elvileg már 3V fölötti értéknek aktív (1) bemeneti értéket kellene adnia. Nagyon sokszor belefutunk abba a hibába, hogy jónak gondoljuk a rendszerünket, és mondjuk az irodai asztalon még működött is szépen, de ipari környezetben vagy nagy energiájú gépek mellett (hegesztő gép) már nem működik, illetve néha nem azt csinálja, amit kéne. Bizony ezekben az esetekben a vasat, áramköröket kell felturbózni és a programunkhoz nem feltétlen kell hozzányúlni, mert az egyébként teljesen jó.

Persze nem mindig jók a szoftverek sem, vagyis a rendszer logikáját tartalmazó rész. Egyrészt a szoftver az előbb említett tranyók állapotából álló logikai halmazából áll. Egy memóriában vannak a bitjeink tárolva, amik a processzor által feldolgozva együttesen valamilyen logikai sort hajtanak végre. Ez az úgynevzett programfutás. Párhuzamosan több program is futhat a processzorban, attól függően, hogy mire van felkészítve, de nekünk a többszörös szinten leegyszerűsítve csak egy programsor látszik a soros Basic vagy C++ szerű programnyelvben. Sorról sorra hajtja végre az utasításainkat és mi ezt szépen fel tudjuk fogni a kicsi fejünkkel és követni tudjuk. Ezért is készült így, hogy jól követhető legyen és átlátható legyen a programnyelv, amin keresztül megadjunk hardvernek, mit csináljon. Tehát, ez egy nyelv, amit azért készítettünk, hogy egy egész sor műveletet el tudjunk végezni az eszközünkkel. Csodát tehát ne várjunk el ettől! Több processzort összekötve még nem fog keletkezni semmilyen mesterséges intelligencia, max nem bírjuk már megadni a rendszernek, hogyan működjön, mert követhetetlen, átláthatatlan. Tehát, maradunk a magunk kis 16MHz-es processzora mellett és a vasakat ennek segítségével mozgatjuk meg. A fenti, hardveres példához hasonlóan viszont itt, a szoftverben is előfordulhatnak olyan hibák, ami miatt nem működik a rendszer vagy az, hogy néha másként működik. Ez pedig legtöbbször az időzítések miatt történik. Vagyis, míg sorról sorra végrehajta az utasításainkat a kis proci, épp jön egy jel egy pillanatra, aminek a figyelését nem adtuk meg, majd csak a pillanat utáni pillanatban, pár sorral lentebb. Vagyis előfordulhat, hogy éppen amikor írjuk, teszteljük a programot, tökéletesen működik, de pár nappal később vagy más környezetben az a jelecske kicsit másik időpontban jelenik meg, vagy rövidebb ideig, így lemarad a program róla. Rengeteg ilyen hiba van az iparban, ami a programnyelvek közti különbségek okoznak, illetve azért nem figyelnek rá a programozók. Általában véve az az alap feltételezés, hogy a hardver olyan “erős” (gyors és precíz), hogy a legapróbb jelet is észleli és nagyos pici a teljes program lefutási ideje. A valóságban viszont ez sokszor megdől! Egyrészt a jel specifikussága is okozhatja, hogy ő bizony csak egy pici tüske. Másrészt a program hossza, vagyis lefutási ideje is lehet olyan hosszú, hogy mire visszaér ugyanarra a bemenet várakozásra a program, már hetedhét országon túl van a jelünk és a 20-ik másikat látjuk csak helyette.

Megszakítva a programmenetet, de a gondolatmenetet folytatva, van rá megoldás, hogy bármikor észrevegye a rendszer a parányi, nagy frekvenciás jeleket! Ezeket nevezzük megszakításoknak, vagyis olyan speciális bemenetek, melyekre a jelszint változásakor lefut egy kis programrész, megszakítva az addig futó programot. Ezek a program részek, rutinok a megszakítás rutinok, melyek épp csak arra vannak, hogy jelváltozásoknak megfelelően egy memóriaterületre, változóba számláljuk az eseményt vagy esetleg valamilyen eszközt ki- vagy bekapcsoljunk. Az ilyen jelek száma korlátos és nem minden processzor van felszerelve ilyennel, de van amelyiknek minden bemenete képes rá.

Melyik kártya, mire képes

Alábbi táblázatban összeírtam az általam preferált arduio kártyák főbb paramétereit:

Arduino Proci Fesz. Log/Táp [V] Órajel [MHz] Analóg Be/Ki Digitál IO/PWM EEPROM/SRAM/Flash [kB] INT/I2C/RxTx Kieg.
Mega2560 ATmega2560 5/7-12 16 16/0 54/15 4/8/256 6/1/4
Mega ADK  ATmega2560 5/7-12 16 16/0 54/15 4/8/256 6/1/4 USB host
Due ATSAM3X8E 3,3/7-12 84 12/2 54/12 -/96/512 54/2/4 USB eszköz
Nano ATmega328P 5/7-9 16 8/0 14/6 1/2/32 2/1/1

Mega2560, Mega ADK, Due+EEPROM és Nano

Azért esett ezekre a választásom, mert ugyanazt a csatlakozási kiosztást használhatom hozzájuk és elég sokat tudnak motorvezérlések megoldásához. Már ami a megákat es a due-t illeti. Nano-nál külön kártyát kellett készítenem, de legalább lett egy kompakt kis megoldásom, amit alegységként is tudok használni.

Tehát a fenti kártyák nem grafikus megjelenítésre és adatfeldolgozásra valók, hanem valamilyen mechanikus szerkezet irányítására! Sok jel van rajtuk, amit érzékelőkhöz, mágnesszelepekhez, motorokhoz köthetünk. Persze mindig valamilyen erősítőn vagy optikai leválasztón keresztül, mivel itt csak minimális, <40mA terheléssel használhatók a jelek.

Az ADK alkalmas USB eszközök kezelésére is, a kiegészítő MAX3421E csipkészlettel. Így a robotunkat irányíthatjuk egy gamepad segítségével is.

Nekem a legjobban bevált kezelő eszköz a TM1638 vagy TM1640-es csippel működő HMI (human-machine interface). A maga egyszerűségével csak számokat tud megjeleníteni, lámpákat villogtatni es gombnyomást érzékelni. Viszont a kijelzést elég csak egyszer kiküldenünk rá, s aztán a következő parancsig az látszik.

LCD kijelző is létezik gombokkal, amire már szöveget is ki lehet írni, de ez nem látszik olyan jól, mint az előző LED-es kijelző.

E-Ink kijelzőt is beszerezhetünk hozzá, ami nappali fényben jól látszik es kevés energiát használ. Sajnos még nem volt alkalmam kipróbálni, de hamarosan veszek abból is, ha már a saját nyákomra rátettem a csatlakozási helyét.

A Due eseteben sokkal nagyobb processzor sebesség áll rendelkezésünkre. Olyan esetekben, ahol nagyobb feldolgozási sebességre van szükség, ez jó választás lehet, de oda kell figyelnünk a feszültségszintekre, mivel ez csak 3,3V-al működik.

Kiegészítők

Vezérlő, kezelőpanel+enkóder kerék, motor hajtások, feszstab, mp3 lejátszó, relék és szalagkábel

Mivel elég macerás egy komplett rendszert összeállítani csupán vezetékeket dugdosgatva a fenti kártyákra, mindenképpen rá kell tenni őket egy kiegészítő kártyára (shield). Rengetegféle shield elérhető mar, de sajátot is építhetünk egy ügyes nyáktervező programmal. Jómagam például olyan kártyát terveztem, amit többféleképpen építhetek össze, attól függően, hogy éppen mire akarom használni a vezérlőt.

A Due esetében például elég nagy gondot okoz, hogy nem 5V-os a rendszer. Az én kártyámmal viszont ezt az építésnél orvosolni lehet. Az IC-k pedig, amik rajta vannak, 3V-os jelváltásra is működnek.

Analóg bemenet

Bemenetek esetén nem szükséges külön csatolót alkalmazni, elég, ha a belső pull-up ellenállást aktiváljuk (digitalWrite(pin,High) paranccsal), illetve az anaóog jeleket pedig a potméter kivezetésére kötjük, a másik kettő pedig a 0V es 5V (Due-nal 3,3V). Arra viszont fokozottan ügyeljünk, hogy ellenőrizzük a tápfeszültséget, mert én folyamatosan azzal szenvedek, hogy vagy zajos az analóg bemenet vagy rossz jelszinten van a táp. Tehát, mindig akkor finomítsuk a beállításokat, ha mar a saját tápját használja a vezérlő. Sajnos a feszültseg stabilizátor nem ad elég tiszta, vagyis sima jelet ahhoz, hogy precízen mérhessünk és kihasználjuk az 1024-es felbontást. Kompenzálni lehet szoftveresen a tápot mérve, de az utolsó számérték akkor is ugrálni fog 2-3 léptékkel oda-vissza.

Tápot is jobb, ha külön adunk az eszközöknek es nem az arduino feszstabján keresztül használjuk az 5V-ot. Ezert tettem en is külön feszstab áramkört a kártyámra, hogy legyen elegendő áram a reláknek, aktív érzékelőknek. Így 4A-ig nyugodtan köthető rá bármi. Ami szinten figyelemre méltó, hogy léteznek olyan áramkörök is, amelyek felfele és lefele is tudnak kompenzálni. Vagyis kapcsolóüzemű áramkörrel es RLC körrel 3V-ból is tudnak 5V-ot csinálni (többet is, csak nagy veszteséggel). Praktikus, amikor akkuról vagy elemről működik a rendszer.

Kimenenti csatoló, ahol RB lehet 1k, a tranzisztor 2N3904 esetén a Vcc lehet 40V/200mA

Tranzisztoros erősítővel is készíthetünk nagyon egyszerű jelerősítést. Ilyen elven terveztem az új kártyámat a Nano-hoz. Volt már korábban, hogy egy PC párhuzamos portján (LPT) lévő jelet erősítettem csak simán a kábel végére forrasztott 2N3904-es tranzisztorral. Mivel a kimenetet földre, illetve 0-ra húzza, akár nagyobb feszültséget is kapcsolhatunk ezáltal. Annyi az egész, hogy fordított logikája lesz, de azt úgyis kiteszteljük a beállításkor.

Monitoring vs sebesség

A teszteléshez előszeretettel használt Serial.println(“text”) rengeteget segít abban, hogy megfigyeljük, mi történik valójában a folyamat során. Legtöbbször, ha valami nem működik, vagy nem úgy ahogy kéne, használom ezt a parancsot. Arra viszont oda kell figyelni, hogy túl sűrűen nem mehetnek a parancsok! Se az arduinonak nem használ, se a laptopnak, ahonnan programozod, ugyanis annyira teleszórja a soros portot, hogy képes lefagyni a windows. Arduino dettó. Szóval, valamennyi, akar 10-20ms időzítést legalább tegyünk két kiírás közé.

Új kártya terve 2db IBT-2 motorhajtással

Amennyiben elég lassú a program már egyébként is es  van jó pár utasítás, amivel elszötyörög a proci, nem kell időzítés. Ilyenkor viszont fordított a helyzet, mivel a soros port nagyon sok időt elvesz a programfutásból, ami lelassítja azt. Tehát, például egy PID szabályzásban ne használjunk kiírást, vagy nagyon toljuk fel a baud rate-et. A HMI elég jól használható a TM1638-al, de ott is csínnyán kell bánni az utasításokkal! Motorvezérlésre külön vezérlőt is használhatunk, mivel van épp elég feladata a központi vezérlőnek. Jómagam is arra a megállapításra jutottam, hogy több motor es főleg hosszú kábelek esetén nagy sebességnél külön vezérlőt kell használnom. Ezert is terveztem így a Nano kártyáját, hogy erre is alkalmas legyen.

Soros kommunikáció, busz

Ahhoz, hogy több aktív eszközt is össze tudjunk kapcsolni, meg kell oldani köztük a kommunikációt. Az arduinokon van I2C/TWI busz es RxTx kommunikáció, valamint nagy sebességű adatkommunikációhoz ISP busz. Az elérhető programbővítésekkel (library) egyszerűen használhatjuk ezeket a funkciókat anélkül, hogy beleásnánk magunkat a különféle kommunikációs protokollokba. Nagyobb távolságokra viszont az 5V-os jelszint nem használható, vagy csak nagyon lassú órajellel. Az I2C kétirányú kommunikációval működik, de normál soros porton, az RxTx jelekkel fix irányokkal dolgozunk, ami lehetővé teszi az egyszerű jelerősítést.

Erősített jelszint a soros kommunikációhoz

Több méteres kommunikációhoz kitaláltam, hogy a kártyámon lévő L298 motor jelerősítővel felerősíthetnem a Tx jelet es az Rx-et pedig, ahogy valaki egy fórumon említette, zeenerrel es 10k ellenállással átkonvertálhatom 5V-ra. Gyors kapcsolásúnak kell lennie a zeenernek, biztos ami biztos. Direkt ennek megfelelően módosítottam a Nano kártyáját, de a másikon is könnyen  beköthető ez a funkció, max kicsit rá lesz forrasztva ott, ahol eredetileg nem volt betervezve.

Javítások, átkötések

Nem csak házi kivitelezéseknél megszokott az áramkörök utólagos átrendezése, javítása. Ahol korábban dolgoztam, az ABB-nel is bevett szokás volt, hogy a robotok saját fejlesztésű áramköreit kijavították, utólag átalakították és úgy épült be a drága robotokba. Szóval, nem kell félni attól, hogy egy helyen elreszelem a nyákot es egy átkötéssel máshova kötöm a lábakat!

Persze, később amikor mar tökéletesítve van a rendszer es nagyon sokat kell belőle csinálni, érdemes újratervezni a nyákot és úgy legyártatni. A kis darabszámú és főleg az egyedi gépeknél viszont erről szó sem lehet.

Két motor vezérlése ugyanazzal az IC-vel

A képeken bemutatok pár trükköt, amivel ugyanazt a nyákot egészen más feladatokra is lehet használni az átkötések, passzív elemek használatával.

Kimeneti helyere köthetünk bemenetet, melyet 24V-os rendszerhez illesztünk, ugyanazt a motorvezérlőt használhatjuk több motorhoz is irányváltó relé segítségével, vagy soros kommunikációnál kapcsolhatunk két eszköz között ugyanazzal az RxTx parossal. Variációk sokasága áll rendelkezésünkre, csak hagyjuk képzeletünk szárnyalni.

Programozás

Képzeletünk szárnyalása ezen a területen tudja leginkább kamatoztatni sikereit. Ma mar köztudott, hogy a telefon (okostelefon) gyártók is leginkább a szoftveres fejlesztésekkel oldják meg a hardveres problémákat, kihívásokat. Persze így is van még sok terület, ahol számomra érthetetlen módon még nem oldották meg a köztudott problémákat. Csak példaképpen írom, hogy amikor fogom a telefont és rajta van az ujjam a képernyőn, nem tudja érzékelni a szoftver, hogy ez nem pötyögtetés, figyelmen kívül kell hagyni azt az érintést es körülötte az ujj lefedési területét, s a másik négy lehetőség közül meghatározni, mit akar a felhasználaló. Nagyon egyszerű programváltoztatás lenne, de sajna még mindig óvatosan kell fogdosni a telefonunkat, mert nem érti, mit akarok, s akár a fülemmel úgy át tudom állítani, hogy egy programozó is alig találja meg, hol kell visszaállítani azt a paramétert.

Tehát, nem vagyunk egyedül a programozási analfabetizmusban és nagyok sem olyan nagyok, mint állítják magukról.

Minden esetre az arduino elég egyszerű programnyelv, ha a basic vagy c++ nyelveket ismerjük. Nekem például az volt egy nagy kihívás, hogy odafigyeljek az = es == használata közti nagy különbségre. Ugyanis a feltétel megadásakor az = jel értéket ad at, ott az == jelet kell használni az egyenlőség vizsgálatához.

Másik nagy problémám a feltételek feldolgozásánál történt. Szeretem egyszerűsíteni és ezáltal összetetté tenni a programot. Egyik mozgásfeldolgozásnál betettem a PID szabályzást egy függvénybe, amit a feltétel sorában használtam. Igen, de amikor a sorban előtte lévő feltétel nem teljesül, a többit már meg sem nézi, így nem futtatja le a függvényt sem. Szóval, szét kellett szednem az if-es utasítást, hogy logikám a gép részére lefordítható formátumba kerüljön. Alább a példa:

Helytelem
while ((!bMoveL(nPosL,0) || !bMoveX(nPosX,Zone) || !bMovelS(nPos,Zone)) && bExec && !bError)
{//Move all axis

Helyes
moveEnable();
bRdy=0;//Requested for right program logic!!! Compiler check only one true function…
while (!bRdy && bExec && !bError)
{//Move all axis
bRdy=1;
if (!waitDI(intWaitDIAddr,1,1)) {moveDisable;module0.setDisplayToString(“WaitDI “+String(intWaitDIAddr));waitDI(intWaitDIAddr,1,0);}
if (!bMoveL(nPosL,0)) bRdy=0;
if (!bMoveX(nPosX,Zone)) bRdy=0;
if (!bMoveS(nPosS,Zone)) bRdy=0;
if (module0.getButtons() == B01000000) bExec=0;
}

boolean bMoveX(int Pos, int Zone)
{//true means the function has error or ready, bExec false means error.
if (Pos>PosX+PosDX)
{//X axis +
if (!ComputePID(1,Zone)) {bExec=0; return true;} //Get MotorOut value from PID controll
analogWrite(mapDCFwdAx[1],MotorOut);//Move forward with byteXSpeed
digitalWrite(mapDCBwdAx[1],LOW);//0
PosX=EncX.read()/nXArany;
if (bA1) module0.setDisplayToString(“a1 “+String(analogRead(mapMotorAmp[1]))+” “, 0);
if (bX && !bA1) module0.setDisplayToString(“X “+String(PosX)+” “, 0);
if (bMan && module0.getButtons() == B01000000) {bExec=0; return true;}//Cancel button
if ((analogRead(mapMotorAmp[1])>900 || (analogRead(mapMotorAmp[1])==0 && moveTime[1]>1000))) {bError=1;return true;}//Motions supervision
return false;//Motor needs to move.
}
else if (Pos<PosX-PosDX)
{//X axis –
if (!ComputePID(1,Zone)) {bExec=0; return true;} //Get MotorOut value from PID controll
analogWrite(mapDCBwdAx[1],MotorOut);//Move backward with byteXSpeed
digitalWrite(mapDCFwdAx[1],LOW);//0
PosX=EncX.read()/nXArany;
if (bA1) module0.setDisplayToString(“a1 “+String(analogRead(mapMotorAmp[1]))+” “, 0);
if (bX && !bA1) module0.setDisplayToString(“X “+String(PosX)+” “, 0);
if (bMan && module0.getButtons() == B01000000) {bExec=0; return true;}//Cancel button
if ((analogRead(mapMotorAmp[1])>900 || (analogRead(mapMotorAmp[1])==0 && moveTime[1]>1000))) {bError=1;return true;}//Motions supervision
return false;
}
//Stop
digitalWrite(mapDCFwdAx[1],LOW);//0
digitalWrite(mapDCBwdAx[1],LOW);//0
return true;
}

Felhasználói kezelés

Bio’S Controller kezelée

Annak érdekében, hogy megkönnyítsem a gép beállítását és mások számára is elérhetővé tegyem a program módosítását, írtam programozható programot.

Nos tudom, hogy ez mar a sokadik szint, de nem látná át egy átlag programozó a programomat és főleg nem egy szimpla gépbeállító vagy otthoni felhasználó. Gépi kód-Arduino-Bio’S programozó logikák vannak így egymásba ágyazva. Bio’S az en saját fejlesztésű vezérlőm, így a programsoros logikát is ezzel jelölöm.

Tehát, a felhasználó által elérhető kijelzőn a gombok segítségével közvetlenül programozható az eszköz anélkül, hogy rákötne bármilyen laptopot, tabletet, bármit. A menürendszerben közlekedve válthat “Manual” azaz kézi üzemre, ahol a kézi mozgatásokat végezheti es programot írhat vagy módosíthat, illetve válthat “Program” üzemmódra, ahol végrehajthatja az utasításokat es elindíthatja a programfutást. Korábbi tapasztalataim alapján, a régi jól bevált ABB S3 vezérlőknél használt menürendszerhez hasonlóan próbáltam alakítani a struktúrát.

Bio’S programsorok és kezelői funkciók

Praktikus olyan módon alkalmazni az eszközöket, hogy beállításkor egyből lássuk, mi történik és lépésről lépésre be tudjuk állítani a masinát. Legyen szó kemeneti értékről vagy bemenet vizsgálatáról, illetve motor vezérlésről, legyen látható, hogy mi történik, mi mennyi.

Bemeneti értékfigyelésnél a kijelzőn lehet látni az utasításban használt jel értéket. Mielőtt megnyomjuk az enter gombot, kézzel be tudjuk állítani a távolságot, pozíciót csavarok segítségével, hogy pont ott legyen, ahol a jelet adja.

Kimenet megadásánál a gombok használatával 4-es vagy 8-as csoportokban kapcsolgathatjuk a reléket, aminek a működését kapásból látjuk és a megfelelő állapotot mentjük el az enterrel. Analog kimenetnél pedig a + – gombokkal állíthatjuk be a kimenetet a kívánt értékre.

Motorok használatánál pedig a tengely kiválasztása után adhatunk meg értéket a + – gombokkal (míg nyomjuk, számlál es amikor elengedjük, 5s múlva odamegy). Praktikus dolgok ezek, mert a soros porton nagyon nehéz lenne előre kitalálni, hova menjen a motor.

Soros porton is akad persze helye a felhasználói beállításoknak. Vannak ugyanis olyan dolgok, amiket lehetetlen 8 gomb es egy kijelzősorral megoldani. Ilyenek például a paraméterek beállítása, vagy a program mentése, betöltése. Köszönet az EEPROM- nak, ami a tap lekapcsolásával is megtartja az információkat, állíthatjuk mindezeket be es tehetjük biztonságossá a működést. Due is kap EEPROM-ot I2C-n keresztül.

Kalandra fel! Működtessük a vasakat!

Mindezek mögött sok-sok vezeték, mágnesek és vasak vannak, hogy a feladatot elvégezzék. Van sok olyan művelet, amihez elég egy faék. Vannak mások, ahol ügyes kis szerkezetek, alakkal záró es vezető formák összetett feladatokat végeznek. Míg vannak olyanok, ahol a félvezetők változtatható logikával hol így hol úgy működnek és akár az interneten keresztül is módosíthatjuk a működésüket.

Mind-mind trükkös kis megoldásokat igényelnek, amik hosszas fejtörés után kézzel fogható valósággá válnak. Annak érdekében, hogy egyszerűsítsük a munkánkat, képesek vagyunk órákat, napokat agyalni ilyen rendszereken. Feltéve ugyan, hogy tényleg szükség van rá! Nyitott szemmel kell járni a nagyvilágban, mert vannak esetek, amikor a megoldás ott van előttünk, csak nem vesszük észre. Teszem azt, minek építünk vezérelt vasakat, ha a megélhetéshez bőven elegendő lenne a kétkezi munkánk is és természetes anyagokból el lehet készíteni minden ehhez szükséges dolgot…

Szóval, használjuk a gondolkodásunk eszközök készítéséhez, de mindig a szívünkre hallgassunk a döntések meghozatalában. Nehéz dolog, de ésszel felfoghatatlan a világunk, ezt erezni kell, megélni kell. Élünk és virulunk!
Írta: Kertész Péter

Könyvjelzőkhöz Közvetlen link.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé.

*