Az eddigi fűtési és mérési tapasztalatok alapján kezd fogalmazódni a követelményrendszer, ami a gazdaságosan megvalósítható komfortos fűtéshez vezethet.
Vegyestüzelés és radiátoros fűtés esetén nem beszélhetünk kiegyensúlyozott hőáramokról, meglehetősen változóak a körülmények.
Ezért fontos a viszonylag kevésszámú beavatkozási elem kezelése.
A szabályzó elektronika ne legyen nagyon bonyolult, masszív legyen, megbízható, az összes bekerülési költség arányos részét képviselje.
Az is látszik a mérések alapján, a puffer lesz az a beiktatott gépészeti elem a rendszerben, ami a legkönnyebben összekapcsolja a két eltérő működésű egységét.
Vagyis kell egy időjáráskövető szabályozás egy vegyestüzelésű-puffer-radiátor elemekből álló fűtéshez. Esetemben.
A kazán-puffer viszonylatában a maximális kazánhatásfok, maximális pufferhőfok, a puffer-radiátor oldalon a maximális hőkomfort, az időjáráskövető egyenletes, a helyiséghasználatot követő hőleadás a cél.
"ahol én a klasszikus értelemben vett pid szabályozásnak nem sok értelmét látom, mert ahogy te is írtad, annyi külső változó van, hogy annak komplexitása"
Ez így nem igaz. persze el lehet menni a végtelenbe bonyolultságot és algoritmust tekintve, de van egy egészséges határ, amit betartva igenis hasznos és jól alkalmazható dolog. Ez kb az a kategória, hogy méred a külső, belső hőmérsékletet, és a keverőszelepen tudsz változtatni az előremenőn. Ez három mérési pont, nem több, és elég tud lenni.- Gyárilag is hasonlóak a szabályzók, van amelyik még az előremenőt sem méri, vagy magával a kazánnal kommunikálva intézi ezt el. és mérhető adott esetben az energiatakarékosság is, a kevesebb energiafelhasználás.
Ipari szintű méretekben is hasonló az elv, csak ott PLC-ket használnak a vezérlés megvalósítására, és sokzónás rendszer van, több mindent mérnek. Illetve ebből kifolyólag sokkal komplexebb.
"de adott esetben egy több magos nagy processzor számítási kapacitását is erősen feszegetné."
Ez nagyon nagy baj lenen ha így lenne. Egy pár Mhz-en ketyegő mikrokontrollerrel ez simán úgy megvalósítható, hogy az idő 99%-ban pihen a kontroller :-). Nem igényel ez komoly erőforrást, csak jól megkonstruált matematikai alapokat amik komoly elméleti háttérrel rendelkeznek. 20-30 ezer ft környékén már lehet kapni az egyszerűbb verziókat készen, abban sem P4 procik vannak - már csak a telepes alacsony energiafelhasználású táplálás miatt se. És PID alapúak. Az egyik ok amiért nem kell nagy erőforrás a sebesség igénye. NAgy időállandók vannak, bőven van idő mindenre. Pl egy motorvezérlésnél, ahol usec idők alatt kell beavatkozni és reagálni, ott már más a helyzet, az keményebb dió.
Köszi, nagyon jó összefoglaló. Java itt megvan/volt teljesen. :-)
Alapvetően rendkívül egyszerű rendszer építése a cél később, 1 bites kimenettel és kvázi-analóg, viszonylag szűk tartományú, de annál nagyobb felbontású bemenettel. Később jön majd kifelé analóg rendszer is, aminek a bemenete már nem egy, hanem várhatóan több paramétert fog elemezni (szintén analógot, csak más jellegűt).
Egyébként pont a ház fűtésvezérlés az, ahol én a klasszikus értelemben vett pid szabályozásnak nem sok értelmét látom, mert ahogy te is írtad, annyi külső változó van, hogy annak komplexitása nem hogy egy Arduino, de adott esetben egy több magos nagy processzor számítási kapacitását is erősen feszegetné. (Megjegyzem, az egyik barátom korábbi házában a fűtésszabályozás konkrétan a külső hőmérséklettől függött, vagyis akkor fűtött, amikor kint hideg volt, nem akkor, amikor bent, volt is gázszámla vastagon.)
Egy egyszerű rendszerben (egy bit ki, analóg be) egy Mega szintű 16 MHz-es mikrokontroller bőségesen elég a cél megvalósításához, ipari berendezésekben (konkrétan kávégépekben) is hasonló bonyolultságú eszközök dolgoznak teljesen megbízhatóan, paraméterezhetően (P, I, D paraméter). Ezt a szintet valamelyik O'Reilly-könyvben elég felszínesen ugyan, de funkcionálisan megfelelően kivesézik, annyira legalábbis, hogy egy működő egyszerű rendszer összeállítható legyen. Majd megkeresem, illetve majd ha odaérek, mutatom a projektet is.
Én igazából kérdeztem, hogy mennyi az alapsebessége, nem tudom, hogy Arduino keretrendszerből hogy kell vagy lehet konfigurálni, állítani (AVR Studio-ból igen). Nem gyorsítani akartam csak kíváncsiskodtam:-).
Igazából azért kérdeztem, mert az I2C maximális sebességének (egyik) korlátja a busz(vezeték) kapacitása. Ugyanis ahogy nő a freki a busz(vezeték) kapacitása egyre inkább bekavar. Hirtelen nem tudom, de le van írva a szabványban mennyi lehet a may, ha jól rémlék nx10pF. Ahogy nő a kapacítás, úgy a felfutó élek (mondhatjuk Slow Rate-nak is) egyre laposabbak, elnyújtottabbak lesznek, ezért határozatlanabbá válik a jelforma, és nagyobb frekin nem lehet jól feldolgozni, oda a minél rövidebb fel és lefutás kívánatos.
Tehát minél távolabbra akarod vinni a buszt, annál inkább lejjebb kell menni a frekivel. Ezért lett volna érdekes dolog, hogy milyen frekin megy ami ezt a távolságot még elviseli (még akár sodrott érpárral is, ami ugyebár kompenzálja a problémát valamilyen mértékben). én 2-3 méternél távolabbra még sose vittem I2C, de jellemzőn általában csak centiket, nagyobb távolságokat mással oldottam meg.
De jó tudni hogy esetlegesen ez is alkalmazható lehet - persze alacsonyabb frekivel.
Azért nehéz megcsinálni egy jó PID szabályzást mert komoly elméleti háttér kell hozzá hogy az valóban JÓ Pid szabályzás legyen, ne csak valami ami olyasmi mint a PID.
Lehet nagyon rosszul gondolom, amit most a PID-ről írni fogok Arduino kapcsán, max majd megköveztek. :-)
A PID nagyon sok területen elterjedt a szabályzástechnika világában, a hőmérséklet szabályzón át a motorvezérlésekig., mindenhol alkalmazzák. Ez tulajdonképpen egy algoritmus, ami három fő elemből épül fel. A P mint arányos tag, az I mint Integráló Tag, és D mind deriváló, differenciáló tag. És ehhez jönnek a visszacsatolásban használt és alkalmazott tagok, melyek szintén a fenti elemek bármelyike vagy azok kombinációja lehet.
A matematikai és automatikai háttere nem egy egyszerű dolog, ahhoz, hogy valaki jó PID szabályzót tudjon készíteni, ahhoz az elméleti hátteret ismerni kell (szabályzási körök, azok modellezése, matematikai leírások, stb). Ha valaki enélkül csinál egy PID szabályzást, abból nagyon nagy katyvasz tud lenni, és nem fogja érteni miért úgy és akként működik a szerkezet, ahogy. Egyetemen is komoly matematikai alapokra építve minimum fél éves tantárgy a PID szabályzás működése, algoritmusának megértése és megtanulása.
Szóval röviden és tömören: nem olyan egyszerű feladat mint látszik elsőre. A gyári PID szabályzókba az algoritmusokat rendszerint magas szintű mérnökök esetenként matematikusok írják.
A meglátásom elsőre: az Arduino keretrendszer kevés ahhoz, hogy ilyet megcsináljanak benne. Vagy csak utánzata lesz, és valami pid-szerűség jön ki belőle. Ahhoz mélyebb (matematikai és számítási) műveletekre van szükség, mint amit Az Arduino keretrendszere meg tud valósítani, mindehez egy regiszterszintű programkezelés is párosul(hat). Vagy esetleg még azt tudom elképzelni, hogy megcsinálják mélyebb szinten, és valahogy "átkonvertálják" Arduino rendszerbe. Bár ennek meg az értelme kérdéses.
Fontos része egy jó PID szabályzó megvalósításához a szimulátor rész, mert így virtuálisan állítva a paramétereken, bemeneteken lehet látni a reakcióját az adott eszköznek, programnak, hogy úgy és akként reagál mint ahogy elterveztük szeretnék. Ilyen lehetőséget az Arduino keretrendszer nem tartalmaz.
Ha pl egy lakásfűtést szeretnénk PID jellegű szabályzással megoldani, ott ráadásul az un. időállandók is nagyon nagyok (pl hőmérséklet-változás percek aakár órák alatt jön létre). Ezért a valóságban viszonylagosan nehéz és időigényes mérni/szimulálni őket. Viszont ha nem optimalizálunk egy PID szabályzásnál akár több kárt okozhatunk, mint amennyi hasznot hoz. Mit értek ezalatt a gyakorlatban?
Pl. PID hőmérséklet szabályzóval akarjuk elérni, hogy 20 C legyen egy lakásban. A cél mondjuk az energiatakarékosság, minél kevesebb energiát használjunk el, hogy ez létrejöjjön. Ehhez mondjuk mérjük a szoba hőmérsékletét, és próbáljuk kapcsolgatni a kazánt, puffert akármit a lehető legkevesebb és legideálisabb módon a legkisebb energiafelhasználás érdekében.
Mi van akkor, ha nem jól lövünk be egy PID-es rendszert, vagy egyszerűen csak rossz az algoritmus? Pár eset: túllengések (túlfűtés), belengések (túl fűtés, majd alacsony hőmérséklet, visszafűtés magasra, stb valamilyen lecsengéssel), legrosszabb esetben gerjedés is könnyen lehet belőle. Azaz gyakorlatilag akár jóval nagyobb energiafelhasználás is lehetséges, mint egy sima tekerős termosztáttal.
Kicsit még továbbmegyek: a jó PID szabályzó ráadásul öntanuló is!Hogy működik ez?
Mondjuk bekapcsol, és az időállandókat elkezdi figyelni, mérni. A bekapcsolás után nézi mennyi idő alatt mekkora hőmérséklet emelkedés történik mindez milyen meredekséggel, és figyeli mellett mondjuk a külső hőmérsékletet is, mert nem mindegy hogy kint +5 fok van, vagy -10. Más lesz ez az idő.
Ezeket az értékek különféle esetekben és esetekhez mind mind eltárolja (táblázatos formában beírja az értékeket), és behelyezi egy képletrendszerbe (az aktuális külső állapotnak megfelelő értékeket), amit a PID szabályzás modellje alapján készítenek modell és programszinten.
És akkor pl lehet megspékelni ezt egy olyan variánssal, hogy az előremenő keverőszelepet is tekergeti a paramétereknek megfelelően, és ezzel állítva az adott körülmények között i leginkább legideálisabb előremenő vízhőfokot.
Azaz van egy táblázatunk, amiben szerepelnek az alábbi adatok a fenti példa esetben: belső hőmérséklet, külső hőmérséklet, előremenő hőmérséklet Emellé még számos dolgot be lehet rakni, különféle időállandókat, stb
És van egy komoly egyenletünk, amit meg kell alkotni PID elven, amibe ezeket az értékeket írjuk be, mindig az adott megfelelő körülményeknek megfelelően. Azaz mindig az adott állapotban csinálunk egy legideálisabb munkapontot (adott paraméterek) a munkaponti görbén (egyenlet).
Ráadásul öntanuló verzióban ezen elemek a táblázatban mindig változnak, ezért öntanuló, mindig újra méri is felülírja őket saját maga. Valamilyen alapértékről elindulunk amikor berakják egy adott házba (alapbeállítások), majd pl pár hét alatt feltöltődik a táblázat valós értékekkel. Sőt ezt a szabályzó élete végéig folyamatosan műveli, mindig közelítve és közelítve a legideálisabb értékekhez.
A PID-es lakás fűtésszabályzók nagyon leegyszerűsítve a fenti elvek mentén dolgoznak, vagy azokat használják. ÉSsfeltétlen fontos az öntanulóág (gyakorlatilag saját magát felparaméterezi idővel), hiszen nincs két egyforma energetikai szempontból megegyező ház, mindig az adott ház hőtechnikai paraméteréhez kell igazodnia a szabályzónak. Jó PID szabályzással pl megoldható, hogy nem akkor kapcsol be egy termosztát, amikor már kihűlt a lakás mondjuk fél fokot, hanem előre tudja mikor fog kihűlni az adott körülmények között, és nem vissza fűti az elveszett energiát, hanem tartja mindig azon a szinten, ahogy kell. és ez igen komoly energiamegtakarításhoz tud vezetni.
Bocsánat ha nagyon hosszú voltam, de nem tudom mennyire ismered a PID szabályzás alapjait. lehet felesleges volt elírnom az egészet, és elnézést érte.
Egy nagyon leegyszerűsített és összefoglalt téma PID téren:
Az atmel procik (1260, 2560, azaz a nagyobb családé) hardweres I2C buszsebessége az adatlapok szerint max 400kHz/400kbit/sec. Más típusnál ez van hogy kevesebb, 100kHz környéke. Egész pontosan függ a megtáplált órajeltől, hiszen azt osztja le. Az órajel frekijét beállítani mélyebb, regiszterszintű műveletekkel lehet, több értékre is akár, ugyanolyan jelleggel mint mondjuk a PWM frekijét.
Lehet ez a keretrendszer ezt nem tudja (én AVR Studio-t használok ismerkedési céllal)
Arduino keretrendszerben az I2C busz sebességét nem kell konfigurálni programból mint mondjuk egy soros port megnyításnál? Ott ugye meg kell ezt adni, I2C-nél nem?
De persze biztos van egy alapfreki is amin alapból használja, de nem tudom melyiket veszi alapbeállításnak, 10-20 kHz környékére tippelnék hirtelen.
A gyorsaság mit jelent? Nagyon sűrű méréseket, nagyon rövid reakcióidőt, nagyon gyors feldolgozást?
Hardver részre itt utóbb kitértek, ezt megnézem én is, mert elég speciális feladat megoldására nekem is kell majd valami ötlet.
Szoftveres és logolás oldalon a fő kérdés az, hogy megy-e folyamatosan a PC. Ha megy, akkor soros kiolvasás és egy Processing alkalmazás, vagy bármi, ami a soros küldést USB-n tudja fogadni (millió ilyen van). Ha a gép nem megy folyamatosan, akkor egy i2c EEPROM-ba logolni időbélyeggel, aztán ezt alkalmasint szintén soros módon kiolvasni. Kérdés továbbá, hogy a kiolvasás alatt kell-e menjen a mérés és a logolás vagy sem. Ha mennie kell, akkor ésszel kell küldeni és fogadni. Plusz ugye visszaigazolás, törlés, overflow-kezelés és társai, tehát eléggé el lehet szaladni.
Az alapot (i2c EEPROM, RTC, hőelem) szerintem egy könnyedebb hétvégén össze lehet hozni működőképesre, a kiolvasást meg egy másikon.
Egyébként nagyjából ugyanezt én április magasságában tervezem megcsinálni csak teljesen más pereméterekkel.
Az 1. ponttal nagy vonalakban egyetértek. Ezért is tértem át a Notepad++-ra.
2. pont dettó, azt leszámítva, hogy nekem eddig sehol sem tűnt fel, hogy az 'INPUT' + pull-up kombó (digitalWrite(..., HIGH);) bármiféle változtatáson esett volna át, legalábbis a most aktuális IDE viszonylatában. Ezen belül a 3. pont nem igazi gondot ír le, mert használhatók a változódeklarációk a klasszikus C++ formula szerint is. A 4. és 5. pont kiegészítve azzal, hogy egyébként gyalázatos a memóriakezelés.
3. pont. Ezzel sajnos nagyon egyet kell értsek. Az arduino.cc sok leírása idejemúlt, fals információt tartalmaz (hogy mást ne mondjak, közel 1,5 év volt, mire a Micro-ra jellemző lábkiosztás változást -- i2c soros port -- hivatalosan is közzétették. Ami nekem különösen fáj, mert szerintem jogosan érzem magam rondán átb'szva, az az ABC The Book (Arduino Basic Connections -- The Book), ami start-up-ként indult, és az elért elég jelentős siker ellenére az is maradt. Frankó a könyv meg minden, de percek kérdése kinőni és sok esetben alapvetően haszontalan a szükséges kódrészletek teljes hiánya vagy a speciálisabb alkatrészek hozzáférhetetlensége miatt. Ja, és hiba is van benne, nem is kicsi. A továbblépésről sincs sok szó, bár elég jó könyvek születtek a témában.
Az 5. ponttal már nem értek egyet maradéktalanul. Az átlag Arduino felhasználó soha nem fog ilyen mélységben hibakeresni, mert jó eséllyel nem fog olyan bonyolultságú, összetettségű kódot ÉS hardvert produkálni, ami ezt szükségessé tenné, de még ha... akkor is ott a kvázi debug-megoldásként funkcionáló Serial.print, ami a jól ismert "tray-and-error" megoldással vagy bejön vagy nem jön be.
Az alternatívákról nem tudok mit mondani. A konklúzió meg... Bizonyára van benne igazság, ugyanakkor nem szabad figyelmen kívül hagyni azt, hogy egyelőre minden hátránya és következetlensége ellenére az Arduinónak van a legnagyobb hátszele.
Ami a párbeszédet illeti. Rettentő időt töltöttem azzal, hogy olyan leírásokat olvasgassak, hogy egy kezdő számára melyik a legjobb, valamit is érő programozási nyelv. A magától értetődő web-alapú rendszerek nyelveit kizárva (html, css, xhtml, xml, java, flash meg még a jó ég tudja mi), többé-kevésbé egyöntetű volt a vélemény, hogy "verything but c/c++". És ahogy kivettem, jó okuk van erre, mivel a C++ pont az a nyelv, ami -- lopott példával élve -- a kulináriának a sushi, vagyis abszolút magasiskola. Mert egy C++ kódot össze lehet hozni pár hónap ügyeskedéssel, de jó, pláne kereskedelmi minőségű anyagot összerakni már nem csak a programozási nyelv tiszta ismeretéről szól, hanem annál sokkal, de sokkal többről. És ha már tanulásról van szó, a tanítási oldal sem mindegy. És az Arduino is tud érdekességekkel szolgálni, és bár itt is próbálok segíteni, több más fórumon egészen elképesztő nagy tévutakba futok bele havi-kéthavi rendszerességgel (kódok szintjén és hardver szintjén is). Az Arduino környezettel ezen viszonylag egyszerű áttolni a kezdőket, egy komplexebb rendszerrel (ahogy a szerző is írja) ez már ne nélkülözheti az alapelvek, összefüggések, alapszabályok ismeretét sem, ez pedig egy fórumozásnál vagy sima közösségi együttműködésnél sokkal összetettebb kérdés.
Ezért is írtam korábban, hogy a „melyik kártya jó” kérdéskör nagyjából egy viszontkérdéssel kezdődik: „mi célra?”
Lektorált tananyag, ami a BKF Digitális és Kollaboratív Művészet (DIKOM) pályázatnak keretén belül valósult meg.
Szerző: Harsányi Réka, Társszerző: Juhász Márton András, Lektor: Fernezelyi Márton
Az I2C, vagy más néven TWI (Two Wire Interface) egy soros[...] Bővebben!Tovább »
Kutakodtam itt néhány viszonylatban az mbed háza táján. Kicsit profibbnak tűnik a háttér, mint ami az Arduinot jellemzi. Massimot szeretem, de alapvetően sok szempontból káosz, ami az arduino.cc-n folyik, a kiegészítő dolgokról nem is beszélve.
Noszóval, ami eddig pozitív: sok platform van, az adott célra megfelelő fejlesztőeszközöket viszonylag egyszerűen meg lehet találni és ki lehet választani. Ezek jóval keményebb hardverek, mint bármelyik Arduino (a Tre és az új Intel kivételével), ennek minden előnyével és hátrányával egyetemben.
Ami eddig kevésbé tetszik -- úgy, hogy alapvetően nem nagyon mélyedtem bele --, hogy nincs off-line rendszer, csak online (vagy valamit kegyetlenül elnéztem). Az Arduino IDE-hez hasonló felület nincs off-line, márpedig előfordul, hogy internettől távol gondolok kódolni (vagy adott esetben teljesen elmegy a net, erre is volt példa).
A kártyákat végignézve van pár igen rokonszenves, de ezek kevés kivételtől eltekintve árban azért számottevően vastagabbak, mint azok az arduinok, amiket néztem. Az is igaz ugyan, hogy a Yún-hoz képest (ami ugye uszkve 22 ezer forint) az mbed LPC1768 számottevően jobb összehasonlításban teljesítményét tekintve, kivéve a wifit. Így a 16-17 ezer forint áfa és szállítás nélkül kb. ugyanaz, mint a Yúné.
Az RS 2000 forintos szállítási díja meg szűken megduplázza az árat... Csoportos rendelésnek lenne értelme, mert hogy én egy darabért nem fogok kifizetni ennyit, az elég valószerű.
