Blocchi improvvisi arduino Mega

Buongiorno,
vengo subito al mio problema premettendo che ho pensato che dovesse essere esposto in questa sezione e chiedo venia se ho pensato male.
Ho creato un 'sistema' che prevede l'utilizzo di Arduino Mega 2560 Rev3 + Ethernet Shield w5100.
Ai pin settati come input viene segnalato se una serie di interruttori a cui sono collegati son on o off.
La segnalazione avviene ad intervalli di 60 secondi. Arduino invia questi 'stati' tramite un GET ad un file php il quale provvede ad elaborarli ed a impostare di conseguenza una serie di variabili con valore 0 o 1. Arduino legge questi valori ed a seconda che siano 0 o 1 aziona o meno dei relè. Tutto questo avviene, ripeto, ogni 60 secondi. Il funzionamento è ottimale ed il sistema esegue ciò per cui è stato predisposto (per questo credo che non sia un problema di software) ma ogni tanto (e possono essere 6 ore come 3 giorni) il sistema si blocca e riparte solo se resetto Arduino. Premetto che ho provveduto dall'inizio ad 'azare' i pin 4, 10 e 53 (forse alzare il 10 non serve a nulla visto che sto usando un Mega)... forse che sono da 'alzare' anche altri PIN? O forse la RAM di Arduino va in overflow perchè ci sono un paio di println()? Io posso anche togliere i println() (in realtà non servono a nulla per ciò che devo ottenere) ma se fosse questo il problema perchè Arduino non si blocca ad intervalli regolari? Confesso che il Mega è originale mentre la ethernet no ed ho già provveduto ad ordinarne una tale e che mi deve arrivare a giorni: forse è dovuto alla non originalità della ethernet il problema?
Spero di essermi spiegato in maniera esaustiva e grazie a chi ha avuto la pazienza di leggermi fino a qua.

Il tuo è un annoso problema...

forse alzare il 10 non serve a nulla visto che sto usando un Mega

Si, stai usando una mega, ma la Ethernet Shield usa il pin 10, come Chip Select

il settaggio iniziale corretto è

pinMode(SS_PIN, OUTPUT); // pin 53. Anche se non usato va impostato come uscita
digitalWrite(SS_PIN, HIGH);
pinMode(10, OUTPUT);
digitalWrite(10, HIGH);
pinMode(4, OUTPUT);
digitalWrite(4, HIGH);

forse la RAM di Arduino va in overflow perchè ci sono un paio di println()?

Non sono certamente un paio di println() che saturano la ram, semmai è l'uso di String.

Quello che dovresti cercare di capire è se a piantarsi è la Shield Ethernet o Arduino

Grazie per la risposta Brunello.
Vedendo ciò che mi hai scritto mi viene un dubbio...
Il settaggio che mi hai proposto è:

pinMode(SS_PIN, OUTPUT); // pin 53. Anche se non usato va impostato come uscita
digitalWrite(SS_PIN, HIGH);
pinMode(10, OUTPUT);
digitalWrite(10, HIGH);
pinMode(4, OUTPUT);
digitalWrite(4, HIGH);

In realtà io ho settato così:

pinMode(4, OUTPUT); //Il pin 4 è di tipo OUTPUT
digitalWrite(4, HIGH); //Scrivi HIGH nel pin 4
pinMode(10, OUTPUT); //Il pin 10 è di tipo OUTPUT
digitalWrite(10, HIGH); //Scrivi HIGH nel pin 10
pinMode(53, OUTPUT); //Il pin 53 è di tipo OUTPUT
digitalWrite(53, HIGH); //Scrivi HIGH nel pin 53

cioè, invece di scrivere SS_PIN ho scritto direttamente 53: forse è lì l'errore o le due scritture sono equivalenti?

Un'altra informazione, se può essere utile.
Dopo l'ultimo blocco, non ho resettato arduino, ma staccato e poi ricollegato alla shield il cavo di rete ed è ripartito tutto. Questo significa che era la shield bloccata? E' possibile che il solo scollegare e ricollegare il cavo di rete alla ethernet la resetti? Scusa se forse ti faccio domande stupide, ma ormai le sto pensando tutte...

cioè, invece di scrivere SS_PIN ho scritto direttamente 53: forse è lì l'errore o le due scritture sono equivalenti?

è la stessa cosa

E' possibile che il solo scollegare e ricollegare il cavo di rete alla ethernet la resetti?

Non mi pare.
Non è che hai anche qualche problema con il router ?

Brunello:
Non mi pare.
Non è che hai anche qualche problema con il router ?

Bella domanda, in effetti il router non è mio, mi spiego meglio: il 'marchingegno' controlla le luci di un circolo privato ed io non gestisco il loro router: io mi sono limitato a far assegnare un ip statico alla shield ma non saprei come verificare se è il router a scatenare il problema. Mi viene da pensare che se è la ethernet ad impallarsi mentre Arduino continua ad essere 'vigile' potrei resettarlo con watch dog quando l'intervallo di tempo tra due connessioni supera per esempio i 180 secondi... ma devo verificare se quando il sistema si blocca Arduino rimane 'sveglio'...

orse alzare il 10 non serve a nulla visto che sto usando un Mega

E' proprio il 10 che usi e non il 53
il 4 serve se usi la SD altrimenti nemmeno quello serve.

pinMode(53, OUTPUT); //Il pin 53 è di tipo OUTPUT
digitalWrite(53, HIGH); //Scrivi HIGH nel pin 53

pinMode(SS_PIN, OUTPUT); // pin 53. Anche se non usato va impostato come uscita
chi l'ha detto?
digitalWrite(SS_PIN, HIGH);

sono linee inutili

Probabilmente hai problemi software, ma lo sketch non c'è quindi .....

arduino legge questi valori ed a seconda che siano 0 o 1 aziona o meno dei relè.

ecco questo può essere la causa 99%

pablos:
Probabilmente hai problemi software, ma lo sketch non c'è quindi .....
ecco questo può essere la causa 99%

Se per problemi di software intendi problemi a livello di codice php (magari invio ad arduino di qualche dato strano che non sia nè 0 nè 1) mi domando perchè funziona per giorni interi per poi bloccarsi improvvisamente; tra l'altro il php è impostato in modo tale che in caso di valori che non siano nè 0 nè 1 il valore ritornato è fissato a 0.
Ora però mi sorge una domanda:
supponiamo che arduino lanci il file php inviandogli i dati opportuni con il famoso GET (sto facendo una descrizione brutale ma spero di farmi intendere)... fino qua è come da prassi... supponiamo però che all'interno del php per una combinazione particolare (e per un errore di programma relativo a quella situazione) il php dia errore e si blocchi senza dare risposta... in questo caso Arduino sta un po' in attesa per poi riprendere il controllo e tentare un nuovo invio dati (continuando a non ricevere rispsta) o rimane bloccato in attesa di una risposta che non arriverà mai?
Io stamani ho provato ad impostare questa soluzione nel caso che sia la ethernet ad impallarsi e non arduino:
siccome ho visto che con un reset ricomincia a funzionare tutto, ho supposto che se è la ethernet a bloccarsi o comunque il php a non dare risposte Arduino riprenda comunque il controllo e riesegua il loop.
Come prima istruzione all'interno del loop ho messo un if che nel caso che siano passati più di 5 minuti dall'ultima connessione avvenuta arduino venga resettato tramite watchdog. E' chiaro che tutto può funzionare solo se non è Arduino a bloccarsi e se dopo un certo intervallo di attesa riprende il controllo.

Credo pablos intenda dirti che il problema potrebbe essere causato dai rele' :wink:

Arduino non ama particolarmente i carichi induttivi ... gia anche se usano un loro alimentatore separato, il semplice far passare i fili vicini puo creare problemi e causare blocchi, se poi usano lo stesso alimentatore e/o sono nello stesso contenitore, magari vicini, allora qualche problema e' quasi garantito ...

Arduino sta un po' in attesa per poi riprendere il controllo e tentare un nuovo invio dati (continuando a non ricevere rispsta) o rimane bloccato in attesa di una risposta che non arriverà mai?

Questa è una bella domanda.

In prima istanza ti dico che se avviene qualche tipo di errore nella comunicazione la ethernet crea parecchi fastidi, utilizzando essa l'SPI del micro temporaneamente se tutto va bene viene liberato e il micro continua per la sua strada, il wiznet in realtà ha un suo timeout mi sembra di 30/60 sec, però ho notato che non sempre libera il micro, il che sarebbe anche abbastanza ovvio visto che il CS lo governa il micro.
Ad esempio, se stacchi il cavo di rete mentre c'è uno scambio dati l'wiznet tiene bloccato il micro per 30 sec e poi tutto riprende regolarmente, se ci sono errori di dati dove l'wiz non è in grado di rispondere a volte non resuscita più.
Che poi il micro non va in blocco in realtà, rimane solo impegnato con la periferica SPI, basterebbe intervenire sul CS in questi casi (riportandolo HIGH) per "staccare" il micro dalla sua shield che l'ha incatenato.

Ma nel tuo caso io tenterei di verificare il tutto senza carichi da comandare prima di dare la colpa al php o alla scheda di rete.
Bisognerebbe studiare tutti i singoli casi e ottimizzare il software con un controllo errori più specifici, ma sono casi rari ed errori gravi sporadici. un reset automatico in caso di blocco ci sta anche bene, ma deve intervenire proprio se c'è la fine del mondo, non ogni volta che ti connetti.
Insomma sarebbe utile che il micro vedesse che qualcosa non è andato a buon fine e abbandonasse la periferica, qualche volta il processo si trova in una parte di codice che lo fa e altre no.

Vi ringrazio tanto per gli spunti davvero interessanti che mi state dando.
Effettuo delle verifiche e nel frattempo attendo "con ansia" il prossimo blocco
per potermi confrontare con voi con nuovi dati o magari il riavvio che ho impostato
funziona ed anche se per vie traverse magari il problema può considerarsi risolto (un reset
ogni qualche giorno penso possa essere accettabile: tra l'altro se dovesse esserci questo
fantomatico riavvio ho fatto in modo che mi arrivi una e-mail che mi avvisi del fatto).
Posterò sicuramente gli sviluppi.

Buongiorno,
il sistema ieri sera si è bloccato nuovamente dopo molti giorni di perfetto funzionamento. Come precedentemente scritto, avevo aggiunto alcuni blocchi nel loop del .ino per far sì che, nel caso fosse stata la ethernet a bloccarsi e nella speranza che prima o poi avesse ripassato il controllo al micro, questi, preso atto che dall'ultima connessione era passato un intervallo di tempo maggiore di un valore fissato, provvedesse ad un riavvio automatico tramite watchdog, ma così non è stato il che mi induce a pensare che il sistema micro+ethernet si blocca nel suo complesso (specifico che il watchdog nel mega 2560 originale funziona, l'ho verificato). Ora, visto che mi è arrivata, ho provveduto a sostituire la ethernet non originale che c'era con una ethernet2 originale che mi è arrivata da un paio di giorni. Vediamo se questo può essere la soluzione del problema.
P.S. Nota di colore: la ethernet2 originale è proprio bella ed accuratamente ben fatta, nulla a che vedere con le schede non originali.

Aspettate,
mi viene in mente che, per come l'ho scritto, il watchdog non poteva funzionare.
Vedo di riscrivere il programma in modo corretto.

Buongiorno a tutti.
Ho una domanda da porvi:
è possibile che la scheda ethernet anche se ha settato un ip statico lo perda improvvisamente magari per problemi dovuti al router o similia?
Ho fatto un paio di prove:
ho fatto partire il micro facendogli stampare sul serial monitor il suo ip.
Poi dopo un po' di connessioni ho staccato il cavo ethernet dalla shield.
Chiaramente ha cominciato a comunicarmi 'connessione fallita' continuando a stampare il proprio ip (che rimane tale se non c'è un reset chiaramente)...
Poi dopo un certo intervallo di tempo di 'connessioni fallite' ho provocato tramite watchdog un riavvio del micro (sempre a cavo ethernet staccato)...
A questo punto mi è comparso sul serial monitor come IP il valore 0.0.0.0 come chiaramente doveva essere essendo il cavo staccato.
Ho riconnesso il cavo ethernet ma l'IP è rimasto 0.0.0.0 (in effetti quello che è stato assegnato alla scheda in fase di settaggio, penso che sul monitor venga stampato 0.0.0.0 ma in realtà l'IP non esista proprio).
Questa situazione è andata avanti fino a quando non ho resettato manualmente il micro a cavo ethernet attaccato, a quel punto tutto è ripartito.
Poi ho fatto una nuova prova cambiando il fatto che nel programma ho chiesto che ad ogni tentativo di connessione in caso di 'non ip' intervenisse un watchdog che provocasse un riavvio ed in questo caso è bastato riattaccare il cavo ethernet per fare ripartire il tutto.
Morale della favola: mi è venuto da pensare che, non so per quale ragione, la scheda perda improvvisamente il proprio IP il che provoca una serie infinita di connessioni 'a vuoto' a meno che il sistema non venga riavviato e per questo mi è venuto da domandare:
è possibile che la scheda perda improvvisamente il proprio IP anche se settata con un ip statico?

è possibile che la scheda perda improvvisamente il proprio IP anche se settata con un ip statico?

No, la scheda non perde l'IP statico, ne con parametri di impostazione sbagliati, ne con cavo di rete assente, ne resettandolo, ne togliendo alimentazione

Ci faresti vedere il setup, secondo me stai usando il DHCP come IP

Hai perfettamente ragione Pablos, il fatto è che stavo facendo delle prove in casa (dove uso dhcp e con settaggio da dhcp) e chiaramente quando staccavo il cavo e resettavo, a cavo staccato, dava ip=0.0.0.0... poi ho messo un ip statico e chiaramente anche a cavo staccato mi dava l'ip statico impostato ne settaggio...
ora invece mi è venuta in mente un'altra possibile soluzione (che chiaramente devo pensare se è relizzabile): usare due client, uno che effettua le connessioni per avere informazioni se eccitare o meno i relè, l'altro che parallelamente va ad interrogare una pagina php che controlla se il database si sta aggiornando o meno... nel caso il database non si stia aggiornando faccio effettuare un riavvio tramite watchdog... nel caso invece la scheda abbia smesso di connettersi, dopo un certo numero di connessioni fallite faccio ugualmente effettuare un riavvio sempre tramite watchdog: secondo me infatti i blocchi sono dovuti o a connesioni fallite continuate (non chiedetemi perchè) o perchè la scheda si connette ma comunque non riesce a scrivere nel database. Vi ringrazio anticipatamente se dite la vostra al riguardo.

Dovresti farci capire meglio come è strutturarto il progetto

Hai un server in casa?
E' un host remoto?
il DB dove si trova su un sistema apache? il php che fa?
cosa scrivi sul database?
Cosa funziona ogni tanto e cosa no?
si inchioda tutto? o non risponde il server?
il server risponde ma non scrive sul DB?

Dovresti togliere pezzi di codice invece di aggiungerli e verificare a step dove è il problema

la butto li, non si sa mai.

quando ci sono comportamenti strani
bisogna anche considerare le alimentazioni
se non sono proprio stabili, se arrivano disturbi
e' facile che il micro vada in reset, o peggio
mostri comportamenti anomali

Buonasera a tutti,
vi dovevo delle risposte non fossaltro per la gentilezza ed i suggerimenti preziosi che mi avete dato in questi post.
Tutte le domande che ha posto Pablos sono più che legittime e ben poste per avere un minimo di indizi al fine di capire perchè il sistema si comporta in una certa maniera.
L'host è remoto, il micro ogni 60 secondi chiama un file php inviandogli lo stato degli interruttori che deve controllare (invia 1 se lo stato è on, 0 se lo stato è off). Il php riceve i dati, li elabora confrontandoli con una striga che importa da una pagina che risponde ad un link predefinito e stampa un vettore di variabili (io lo chiamo vettore commutazioni) che possono assumere valore 1 o 0: il micro legge le variabili (ognuna che fa riferimento ad un relè) e quando questa ha valore 1 eccita il relè che fa scattare l'interruttore corrispondente (se è off lo commuta in on e viceversa).
A me in realtà se gli interruttori scattano con uno o due minuti di ritardo interessa relativamente, l'importante è che il sistema non si blocchi del tutto. Ho cercato di avere un approccio ingegneristico per la soluzione del problema ossia: mi interessa scoprire perchè e come improvvisamente si blocca o fare in modo che, a meno di rotture, non si blocchi più? Ho concluso che a me interessava la seconda che ho scritto. Quindi ho supposto che il sistema non si bloccasse completamente ma che, non so per quale ragione, ogni tanto ed improvvisamente, si impallasse sì ma con il micro che continuava comunque a contare almeno il suo tempo di funzionamente (il millis() per intenderci): dato che nei casi di blocco bastava resettarlo per far ripartire tutto se fossi riuscito ad usare il watchdog in maniera opportuna probabilmente non avrei scongiurato i blocchi ma comunque avrei procurato un riavvio automatico in caso degli stessi. E così ho fatto e devo dire che ad oggi di blocchi ce ne sono stati ma anche i subitanei riavvii che hanno fatto sì che il sistema non si è più ribloccato per più di 10 minuti (e solo 2 volte). Dalle osservazioni che ho fatto e dalle informazioni che mi sono giunte via e-mail e db (nel db viene segnata ogni connessione e l'ora in cui avviene, inoltre nel caso di db 'statico' (che non si aggiorna quindi sistema in blocco) o riavvio mi arrivano mail distinte) ho comunque dedotto che nel posto in cui è montato il sistema la connessione di rete non è per nulla ottimale: ci sono giorni in cui il sistema si connette spaccando il secondo e giorni in cui è come se fosse molto rallentato (ed in tal caso il watchdog entra in azione spesso)... è capito qualche volta che la rete (suppongo) è mancata per più di 5/6 minuti ma nel frattempo il watchdog ha fatto il suo lavoro e non appena è tornata il db ha riiniziato ad essere aggiornato. Dico 'il watchdog ha fatto il suo lavoro' perchè a questo punto la domanda che mi sorge è: è possibile che in caso di non connessioni al client ripetute (per mancanza di rete per esempio) micro+scheda non riuscissero più ad effettuare la connessione sebbene fosse 'tornata' la rete dopo qualche minuto?
Inoltre, siccome nelle giornate di 'connessioni lente causa poca rete' il dispositivo si riavvia anche 10/15 volte, quersto lo potrebbe danneggiare?