jaja, ez mindig az utolsó 5 mérésből veszi a érték szerint középső hármat, és azok átlagát adja.
ha pl 1 másodpercenként mérsz, akkor ez minden mérés után ad egy értéket, de az függ az előzőektől is. kicsit le van simítva, meg kicsit késik. cserébe nem szőrös meg tüskés.
Így már jobb :-) Pl.: egy hibás mérés 5 eleme így néz ki: 75,25 ; 75,50; 32,50; 75,50; 75,75; ezekből ki kellene venni a 32,50-es és a 75,75-ös mérést. Vagy valahogy a tőle legtávolabb eső elemet fogja kicserélni?
%5 azt jelenti hogy az 5tel osztás maradéka. így ha a p eléri az 5öt, újra nulla lesz.
na megtaláltad az első bugot.
a maxx-ot kell mínuszra inicializálni, a minn-t pluszra. így az ifek szépen lecserélik az aktuálisra, ha az még nagyobb vagy kisebb, kigyűjti a legnagyobbat/legkisebbet.
Tetszik a dolog, de nem nagyon értem :-) durván 20 perce nézem a programot, de nem jövök rá :D
int p=0;
double buffer[5]; // gondolom ez csak egy sima 5 elemű tömb
mérsz egyet, és beteszed a pufferbe következőnek:
buffer[p]=mért adat;
p=(p+1)%5; // a p-t emeljük egyesével 5-ig? ( a %5-öt nem tudom mit jelent )
így a tömbben az utolső 5 mérés eredménye van mindig. végigmész, és a középső három átlagát veszed:
double szum=0; // szum-ot nullázzuk
double maxx=1E10; // maxx értke 10Milliárd
double minn=-1E10; // minn értéke -10Milliárd
for (i=0;i<5;i++) { // for ciklus. tiszta sor...
szum+=buffer[i]; // buffer 5 értékét összeadom
if (buffer[i]>maxx) maxx=buffer[i]; // ha valamelyik elem nagyobb mint 10Milliárd akkor az legyen maxx de ez soha nem lesz igaz, csak 20-30C félremérésem van
if (buffer[i]<minn) minn=buffer[i]; // ha valamelyik elem kissebb mint -10Milliárd akkor az legyen minn de ez soha nem lesz igaz, csak 20-30C félremérésem van
}
eredmeny=(szum-minn-maxx)/3; // összegből kivonom minn-t (-10Milliárd) és maxx-t (10 Milliárd) ha az if nem lett igaz.
Javítsatok ki ha tévedek, lehet estére gondolom rosszul :-)
Köszi!!
Bocsi, most nem tudtam kipróbálni, hogy félrebeszélek-e nincs nálam board :D
nem nagyon vagyok tisztában hogy milyen cpu van a projektben :(
ha másodpercenként 5 mérés van, akor csak belefér egy ilyen. lehet szórakozni hogy ne double legyen, hanem valami fixpontos intekkel lehessen számolni, 6 elemű a buffer, mert akkor néggyel kell osztani, stb.
U.i.: egyszer ennél egy kicsit egyszerűbb megoldással összevetettem egy Leonardot egy Nucleo 401-gyel. A pontos számra nem emlékszem, de nagyjából két nagységrenddel volt gyorsabb az utóbbi (azonos számítási ciklusidőhöz hány szám átlaga kell, és amíg a Leonardon ez olyan 10 volt, a Nucleon 400).
Köszönöm, jegyzeteltem, :-) ki fogom próbálni a javaslatokat, a távolság ebben az esetben akadály, mivel a "prototípus" üzemel a főzdében, ami a lakhelyemtől kicsit messzebb van, és a munkám miatt csak talán hétvége fele fogok tudni eljutni mókolgatni.
Köszi, ez nekem is eszembe jutott, de pontosabban ezt hogyan tudnám kivitelezni programnyelven? Hogyan magyarázom meg neki, hogy x%-al tér el? Gondolom egy egyszerű if-el vizsgálnám a feltételt. Ez megoldhatná a "lassú" méréseket is mivel nem kellene tömbösítenem.
Van sugárzó hő a környéken, de be van dobozolva, és ventilátor hűti az egész dobozt.
De csak, hogy okosodjak, milyen hibát okozhat az, ha közel azonos a mért és a referencia hőmérséklet? Gondolom, tartós félremérést okoz, lineárisan.
a tüske szerű hibákat kiküszöbölheted ha minden mérési eredményt eldobsz ami az előzőtől több mint x%al eltér. ha tudsz monduk 5 mérést tárolni folyamatosan (egyet eldob, egyet mér), akkor azt is átlagolhatod úgy, hogy a két szélsőt kihagyod az átlagból, csak a másik hármat átlagolod.
nem tüske jellegű hibát okoz, ha a max és a panelen a kötés nincs azonos hőmérsékleten. ha van sugárzó hő a környéken, ez is okozhat hibát.
- ha esetleg árrnyékolt vezetékes K szenzort használsz, akkor próbáld ki úgy is, hogy az árnyékolást bekötöd a testre. Vagy a kritikus szenzorokat cseréld le gyárilag árnyékolt megoldásura, 400 ft köröl van darabja az ebayen
- végszükség esetén elgondolkodnék más thermo elem használatán, pld ntc PT100, vagy egyéb ellenállás hőmérőn, mert ott a zavar jóval nehezebben tud megjelenni. Általában sajnos ezek alacsonyabb hőfoktartománnyal bírnak.
A háromvezetékes (négyvezetékes is van) dolognak a neten nézz utána, beütőd a keresőbe, és rengeteg találatod lesz, csak ugyanazt tudnám leírni. Nem ismerem annyira ezt az IC-t, hogy tudjam, hogy ennél megvalósítható-e (meg kéne néznem az adatlapot). Ez egy (mérési) elv pont zavarvédelem és mérési hiba kiküszöbölésére. Most hirtelen abban biztos nem vagyok biztos, hogy K hőelemnél is jó, eddig csak ellenállás jellegű hőmérőknél használtam - lehet a K-nál nem is lehet.
Az árnyékolást elsősorban a K hőelem vezetékénél kezdeném =(zenzor-Max között) Azaz a gyári vezeték helyett két ér plusz árnyékolás bekötve. Ugyanis egy K hőelemnek a kimenete igen kicsinyke ebben a mérési tartományban (ráadásul a bemeneti fokozat is nagyimpedanciás bemenet), néhány mV. erre bármilyen RF zavar egy ekkora vezetékre már simán rá tud ülni. Ilyen pl a világítás zavara (fénycső akár elektronikus előtéttel is), de tedd mellé a mobiltelefonodat amikor tárcsázol valakit, és érdekes dologban lesz részed. Ráadásul teljesen véletlenszerűen fog megjelenni - pont ebben különböznek ezek az occo cuccok az ipari robusztus dolgoktól, amik minden körülmény között atombiztosak.
Régen sokat szívtam ilyenekkel, ma már alapból csak árnyékolt vezetékkel kötök be ilyeneket, vagy olyan védőcsőbe teszem a kábelét ami árnyékolt (és eb is van kötve). Más hőérzékelőknél - pl PT 100 - annyira ez nem tud megjelenni, mert nem jellemző hogy teljesítmény is létrejöjjön az indukált feszből, de K hőelemnél gyakori.
Egy két egyszerűbb próbát még megtehetnél egy komolyabb átkábelezés előtt:
- a termoelem bemenet T- pontját kösd össze direktbe a DC táp földjével. Azért tud javítani a dolgon, mert innentől ez a láb nem "lebeg", és ha indukálódik valami rajta, akkor ezt rövidre is zárja valamennyire, zavarvédettebb lesz. Ha nem jön be, akkor egy 10-100 ohm körüli ellenállással tedd ezt ugyanígy meg. nem tudom a panelodon össze van-e kötve
- az IC táp lábaihoz tegyél be valami szúrést, mondjuk 100nF nagyságrendben és minél közelebb a lábakhoz! Már ha nincs a panelon.
Leírom az egészet: a hőmérési pont az elektronikától maga a K hőelem vezeték hossza határozza meg 6db-ból 3 5m-es K elem, 3 pedig 3m hosszú. Ezeket így vettem, nincsenek toldva, sorkapcsozva, stb... Ezek külön-külön mindegyike egy-egy MAX6675-ös chipet tartalmazó modulba futnak bele, ilyen:
Tápjuk az ATX táp 3,3V-os kimenete, 3-5,5Vig mennek datasheet alapján, elméletileg megfelelőek. Ezen a feszültségszinten semmi más nincs. Élesztésnél, nem volt semmilyen megzuhanás, semmi áramfelvétel változás bármelyik fogyasztó terhelésére. Ha megnézed a feltöltött doksit, a hibák nem is vágnak egy időbe a motor mozgásával sem, pedig ez is az ATX 12V-járól jár.
A kommunikációs vonalak, SCK,CS,SO sima 20cm-es tüskés "arduinos" vezetékkel vannak bekötve, a MEGA digitális portjaira.
Mit értesz pontosan a háromvezetékesen?
Árnyékolás erre a 20cm-es szakaszra? Értem én, de gondolhatod hogy néz ki az arduino mikor a digitális portoknál 18db vezetés sorba be van dugva :D és ez csak a hőmérő.
Nem tudom mekkora távolság van hőelemek és az elektronika / arduino között. Elgondolkodnék a háromvezetékes mérésen, ami rengeteg hibát megold. A neten sok infót találsz róla.
Illetve nem tudom árnyékolt kábeleket használsz-e, ha nem itt az alkalom :-).
A kiolvasásokat pont a hibák miatt 10xeztem meg, mivel 10 mintában ha van egy rossz mérés, átlagban nem fogja elvinni annyira.A hibák számát redukálta, mivel korábban több félremérés volt, de nem szűnt meg teljesen.
Nem szeretnék nyákot maratni, és építeni, rendeltem az általad linkelt csatolóból, várom a postásbácsit. :-)
Tudom, ki kell próbálni, de akkor véleményed szerint ez a probléma?
Sziasztok, egy kis segítséget szeretnék kérni. Előzőekben már beszámoltam a projektem részleteiről, a tegnapi főzést változóit végig loggoltam, és excelbe tettem. A diagrammokon látszik, hogy tüskékként félremérés történik a hőelemeken, ami bosszantó ami a vezérlést illeti. (hőmérséklet értékre kapcsol lámpákat, forgat léptetőmotort a program) A hibák, ha a hiszterézis értéken túl vannak, akkor indokolatlanul fel-le kapcsol, hibázik...
Ahogy már korábban írtam K-hőelemeket használok, amik optocsatolóval nincsenek leválasztva, de hőálló szigeteléssel le vannak szigetelve a mérőfejek, így nincsenek közös potenciálon (elméletileg). Mindennek a tápját egy ATX tápegység adja, melyen a feszültségszintekre el vannak osztva a terhelések. Nem veszem észre, hogy esetleges terhelés okozná a gondot. Mi okozhatja ezeket a "tüskéket" ?
A mérések átlagolva vannak 10-elemes tömbből.
Új hiba: mióta a tömbös átlagolások bent vannak, a program (számomra) indokolatlanul lassult, egy ciklus ~ 3 sec. 13:23 kor a PID könyvtár kiesett a számolásból... A számolt érték átment NAN adatra, melyet nem tudott reagálni a motor. Resettel megjavult. Ezt korábban nem csinálta egy műszakon keresztül sem.
(röviden a menetéről: használok egy libary-t ami a bemeneti érték és a cél érték eltéréséből egy kimeneti jelet generál, mint beavatkozó jel 0-90 ig a táblázatban ez az OUTPUT érték). Fizikai megvalósításban egy fatüzelésű üstnél mérem a kimenő füstgáz hőmérsékletét, a bemeneti oldalon egy 160-as PVCcsőbe építettem egy pillangószelepet, amit egy léptetőmotor állít be az OUTPUT értékére. A programban megadom a kívánt füstgázhőmérsékletet, és a mért értéknek megfelelően eldönti hogy emelni kell-e hozzá, vagy csökkenteni, ha a mért alacsonyabb mint a cél, akkor nyit a huzaton, ha magasabb, zár rajta. 0-értéknél teljesen lezár ( levegőt elzárom tőle) 90-nél teljesen nyitva van, húz.
Lehet köze a tömbösítésnek a hibához?
Hogy oldhatnám meg, hogy ilyen hibánál, észrevétlenül újrainduljon?
Én még ezzel nem találkoztam, de ha jól tudom változókat a "sima" változatban is el tudsz tárolni, és kiküldeni az arduino felé. Az editorban van lehetőség, hogy egyedi változót küldj az arduinonak. A gomb tulajdonságai alatt megadhatod, hogy mi történjen ha megnyomod, vagy elengeded. Itt vannak az írható parancsok : https://www.itead.cc/wiki/Nextion_Instruction_Set
Ez ha jól látom az Enhanced verziójú kijelzőkkel működik együtt, a két típus között a különbség a ki bemenetek lehetősége, és eepromban van, illetve más a ram és flash méret.
Ezzel esetleg játszottál? Mert így elsőre azt gondolom, hogy bizonyos változókat itt a kijelzőben is tudsz definiálni, és az eepromban tárolni, a nyomógombok hatására ezeket tudod esetleg változtatni, vagy legalábbis ehhez is hozzárendelheted. Mert ahol van eeprom csak ott van GPIO portod. De lehet rossz a következtetésem.
Na de van rá mód, hogy ezen változásokat funkciókat a rá kötött eszköznek - pl ebben az esetben az Arduinonak - átadd valahogyan?
