A tabulátor / "behúzások" mert így részben értelmezhetetlen melyik melyik if melyik case-el kezdődik és végződik logikailag melyik részek tartoznak egybe .

Sajnos a 3 mp várakozás miatt nem indul el a 2-es motor, ami az LM1_2 érintkező aktiválása után kellene oda vissza mennie 1x a 3 mp várakozási időban.

Hiányzanak a break utasítások!
switch / case statements

Vannak felesleges {}-jelezések helyette!???

Old meg másképp a várakozást: delay(3000); /*3 mp várakozás*/

Helyette alkalmazd a millis()
figyelését 1 ciklusban, közben elvégezheted a további teendőket.

Sima mikrokapcsoló a 10 kOhm ellenállással. A vezeték olya n 20 cm(dupont). Ami lemaradt az az, hogy egy L298-as panelt kapcsolgat az UNO.

Beírtam egy pár break utasítást remélem jó helyre és megpróbáltam a millis() függvényt is.Lehet az alapértéket nem jó helyen deklaráltam. Nincs valami tesztelő program kipróbálni, hogy ne kelljen annyiszor újraírni?

Hol? Mindenütt a delay függvényt használod.
Ha nem akarsz tápfesz felől érkező zavarokat akkor érdemes független áramkörről táplálni a motort és az arduinót. 20cm vezeték is lehet antenna .. persze lehet oda elég 1 1 pár nanós kondi is mint szűrő elem.

A millis() és micros() függvények egy változó értékét adják vissza amik minden 1 ms és 1 us időpontban 1el növelik az értéküket.(megszakításon keresztül ezért nem áll meg a uCben a program futása a delay() esetén minden áll addig amíg lenem telik az idő)
A millis() micros() esetén feltétel vizsgálatot kell végezni, hogy az előző érték amit vissza adott a függvény kisebb-e annyival mint amennyit időzíteni szeretnél érték.
Igaz ezek nem növekednek végtelenségig (32 bites változó) millis kb.: 50 nap után lesz 0 a micros pedig kb.: 70perc (órajel függő) múlva.Amolyan üzemóra/bekapcsolási idő mérő is lehetnek ezek a függvények.

Rajzold le mit szeretnél pontosan. Én vizuális típus vagyok... Akkor tudok segíteni, ha látom legalább mit szeretnél. Nem kell megijedni a szoftvertől, mert szinte mindent el lehet már a neten érni, sokan csak ollóznak a megírt szoftverekből, nem nulláról írják a működtető programokat sem.Ha a koncepciód világos - könnyebb megépíteni és leprogramozni is. Így kicsit még zavart érzek az erőben - de ez meg az én képességeimnek a határa...

Az arduino dugasztápról megy és a motor is külön tápról , ami az l298 panelbe van kötve. Ha csak az egyik motor oda-vissza van feltöltve akkor müködik minden.A gond a másik motor indulásánál jelentkezik.

Az elv:
Multi-tasking the Arduino - Part 1


Ezt végig olvasod! És próbálod átültetni a te alkalmazásodra.
Bővebben: Link

Ennél többet segíteni! Már csak ha megcsinálom helyeted?

Ezt már láttam, de valahogy nem azonos két led villogtatása és 2 dc motor forgásirány váltása és megállítása időre. Azért köszi.

Ha nem tudod végig olvasni?
A végén már két szervó motort mozgat felváltva!

Itt az időzítés elve a lényeg! Ha megfigyeled nincsen a programban egyetlen delay sem!

Ha kulcsrakész programot akarsz? Megegyezhetünk!

Igazán köszönöm,de a szóbeli válveregetésen kivül nem igazán tudom mit ajánhatnék fel 1 sor megírásáért. Azt gondoltam a segítség nyújtás öröméért is érdemes élni, igaz a semmit tevésbe sem halt még bele senki.

A gondom a kapcsolással hogy hogy 4db servot kellene működtetnem "pan, tilt, gobo, color"illetve kellene egy dimmer a led-hez, illetve ha már van benne strobi funkció akkor azt is viszont a program úgy van megírva, hogy 2db servo-t tud működtetni "pan, tilt" és 4db pwm kimenete van. Mivel nekem nem kell RGB LED-et hajtanom, ezért arra gondoltam, hogy egy-egy avr-el a pwm jellel működtetnék 1-1 servo-t "gobo, color" és így akkor meglenne a 4db servo a dimmer és a stobi is.

Az Arduino alapú fűtésvezérlés utolsó, a rendszer lefagyását okozó alkatrésze SSR relére lett kicserélve, ez kapcsolja a keringető szivattyúkat.
A cserével megszünt a rendszer lefagyása, az automata üzemmód működőképes, egy DLA 750i szünetmentessel kiegészülve már remélhetőleg biztonságosan.
Napjainkban az 1080 l-es puffer 3-4 napig biztosítja a ház hőntartását 60-70% induló töltéssel.

Gratula, megdolgoztál érte.
Elvi kérdés: a kánon szerint az Arduinoval készített különféle rendszerek (mérés, vezérlés, stb.) nem alkalmasak folyamatos, 24 órás üzemre.
Vajon miben más, miben több pl. egy PLC? Az miért üzembiztosabb? Milyen dolgokban más hardver ill. szoftver szempontjából?

Miféle kánon szerint? Ez egyébként butaság és talán a PLC gyártók találták ki.

Itt olvastam pl.

Én nem tudom megítélni a dolgot pro/kontra, nincs jogom pálcát törni senki felett, mert nem értek az elektronikához, de érdekel, így olvasgatok. És ez a dolog valahogy szöget ütött a fejembe.

Az kétségtelen, hogy a PLC-k mindenféle minősítéssl szoktak rendelkezni, az Arduino pedig nem.

A papír sok dolgot elbír. Nem egyszer olvastam már itt a fórumon is, hogy ilyen-olyan PLC lefagy. Az üzembiztosságot meg lehet oldani, csak akarat kérdése. teglascs linkelt fórumtémájában nincs olyan, amit ne lehetne teljesíteni. A PLC-k általában bolondbiztosak, de ezek teljesíthetőek kontroller esetén is, pláne, hogy a PLC-kben is tulajdonképpen mikrokontroller van.

Valószínűleg azért írnak ilyet, mert az Arduino-t hobbistáknak készítik, azok pedig általában azt sem tudják, mi az a stabil tápegység, a többiről már nem is beszélve (lásd pl. ezt: Bővebben: Link). Ha a kontroller programja stabil, biztosítva van a működéséhez szükséges környezet, miért ne mehetne non-stop üzemben? Eléggé sarkított kijelentés, értve ez alatt minden mikrokontrollert. Készítettem már több vezérlést, non-stop mennek (kivéve az áramszüneteket) gond nélkül.

Nem a tényleges üzembiztonságot tartom kritikusnak.
A PLC-k rendelkeznek bizonyos tanusítványokkal, hogy ilyen-olyan ipari környezetben garantált a működés. Az AVR uC önmagában nem rendelkezik ilyennel, az Arduino HW sem.
A PLC szállítója felelőssége vállal, hogy ha valamit megrervezel, a terv szerint fog működni.
Az Arduino IDE működésére nem fog a szállító felelősséget vállalni.
A mindenféle Arduino library készítője se vállalja majd a felelősséget, ha valakire rászakad a daru.

Hali!
Több "bonyolult" fűtésvezérlést csináltam már, de talán a legösszetettebb a 3 termosztát, 2 zónaszelep, 3 szivattyú, és 4 mérési bemenet, 1 motoros váltószelep, és 1 gázkazán számára biztosított potenciálfüggetlen kimenet. Mind relével, gondolkodtam az SSR-re való áttérésre, de ezek szerint nem jó ötlet. Persze az említett vezérlő 0-24-ben működik a fűtésszezon alatt, fagyogatás nélkül.

Nem a tanusítványokról van szó hanem arról, hogy egy mikrokontroller alkalmas-e non-stop üzemre. Erre pedig igen a válasz.

Én is így gondolnám. Ha a megfelelő működ(tet)ési környezet biztosítva van (azaz ha olyan szinten vannak kezelve a vezérlőchip igényei, mint u.ez egy PLC-ben), akkor elvileg az Arduino is működhet ugyanolyan megbízhatóan.
Nem tudom, van-e ilyen, de elvileg egy PLC-ben lehetne akár Atmel proci is, akkor meg az, hogy egy PLC-ről vagy egy Arduino lapka+egyebekről beszélünk, "CSAK" a körítés.

Arduino is tökéletesen alkalmas 24 órás üzemre. Csak sokan elfelejtik, hogy a fejlesztés nem csak abból áll, hogy megírom a kódot és kész. Erre lett kitalálva a debugWire és JTAG hogy lásd mit is csinál a kód és HW.
PLC semmivel sem megbízhatóbb, csak ott éppen a gyártó mérnökei x órát beleöltek a fejlesztőkörnyezetbe/FW és HW-be, hogy megbízhatóan működjön a rendszer. (Persze az más dolog, hogy én is láttam PLC lefagyni...) Ha te is belerakod a szükséges tudást, fejlesztési órát, még atomreaktor vezérlést is csinálhatsz arduinóval.

Csak úgy általánosságban bele vau-vau.

A cég, ahol dolgozok is használ többféle (Ab, Siemens, Omron) LC-ket. Vannak érdekes dolgok ezekkel is. Pláne, ha előjön egy jó kis FW hiba, amit alig akar a support elismerni.
Igen, a PLC talán kicsit stabilabb (eleve 24 órásra tervezett, átgondoltabb tápellátás, valamilyen zavar és túlfeszvédelem), de egy hardveresen megfelelően támogatott Arduino is lehet stabil.

Másfelől komoly dolgot nem bízunk programra (vészfékezés, vészstop, daru vészmegállítás). Persze vannak programozható "safety" PLC-k és "safety" relék, de ezeket is megfelelően kell bekötni a rendszerbe.
Minden legyen a maga helyén.

Sziasztok!
Az arduino uno-mban tönkre ment az atmega328(valami belső zárlat, mert melegszik, de működik). Vettem az ebayen egy olyat, amit úgy árultak, hogy rajta van a bootloader. Beleraktam, semmi. Két lehetőség van:vagy nincs rajta a bootloader, vagy rossz az mcu.
Mivel nincs programozóm, ezért megpróbáltam ezt a technikát. Addig eljutottam, hogy lecseréltem az atmega16u2 progiját, de az avr studiónál megakadtam. Amikor rányomok az apply-ra, ezt a hibaüzenetet dobja.

Sziasztok! Vettem egy esp8266-os wifi modult, de sehogy nem sikerül bele életet lehelnem. Nincs véletlenül valakinek egy működő libje, és példaprogija? Előre is köszi!

Azt inkább ne! Nemcsak az atomreaktornál, hanem minden olyan helyen (pl. járműipar, orvosi eszközök, egyéb ipari alkalmazások), ahol emberi élet vagy egyéb nagyértékű dolog sorsa függ a mikrovezérlő működésétől, szigorú követelményeket kell teljesítenie mind a hardvernek, mind a felhasznált szoftvernek. Lásd pl. itt, ott és emitt

Szia! Azért nem értem a problémád gyökerét, mert az Arduino egy filléres cucc. Láttam pár robotlámpát belülről. Ezeknek sokszor több címük is van, sőt több mikrokontroller dolgozik bennük. Ez neked nem megoldás? Akkor nem kell szöszölni - hajtasz 2-motort egy Arduinóról és 2 funkciónként felhasználsz egy címet és egy arduinót. Ez teljesen szokványos megoldás a DMX robotlámpáknál. Ha szeretsz vele kínlódni és nem maga a lámpaápítés a cél - az más tészta.