Van egy olyan is hogy Nyák Iroda Bt. Ők nem gyártanak hanem gyártatnak. Azt nem tudom jelenleg kivel, régen magyar gyártókkal csináltatták, lehet ez változott. Mert megnézve az árait, olcsóbbak mint akikkel régebben gyártattak. Aztán fene tudja.
De csak félig igaz, mert széria függő. Van hazánkban is üzeme, de a nagy szériákat meg kint gyártják. Legalábbis ha jól rémlik. Régebben utánamentem de már nem emléxem......
valaki mesélt nekem valami magyar cégről, aki feléd teljesen nyákgyártónak látszik, de a cucc kínában készül el. viszont neked nem kell ezzel foglalkozni, nekik megvan a bejáratott kínai partnerük, tartják a határidőket, stb.
A kicikínai beszerzés az időfaktor és a kiszámíthatatlan végeredmény miatt nem játszik, bármennyire is olcsó. Legújabbkori tapasztalataim alapján nagyobb időráfordítást jelent egy kétes helyzetből való kimászás, semmint értelme lenne ennyire a low-budget-re menni.
Ha a költség nagy úr és nagyon olcsón kell nem sürgősen, ezt már megéri csájnában gyártatni.
Ha preferálod a hazai gyártót - munkaerő megrendelés - akkor most hirtelen nem is tudom melyiket mondjam, van jópár és örök vita van, melyik miért jó vagy nem jó :-)
Kérdésem, hogy kis szériás (30-50 darab) két oldalas, furatgalvános, forrvédő lakkos nyák gyártással kapcsolatban kinek és hol vannak pozitív tapasztalatai?
Segítséget szeretnék kérni arduino programozásban. Mega-ethernet és nano-wifi párosokat szeretnék használni a Blynk app-al. Egyszerű alapokat létre tudok hozni, de ezt nem: szeretném a Blynk app "LED" widgetjeit használni visszajelzésként. Ha két "LED" widgetet programozok fel, akkor el tudtam érni, hogy ha a "V2" virtuális bemenethez és, a "V3" virtuális bemenethez tartozó is indikáljon, de csak úgy, hogy egymást oltják ki. Háromnál össze vissza jeleztek. Én azt szeretném elérni, hogy a "LED" widgetek (5db digitális bemenethez hozzárendelt: D3-V3, D4-V4, D5-V5, D6-V6, D7-V7. virtuális bemenet) függetlenek legyenek egymástól, és ezt a Blynk appon megjelenítse. Amikor Blynk app nélkül programozok kicsit egyértelműbbek a sorok. 1,5 hónap tapasztalattal kérem segítségeteket, mivel én csak hobby szinten szeretnék ezzel foglalkozni-egyelőre.
A hozászólásaid (és azokra a profi válaszok), illetve a linkjeid eddig nagyon jó ötleteket adtak a saját projektem megvalósításához. Lassan formálódik az akvárium vezérlőm nekem is. Nem kopizni, hanem tanulni szeretnék a projektedből, ezért el szeretném kérni a HMI illetve az ino fájlaidat (gondolom nem kereskedelmi forgalomba szántad, bár akkor sem élnék vissza vele). A sok hőmérős mérésekkel végzett adatátlagolás és min-max eldobás nagyon jónak tűnik, de sajnos az itt leírtak alapján még nem értem a működését, példád alapján viszont valószinüleg végig tudnám követni.
Szóval ha nem túl nagy kérés, légyszi küld mel nekem egybecsomizva: nagyharcos@freemail.hu
Az "s" és a "c" változókat rendberaktam, szépen számolt az "s" 0-4ig, a "c" 5-9ig, de így sem működött normálisan... mindaddig megvolt az értékem míg a második for ciklushoz nem ért a program, pedig a buffer 10 elemű volt, 0-4 ig akartam az első mérési pontot tölteni, illetve kiolvasni, átlagolni stb... 5-9ig pedig a másik hőmérő elemei voltak. De ahogy javasoltad, betettem egyetlen for-ba az összes számítást, de mégis cikluson kívül mérek. Sokkal-sokkal gyorsabb lett a program, eddig a 6 hőmérő 6 különböző 10elemű tömböt töltött, 6 különböző for ciklusban. Ezzel csak az volt a probléma, hogy a 10 elem mérése, a másodperc törtrésze alatt történt, és ha rossz volt a mérési eredmény, akkor mind a 10 elem rossz volt, ezeknek az átlaga, meg pláne. Sokkal jobb, hogy egyesével mérek, és az utolsó 5 mérés eredményével számolok, illetve még a legkissebbet, és legnagyobbat el is dobom.
Ezer hála érte!
Teljes kódot nem akarok feltölteni, mert nagyon hosszú. 6 hőmérő, kijelző, 8 relé, kijelző kapcsolói, léptetőmotor... a Megán nincs szabad digitális lábam :D
Én alapból rühellem az olasz termékeket, sokat szívtam már velük (nesze neked Arduino, az is olasz), ez meg véletlenül került hozzám. De hogy 1000-es lábszámra jó lesz-e......
Jól látod, a gond valóban a bufferben van [későbbi felismerés alapján csak lehet].
A buffer változó itt egy mátrix (Array). Nagyon egyszerűen úgy kell elképzelni, mint egy excel táblázat n elemű oszlopát (vagy n elemű oszlopát és m elemű sorát stb., mert ugye több dimenziós is lehet). A mátrix indexe (az, ami a [] között van) a változó adott sorszámú elemére mutat. Te ugyanazt a változó-mátrixot használod mindkét célra, a differencia csak annyi, hogy az első esetben az s (sapka) adott sorszámú elemével (s változó), a második esetben a c (cefre) adott sorszámú elemével hivatkozol rá. Mivel mindkét változó nullával indul, így mindkét esetben az lesz a helyzet, hogy a cefre értéke felül fogja írni a sisak értékeit, mert a cefre kiolvasása időben később van.
Javaslat: két külön buffert használj és egy hivatkozó változót:
buffer[] helyett:
buffer_sisak[]; //mindehova, ahol buffer[s] van,
buffer_cefre[]; //mindenhova, ahol buffer[c] van,
s és c helyett:
buffer_index; // nem kell különvenni az s-t és a c-t,
Mivel ez csak kódrészlet, így nem tudjuk, hogy a buffer[] és a c miként van deklarálva és van-e kezdeti érték hozzárendelve bármelyikhez is. Ez alapján az első futásban a c nem tudom, hogy nullán vagy 5-ön indul (ha nullán, akkor a fenti sejtésem helyes, ha 5-ön, akkor nem tudom).
Koncepcionális javaslataim:
1. a cefreTomb[] és sisakTomb[] mátrixok teljesen feleslegesek, a tartalmuk megegyezik a buffer[] tartalmával. (Olyannyira, hogy a két min/max ellenőrzés közül a másodikat már úgy csináltad, ahogy egyszerűbb és ahogy van értelme.)
2. a két for ciklust össze kellene hozni egyetlen for ciklusba, amelyen belül mindkét mátrix (buffer_sisak[] és buffer_cefre[]) adatait kiértékeled,
3. a buffer-mátrixok összes elemét a void setup()-ban töltsd fel releváns értékkel (egy-egy kiolvasással),
4. számold ki, hogy az atlag_s és atlag_c változókban nem lehet-e túlcsordulás,
5. minden ciklusban írasd ki a buffer_index értékét (ezt a jelenlegi kóddal is érdemes lenne megjátszani, mert lehet, hogy a c és s változókkal van valami kavarodás).
A teljes kód nélkül nehéz rábökni egyetlen pontra, mert alapvetően hibát nem találtam, de olyasmit sem, ami a jelzett ponton a sisak változó értékét felülírná. Szóval egyelőre inkább UFO-jelenség, de a fenti javaslatokkal a hibázás valószínűsége jelentősen csökken.
Kipróbáltam az általad javasolt mérési technikát, úgy látom jó lesz a feladatra, csak olyan gondom van vele, hogy nem tudom több mérőre alkalmazni. Valószínűleg a buffer okozza a gondot, de nem tudom miért.
Serial.print("Sisakhom: "); Serial.println(sisak); // rendben lezajlik minden, ha itt Serial.printtel kiíratom a sisak értékét, akkor az helyesen meg is jelenik
buffer[c]=thermocouple1.readCelsius();
c=(c+1);
if (c >= 10){ c=5; }
double maxx_c=-1E10; double minn_c=1E10; atlag_c = 0.0; // még itt is jó a sisak értéke
for(int i=5; i < 10; i++) {
cefreTomb[i] = buffer[i]; //elmented a hőmérséklet értékét //ha ide szúrom be a serial.print(sisak) sort, akkor itt már nem helyes az érték Serial.println(buffer[i]); atlag_c += buffer[i]; //összeadod az elemeket if(buffer[i]>maxx_c) maxx_c=cefreTomb[i]; if(buffer[i]<minn_c) minn_c=cefreTomb[i];//ide lehet hogy kell egy pici delay, de ki kell próbálni
}
cefre = (atlag_c-minn_c-maxx_c) /3;
A második for ciklus után a sisak értékét egyenlővé teszi a cefre értékével.
