Fråga:
Kan en Arduino köra 24/7?
Butzke
2014-02-12 04:24:10 UTC
view on stackexchange narkive permalink

Jag gör en enkel Arduino-webbserver och vill hålla den påslagen hela tiden. Så det måste uthärda att fortsätta arbeta kontinuerligt.

Jag använder en Arduino Uno med Ethernet-sköld. Den drivs med en enkel strömförsörjning 5V @ 1A.

Mina frågor:

  • Kommer jag att ha några problem att låta Arduino vara påslagen hela tiden?
  • Finns det någon annan Arduino-styrelse som rekommenderas bättre för detta?
  • Finns det några försiktighetsåtgärder som jag måste beakta angående detta?
Första frågan!
** Moderator: ** vi verkar få många svar som säger att det fungerade i deras situation. Om du har något tekniskt att lägga till i frågan är du välkommen att svara. De tekniska svaren verkar dock täcka att det fungerar. Om du absolut * måste * ange att din situation fungerade, skulle det vara bättre att lägga till en kommentar.
Elva svar:
#1
+59
sachleen
2014-02-12 04:36:58 UTC
view on stackexchange narkive permalink

Du borde inte ha några problem med att hålla den på hela tiden, men en sak att tänka på är alla räknare du kan ha, som att använda millis () .

Från Arduino-dokumenten på millis:

Detta nummer kommer att rinna över (gå tillbaka till noll) efter cirka 50 dagar.

Så för projekt som pågår under långa perioder kanske du inte ser ett problem omedelbart, men något liknande kan dyka upp och orsaka fel på vägen.

För att vara exakt är millis en "uint32_t" -variabel, så den kommer att rinna över ("gå tillbaka till noll") på 4294967296 millisekunder, vilket är ~ 49,7 dagar, ~ 1193 timmar eller ~ 71582 minuter.
Allt du behöver göra är att använda en annan uint32_t som ökar när den första rullar över. Sedan kan du njuta av ungefär 5,846 × 10 ^ 8 år mellan övergångarna.
Mycket av tiden är mills () rollover inte riktigt ett problem eftersom människor tenderar att använda millis () är ett relativt sätt. De tar skillnaden mellan två millis () samtal, eller så tar de en starttid och kontrollerar om millis () är större än start + tid. Aritmetisk rollover och millis () rollover avbryts ofta så att time2-time1 är korrekt även om det finns en rollover mellan dem, så länge det inte finns två rollovers. Om din kod använder absoluta millis () -värden kan den ofta omformuleras för att använda relativ millis () -logik.
om du gör millis () - startTime (med starttiden som en osignerad lång, aka uint32_t) får du alltid ett giltigt resultat om inte mer än ett överflöde händer
För att vara mer exakt, sker överflödet efter 49 dagar, 17 timmar, 2 minuter, 47 sekunder och 295 millisekunder.
Millis () -flödet ** behöver aldrig ** vara ett problem. Se [millis () overflow ... a bad thing?] (Http://www.gammon.com.au/millis) för mer information. I grund och botten om du beräknar tidsintervall genom att subtrahera, med hjälp av lämpliga datatyper, kommer du aldrig att ha ett problem.
Även om man inte använder 'millis' direkt undrar jag om man kan vara säker på att inget av de importerade biblioteken gör det.
#2
+33
Matthew G.
2014-02-12 04:40:23 UTC
view on stackexchange narkive permalink

Ett par saker att tänka på (utanför @ Sachleens omnämnande av millis () ):

  • Som alla elektronik kan värme vara störande. Mikrokontrollen i sig kommer sannolikt inte att bli en enorm fråga ur värmeperspektivet, men andra komponenter som strömförsörjningen kan orsaka problem.

  • Om din kod använder EEPROM.write () , tänk på att EEPROM i din Unos ATmega328P bara är klassad för 100 000 skrivningar.

#3
+12
TheDoctor
2014-02-12 04:54:56 UTC
view on stackexchange narkive permalink

Tänk på att blixt och EEPROM har begränsade livstider (cirka 10 000 respektive 100 000 skrivcykler), så om du skriver mycket till dem kan de bli skadade. I ett test som jag gjorde tog en extern EEPROM ungefär tre dagar att börja bli skadad.

Medan dokumentationen kan lista 10 000 cykler, har många tester visat att ~ 100 000 är där problemen börjar uppstå.
EEPROM-livslängden är minst 100 000 skrivcykler enligt databladet. Jag tror att jag minns att jag läste ett test där korruption började på nära en miljon skrivningar.
#4
+10
JVarhol
2014-02-12 04:47:08 UTC
view on stackexchange narkive permalink

Att köra Arduino 24/7 Bör inte vara ett problem.

Men se till att du har ett fodral som möjliggör ventilation och att du förvarar det i ett väl ventilerat område. Precis som datorer, om du inte håller dem i en miljö som kan hålla dem svala, kommer de inte att vara svala.

Serverbelastning bör också vara en sak att tänka på, ju mer belastning det finns på servern desto mer bearbetning måste den göra och desto mer värme kommer den att generera.

ATmega har inte traditionella lägen med låg effekt som vanliga datorer, så belastningen är irrelevant. Om du inte gör aktiv beräkning är det bara snurrväntan. Strömförbrukningen när du kör är faktiskt ganska mycket statisk (förutom saker som att skriva till EEPROM / blixt), åtminstone för ATmega MCU. Det kan finnas variationer i Ethernet-gränssnittseffekten som bestäms av trafikbelastning, men ingenting kommer sannolikt att generera tillräckligt med värme för att vara ett problem om det inte är i ett perfekt vakuum eller på en värmare eller något.
[Atmega328p] (http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf) har låg effekt viloläge som drar ~ 0,1 uA.
Vilket bara skulle vara relevant om koden faktiskt sätter processorn i viloläge.
#5
+8
sdcharle
2014-07-17 20:08:02 UTC
view on stackexchange narkive permalink

Vi har kört vårt Arduino-baserade RFID-åtkomstsystem på Bloominglabs Hackerspace i Bloomington IN sedan slutet av 2011 och förutom ett par strömavbrott och programuppdateringar går det dygnet runt, inga problem. På senare tid har vi lagt till en nätverkstermostat, samma affär - den går dygnet runt.

Jag har också ett RFID-åtkomstsystem som körs 24/7. Den enda gången det "misslyckas" är om strömmen går av, eftersom den går från elnätet. Detta har pågått sedan 2011 utan problem.
Haha, hey Steve!
@NickGammon Ja, ditt system är coolt, men varför är inte autentisering baserad på kortdata, utan bara token UID? Snälla visa oss en smart lösning.
vad är din poäng? det är inte relaterat till affischens fråga.
#6
+6
Manishearth
2014-02-12 04:50:23 UTC
view on stackexchange narkive permalink

Arduinos kan köras utan problem under riktigt lång tid, men beroende på lokala förhållanden och beräkningsintensiteten kan du behöva ansluta kylflänsar.

Håll den också väl ventilerad.

Det beror också på vilket program som används, om din server serverar en sida då och då borde det inte vara ett problem, men om du förväntar dig konstant trafik kan Arduino värmas upp snabbt.

Du vill också säkerställa strömförsörjningens stabilitet, när du kör experiment på bänkskivor med en Arduino är detta inte ett stort problem, det kan bli ett problem om du omvandlar ström från elnätet för en permanent armatur. / p>

Det finns ingen anledning att förvänta sig att beräkningsbelastningen får en Arduino att överhettas. Som har påpekats i de mer faktabaserade svaren är det ** normala ** fallet att köra med full belastning. Om det finns en komponent som kan överhettas kommer det att vara spänningsregulatorn, men det är främst en funktion av ingångsspänningen, eftersom den redan körs med nästan den högsta förväntade strömmen när du inte gör något.
@ChrisStratton en Ethernet-skärm kan variera beroende på användning. Arduino kan också vara i ett lågeffektläge (till exempel sova mellan 00:00 och 05:00).
#7
+4
Steven10172
2014-02-12 07:48:43 UTC
view on stackexchange narkive permalink

Jag har aldrig kört en Arduino så länge, men det borde inte vara något problem. En sak att se upp för är ingångsspänningen.

Medan en Arduino kan hantera 7-20v som ingång kan allt över 12v överhettas efter längre perioder och orsaka skador på kortet. Som en snabb rekommendation för att undvika överhettning av Arduino skulle jag hålla spänningen så nära 7v som möjligt.

#8
+4
EternityForest
2014-04-04 12:08:21 UTC
view on stackexchange narkive permalink

Jag vill nämna ett problem som inte kommer upp så ofta men kan orsaka långsiktiga problem. Minnesläckor och högfragmentering. Nästan ingen mallocs i inbäddade saker, men om du gör det, gör det rätt.

Du slog mig, +1.
Jag tror att strängklassen använder malloc och det är ganska vanligt.
Kommit överens. Speciellt med en webbserver, se till att du inte gör något som kan fragmentera minnet, som att använda strängklassen. Men det är lätt att undvika det. Jag har en Arduino som webbserver för att meddela mig om min garageport är stängd. Det har pågått i flera år.
#9
+4
TimboTinkerer
2014-04-07 01:13:32 UTC
view on stackexchange narkive permalink

Jag byggde en enkel strömmonitor med min första Arduino. Den drivs via USB från en webbserver som i sin tur drivs via en ganska stor batteribackup (som inte har aviseringar).

Den är också ansluten till en mobiltelefonladdare som är ansluten till en icke -UPS eluttag.

Så om strömmen dör skickar Arduino ett meddelande till ett litet program som körs på servern. Serverprogrammet skickar i sin tur ett e-postmeddelande.

Det installerades i slutet av september 2013, den 23 mars 2014 - jag fick min första e-post!

Så jag har inte sett ett problem (det använder inte millis ()) men det samplar strömmen var 5: e sekund.

#10
+1
next-hack
2017-09-02 21:53:46 UTC
view on stackexchange narkive permalink

Kan en Arduino köra 24/7?

Detta är en tillförlitlighetsfråga. Tillförlitligheten finns det många saker att tänka på.

  1. Programvaran. Det finns mer robusta programvaror. Det finns mindre robusta programvaror. Till exempel för kritiska applikationer avråds dynamisk minnesallokering, eftersom det kan leda till minnesfragmentering. Tyvärr är Arduino starkt beroende av dynamisk minnesallokering. Detta problem förvärras eftersom de flesta av Arduino-kortet har ett mycket begränsat RAM-minne.
  2. Biblioteken. Många Arduino-bibliotek har buggar (även den inbyggda i Arduino-paketet, så enkelt som WString!). I normal drift kanske sådana buggar inte visas alls. Du kan dock inte hoppas att "allt kommer att bli bra" och att "användaren" (eller delsystemet) kommer att fungera som förutsagt. Bibliotek kan också ha sina gränser (dvs. inte ordentligt fel). Till exempel har många användare redan citerat themillis () -funktionen, som återställs efter 50 dagar. Detta, om det inte hanteras på rätt sätt, kan leda till allvarliga buggar.
  3. Hårdvarans tillförlitlighet (inte ens prata om billiga Arduino-kloner ...). Här öppnas en ny klass av underfrågor. Jag kommer bara att citera en mycket begränsad delmängd.
    • Är Arduino-korten utformade för tillförlitlighet? (t.ex. vad är pålitligheten hos de använda kondensatorerna? och andra komponenter?)
    • Robusthet mot EMI? Jag skulle inte förlita mig på det: de flesta Arduino-kort har bara två lager och brist på ett ordentligt jord / kraftplan.
    • EEPROM (det här är både mjukvara och hårdvara). Använder din programvara EEPROM? Implementerar någon algoritm för att förhindra cykling (upprepad skrivning / radering på samma celler)?
    • Retentionstid för flashminne. Retentionstiden minskar med temperaturen och även med antalet programmeringscykler.
    • Joniserande strålning. Ja, även om sannolikheten är MYCKET låg, åtminstone vid havsnivå, är sannolikheten för strålningsinducerad enstaka händelse upprörd inte noll, och det bör vidtas adekvata motåtgärder (särskilt med tanke på att RAM inte har någon hårdvarufel upptäckt ) i kritiska applikationer.
    • Strömförsörjningens kvalitet.
    • Driftsmiljön. En 25- ° C-kontrollerad miljö eller i en svart låda över taket (70 ° C under solen på sommaren)? Ju högre temperatur desto snabbare blir alla nedbrytningsmekanismer.
    • ...

Ändå borde du inte bli förvånad om din arduino kommer att fungera felfritt i många år. Men detta säkerställer inte att varje arduino kommer att göra det.

Vissa motåtgärder ökar tillförlitligheten:

  • Använd vakthunden: det är bättre att återställa ett system som inte reagerar, än att ha ett fast / felaktigt.
  • Undvik att använda något bibliotek som använder minnestilldelning.
  • Implementera (om du använder EEPROM) en algoritm för att bevara den!
  • Bra strömförsörjning.
  • Undvik hårda miljöer (hög temperatur, hög luftfuktighet, stora och kontinuerliga termiska cykler osv.).
#11
  0
user2497
2017-11-05 02:34:11 UTC
view on stackexchange narkive permalink

Det kan verkligen köras 24/7. Antingen använder jag 5V ​​till 5V-stiftet eller en 7808 till Vin-stiftet för att ladda ner vreg. Helst skulle det vara 6,5 ​​V, men jag har inte sådana leveranser. Du kanske vill ha ett frikopplingslock på 5V för att suga upp alla mindre spikar när du slår på strömförsörjningen.

Alla anslutna hårdvaror som körs vid 5V matar jag med en 7805. Du kan använda LM317s eller LM350s istället för av 78XX, men du behöver några motstånd för dem, kanske trimpoter.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...