A változód értékét kell serial print-el a pc felé küldeni, mintha csak az arduino programjánál tennéd.
Sok példa lesz c-ben is. Mindenképpen kell egy szálat indítanod, ami a sorosportot figyeli, a többi szálra tedd a programod megjelenítőjét (Form, Chart, textbox) stb.
A korábbi kódom amit mutattam azért jó, mert egy boxban megjeleníti a géped összes portjának a nevét, ott ki tudod választani, hogy melyiken lóg az arduino, sebesség beállítás és go.
Windows form os alkalmazást szeretnék fejleszteni arduinohoz visual stúdióban,(real time adatgyüjtőt szeretnék legalább 5 szenzorral).
A kérdésem az lenne, van- e valakinek tapasztalata ilyen téren, és hogy, hogyan tudnék írni-olvasni adatot az arduinoról?
A neten fellelhető íràsokban com porton kommunikálnak az eszközzel, de nem látom àt, hogy hogyan lehet com porton keresztül adott analóg bemenet lévő értéket belolvasni majd felhasználni egy visual c kódban.
A wdt-t probalnam ugyanezzel a programmal, de nem muxik, sot lefagy tole a cucc. Ha ez a sor benne van barmilyen parameterrel, akkor fagy meg (feltolteni meg fel tudom, utana a parametertol fuggoen 0-2 villog a led es utana mar csak aramtalanitas utan lehet ra ujra feltolteni barmit):
Üdv! Robotot szeretnék összeállítani Arduino segítségével. Motor shield vásárlásra adtam a fejem - esetleg ha valaki tud normális guide-ot egy megépítéséhez, szívesen fogadom -, kérdésem melyik volna az ideális egy 2db DC-motoros robothoz?! Íme a választék:
Teljesen igazad van kicsit hülye kérdező vagyok, bár igazság szerint nekem sincs mert leírás alapján csináltam. Viszont ugyanakkor rájöttem, hogy az arduino minivel volt a probléma (magával a board - al) mivel az 5v - os kimeneten csak 3,6v - ot adott a 3,3v - os kimeneten pedig csupán 1,8 - at (így már értem, hogy a hálózati modul miért nem indúlt el). Ugyanakkor nagyon nem lepődtem meg mert 1 euróért rendeltem darabját, legközelebb inkább egy minőségibb beszállítótót rendelek. Megcsináltam ugyanezt a kapcsolást egy normális Arduino Uno - n (amit hazai beszállítótól rendeltem még korábban) és minden tökéletesen működik program szerint jár el és stabil a hálózati kommunikáció.
Elnézést kérek a (végtére is) felesleges kérdésemért de nagyon érdeklődöm a terület iránt viszont tapasztalatom még sajnos csak gépi programozás terén van és nagyon érdekelnek a PLC - k ill. mikrokontrollerek mert ezeknél legalább fizikai eredményem is van :-)
Segítséget szeretnék kérni tőletek abban, hogy "készítettem" egy kapcsolást arduino nano, hr911105a 15/21 Ethernet modul segítségével egy led szalag kapcsolást. A problémám az lenne, hogy amíg rendes usb - röl kapja az áramot addig semmi gond nincs megy a hálózat, a kis webszerver stb (nyilván így viszont nem tudom kapcsolni a ledeket mert ahhoz viszont kevés) viszont amikor a VIN és a GND pin - re kötök 12V feszültséget az arduino borzasztóan elkezd forrósodni az 5v - os selector környékén majd természetesen egy kis idő múlva le is esik a feszültség és leáll a program is. észrevettem, hogy amikor a hálózati modul VCC pinjét leválasztom az arduinoról akkor semmi baja nincs ( persze így viszont nincs hálózatom). Mindenhol azt írják, hogy a hálózati panel VCC pinjét a 3,3V - ra csatlakoztassam viszont így csak a led halványan pislákol rajta és nem működik a hálózat ellenben az 5V - os kimenettel nincs semmi gond.
Tanácstalan vagyok mit ronthattam el, hogy 5v - ról minden rendben 12V - ról pedig forrósodik a hálózati panellel. Remélem tudtok tanácsot adni ebben a problémában pár napja szívom a fogam emiatt, hogy hol lehet a baj. Előre is nagyon köszönöm.
Az Arduinok magja egy Atmel ATmega mikrokontroller. Ez önmagában a saját szoftveres fejlesztői környezetével pompásan alkalmas ipari felhasználásra (általános automatizálás, gépkocsiipar, háztartási gépek stb. stb. stb.). Az Arduino keretrendszer azonban ehhez képest -- hogy egyszerűen fogalmazzak -- ki van herélve, elsősorban szoftveresen, részben hardveresen. A szoftveres rész:
-- a fejlesztői környezet (Arduino IDE) konkrétan egy vicc mérnöki szemmel, egyértelműen látszik rajta, hogy oktatási célokra találták ki (arra viszont egészen jó, ha nem is tökéletes),
-- a rendszerbe beletoltak egy bootloader-t, ami egyérszt kicsit hülyebiztossá teszi a rendszert (lásd Arduino IDE), másrészt sok szempontból többet árt, mint használ, többek között brutálisan lassítja a bootolási fojamatot, egyszerű eszközökkel lehetetlenné teszi bizonyos beállítások elvégzését stb.
-- a keretrendszer könyvtárai, illetve azok, akik ezeket létrehozzák, nem integritáson, hanem a saját céljuk megvalósításán gondolkodnak (hozzáteszem, az mbed is), emiatt sok könyvtár nem kompatibilis más könyvtárakkal, rosszabb esetben olyan gyorsan tömik tele az egyébként limitált memóriát, hogy jobb esetben csak a hely fogy el, rosszabb esetben papírnehezékké konvertálja a hardvert.
És ha már hardver.
Egyrészt rátoltak egy alapvetően nem feltétlenül felesleges, de mégis, soros--usb csatolófelületet, ami hasznos, mert egyszerű, és káros, mert pl. egy ipari adatgyűjtőt a legritkább esetben dugdosnak USB-re.
A debug lehetőségek Arduino IDE környezetben gyakorlatailag a Serial.print() parancsra és a Serial Monitorra korlátozódnak. A saját ATmel keretrendszerben ez azért szofisztikáltabb, de az nem is hobbi/tanulási kategória. Watchdog csak nagyon faramucin van (vagy hardveresen kell megoldani).
Továbbá. Magukon a fejlesztői paneleken (és ez nagy vonalakban mindegyikre igaz) van egy csomó holmi, ami konkrétan a fejlesztést szolgálja/segíti (ilyen pl. a szabványos hüvelysoros csatlakozófelület, ami az Uno Rev.3 óta nagyjából változaatlan), emiatt bizonyos fejlesztési feladatok végtelenül leegyszerűsödnek (pl. nem kell szopni, hogy hardveresen illessz mondjuk egy 16x2 alfanumerikus kijelzőt, hanem simán rányomsz egy shield-et és kész -- az ST Nucleo például képes akár 2-3-4 gyári kiegészítő panelt is elviselni magán, az Arduino esetén ez már nem feltétlenül igaz, mert sok shield üti a másikat a lábkiosztás miatt). Ipari felhasználásra a legritkább esetben elfogadható egy alapvetően szétszedhető, plusz rengeteg felesleges alkatrészt tartalmazó (nagy, sokat fogyaszt stb.) rendszer használata, ezért van az, hogy a prototipizálás után jön a sorozatgyártásra tervezés, amikor az adott célra szükséges elemeket, de csak azokat (már debug felület, usb stb. nélkül) egy célpanelre pakolják, aztán jöhet a mehet (a sorozatgyártás). Néhány darabért nyilván épeszű ember nem fog nyákot tervezni (plusz gyártatni), de erre is csillió elegáns módszer van azon kívül, hogy egy Mega2560-at a jumper kábelekkel együtt behányunk egy csinos műszerdobozba (az Instructables konkrétan dugig van ilyenekkel).
Összefoglalva: ha az Arduino keretrendszert és az eszközöket nézzük (még talán az Intel magos cuccokat is beleértve) alapvetően hobbi / tanulási célú eszközökről van szó (mondjuk játéknak titulálni már a Mega2650-et is barokkos túlzás). Ugyanakkor a mag olyan szinten ipari, hogy a most futó alsó és középkategóriás kocsik kb. felében valamelyik ATmega (vagy csak simán valamelyik Atmel) mikrokontroller törli az ablakot vagy indexel.
Alapvetően itt is igaz, hogy a projekthez kell eszközt választani.
pont azok amiket felsorolsz. kellene hozzá doboz, tápegység, perifériaillesztők. ha bármi veszélyeset irányít, akkor minősítések. egy mérnök, aki egy ilyet össze tud rakni, az napi 30ezer forint feletti összegbe kerül a munkáltatójának, ehhez képest egy mini plc ami pár tízezer forint nem pénz.
ahogy nézem, az a NI MyDAQ is egy oktatási célú eszköz, nem ipari felhasználásra van szánva.
Értem, nem is feltétlenül sorozat gyártott termékre gondolok, hanem pl célgépekre plc kiváltására, vagy diagnosztikához adatgyűjtő eszközként felhasználni mint pl az NI myDAQ.
Nyilván azzal tisztában vagyok, hogy ez nem olyan színvonalú eszköz mint az NI termékei, de egy-egy karbantartási feladat során hőmérséklet, nyomás stb.. mérésre elegendő lehetne, főleg egy olyan cégnél ahol nem enged meg többet a büdzsé. Csak azt nem értem ,hogy akkor mégis mik a problémák, mert több helyen leírják hogy ipari használatra nem megfelelő, de azt sehol nem részletezik hogy miért ( zavar érzékeny?, nincs IP védettsége? nem bírja a poros környezetet? a kimenetei csak kis árammal terhelhetők amiknél az ipari szenzorok többet vesznek fel? stb... )
mert direkt egy prototípus eszköz. a benne levő atmel mikrovezérlő nagyonis elterjedt ipari felhasználásra. rengeteg ipari cuccban van benne, de sorozatgyártott termékhez nincs értelme a protóhoz kifejlesztett panelt használni, gyártanak olyan panelt ami az adott feladatra szükséges cuccokat tartalmazza csak.
Arra keresem a választ ,hogy az Arduino miért nem terjedt el ipari felhasználásban? Milyen kizáró tényezői vannak és ,hogy konkrétan mik a gyenge pontjai?
Első ránézésre, és még másodikra is alkalmasnak tűnik adatgyűjtésre és vezérlésre egyaránt, megfelelő burkolattal véleményem szerint ipari célokra is, ugyan akkor erre még nem láttam példát.
Induláskor az MCU minden lába nagy impedanciájú bemenet. Tehát a relé vezérlése lebegni fog, állapota a környezetből összeszedett zajtól függ. Ezért a vezérlő lábat földre vagy tápfeszültségre kell húzni egy közepesen erős (10-20 kOhm) ellenállással. Ezen keresztül nem fog számottevő áram folyni, viszont stabilan tartja a feszültségszintet, amíg az MCU el nem indul, és át nem kapcsolja az adott lábat kimenetnek.
Az, hogy nálad konkrétan mi kell, azon is múlik, hogy milyen a kapcsolásod (relé típusa, kapcsoló tranzisztor, ellenállás, védő dióda, stb), és mit szeretnél elérni (bekapcsoláskor fixen ki vagy be legyen kapcsolva).
Sziasztok!Az Arduino újraindulásakor miként lehet kiküszöbölni, hogy a kimeneteken ne engedjen ki jelt. Vagyis érthetőbben: egy áramszünet után egy arduinora kapcsolt relé ne kezdjen el ki-be kapcsolgatni, amíg újra nem indul teljesen.
Sziasztok. Van egy olyan problémám hogy mikor elkezdek nyomtatni,valamiért az első réteg után a z-tengely nagyobbat ugrik a kelletténél. Akármit csináltam,ujra raktam mindent meg megnéztem a firmwaret de nem yó.... A z-tengelynél hogy tudom átálitani azt hogy a stopper mikor érzékel és beáll alap helyzetbe és nyomtatási helyzet az extrudernek az asztal felett legyen 0.5-el? Lelyebb van az extruder feje mint az asztal és nem tud elindulni n yomtatásnál és csak darálja a muanyag lancot... :/
Félelmetes egyébként, hogy mennyire tudnak emberek súlyos tévútra menni és túlbonyolítani bizonyos dolgokat. Külföldi fúrumokon botlottam bele néhány képességeiben korlátozott emberbe, akinek az ötödik magyarázat után is csak az esett le, hogy valami nem stimmel, de az, amit mutatni próbáltam, nagyon nem. :-( Pedig rajzoltam is. :-D
Ha megnézed az első kódot, rájössz, hogy a két if--else páros szépen kiüti egymást bizonyos értékeknél, emiatt nem igazán úgy fog működni, ahogy elvárod.
if(DHT22.temperature < 28)
{
digitalWrite(HEATERRELAY, HIGH);
}
else
{
digitalWrite(HEATERRELAY, LOW);
}
if(DHT22.temperature > 31)
{
digitalWrite(HEATERRELAY, LOW);
}
else
{
digitalWrite(HEATERRELAY, HIGH);
}
Tegyük fel, hogy a kiolvasott hőmérséklet 29 fok. Első vizsgálat: kisebb, mint 28? Válasz: NEM, így az "else" megy tovább, tehát alacsony szintre húzza a lábat. Második vizsgálat: nagyobb, mint 31? Válasz: NEM, így itt is az "else" megy tovább, ami magasra húzza a lábat. Ezzel a 28-nál nem kevesebb (28-at is beleértve) és a 31-nél nem több (a 31-et is beleértve) minden kiolvasott értékre két egymást követő vizsgálat során két egymásal ellentétes parancs megy ki.
Nem ösmerjük a fűtés/párásítás hatékonyságát. Lehet, hogy 5 perc bekapcsolás elég arra, hogy 10 fokot emeljen a hőmérsékleten. A mintavételezés gyakorisága irreleváns, de az már nem, hogy milyen gyakori a beavatkozás (kattog-e másodpercenként a relé) vagy hogy felforraljuk-e szegény tekiket.
Nem fogok mélységesen belemenni, csak azt javaslom, kezdjük az alapoktól!
Ne a kódolással indíts, hanem a koncepció papírra vetésével. Mit mérsz? Hogyan méred, milyen pontossággal és milyen mintavételezési gyakorisággal? Mikor (milyen gyakorisággal) és hogyan avatkozol be? Milyen sűrűn akarod kiíratni az értékeket?
Mindezt papíron, lehetőleg. Aztán kezdd el felfedezni az eredeti kódot, átírni azokat a részeket, amelyek szükségesek ahhoz, hogy úgy működjön, ahogy azt elvárod. Egyszerre egy részbe túrj bele, és addig ne nyúlj hozzá másikhoz, amelddig az nem működik tökéletesen!
Hőmérséklet modellehézéshez a legjobb a potméter plusz egy LED (relé felesleges), zéró a késése és viszonylag precíz (legalábbis annyira, hogy érdemben ne befolyásolja a debug folyamatot). Egy általad említett nagy hőtehetetlenségű (óránként 1 celsius) rendszernél ilyen pokoli nagy hiszterézis mellett napokig tesztelhetnéd, hogy működik-e a kód, és ha nem működik, még akkor sem lenne világos, hogy miért nem.
A PID-et egyelőre nem javaslom. Tisztán elvi alapon nem más, mint az eredeti if() szakasz kicserélése egy sokkal szofisztikáltabb, if-ekből és else-ekből álló rendszerre. A sima if() nagyjából megfelel egy termosztátnak, a PID viszont nem csak azt figyeli, hogy az adott érték alatt vagy fölött van-e a vizsgált változó, hanem azt is, hogy az aktuális változó értéke éppen közelít vagy távolodik-e a beállított értéktől, illetve ezt milyen sebességgel teszi. A változás mértékétől és irányától függően, továbbá a korábban beállított vagy betanult paramétereknek (P, I, D attribútumok) megfelelően kapcsolja be és ki a fűtőszálta (illetve analóg PID esetén módosítja a fűtési teljesítményt).
Ha kódot küldesz, lehetőleg az egészet küldd, mert így átláthatatlan és értelmezhetetlen!
Esetleg ha mondjuk 10 perces delay-eket csinálnék és 10 percenként lenne mérési fázis, akkor elvileg működne így szerintem ...
pl bekapcsol a heater, 10 perc múlva mér újra, addig a heater megy, felfűt mondjuk 30 fokra, jön a következő mérés amikor már nem teljesül a függvénny...
if(DHT22.temperature < 28)
{
digitalWrite(HEATERRELAY, HIGH);
}
else
{
digitalWrite(HEATERRELAY, LOW);
}
tehát lekapcsolja a relét! Maga a doboz amiben lesz az egész, egy 10 centis hungarocellel szigetelt doboz, így a lehülés
nagyjából óránként 1 °C...tehát a relé nem kapcsolgatna sokszor...
