Én a legutóbb egy Piergiacomi tre-03-nb típusú csipőfogót vettem, de nyílatkozni nem tudok róla többezer lábbal kapcsolatban mert nem számolom :-), nincs annyira napi szinten használva sok lábra.. Egyelőre teszi a dolgát, és a br 2000 ft alatti árat megéri. A TR25 állítólag valamivel jobb.
De fogalmam sincs hogy nagyipari használatnál mennyire válik be, főleg mert olasz termék..... Ha valaki ügyes talán egyszeri élezést is meg lehet próbálni, de nem tudom van-e az élén valami felületi edzés keményítés, akármi.
Igen, egy eszközt, amivel nyákforrasztás után számtalan (illetve számos, de bőven több, mint ezer) alkatrészlábat levághatok. És nem negyvenezer és nem vajból van. :-D Utóbbi van, fáj a kezem tőle.
Most pár hete csak read-only vagyok, de visszaolvasok mindent, a nekem küldött (hasznos) válaszokat is, amiket köszönök!
Kérdésem: ha nem olcsó, vajszerű kínai vackot, de nem is 40000 forintos Erem (/Weller) igáslovat akarok, hanem a kettő között valamit, akkor mit (és hol) tudtok ajánlani?
Most alkatrészláb vágáshoz kellene kicsi, de nagyon strapabíró fejű darab (1N4007 diódákhoz is, ami ugye 0,6 mm-es láb).
A korábban már beüzemelt Mega2560 R3 ATMEGA16U2 + SainSmart TFT LCD Adjustable Shield +
3.2” TFT LCD with SD and Touch for Arduino Mega
Után megérkezett a Due + CTE TFT/SD shield for arduino DUE + 3.2” TFT LCD with SD and Touch for Arduino hármas.
Az utóbbi összeállítást egyelőre nem sikerült munkára bírni.
A Megahoz képest változtattam:
To use with UTFT library:
1.uncomment "#define CTE_DUE_SHIELD 1" in the HW_ARM_defines.h in the hardwarearm folder of the UTFT library
2.Change the pinout to : UTFT myGLCD(ITDB32S,25,26,27,28);
Using the Touch function:
Remember to change the touch initialization to the following if it does not work. The TP DataIN is routed to pin 32 of arduino DUE instead of 4. (Because pin4 of arduino is a hardware SPI CS pin, which is reserved for SPI device)
URTouch myTouch( 6, 5, 32, 3, 2);
Shipping default jumper configuration:
The TFT/SD Shield for arduino DUE is shipped with the following jumper config, if you use TFT modules in our store, you do not need to reconfig the jumpers.
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ő.
