- Felvarrták az Arctic rackmount rendszerekhez szánt CPU-hűtőjének ráncait
- Háromféle kivitelben, és nem kis kapacitásokkal jönnek a Micron 6550 ION SSD-i
- Már a Samsung sem szolgálja ki modern AI lapkákka Kínát
- Havazáshoz igazított kiadás kap a Steam Deck OLED
- Híres régészprofesszor segíti a GeForce-ok eladását
- Milyen monitort vegyek?
- Fejhallgató erősítő és DAC topik
- Kormányok / autós szimulátorok topikja
- Androidos tablet topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- OLED TV topic
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Samsung LCD és LED TV-k
- Házimozi belépő szinten
- ThinkPad (NEM IdeaPad)
-
PROHARDVER!
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
atesss
addikt
válasz
gyapo11
#13450
üzenetére
De mivel többször is mértem, így eléggé valószínűtlen hogy minden mérésnél pont a rövid impulzusba mért volna bele.
Mindegy, ma du. végre kiderül, ma meg tudom mérni szkóppal.
A PCF8574 bemeneti pinjeire erősen ajánlott ellenállásokat is megveszem, de még direkt nem forrasztom be, előtte kimérem szkóppal ezt az anomáliát.
Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?
Rigol, digitális, elég nagy tudású (és sajnos a bonyolultabb funkciókat nem is nagyon tudom használni). -
And
veterán
válasz
atesss
#13452
üzenetére
"Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?"
Egyszerűen nem automata triggerelést választasz (amikor ész nélkül fut a sugár akár van trigger, akár nincs), hanem normál vagy 'one shot' módot - hívják akárhogyan, a lényeg, hogy csak triggerre induljon a mérés. A trigger szintjét féltápfesz környékére választod, a típusát pedig lefutó élre. -
Janos250
őstag
válasz
atesss
#13452
üzenetére
Ha nem akarsz triggerelni, azzal a szkóppal elég széles időintervallumot tudsz a memóriába helyezni, utána tetszőlegesen tudod nagyítani, részleteiben vizsgálni. Jó az a szkóp!
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
atesss
addikt
No a szkópos mérés alapján úgy néz ki hogy mégiscsak valahogy a programkód okozza a problémát.
Az 1. ábrán nem volt sleep a python scriptben a kiolvasú függvényemben a PCF8574 kiolvasása után: [kép]
A 2. ábrán 35 ms sleep() volt: [kép]
A 3. ábrán pedig 125 ms sleep() volt: [kép]A kék az INT pin.
A sárga pedig a nyomógomb amit megnyomtam, és a PCF8574 egyik bemenetét húzza földre egy ellenálláson keresztül.[ Szerkesztve ]
-
And
veterán
válasz
atesss
#13456
üzenetére
Az nem világos, hogy ha gombnyomásra indul a folyamat, és az input portra kerülő jelet - vagyis a gombnyomást, ami GND-re húz - a sárga görbe írja le, akkor miért csak a 3. képen szerepel ez a jel lefutó éllel, a másik kettőn pedig felfutóval? Egyáltalán, hol volt a mérőfej, magán az input porton, vagy a soros ellenállás előtt? Amúgy végül került arra a portra felhúzó vagy sem? Bocs, ha említetted volna, de nem találom ezt az infót.
Az is egy érdekes mérés lenne, ha a második csatornán nem az INT-jelet vizsgálnád, hanem magát az I2C-jelfolyamot, hogy az hogyan viszonyul időben a fizikai bemenet változásához képest. -
atesss
addikt
No már elkezdtem írni hogy mi lehet ennek az "anomáliának" az oka.
Aztán miközben írtam, esett le hogy mi is van:
Mivel a --változásokat-- figyeli a PCF8574, akkor is van ugyanúgy interrupt, amikor elengedem a gombot (az INT pin akkor is 0-ba megy).
És a gombot jelző sárga jel ugye így pont az inverze. De amúgy semmi más különbség nincs, most teszteltem.
Valószínűleg csak annyi történt, hogy a 3. képnél még nyomva tartottam a gombot, amikor csináltam a képet. Vagy esetleg STOP-oltam a triggerelést a szkópon.
A sárga mérőfej magán az input porton volt (illetve egy 20cm-es hozzáforrasztott kábel végén).
A kék mérőfej pedig magán az INT porton (szintén egy 20cm kábelen).
A felhúzó ellenállás még nem került fel. Írtam, hogy direkt úgy tesztelem most a szkóppal, hogy még nem forrasztom fel őket.
Az I2C-s mérés is egy jó ötlet lenne. De közben még tesztelgettem, és egyértelműen programkód-oka van a dolognak.
Ámde azon belül valami nagyon is fura oka...
Direkt kiszedtem a GPIO interruptot. Illetve a PCF8574 beolvasását is közvetlenül a MAIN-be raktam (kiszedtem még a MAIN-ből meghívott függvényből is). De erre nem lett változás.
Eddig amit találtam hogy "megoldja" a problémát, ha kiprintelem a tömböt, amibe előtte már beolvastam a PCF8574-nek a portját.
Próbáltam, hogy kiprintelek egy másik, teljesen ugyanilyen adat-szerkezetű tömböt, de arra meg nem.
Szóval egyelőre tiszta X-akták...if GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:# i2c_io_readed_array = i2c_io_reader()print("------")io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)print("--")i2c_io_readed_array = i2c_io.portif len(i2c_io_readed_array) == 8:# passprint("az előző kiolvasás megfelelően megfordított értéke: ", i2c_io_readed_array_reversed)teszt = i2c_io_readed_array# print("A beolvasott port tömbje egy külön [teszt] nevű változóba átmásolva: ", teszt)# print("PCF8574 Port beolvasva. A beolvasott port tömbje:", i2c_io_readed_array)time.sleep(0.125)io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - 0.125 sec-el olvasás után: ", io_interrupt_flag)print("------")i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)
A legbelső if-ben láthatóak a tesztelt "feltételeim".
Csak az utolsó két, most #-el kikommentezett print() bármelyike oldja meg a problémát (természetesen a teszt változós csak akkor ha előtte megvan az értékadása is).
Ez valami eléggé érdekes bug lesz... -
válasz
atesss
#13458
üzenetére
Azt hiszem végre sejtem, mi lehet a háttérben.
Van hardveres pergésmentesítés a nyomógombon? A kolléga már kérdezte, de nem adtál rá választ. Ha nincs, az egész teszt ebben a formában értelmetlen, mivel a lenyomástól számított 50-100ms-on belül a kapcsoló a pergés miatt random időközönként nyit-zár, mire megnyugszik. És mivel - ahogy Te magad is írtad - az INT láb az elengedésre is triggerel, ha interruptot állítasz be a gombnyomásra, a legelső kiolvasás után még számtalanszor tüzelhet az INT, mire beáll.
Ha igazam van, akkor ezt akkor fogod látni a szkópon, ha sleep nélkül folyamatosan olvasod az i2c port állapotát végtelen ciklusban (ezzel törölve az INT láb aktív állapotát). És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c. -
atesss
addikt
Igen, ez a hardveres pergésmentesítés tényleg probléma forrás.
Ezt milyen kapcsolással tudnám megoldani a lehető legegyszerűbben ?
Ugyanakkor ezt az elég fura, programkód-alapú hiba forrást (konkrétan én ezt valami bug-nak sejtem már) valószínűleg nem oldaná meg.
Miért lesz teljesen más az INT pin működése - a szkópon is láthatóan - , ha beteszek egy már kész (fixen feltöltött) változót kiprintelő függvényt ??
(Jó párszor lefuttattam direkt, szóval a pergés miatti különbséget ebből a szempontból kizárhatjuk.)
"És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c."
Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? Vagy pedig amit már írtál egyszer korábban hogy bizonyos időn belül újra meghívva nem frissíti a korábban lekérdezett állapotot ?
Bár azt azért kipróbálnám, hogy mi van ha kiveszem, azif GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:
feltételvizsgálatot, és úgy olvasom be folyamatosan i2c-n a port állapotot. -
gyapo11
őstag
válasz
atesss
#13461
üzenetére
A legegyszerűbb pergésmentesítés ha csak egyáramkörös nyomógomb van, az r-c szűrő. Ha váltó kontaktusok, pl. mikrokapcsoló, akkor 7400, két nand kapu.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
válasz
atesss
#13461
üzenetére
"Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? "
Nem tudom pontosan hogy működik, mert sosem merültem el ilyen szinten a raspberry lelkivilágában, de úgy olvastam, hogy a python nem közvetlenül éri el a gpio-t, mint a C programok, hanem fájlként kezeli (talán a /dev/pigpio-t (?) írja-olvassa), ezért elég lassú, ~1ms egy művelet. Ha hülyeséget írtam, akkor javítson valaki.
-
válasz
gyapo11
#13462
üzenetére
De jelen esetben is egyszerűbb a szoftveres megoldás: interrupt esetén kell egy kb. 50-80ms sleep (ezalatt természetesen az interruptokat letiltani, hogy ne okozzon zavart a pergés miatt a többszörös interrupt), csak utána beolvasni a portok állapotát. A gomb elengedése esetén ugyanez, csak itt az eredményeket eldobjuk, ha nincs művelet gomb felengedésre.
-
atesss
addikt
válasz
gyapo11
#13462
üzenetére
2db egy-áramkörös záró mikrokapcsoló van, ilyesmi: [link] (Hiába nézne ki elsőre két-áramkörösnek a 4 lába miatt, nem az.)
Illetve van még 4db DIP-kapcsoló, ilyesmi: [link]
Utóbbinál is lehet pergés tulajdonképpen, szóval azt is meg kellene oldani akkor már.
És ráadásul már elég kevés helyem is van a nyáknak azon a területén, szóval helytakarékosnak is kellene lennie (pl. 1-2 raszteres alkatrészekből).
MOD:
aryes
Hát igen, a SW-es megoldás jobban tetszene.
Bár most ugyan nem számítana, de - kvázi tanulási célból is - olyan megoldást szeretnék ami azért kicsit elegánsabb.
Szóval sleep-et nem szívesen raknék be, mert amúgy indokolatlanul lassítja a program működését, sőt fixen egy időre megakasztja.
Ami az ötletem lett helyette:
Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms. És ha ez eltelt, csak akkor indulna el a tényleges interrupt-handler függvény. A függvény végén pedig újra engedélyezni az Interruptot, globálisan.[ Szerkesztve ]
-
válasz
atesss
#13465
üzenetére
Ez jó ötlet, de ha kiveszed a feldolgozást az interruptból és a main-be teszed, akkor nem is kell letiltani az interruptot, csak azt vizsgáld, hogy a gomb állapota mikor változott utoljára. Mented az utolsó változás idejét, és ha eltelt azóta pl. 50ms, akkor mehet a művelet.
Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását. Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni. Ennek pedig a zajérzékenység a hátulütője. -
atesss
addikt
"de ha kiveszed a feldolgozást az interruptból és a main-be teszed"
Azért ettől még nem raknám be a main-be. Az Interrupt megtörténte átállítana egy Flag-ként használt változót. És akkor innentől indulna el az időmérés a main függvényben (innentől minden ciklusban lefutna a mainben az, ami ellenőrizné mennyi idő telt el).
Amint az eltelt idő több mint 50ms, akkor indítanám a "tényleges interrupt-handler" , azaz a PCF8574-et kiolvasó, és utána az ezt a kiolvasott értéket meg feldolgozó függvényeket.
"Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását."
Ez sajnos így van, ez speciel tényleg nem tetszik ebben a megoldásban.
"Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni."
Ez tényleg gyorsabb. Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le.
Akkor ha tényleg eléggé egyszerre történt a megnyomás (80ms-on belül), akkor simán előfordulhat, hogy ugyan az első beolvasás időpontjában (1-2ms után) még csak az egyik gomb volt lenyomva. De viszont a 80ms vége után (amikortól megint újra figyelnénk a változásokat), viszont már mindkettő, és így már többé nincs változás --> nincs Interrupt.
Vagyis a második gomb lenyomása így akár el is veszhet. -
gyapo11
őstag
Sokszor jó a sw megoldás, az én teszt óraprogramomat is egy sima kontaktussal vezéreltem, 50 ms körüli időt vártam, és tévesztés nélkül működött jól. De koszosabb vagy oxidos, szulfidos stb. érintkezőkkel, lassúbb nyomással, remegő kézzel adódhatnak problémák, vagy már olyan hosszúra kell nyújtani a várakozást, ami gondot okoz. Az én tesztem mikrokapcsolóval az volt, hogy a legrövidebb pöccintés is 50 ms körüli időre zárta az áramkört. Ez nyilván kapcsolótól és kéztől függ. De így 150 ms-on belül simán be tudok vinni két pöccintést, viszont ha 100 ms-ot vár a program, akkor már nem. Hw megoldással pedig bármennyit, ott az emberi képesség a határ. Pl. zongora billentyűket 4 ujjal simán lehet gyorsabban nyomogatni. 4 billentyűt egymás után. De akár egy db mikrokapcsoló is képes gyorsabb működésre, ha nem ember nyomogatja, hanem szalagon haladó dobozok vagy ilyesmi.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
válasz
atesss
#13467
üzenetére
"Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le."
Erre egészen egyszerű a válasz: minden gombhoz külön-külön kell egy számláló, nem az interruptok közti időt kell számolni. Ezért is nem érdemes az interruptot letiltani.
"Azért ettől még nem raknám be a main-be."
Ezt írtad: "Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms."
-
válasz
gyapo11
#13468
üzenetére
Az ilyen gyors reagálást igénylő feladatokhoz sokkal alkalmasabb a gumi kontaktusos nyomógomb (pl. távirányítók, gamepad-ek gombjai stb), az ugyanis nem pereg, így nem kell prellmentesíteni.
Cserébe nem zár nullára, de ez egy nyomógombnál többnyire nem is okoz problémát.A zongorabillentyűkről jut eszembe: akár optokaput is lehet ilyen célra használni (szerintem a szintetizátorok sebességérzékelős billentyűmechanikáját is valahogy így oldhatják meg).
[ Szerkesztve ]
-
atesss
addikt
"Azért ettől még nem raknám be a main-be."
Mármint ezt magára a port-lekérdezésre és a feldolgozásra értettem.
Az "órás mérés" az, amit viszont beraknék a main-be.Közben viszont kiderült, hogy az event detection függvény:
- Tud olyan kapcsolót is, hogy ... , bouncetime=xxx [msec]
Ez így kb. azt valósítja meg készen, amit te írtál első opciónak. Amint van egy interrupt, onnantól vársz 80ms-ot (ilyenkorra ugye már biztosan nem lesz 0-sban az INT pin, mivel pont ez a cél vele).
Szóval ez most nekem nem túl jó megoldás.
- Alapból Threading-ként, többszálúan működik [link] (Install RPi.GPIO version 0.5.2a for multiple threaded callback interrupts)
És nem találtam rá opciót, hogy kikapcsolható lenne a Threading (egy ezt még nem tudó régi verziót - csak ezért - meg nem akarnék felrakni)."Ezért is nem érdemes az interruptot letiltani."
Pedig ezzel próbálkoztam most. Első körben csak hogy csak egy gombra megoldjam a pergésmentesítést kb. valahogyan.
De hát nem akar így sehogy se menni, szóval megyek tovább úgy, hogy nem tiltom le az interruptot.[ Szerkesztve ]
-
Tankblock
aktív tag
válasz
atesss
#13471
üzenetére
Schmitt trigger alkalmazol, vagy a gomb helyett egyszerű érintő panelt pl TTP223
Problem solved.Ha meg szálaid vannak akkor meg nem mind1? írsz egyet ami figyeli h 1be vált-e az interrupt ban lévő flag. Amint lefutott amit szerettél volna és eltelt + 50 ms akkor 0 -ra váltog a flaget...
Release the Beast....
-
repvez
addikt
valaki tud olyan szelepről ami a levegő mennyiségét tudja szabályozni 0-100% között és elég gyorsan ?
Pl ha van egy ventilátor ami fújja be a levegőt egy csőbe akkor ezen a szelepen keresztül haladva lehetne szabályozni a levegő mennyiségét?
kb 1-2 cm es átmérőben kellene -
repvez
addikt
válasz
gyapo11
#13474
üzenetére
ilyesmire gondoltam, de nem találtam sehol ekkora méretben vagy aminél már alapbol be lenne épitve arduino kompatibilis servoelektronika a vezérlésre.
DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap.
-
tibi-d
tag
válasz
repvez
#13475
üzenetére
Sajnos ez a feladat még ipari technikával is nehéz feladat, mert a szelep zárásával nem lineárisan változik a levegő mennyisége. A szelep fél állásában, szinte még semmit nem csökken a légáram. Ha precízen kéne légáramot szabályozni, akkor kéne egy ballon, aminek a nyomását lehetne szabályozni, és egy állandó keresztmetszetem elszállítani a levegőt. Így a nyomással arányos lesz a szállított levegő mennyisége. Ehhez szabályzó elemeket nem könnyű beszerezni, és az áruk nincs arányban a lehetőségekkel.
-
gyapo11
őstag
válasz
repvez
#13475
üzenetére
A fényképező objektívek blendéje lenne ilyen, még valami régit lehetne is találni olcsón, de nagyon nem motoros mozgatásra van kialakítva, hanem egy gyűrűt kell forgatni, viszonylag munkás lenne átalakítani.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
atesss
addikt
válasz
tibi-d
#13477
üzenetére
"mert a szelep zárásával nem lineárisan változik a levegő mennyisége."
Ha szervóról beszélünk, akkor azzal elvileg viszonylag pontosan szabályozható a szelepnek a szöge. Persze ha az egyéb mechanikai elemek is eléggé merevek ehhez.
Szerintem ha egyszer kiméred műszerrel, hogy milyen szervó állásnál mennyit szállít (mondjuk 10-20 különböző állásban), akkor abból már tudsz csinálni egy függvényt. Vagy akár csak egy look-up-table-t, interpolációval. És onnantól az alapján már vezérelheted. Nyilván nem lesz óriási a pontossága, de ha nem speciálisabb ipari rendszerbe kell, akkor szerintem a célnak megfelelhet. -
atesss
addikt
válasz
repvez
#13475
üzenetére
"DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap."
Ez nem is rossz ötlet.
Ha tényleg elég rugalmas és tartós a csöved, akkor esetleg lehetne olyat csinálni, hogy egy szalagot/kötelet meghúzva, "összehúzod" a csövet. Nyilván ez csak egy bizonyos határig működik (csőtől függő, de szerintem a min. olyan 1/4 átmérő lehetne, még valami spécin rugalmas csővel is).
Tehát egy motor tengelye egy szalagot húz meg/enged el (ami mondjuk egy kis orsóra/rúdra fel van tekerve). Amikor meghúzza, akkor ezzel összehúzza a csövet. Amikor meg elengedi, akkor a cső a saját rugalmassága segítségével nyomja magát vissza eredeti állapotába.
Persze még külön kiépített, megfelelő végállások is kellenének, hogy biztosan ne húzza túl a csövet.
Elvileg a motor-fordulatok száma az orsó kerületével szorozva megadja az áramlási cső kerületének csökkenését. De a gyakorlatban itt is ki kellene a léghozamot úgy mérni, mint ahogy az előzőre is írtam.[ Szerkesztve ]
-
repvez
addikt
[link]
Első körben olyasmire gondoltam mint a hajtómüvek gáz sugár fokozó redőnyei.vagy a videon látott sugárforditó
Ami nem is lenne rossz ötlet csak az a gondom vele, ha a csö végére teszem akkor ott már nem tudom mérni a levegő nyomását vagy a sebességét , mert a külsö térrel érintkezve már nem ad jó eredményt. ha beteszem egy cső közepébe ,hogy az elötte utánna értéket össze tudjam hasonlítani, akkor is hasonló a helyzet, hogy a szűkület után visszatágul a cső és ezzel a levegő értékei is megváltoznak és a csö végén már nem a megfelelő hatást éri el.
Bár ha ez a változás statikusan mindig ugyan annyi akkor talán lehet vele korrigálni.A probléma lényege, hogy egy közös nagyméretű csövön jövő levegőt kellene 4 vagy több kisebb részre elosztani, hogy mindegyiknek külön külön lehessen mérni, szabályozni a paramétereit (mennyiség, nyomás, sebesség.)
-
gyapo11
őstag
válasz
atesss
#13479
üzenetére
Akkor már jobb a vezérlés helyett szabályozni, betenni egy légmennyiség mérőt, és addig nyitni-zárni a szelepet, amíg a kívánt mennyiségű áramlás be nem áll.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
-
repvez
addikt
válasz
Gergosz2
#13483
üzenetére
mindenképp valami 3d nyomtatásos megoldás lenne csak előtte egy működőképes megoldást kell találni amihez már lehet tervezni a kialakitást.
Egyébként azon gondolkodtam, hogy nem feltétlenül kell kör keresztmetszet. így nem kellene a cső közepében elforgatni a szűkítő lapot hanem elég valamelyik oldalhoz csatolni, viszont az alábbi probléma akkor is fennáll, hogy hogy lesz a szűkítés után mérés és hogy marad meg a megváltozott paraméter
-
zsolti_20
senior tag
Üdv emberek!
Van valakinek tapasztalat bárkód (bar code) szkenneléssel kapcsolatban? Érdemes arduinora építeni vagy legalább egy raspberry pi szükséges?
A feladat annyi lenne, hogy kb minden műsodik mp-ben jön egy matrica egy nyomtatóból amin van 3 bárkód. Ebből csupán az egyiket szeretném használni de ezt sima szűréssel kitudom majd a későbbiekben választani. Először azt szeretném megoldani, hogy tudjak egy olyan eszközt készíteni ami minden matricáról képes beszkennelni azt a 3 bárkódot és elmenteni azt bárhová amit a későbbiekben elő tudok venni. Találtam pár projektet az USB bárkód szkennelőhöz, de úgy gondolom jobb lenne a csillagszkennelő ami a boltokban is található. Folyamatosan kellene olvasnia, nem gombnyomásra hiszen beidőzíteni a szkenelést lehetetlen lenne mert van olyan ami matrica ami 2.5mp múlva jön de van olyan ami mondjuk 4. Így csak akkor működhet a dolog ha folyamatosan be van kapcsolva a szkennelés funkció.
Létezik vagy lehetséges hasonlót csinálni? Sajnos PC-ről nem tudom kiolvasni ezeket, mert fizikálisan kinyomtatott matricáról szükséges a bárkódot leolvasni. -
Dißnäëß
nagyúr
Sziasztok !
Tudom, hogy alapvetően komponens szórástól függ, mennyire pontos, de: használtatok már Arduino féle állatot feszültség és áram mérésre (akár logolás, akár kijelzés, akár csak védelemként) valamilyen elektronikai eszközben ?
Lenne egy második kérdésem is: mennyi RFI/EMI-t okoz egy Arduino egy "muszály csendesnek lenni" környezetben ? Gondolom, töredékét még egy Pi-nek is, de kb. számottevő, vagy nem kell foglalkozni vele, annyira szinte semmi ? Most csak úgy árnyékolatlanul ott van egy sarokban a sasszi aljára csavarozva négy műanyag távtartóval. (És egyelőre jó így). Ja, wifi és bluetooth mentes eszközről kérdezem ezt. (Leonardo).
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
válasz
zsolti_20
#13485
üzenetére
Szia! Tudni kéne, hogy milyen bar code - magyarul vonalkód - lesz a matricán. Ha sima 1D (vmilyen EAN) kód lesz, akkor a legegyszerűbb egy reflektív optokapu lenne! A kód egy egyszerű bitsorozat, ha a nyomtató papírmozgató mechanizmusa egyenletes sebességgel tolja ki a papírt, akkor egyszerűen mérni kell a jelek hosszát, és visszafejteni belőle az adatot.
-
válasz
zsolti_20
#13490
üzenetére
Két teljesen különböző dolog, nem lézeres, és nem mér távolságot, bár közelség mérésére szokták használni (proximity sensor).
A lényeg, hogy a fekete és fehér felület más fényvisszaverő képességgel rendelkezik, egy fototranzisztorral pedig tudod mérni a fényerő változását, ahogy a csíkok sorban elvonulnak a szenzor előtt. Ehhez persze úgy kell nyomtatni, hogy ne keresztben, hanem hosszában jöjjön ki a vonalkód a nyomtatóból, tehát ha az optikát elhelyezed a nyomtató papírkiadó tálcája fölött, a csíkok maguktól átmenjenek alatta.
Megpróbálom lerajzolni neked.[ Szerkesztve ]
-
Remélem látszik a lényeg a képen.
Olyan optokapu kellene, ami nem infra fényt használ, hanem látható fényt, vagy egy egyszerű vörös lézerdióda + fototranzisztor, mert a fekete nyomtatófesték sajnos az infravörös fényt nem igazán nyeli el, nem lesz elég kontraszt a két jelszint megkülönböztetéséhez.
Rajzoltam egy lencsét a fény fókuszálásához, hogy a vékony vonalakat be lehessen olvasni, de ez egy lézerdiódánál talán el is hagyható. -
FeniX-
senior tag
Sziasztok, egy kis segítségre lenne szükségem. Egy viszonylag egyszerű áramkört akarnék összeállítani, de nem áll össze a kép, vagy nem értek valamit.
Egy arduinoval szeretnék irányítani egy 12v-os ventillátort, tranzisztor segítségével.Az arduinot egy 4b-os cerkaelem csomag hajtaná meg, a ventit pedig egy 8db-os cerkaelem-pakk. (tehát, 2 külön, független áramforrás)
Ha simán az arduino bármelyik PWM lábára programozok egy pár századmásodperces delayt és "kapcsolgatást", majd azt a tranzisztor bázisára kötöm, a 12v-os ventit pedig a saját áramforrásán keresztül a tranzisztor kollektorához, akkor ezzel nagyjából fel is vázoltam az egész kapcsolást.
Mégsem működik a cucc..
közös test kéne nekik?
(elvileg a tranzisztornak működnie kéne, 'ctbc 639 NPN', ha jól néztem) -
válasz
FeniX-
#13493
üzenetére
Szia! A tranzisztor emitterét mindenképp össze kell kötni az arduino gnd-jével, különben nem jön létre az áramkör.
A ventilátort pwm-mel szeretnéd szabályozni? Először próbáld ki 100% kitöltéssel, és onnan csökkentsd a kitöltést, ne 0-ról felfelé, mert 30-40%-ig valószínűleg meg sem fog mozdulni. -
FeniX-
senior tag
válasz
FeniX-
#13493
üzenetére
Összeállítottam még egyszer: valóban, közös testtel működik. De ez nem gond? Egy 12v-os meg egy 5v-os "hálózat" közösre kötése?
Időközen látom a választ is, szóval köszönöm szépen, igen, így már jó.
50-80-100%-on változtatom. Tök jól megy!
(A konyha kamra részéhez akarok egy miniatűr szellőztető 'rendszert', ami a hűtő mögül kiszívja a meleg levegőt, egy másik részéből pedig hideg levegőt fúj be a kamrába.)[ Szerkesztve ]
-
-
Janos250
őstag
Srácok!
Érdemes gyalog megcsinálni a vonalkód olvasást, amikor 10-20 dollárért
kész Uart/USB/WiFi csatlakozású vonalkód olvasót lehet kapni?
Ami mellékesen többnyire még QR kódot is tud olvasni, ha esetleg a későbbiekben arra is szükség lesz. Van kézi, és beépíthető egyaránt.
Webáruházakban "barcode scanner"
Például:
link
linkAz amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
zsolti_20
senior tag
válasz
Janos250
#13498
üzenetére
Ezek egész jónak tűnnek. Főleg a második az automata érzékelő miatt, pont amilyen nekem is kellene. Nem tudom ez össze hangolható vagy sem arduinóval, esetleg olyan megoldást kell keresnem, hogy először wndowsra szkenneli be mondjuk egy excel fileba aztán abból dolgozik az arduino a továbbiakban.
Tudna valaki segíteni?
Új hozzászólás Aktív témák
Hirdetés
ekkold- Autós topik
- World of Tanks - MMO
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Kupon kunyeráló
- Milyen monitort vegyek?
- Huawei Pura 70 - fura lettem
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Black Friday november 29. / Cyber Monday december 2.
- Fejhallgató erősítő és DAC topik
- Futás, futópályák
- További aktív témák...
- 7320 2-in-1 27% 13" FHD+ IPS érintő i7-1180G7 16GB 512GB NVMe ujjlolv IR kam gar
- LG 27QP88D-P Dual Ergo Monitor Szett!2x27"/IPS/2560x1440/HDR/Type-C/Dual Ergo Kar/
- Raspberry Pi Zero W (v1.1) + 16Gb Sandisk UHC microSD
- Latitude 5290 2-in-1 12.3" FHD IPS érintő i5-8250U 8GB 256GB ujjlolv 4G LTE gar
- X13 Gen1 27% 13.3" FHD IPS érintő Ryzen 7 PRO 4750U 32GB 512GB NVMe ujjlolv IR kam gar
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest