Alapból a kapcsolókban a legritkább esetben van nulla (ezt ugyanis ritkán kapcsoljuk). Általában (jó esetben) csak a fázis van megszakítva.
Több lehetséges megoldás van. Egyrészt behúzol egy teljes, új 5V-os tápot mindenhova. Ez, különösen 230 V mellett jelentős zavarokat okozhat, ha nem készülsz rá. A másik alternatíva, hogy beépítesz egy kis tápot is a kapcsoló mellé. A fázis bejövőt és a nullát leágaztatod, az egyikre megy a táp. A nulla másik fele megy vissza a lámpához, a fázis másik fele pedig a kapcsoló relébe, ahonnan az eredeti szál megy vissza a lámpához. Feltéve, hogy van nullavezetőd a kapcsolónál (ez egyáltalán nem biztos). A többi csak kötögetés és biztonságtechnika kérdése. Leágazást wago elosztókkal tudsz csinálni: https://www.hestore.hu/prod_10036983.html
Ha nincs nullád, akkor el kell hoznod valahonnan (elég egy szál, mert csak a táphoz kell).
Viszont a helyszűke miatt nagyon nem lesz egyszerű dolgod, és még ha meg is oldod, akkor is ott van, hogy maga a kapcsolás bele tud szólni úgy az Arduino működésébe, hogy pl. lefagy vagy újraindul stb. stb. És akkor az olyanokról, hogy kézi kapcsolás (valóban kézzel, nem telefonnal) hogyan is működhet.
A lényege, hogy villanykapcsoló helyére illeszthető be ez az "okos" kapcsoló, így telefonról lehet a villanyt kapcsolni különösebb kábelezés nélkül. Régóta gondolkozom hasonló megoldáson is de egyszerűen nem tudom elképzelni, hogyan tudnék relével villanyt kapcsolni, hogy ha a betáp és a kapcsolandó áramkör egy és ugyanaz (ugye nekem a kapcsolóban csak két vezeték van fázis - nulla).
Szeretném megkérdezni, hogy van erre valamilyen megoldás? Mert a fenti linken ezt megoldották de rövidzár nélkül nem igazán tudom elképzelni a dolgot.
Èn úgy gondoltam, hogy egy transzformátorra kötöm a két db 220V - os vezetéket majd ez adja az 5V - ot az arduinonak. Ez oké ez még megy is viszont a lámpát nem tudom így kapcsolni relével mivel a két vezeték felvan használva betápnak :S
Remélem tudtok nekem valamilyen ötletet adni erre mert jó ideje csak ezen gondolkozom.
Vettem egy DIY MIDI E-Drum kit-et, de nincs időm foglalkozni vele (meg nem is igazán értek hozzá), ezért, ha valakit érdekel megválnék tőle. Az összes alkatrészét összeszedtem (alu. doboz, stb.)
Itt ezen a fórumon is, és számos más hazai és külföldi fórumon is visszatérő történet, hogy "csináltam egy ilyet, működik, de most ki akartam bővíteni és nem működik, mi a hiba". Egy fejlesztés során, hobbistaként is (sőt, ott még inkább) előfordulhat, hogy útközben jössz rá valamire, amit máshogy akartál és/vagy kitalálod, hogy hopp, még de jó lenne bele egy kijelző vagy egy gomb (ad abszurdum, egy vészleállító). Ha ezt eleve így írod meg, nem lesz több perc/óra/nap többlet feladat a változó igényhez igazítani. Ha nem, akkor nulláról (vagy közel nulláról) kezdheted elölről.
Ja, és nem mellesleg, fogalmunk sincs, hogy az eredeti kérdező a két relé kapcsolgatásán kívül akart-e valamit kezdeni vele és/vagy van a programnak még egy halom más feladata is (mondjuk a Csendes éjt kopogja morzejelek sorozataként napi 23 óra 57 percen át).
A tipikus erre egyébként az okos ház. Amikor először csak a lámpák, aztán a rendőnyök, aztán a fűtés, aztán a kazán füstgáz, a keringetőszivattyú, a visszatérő hőmérséklet, esetleg szobánként a szelep stb. stb. És az elején nem tudja, hogy most csak a lámpák lesznek, vagy minden más is.
Az előbb írt hármas (négyes) szabályt az általad írt forrás úgy teljesíti, hogy a funkciót (amit tudunk) betölti, egyszerűen viszonylag egyszerű, módjával olvasható, de a legkevésbé sem hatékony.
Ez nem baj. Majd a kérdező eldönti, hogy melyikkel mit kezd, leragad a delay/waitms megoldásnál, vagy az eredeti (egyébként nem nagyon rossz, csak végtelenül túlbonyolított) példához hasonlóan időbélyeget használ (ahogy egyébként az összes belső órajelet használó időalapú megszakítás teszi).
miszerint a tiédet teljesen át kell írni egy új feladathoz (mondjuk egy harmadik, teljesen eltérű ütemben villogó ledhez), az enyémet pedig csak ki kell egészíteni.
megint csak azt mondom: más a célcsoport, amiről beszélünk. ha mindenki, aki ma arduinoval vagy más ilyen játékkal HASZNÁLHATÓ dolgot tervez, ezen a módon kezdene hozzá, akkor kb az egy százada valósulna meg az áramköröknek.
Nekem (és még sokunknak) nem életcélom a programozás.
Az Arduino keretrendszer bázis függvényeit nem tudod módosítani, de speciel pont az i2c külső könyvtár, minden további nélkül belenyúlhatsz (mondjuk előtte célszerű átnevezni a sajátodra). Én egy halom könyvtárba beletúrtam már, mert messze voltak az optimálistól (egyik-másik kifejezetten használhatatlan volt).
Hobbi szinten, ha örömöd leled benne, teljesen megáll ez a dolog és eszemben sincs lebeszélni róla (vagy másra rábeszélni). Ha az időd számít, akkor viszont nem mindegy, hogy valami már készen van és csak használni kell, vagy neked kell birkóznod, akár regiszterek mélységében, hogy működésre bírd. Az Arduino keretrendszer tanulásra jó, de egyébként egy elképesztően nagy rakás szar. A PIC ehhez képest egy egészen más logikát és belső architektúrát követ, annak minden előnyével és hátrányával (utóbbira remek példa, hogy egyetlen szar címzéssel máris stack overflow, és ezt bizony kezdőként nagyon nem nenéz elkövetni -- az Arduino e tekintetben majdnem teljesen hülyebiztos).
A pontosságot hasonlóan értelmezzük.
A te szoftvered és az én szoftverem kb. ugyanazt a kimenetet produkálja, a belső struktúra különbözősége miatt van azonban egy számottevő különbség, ahogy korábban írtam, miszerint a tiédet teljesen át kell írni egy új feladathoz (mondjuk egy harmadik, teljesen eltérű ütemben villogó ledhez), az enyémet pedig csak ki kell egészíteni.
nézd, szerintem te mikrokontrollerekben valószínűleg több nagyságrenddel fölöttem állsz. Mégis, van egy dolog, amit még matematikatanár osztályfőnökömtől tanultam, és nyilván nem ő találta ki: ágyúval nem lövünk verébre.
Mégis ki a jóég akar egy egyszerű, két darab relét működtető program esetében azon gondolkodni, hogy milyen módon lehet majd bővíteni?!
Kell belőle 1 darab. Van egy jól behatárolt feladat, azt tudja. Akkor MINEK készítenék bonyolultabbat? mert ha jól értettem, csak az a bajod vele, hogy nem tudom elegánsan továbbfejleszteni. Na ezért tanultam én meg - ezen az egyszerű szinten - programozni. Van egy ötletem, összerakom, működik és ennyi. Egy szoftver pontosan annyit ér, mint amire az adott feladatban használható. Ha egy 600 forintos arduino nanon fut, akkor nem fogok bele mondjuk 15000 Ft/óra áron programot iratni. Mert az mondjuk ugyanúgy szénné ég majd, amikor a kínai tápegységről telibe kapja a 230 voltot. :)
Ehhez meg kell tanulni a programszervezés alapjait, ami kb. négy szóban összefoglalható:
-- legyen korrekt (azt csinálja, amit elvárnak tőle),
-- egyszerű (amennyire csak lehet),
-- hatékony,
-- magától értetődöen olvasható.
Az első három Bjarne Stroustrup C++-szal foglalkozó alapművében szó szerint benne van, a negyediket is írja, de én úgy gondolom, hogy különösen kezdők számára legalább olyan fontos alapvetés, mint az első három.
Ha egy program végig van kommentelve, mert nem világos, hogy a "szerző" mit akart az adott kódrészlettel, akkor az a kód nem jó, mert 3-5 év múlva össze kell fejtened majd a kommenteket és a kódot, hogy vajon tényleg az-e.
Jól értelmezem, hogy a WaitMs függvény (vagy bárminek is nevezzük) gyakorlatilag annyit jelent, hogy "várj az attribútumnak megfelelő számú milliszekundumig"? Mert akkor logikailag ez a szoftver kb. a "blinky 1.5" szintjén van, ami az első megtanulandó és az első elfelejtendő szoftver beágyazott rendszerekben. Az indok pedig kő egyszerű: ha egy szoftver képes egy feladat elvégzésére, de később bővíteni szeretnéd egy másik feladat elvégésére is, és ehhez át kell írni (nem pedig bővíteni kell), akkor a kód rossz.
még valami: arra már nagyon régen rájöttem, hogy az ilyen hozzám hasonló amatőrnek a legfontosabb, hogy a saját programját jól dokumentálja, kommentelje - éppen azért, amit mondtál, hogy később egyáltalán megértsem, mit akartam egy adott sorban.
egyébként érdekes, de én, gépészmérnökként kicsit fordítva állok egy feladathoz: ha nincs megadott pontosság, akkor nem a lehető legnagyobbra törekszem, hanem az általános clú - ezáltal egyszerű és nyilván kevésbé pontosra.
Ami a ráfordított munkát illeti: ez most kb 10 perc volt. Nekem éppen azért jó ez az oshonsoft-os basic program, mert ugyan nem ez a foglalkozásom, de leülök, perceken belül ott a végeredmény. Ja, hogy nem kompakt a végeredmény? Most úgy komolyan, egy 328 chipnek van akkora tárhelye, hogy beleférjen.
Lehetne még reszelgetni, hogy mi legyen , ha leesik a tápfesz stb stb - .
Egyébként én azért ezt használom, mert a PIC-hez ugyanez a basic rendszer használatos, csak persze a kompilátor különbözik - csak aztán jól megszivatott, mert kiderült, egy csomó függvény még nincs készen. És akkor jön a datasheet meg a regiszterek kibogozása - ami szerintem a PIC esetében egyszerűbb (nekem logikusabb), viszont az Atmelnél van olyan funkció, ami sokkal jobb - pl a pwm generálás egyszerre több, független generátorral. Így aztán most van egy néhány saját programocskám, I2C vezérlés meg ilyenek - vagyis felépítem ugyanazt, ami az Arduiono könyvtárban megvan :).
Viszont: ezeket a kis szubrutinokat akármikor módosíthatom, amire az arduino esetében nincs lehetőség. Szóval van ahol nyerek, van ahol veszítek - de mégiscsak játék.
Láttam, nem reagáltál a felvetésemre. Nos, nézzük részletekben.
1. Ha valami nincs előre meghatározva, akkor alapértelmezett a „magától éretődő” kivitelezés. Pl. ha időt mérünk, akkor praktikusan jó, ha azt pontosan tesszük. Itt persze a pontosság viszonylagos, de vannak bizonyos hétköznapi fogalmaink arról, hogy ha óráról beszélünk, akkor mondjuk 1 nap ne legyen 15 perc járateltérés, mert a hét végére hülyén fogja kivenni magát, hogy 7 óra helyett 8 órakor kelünk (és így tovább). Vannak alkalmazási területek, ahol minden idősíkon 1 mp és 1 év között a milliszekundumos pontosság a követelmény, erre nyilván nem egy retek Arduino a válasz. A pontosságot azért írtam, mert a rendszer kb. ezt tudja (ha nem kristályos, hanem rezonátoros a kapcsolás, akkor még ezt sem), és az alkalmazása előtt ezt alapból figyelembe kell vennie a felhasználónak. Amolyan apróbetű.
2. Ami a fejlesztői környezetet illeti. Ez egy szimulátor alapvetően, amelyből a kész hex-eket simán át lehet tölteni bármilyen Arduinoba (kis túlzással) vagy különálló eszközre, akár kész kódként. Jópofa cucc, de alapvetően -- ahogy nézem -- valahol a gépi kód, valamint a regiszterek és egy magasabb szintű kód (mondjuk C) között van, mindkettőből merítve elég vastagon (még ha a szintaktikája láthatóan viszonylag egyedi is). Arra jó is jó, hogy egyedi gépi kódú instrukciók szintjéig lehet debugolni, ami mondjuk nem egy mindennapi lehetőség.
Ugyanakkor az tény, hogy minden magasabb szintű nyelv valamelyik könyvtárába implementálva van a várakozás valamilyen formában. Arduinoban a delay(), mbedben a tick() és a wait(), C++-ban (11-től) a sleep valamilyen formája (vagy a standard könyvtárban vagy valamelyik időzítésre kitalált könyvtárban). Az tehát nem nagy nehézség, hogy várakozásra késztessünk egy processzort, a kérdés az, hogy körülötte mit csinál a program, illetve az, hogy ezzel mennyi ideig kell szívnunk (nem tartom kizártnak, hogy barkócza nekiállt gépi kódban, tisztán az órajelek tekergetésével megoldani a feladatot -- kérdés, hogy ezzel mennyi időt fog igénybe venni és a kész kód mekkora lesz. Nekem kb. 45 perc volt, és szépítgettem is (mondjuk nem tökéletesre), 1 kB a kód, ami cseppet több, mint amit ideálisnak tartanék erre a feladatra, cserébe átlátható, olvasható, bármikor nehézség nélkül (évek múltán is) karbantartható különösebb dokumentáció nélkül, és nem mellesleg az Arduino keretrendszeren belül bármelyik eszközre nehézség nélkül portolható.
Bármit bármivel meg lehet oldani, lényegében teljesen szabadon. A kérdés csak az, hogy ez mennyi idő, mennyire egyedi és mennyire karbantartható/olvasható. Ezért is vagyok kíváncsi a te megoldásodra.
Kevertem kicsit, nem neked szántam. Egyébként az Arduino panelek 90%-án 328p van, úgyhogy abból ki lehet indulni (amin nem az van, azzal kapcsolatban meg ritkán kérdeznek ennyire alap dolgot).
na de ha a feladatban egyáltalán nem volt szó arról, hogy pontosan kell működnie, ráadásul állandóan újraindítja a ciklust, akkor miért nem lehet valami egyszerű, egész számon alapuló, számláló típusú időzítő függvényt használni? Én az arduinokat nem a hozzá kitalált nyelven programozom, hanem egy basic szerű, profik számára valószínűleg megvetendő szoftverrel (www.oshonsoft.com), de hát ott van pl egy waitms időzítő függvény, megadod, hány milliszek, ha nem elég, beteszed egy ciklusba, aztán működik és kész. Ha nagyon akarom, akkor még azt is kiszámolhatom, mennyit téved ciklusonként s korrigálok. Vagy félreértettem a kolléga feladát?
A millis() függvény unsigned long típusú változó. Ez 0 és 2^32 (-1) közötti értékeket vehet fel. 2^32 hatványon osztva ezerrel (milliszekundum), osztva 60-nal (másodiperc) osztva 60-nal (perc), osztva 24-gyel (óra) 49,7. Ennyi nap után nullázódik. Ha erre nem figyel a kód, belefuthat abba, hogy a millis() függvény által visszaadott érték már fordult (elindul újra nullától), de a vizsgált értékek ezen túlmutatnak. Egy viszonylag egyszerű kóddal ez kezelhető, csak figyelni kell rá fejlesztéskor. Meg mondjuk a millis() függvényt nem egészen erre találták ki, ha ilyen hosszú időtartamot kell figyelni, arra inkább precíziós időmérőt illik használni (real time clock), és ahhoz igazítani az abszolút méréseket.
Van benne egy logika, ami alapján nem hülyebiztos. Ez pedig az, hogy ha a két led közül bármelyik kivárási idejét magasabbra állítod, mint a ciklusidő, akkor az egyik led folyamatosan világítani fog, a másik fog (a rövidebb ideig bekapcsolt) villogni.
A 2 perces ciklus pontossága javítható (közelíthető egy atomórához) úgy, hogy:
unsigned long EndTimeCycle = 0;
csere
unsigned long EndTimeCycle = millis();
és
EndTimeCycle = millis() + CycleTime;
csere
EndTimeCycle += CycleTime;
Ezzel a két változtatással az első induláshoz képest fogja számolni a ciklusidőket, nem pedig attól, amikor az ellenőrzések miatt épp befut az újraindító függvénybe. Ez valamivel pontosabb (itt napi mondjuk 1-2 mp járateltérés lehet a két megoldás között, talán még annyi sem. Cserébe az első kör néhány milliszekundummal rövidebb lesz.
Szia, Kb. 45 napig üzembiztos, utána újra kell indítani.
// led 1 declarations #define ledPin1 12 // the number of the LED pin bool ledState1 = false; // ledState of first LED unsigned long OnTime1 = (60L * 1000L); // milliseconds of on-time (seconds * milliseconds) unsigned long EndTime1 = 0; // value of millis() when LED 1 should shut off
// led 2 declarations #define ledPin2 13 // the number of the LED pin bool ledState2 = false; // ledState of second LED unsigned long OnTime2 = (90L * 1000L); // milliseconds of on-time (seconds * milliseconds) for LED2 unsigned long EndTime2 = 0; // value of millis() when LED 1 should shut off
// Full Cycle declarations unsigned long CycleTime = (2L * 60L * 1000L); // cycle time in ms. (minutes * seconds * milliseconds) unsigned long EndTimeCycle = 0; // value of millis() when the new cycle should start
void ledOneOn() // Turns led 1 ON { digitalWrite(ledPin1, HIGH); ledState1 = true; }
void ledOneOff() // Turns led 1 off { digitalWrite(ledPin1, LOW); ledState1 = false; }
void ledTwoOn() // Turns led 2 ON { digitalWrite(ledPin2, HIGH); ledState2 = true; }
void ledTwoOff() // Turns led 2 off { digitalWrite(ledPin2, LOW); ledState2 = false; }
void loop() { // check if leds is out of ON time if (ledState1 && EndTime1 <= millis()) ledOneOff(); if (ledState2 && EndTime2 <= millis()) ledTwoOff();
// check if the cycle has ended if (ledState1 == false && ledState2 == false && EndTimeCycle <= millis()) startCycle(); }
