Egy kis elektronika - amúgy sem árt, ha az arduinosok néha észreveszik, hogy nem csak programból áll, hanem elektronikai alkatrészekből is :)
Szóval, van egy kapcsolásom, aminek a tápja eredetileg egy apcsolóüzemű táp volt, de a nagy áramú kapcsolgatásokra (20 amperos impulzuok egy FET-en) elég rosszul reagált, mert mindig rátöltött a pufferkondikra, ami miatt tele lett zajjal a tápvonal.
OK, átépítettem trafó plusz Graetz-hídra, egy LM7812 stabival.
A problémám.
A trafó 13,2 VAC-t ad ki. Ebből lesz ugye az egyenirányítón 13,2 x 1,4 - 2 x 0,5 = 17,5 volt.
A kapcsolás folyamatos üzemben 50 mA áramot vesz fel, 12 volton. A 7812-nek akkor a maradék feszültségen kell eldisszipálnia ezt az áramot: 5,5 volt x 0,05 A = 0,275 W.
A mellékelt ábrán látjátok, mekkor hűtő van rajta - ami RENDESEN meleg, mondjuk 50 fokos.
Nomális ez? Mi lenne, ha a névleges 1,5 ampert venném ki belőle???
Ismerősöm nem annyira rossz (CC) háza. Kicsi volt, így csak egy ponton mért, viszont volt kint is egy érzékelője, hogy a fűtés erősségét a külső hőmérséklethez tudja igazítani (padló + radiátor). Sikerült annyira elbaltázni a szabályozást, hogy néha akkor is bekapcsolt, amikor kint 15, bent pedig 22 fok volt. Ne kérdezd, miért. Akkor viszont, amikor kint -10 volt, bent pedig 18, akkor előfordult, hogy 5 percenként kapcsolt ki-be, teljesen indokolatlanul.
Más megközelítésben meg... Én biztosan nem kötnék semmit RPI-re. ESP8266-ra sem igazán. Ezeknek a hardveres oldala még viszonylag erős fejlesztői környezetben, tudatos (mérnöki) fejlesztéssel sem egy életbiztosítás (a RPI még talán, az ESP-et engedjük el!).
Egyrészt, 9 mm mozgás nagyon sok. Pláne, hogy 0, 9 mm vagy 9 mm egész számú többszöröse játszik csak. Itt adott esetben milliméteres (extrém megközelítésben ennél is pontosabb) pozicionálás kellene, ráadásul gyorsan. Ebből következik még egy dolog. A PID szabályozás lényege pont az, hogy a célként kitűzött egyensúlyi pont környékén elég pontos, azon kívül meg elég gyors. Ezt ezzel a motorral csak részben tudod teljesíteni, az egyensúlyi pont környékén ide-oda fog ugrálni a kocsi, mert hol az egyik, hol a másik irányba fog kitérni. Már ha egyáltalán képes leszel a PID szabályozást megfelelően paraméterezni. A PID nem pozícióra szabályoz, hanem állapotra. Mivel ez egy analóg rendszer, itt az lesz, hogy az ideális állapottól való eltérés mértéke, az ideális állapothoz képesti változás vektora (iránya és sebessége) fogja meghatározni, hogy milyen irányban és milyen sebességgel kell mozogjon az autó. Ninyilván minél szélsőségesebb az eltérés, ez az sebesség annál nagyobb lesz. Amire te gondolsz, az az lenne, hogy "ahhoz, hogy egyensúly legyen, innen ide kell mennie", csakhogy ha mérleghintáról van szó, ez (nagyon kis számú kivételtől eltekintve) nem fog működni.
Én nem kínlódnék enkóderrel. Ha van egy lineárisan mozgó tömeged, akkor kizárólag azt figyelném, hogy az egyensúlyi állapot eléréséhez merre és milyen sebességgel kell mozognia. Ha PID szabályzás van, akkor a pozíciónak nem lesz jelentősége, mivel a változás irányából és mértékéből (mennyire dől a mérleghinta, illetve a dőlés szöge változik-e, és ha igen, milyen irányban) lehet következtetni arra, hogy a kocsinak merre és milyen sebességgel kell mozognia (ez a sebesség lehet 0 is, elméletileg). Ilyen rendszerekben a PID nagyon kifinomult és jól működő szabálozási megoldás, de ehhez nem kell enkóder. Egy baromi gyors, jó tapadást biztosító kerék (vagy mint a példában láttuk, lánctalp) és egy kellően precíz és gyors léptetőmotor kell hozzá. Namost ez drága mulatság lesz, de megfelelő áttételezéssel megoldható, hogy elég legyen egy darab.
Igazából a mentorommal konzultàltam a projektemről, és közösen döntöttünk hogy így legyen. Így pontosabb szöget tudunk mérni, mert ha nem lenne párhuzamos az autó felülete az asztallal akkor nem tudunk pontos szöget mérni.
Bocs, megint belekotty :) A helyzet az, hogy a fűtésünk korszerűsítése kondenzációs kazán beépítését követelte - hála a rendeleteknek, sikerült rendes fogyókúrát előidézni a pénztárcán :( Lényeg, hogy olvasgattam a hozzászólásokat, és egy lényeges dolog elsikkadt: a mai kazánok - a kondenzációsak szinte biztos - Opentherm protokollal vezérelhetők. Ha veszel egy olyan termosztátot, amelyik ezt tudja, akkor gyakorlatilag a kazán vezérlését a helyi fűtési igényeknek megfelelő külső szabályozót telepítettél. Magyarul: kiszedted a vezérlést a kazánból, és oda tetted, ahol több lehetőséged van az adaptív vezérlésre, mint eredetileg volt. Pontosítva: a levegő hőmérséklet eltérése a kívánttól is belejátszhat a fűtési teljesítmény meghatározásába, a kazánban megvalósított kimenő-visszatérő víz hőmérsékletén kívül. De ez utóbbit is le lehet kérdezni, azaz a komplexebb vezérlés megvalósítható, időjárás követést is beleértve.Arról nem is beszélve, hogy az egyszerű on-off termosztáthoz felvehető fűrészfog jellegű hőmérséklet diagram burkológörbét kap(hat), további komfort növekedést eredményezve. Nevezzük ezt a vezérlési pontot A-nak, azaz A1 földszint, A2 emelet. A kolléga írt egy önszabályozó szivattyúról, ez B. Azaz, lesz 3 olyan bemeneti pont, ahol a halvány lilába derengő fogalma sem lesz az illetőnek a vezérlési görbe sajátosságairól, doksi ide vagy oda. A kazánon egyetlen bemeneti pont van - azaz, az A1 és A2 által generált igényeknek (szivattyú fordulat, láng szabályozás, mint minimum) valahova be kell futni, és ez a valami aztán összegyúrja az igényekből a tényleges parancsokat. Nos, én egyszerűsítettem a dolgot, de még nem készítettem el:
- egy-egy ESP8266 figyeli az alső ill. felső szint léghőmérsékletét. Önmagától nem küld semmit, csak ha kérdezik (mini webserveres üzemmód). Aki kérdez, az pl. egy Raspberry, akire a két szelep van bízva - földszint és emelet, valamint a kazán indítása-leállítása a legegyszerűbb esetben. A RP tárolja a távolról betölthető fsz és emeleti kívánt fűrési értékeket, ezeket a pontokat veti össze a két ESP-ről lekérdezett értékekkel, valamint naplózást is végez. Ha most bonyolultabbá akarjuk tenni a vezérlést, akkor az RP-be beépítjük az Opentherm vezérlést, két pontos bementettel, ha a kazánt is kérdezgetjük, akkor 3 pontos lesz a bemenet. Ha ezt megcsinálom, akkor nem kell hozzá mérnökcsapat, csak egy meglehetősen türelmes hátsó fertály :) - emellett az egyszerű, kétpontos termosztát működésre rátettem egy intelligensebb vezérlést. Kisit hosszabb lett a hozzászólás, mint terveztem, bocsánat.
Egy ilyen rendszernek pont az a lényege, hogy az összes node (autó) saját maga méri a dőlésszöget, és saját maga dönt arról, hogy merre induljon el az egyensúly kialakításához.
A feladatot egyedül kezdtem el kb 2hónapja. Most állok úgy hogy el kellene kezdenem foglalkozni a szabályozás résszel. Van még rengeteg időm. És én csak egy úgymond "gagyibb" változatát szeretném megvalósítani, csak annyira kell hogy működjön a rendszer hogy ha elinditom 2percre akkor tegye a dolgát és ennyi.
Azért esett az ESP vezérlőkre a választásom mert van egy viszonylag egyszerű protokoljuk, rettentően gyorsan küldi az adatot wifin keresztül egymás között. Ezzel a résszel már készen is vagyok.
Ahogy említetted is a motorokkal vagyok bajban, de sajnos csak ezeket tudtam beszerezni mivel Aliról valószínű nem jönnek meg a csomagok. Egy lépéssel ezek kb 9mm mozdulnak, ha ezeket a kerekeket használom. Tudom ez nem precíz de remélem megoldható lesz a dolgok ezekkel.
Akkor vissza térnék a legelső kérdésemre, hogy ezzel a motorral és Enkóder tárcsával megvalósítható e valamilyen PID szabályozás pozícióra? Vagy van e erre szükség egyáltalán?
Tudom vezérelni őket pozícióra PID nélkül csak úgy van túllövés 1-2lépés. Ezt szerettem volna kiküszöbölni a pozícióra szabályozással.
Nem kis pályás ez a cucc... De pár dolgot így előre nem árt tisztázni a témában.
Ez nem one-man-show. Ezt egyedül borzalmas és kegyetlenül fájó tapasztalatsorozat végén fogod tudni megvalósítani, ha egyáltalán. Ez, amit itt láttál, egy legalább 3-4 fős team munkája, amiben éppúgy van mechatronikai mérnök (hallgató), mint programozó matematikus (hallgató), mind gépészmérnök (hallgató) és valószínűleg egy elektromérnök (hallgató) is. Akkor bele se vágj, ha nincs rá legalább egy éved, szemmel jól látható nagyságrendű forrásod és egy hozzáférhető műhely, amelyben minden szükséges eszköz, felszerelés rendelkezésre áll. Ha egyetemen kívül akarsz vele mókolni, tudok helyet javasolni rá.
Műszaki megközelítésben pár javaslat:
1. Az esp32 / esp8266 wifi modul. Itt erre nincs szükség, mert az adatátviteli rétegben a szükségesnél számottevően több adat jön-megy, amelynek a feldolgozása, küldése, visszafejtése és újrafeldolgozása borzalmasan sok erőforrást köt le ahhoz képest, amire igazából szükség lenne. Sok lehetséges megoldás van, ezeken érdemes esetleg végigmenni kísérleti jelleggel egyszerűsített modelleken. Vannak az esp-nél sokkal egyszerűbb, adatátvitelt lehetővé tevő megoldások, amelyek sokkal alkalmasabak két darab, maximum 10-12 bites érték átküldésére.
2. Az a motor, amit választottál, csak ennél számottevően kisebb léptékben fog tudni működni és ott is vannak fenntartásaim a megbízhatóságával kapcsolatban. Itt is igaz, hogy attól függően, hogy mit és hogyan akarsz bizonyítani és/vagy milyen típusú adatokat szeretnél gyűjteni, eltérő forgatókönyvek és elképzelések alapján lehet építeni. Bizonyos megoldások borzalmasan gyorsak, mások elképesztően precízek, megint mások gyorsak és precízek egyszerre, cserébe baromi nagyok horrorisztikus mennyiségű energia kell a működésükhöz.
3. Mindenképp csinálj pontos tervet, de ne arról, hogy hogyan, hanem arról, hogy mit és miért szeretnél megvalósítani. Vagyis a cél legyen az első, ne pedig az ahhoz választott eszköz. Kb. mint a kalapács, ami ha a kezedben van, egyből mindent szögnek nézel. Nem lehetetlen a cél megvalósítása (lásd fentebb), de nagyon észnél kell lenned, ha nem akarsz végtelen mennyiségű pénz kidobása után kudarcot vallani a megvalósítással.
Akkor pontosítanám hogy miért is kellene nekem ez a szabályozás. Szakdolgozatomhoz kell majd az egyetemen. Egy ilyen hasonló projektet szeretnék összehozni. https://youtu.be/ElEHN8tHJnc annyi különbséggel hogy én csak 1 autót szeretnék használni. 1:05től 1:16ig látható a videón.
Kettő ESP mikrovezérlő lesz, az egyik méri az asztal dőllés szögét és azt küldi a másik vezérlonek ami az autó lesz. Az autó pedig majd próbálja vízszintbe állítani az asztalt.
Ha szükséges akkor összedobhatok egy kapcsolási rajzot.
A "mit akar a szerző" felvetés jön bennem elő mindig hasonló esetben. A kód rendben van, de amíg az nem tiszta, hogy a kapcsolásban az in1~in4 mi és hova és hogyan van kötve, addig nehéz lesz megoldást mondani rá. Ezek a motorok PWM-mel hajtva nem fognak optimális teljesítményen üzemelni, mert a terheléstől alapjaiban változik meg a viselkedésük. Lehet, hogy üresjáratban 30 százalékos kitöltési tényezőnél már vígan pörög, viszont terhelve csak 70 százalékos kitöltési tényezővel indul el. PID szabályozást nem értem, amíg nem akarsz önegyensúlyozó vagy baromim gyors vonalkövető robotot csinálni, addig nincs sok értelme. Az enkóderek osztásának megfelelően elég jó pontosságot lehet elérni, de nyilván ez rengeteg dologtól függ. Ha nagyon nagy precizitás kell, akkor én inkább valami vaskosabb léptetőmotorra szavaznék, akár gyorsítóáttétellel, azzal (a csúszást/kúszást nem számítva) nagyon jó pontosság érhető el. Van egy robotépítős közösség, ott egész komoly precizitást tudtak megvalósítani ilyen elven.
A kapcsolást nem tudom megrajzolni, mert én ESP vezérlőt használok, és L298N H hidat sem találtam. De viszont azt elmondhatom, hogy egy egyszerű robot autót szeretnék építeni és azt szeretném pozícióra szbályozni, hogy pontosan annyit menjen előre vagy hátra amennyit megmondok neki.
Az ardu megbízhatósága bennem is felmerült. Igaz, hogy itt nincs olyan biztonsági kockázat mint egy vegyestüzelésnél, de akkor se lenne jó -10-ben fűtés nélkül maradni.
Az adatok mennyisége szerintem jóval több mint 3:
- Emeleti szoba hőmérséklet - Földszinti szoba hőmérséklet
- Puffer tartály felső hőmérséklet - Puffer tartály középső hőmérséklet - Puffer tartály alsó hőmérséklet - Fűtési előremenő - Fűtési visszatérő - Térfogatáram - Kazánkilépő hőmérséklet
Mivel a radiátorok termosztatikus fejjel szereltek így a helyiség szabályozás megoldott. A szobánként programozott radiátor itt már nem hoz annyit, hogy bármi érdemi haszna lenne. Éjszaka 23 fokról reggelre 21 fokra hűl a szoba, nincs az a radiátoros termosztát ami ezt le tudja követni. Lehet, hogy egy fej elvileg ezt tudja, de a helyiségben mindenütt, vagy méginkább a jellemző tartózkodási helyeken a hőérzet nem függ attól, hogy 0,1 vagy 0,5 vagy 1K-es a fejegység pontossága.
A pufferbe való bekötést pontosan a tehetetlenség miatt szeretném megcsinálni. A hagyományos radiátorok esetében ha már leszabályoznak a termofejek, pont fordítva megnő az előremenő-visszatérő különbség. A térfogatáram esik be. Ez az új összeállításban nem okozna problémát mivel van egy autoadapt-os Grundfos Alpha2 szivattyúm, térfogatáramot és nyomást saját maga szabályozza.
Fűtési körben nem gondolom, hogy 0,1-es pontosságra szükség van. Még az 1 Kelvines mérés is feleslegesn pontos. A standard radiátor fejek 2 Kelvines értéke úgy gondolom bőven elegendő vízhőmérséklet mérése esetén. Egy radiátor 40 vagy 42 fokos víz esetén nem fog érdemben nagyobb/kisebb teljesítményt leadni.
A Dallas hőfok IC úgy gondolom monitorozni jó. De abban egyetértünk, hogy nem elég stabil.
A baxi pl 15K NTC hőelemeket használ.
A vezérlő esetén nézegettem már a PLC-ket, lényegesen stabilabb, "ipari" szerkezetek, de azért az áruk is vastagabb minimum egy 0-val.
Nem tudom jó helyre írok-e új vagyok a fórumon. Lenne egy pár kérdésem az Arduino programozással kapcsolatban.
DC motort szeretnék vezérelni pozícióra PID szabályozással. Igazából azt szeretném megtudni, hogy erre létezik e olyan megoldás hogy fix PWM értéket kapjon a motor és pozíció értéket(lépést) adjon ki a PID? Az a problémám, hogy ha PWM értéket ad kimeneten a PID akkor van egy pillanat amikor kisebb lesz a feszültség mint 3V és nem megy a motor. Csak nyöszörög.
1. Elvileg alkalmas rá az arduino, sok függ attól, hogy pontosan mit akarsz. 2. Az, hogy mi kell hozzá és ezt hogyan lehet működő projektté faragni, szintén attól függ, hogy pontosan mit akarsz (lásd az előző válaszomat). 3. Indulj el arra, hogy a lehető legpontosabban, a saját szavaiddal leírod, hogy mire van szükséged.
Szóval, egy ilyen rendszerrel folyamatosan az lesz a gondod, hogy gazdaságtalanul és nagyjából megbízhatatlanul fog működni.
Egy ilyen szabályozást rá lehet bízni egy 328p-re, DE azok a biztonsági elemek, amelyek a tuti működést biztosítják, az Arduino keretrendszerben annyira már nem elérhetők egyszerű módszerekkel. Mókolni és regisztereket állítgatni persze lehet, de ettől még a rendelkezésre állás optimális esetben sem lesz több, mint 95 százalék.
Olyan rendszert kell szabályozz, aminek legalább három analóg bemeneti adata van és az ezekből kialakuló lehetséges esetkombinációkból kell befolyásolnod néhol bináris (fűtsön-e a kazán), néhol analóg (bekeverés mértéke), mindezt úgy, hogy a rendszer lehetőleg ne fusson meg sehol.
Én azt csinálnám, hogy egy teljes, szobaszintű (de legalábbis légtérszintű) tervet csinálnék a kalkulált fűtési teljesítménnyel. Mivel felteszem, hogy köponti fűtés van jelenleg egy szabályozó ponttal (termosztát), a hőigény alapján overkill (ráadásul valószínűleg jelentős hiszterézise van minden irányban). Ezt bontanám le úgy, hogy lokális szaabályozást tennék a rendszerbe, már ha erre egyáltalán mód van, akként, hogy minden szobai radiátorra egyedi, esetleg programozható szabályozót tennék, így mindenki igénye és kényelme szerint tudná beállítani a hőmérsékletet. Ha a rendszer forszírozott áramoltatású (ami egyébként villamos energiában eléggé komoly veszteség), akkor csak az előremenő és a visszatérő különbségét figyelném a bevont pufferrel együtt, így az egész fűtési rendszernek egy brutál nagy tehetetlenséget adnál, így -- elvben legalábbis -- ritkán kellene kapcsolgatni a kazánt, hogy a kellő hőtöbblet rendelkezésre álljon. Ha mindenhol meleg van, akkor a visszatérő hőmérséklete érdemben nem lesz alacsonyabb, mint az előremenőé, ezt is akár órákra kompenzálja a puffer.
Szívás, ha van padlófűtés, mert míg a rendes kör előremenője 85 fok is lehet, addig a padlóba 65 fok fölött nem mehet semmi és a visszatérő mindig szignifikánsan hidegebb lesz.
Az, hogy ehhez az egészhez legyen egy megbízható rendszered, legelőször nagyon pontos és 100%-osan megbízható mérés kell. Ez már nem a DS18B20 hatásköre, mert van pár olyan pont a rendszerben, ahova bizony ipari minőségű hőmérők kellenek, amelyek pontos illesztése az Arduino alapvetően feszültségalapú analóg mérésére, nem olyan magától értetődő (elképesztően sokat szívtam vele egy éve egy projekten). És itt mondjuk egy előremenő víhzőfok mérése +/-0,1 abszolút pontossággal több tízezres nagyságrend és még mindig csak egy áram kimeneted lesz, amiből pontosan feszültséget vagy digitális jelet kell konvertálnod.
Sok függ attól, hogy mi az a fényforrás. Led? Karácsonyfaizzó? Halogénlámpa? Világítótorony reflektorának fényforrása?
Ha 230 V-os, akkor kell venni 12 db programozható időkapcsolót bármelyik barkácsáruház on-line shopjában, be kell őket állítani és kész.
Ha kivitelezés alatt álló épületbe kerül, akkor szereléksínre rakható programkapcsolók is vannak, parádésan működnek.
Ha mindenképp barkácsolni akarsz, akkor a világítótestek jellegétől függően (néhány) tízezer és nagyjából 100 000 forint közötti összeg jön ki anyagárra, plusz erelés plusz a szoftver. Amit egyébként kb. 1 óra alatt üzembiztosra meg lehet írni.
egy olyan probléma merült fel nálam hogy egy Hobby projekt miatt kéne egy olyan áramkör, mely óránként mindig a következő fényforrást kapcsolná fel, és az előzőt le. Egészen a 12-dik fényforrásig, és a 12-diknél ezt előről kezdené. Így egy 12 órás formátumú órához hasonlóan működne. Remélem egészen érthető a dolog. Az lenne a kérdésem hogy ennek a vezérlésére alkalmas lenne e egy Arduino? És ha igen, hogy? Sajnos nincs ilyen téren semmi tapasztalatom, a programozás is elég messze áll tőlem. Remélem egy picit tudnátok segíteni abban, hogy milyen irányba induljak el a dologgal. Előre is köszönöm!
Amikor bekerült, se szigetelés, se ablakcsere. Akkor kb kellett is ez a teljesítmény.
Ma már ott tartok, hogy a méretezett hőigényem 8kW. Azaz a kazán addig tud érdemben fűteni amíg felfűti a rendszert. Hőn tartani csak hidegebb időben, s akkor se hosszan.
Pufferem van - mert van egy vegyeskazánom is - muszály leszek bevonni a körbe.
Innentől jön a vezérlés érdemi része: a lakáskör fűtési előremenő hőmérsékletét egy keverő szeleppel akarom biztosítani. Ez már megvan. Ennek a vezérlése 220V-al történik, nyitó illetve záró irányba. A szelep teljes futási ideje 90sec.
Most egy szobatermosztát vezérli csak a a gázkazánt (de ez termosztát már haldoklik).
Ezt szeretném felváltani szintenként egy hőfokmérővel.
Most egy málnapc gyűjt adatokat, de arra nem mernék ilyen feladatot bízni, egy év alatt túl sok volt a lefagyás.
Ennyi.
Kéne csináljak egy vázlatot, abból jobban át lehetne látni.
Én szeretek rendszerben gondolkodni, és előfordul, hogy minimális többlettel (pénzben) már van bevizsgált, kereskedelmi megoldás. És visszatérnék ismét a 0. feladványhoz: írjuk le pontosan, hogy mit szeretnénk. A „belenyúlnék valahogy a fűtésvezérlésbe” azért marhára nem elég.
Esetleg teljesítmény szabályozást ? (Bocs, hogy belekotty ...) Egyébként meg, ha a közvetlen vezérlésű relétől tart az illető, semmi akadálya, hogy az eddig használt Arduino relay board-on keresztül küldje az új relének a vezérlést :)
Ez egy jó téma: Ugye most én is arduval kapcsolgatok 220-at. Sima kínai relé. Mivel csak pár hét, viszonylag izolált nem izgulok.
De jön egy másik téma: fűtésvezérlésbe is be kéne avatkoznom, de ott már ezzel 220-at nem kapcsolgatnék, max egy vezérlő 12V-ot, amivel már mondjuk Finder relét lehet kapcsolgatni.
Ha lenne ebből a témából is egy (pár) 5perces ....
Sajnos a hosszú távú mérés már nem lehetséges lévén ez a hőntartás mindössze egy hetes ciklus, ami maholnap lejár.
Jön egy kevésbé érzékeny 23-25 fokos időszak, ahol alig kell majd fűteni.
Ha jövőre újra összerakom, akkor viszont logolni fogom. Ez az idei mindenképp kísérleti év, magát az oltást is most csinálom először.
Azt már látom, hogy a vízben kb 2 fok difi van alul-felül, hiába van az edény alján a cekász. Azaz keverő kell, különben rétegződik. Erre nincs programozható megoldás.
