next topic »

[Reply #30 on:]

Dipende.
Metti che lui abbia questa pressa con cui si voglia contare i il numero dei pezzi prodotti.
Una volta finita la serie il contatore viene azzerato.

Se come ha detto lui

Può esere che lavori per 5 giorni di fila e che poi rimanga ferma per altrettati.Producendo in 8 ore da 500 a 2500Pz

possiamo stimare che in un mese produca fino anche 7500 pezzi avremo su una cella la durata di 100'000/7500 = 13.3 mesi, poco più di un anno.
Se cicliamo la scrittura sulla roma interna di Arduino esso durerà (con 2 contatori a 32 bit) 1024/8*1.11 = 142 anni.
Se poi mettiamo la eeprom i2c da 256Kb credo che finisca prima il mondo del contatore.
Quindi ritengo inutile la SD a meno che non voglia creare delle statistiche più complete includendo anche data e ora dei pezzi fabbricati (ma questa potrebbe essere vista come violazione alla legge 300 del '70 riguardo il controllo sulle attività lavorative - anche la pressa ha i suoi diritti).  

[Reply #31 on:]

Una domanda.... siete tutti a pensare come ottimizzare le scritture sulla EEPROM... ma.. rocco: ha pensato anche che questa EEPROM va svuotata perché con 1024 byte e basta non ci scrivi nulla, se la frequenza è di qualche scrittura al secondo?

In che senso svuotata?
Trascriverla su un'altra eeprom per continuare a contare?

Non ho capito perché non dovrebbe scrivere?? 
La scrittura impiega 3,3 ms a byte e ne deve scrivere 4 per un contatore a 32bit. Ne ha dei tempo tra una scrittura e l'altra.

Svuotata del suo contenuto... 1024 byte, mettiamo a 4 byte per blocco, sono 256 scritture.
Poi inizia a perdere le registrazioni, a meno che qualcuno non svuoti la EEPROM su un altro supporto. E lui dice che fa da 500 a 2500 pezzi in 8 ore, quindi potrebbe benissimo darsi che in 1 ora l'abbia già riempita.

[Reply #32 on:]

Leo, da quello che ho capito io a lui serve un semplice contatore su display LCD dei pezzi prodotti dalla pressa.
La memoria gli serve in modo che, se spegne tutto e torna il giorno dopo, il contatore riprende da dove aveva lasciato.
Poi quando cambia pezzo credo che azzeri e ricomincia a contare.
Non credo che gli serva, per il codice che aveva scritto inizialmente, salvare data ora e numero di pezzi creati.
Comunque questo potrà dircelo lui.
Al massimo si fa un upgrade del codice per usare una SD.  (ma stiamo correndo troppo in avanti)

[Reply #33 on:]

Se è solo la memorizzazione di un contatore giornaliero, la EEPROM interna gli basta ed avanza per tante scritture, concordo.
Eventualmente mette un supercondensatore come backup di emergenza per avere quei decimi di secondo di autonomia necessaria a salvare il dato sulla EEPROM nel caso vada improvvisamente via la tensione di rete.

[Reply #34 on:]

Ciao scuate ma oggi sono stato un po preso in altro.Io direi che va piu che bene cosi.L'unica cosa che mi viene in mente è che potrebbe essere utile sapere il tempo trascorso.Quindi per esempio utilizzare la riga in alto per un orologio.Ho bisogno di acquistare un modulo esterno di real time clock?

[Reply #35 on:]

Dipende dalla precisione che vuoi ottenere.
Puoi usare un RTC software tipo la swRTC di Leo oppure un RTC hardware che potrebbe avere il vantaggio di mantenere data e ora con una batteria esterna; quello più diffuso è il DS1307.

[Reply #36 on:]

Trattandosi di contare qualche decine di ore al massimo, quello software è abbastanza preciso?

[Reply #37 on:]

Si, se ti serve la risoluzione del secondo per contare il tempo trascorso dall'ultimo reset.

[Reply #38 on:]

In questi giorni ho fatto delle prove montandolo sulla macchina, ma se volessi impostare un numero di pezzi a cui arrivare e poi attivare un uscita per accendere un led o un rele per spegnere la macchina, in modo da non dare all'operatore la possibilità di sbagliare quantità, sarebbe possibile farlo programmandolo tramite dei pulsanti esterni senza dover settare la quantità tramite sketch per esempio.Scusate ma spero di essere riusciuto a spiegarmi...

[Reply #39 on:]

se volessi impostare un numero di pezzi a cui arrivare e poi attivare un uscita per accendere un led o un rele per spegnere la macchina, in modo da non dare all'operatore la possibilità di sbagliare quantità, sarebbe possibile farlo programmandolo tramite dei pulsanti esterni senza dover settare la quantità tramite sketch per esempio.Scusate ma spero di essere riusciuto a spiegarmi...

Puoi farlo, ti servirà però un display o quant'altro per poter interagire con l'utente per fargli inserire il numero di pezzi a cui fermarsi.

[Reply #40 on:]

Dico forse una fesseria, correggetemi se sbaglio, i cicli di scrittura per cui le EEPROM sono garantiti dai vari fabricanti sono circa 100000 e se dopo questi si pianta, è possibile solo la lettura (che è a quanto sembra, quasi eterna o almeno, per 20 o più anni), ma se non ricordo male, i 100000 cicli sono per singolo byte dell' EEPROM, quindi se ne avessimo una da 1024 bytes (come quella interna) ed il nostro blocco dati fosse di 4 byte, salveremo => 1024/4=256 blocchi dati per ogni ciclo di riempimento dell' EEPROM,  quindi i 100000 cicli per byte dell' EEPROM ci garantirebbero 25600000 (25 milioni 600 mila) blocchi registrati, ad una cadenza di 1 sec a blocco, per un'ipotetico 176 ore lavorative al mese (5gg x 8 h e 1 x 4 h a settimana = 24 gg lavorativi) finirebbe... la macchina, prima dell' EEPROM!!    circa 404 mesi = 36,7 anni lavorando 11 mesi l'anno (un po di ferie se le meriterà o no? )  quindi ad 1 sec. sono d'accordo che sarebbe più che sufficiente come capienza, ma visto che deve portare un conteggio pezzi, non sarebbe meglio che registrasse ad operazione avvenuta?  se faccio 2500 pezzi al giorno, farà 2500 salvataggi di blocchi e non 8 h x 3600 sec = 28800 salvataggi, no? anche prevedendo che di quei 100K cicli siano effettivamente la metà (eh si, avvolte capita che vanno in errore, mi è capitato con quelle dei codici delle ECU stradali, e le devi buttare) comunque la durata sarebbe ben oltre le aspettative della vita produttiva sella macchina in questione!
L'idea della batteria tampone o del condensatore per garantire un backup momentaneo e ottima per questo tipo di applicazione secondo me, aggiunge pochissimi costi in cambio di un'aumentata sicurezza in caso di problemi di tensione.

[Reply #41 on:]

problema: dove memorizzi il luogo dove hai memorizzato il dato?
In oltre non credo che lavori a blocchi di 1byte ma a blocchi un pò più grandi, ma potrei essere smentito.

[Reply #42 on:]

Se usa una batteria tampone, elimina del tutto il problema della EEPROM e della sua durata, visto che ci scriverà solo nel caso in cui il micro si accorga che è venuta meno l'alimentazione principale e salvi i dati per sicurezza.
Normalmente poi, terrà tutto in RAM.

[Reply #43 on:]

anche io approvo l'idea di Leo72, con le giuste funzioni di sleep e una normale batteria tieni in vita l'atmega per anni

[Reply #44 on:]

L'idea della batteria tampone piace anche a me, facilita il compito, ma ho qualche dubbio, e se ci fossere sbalzi di tensione che provocassero il reset del micro?  io ho fatto in passato qualche applicazione a microprocessore su autovetture, e in uno riscontrai un problema che ad oggi, non sono sicuro di aver risolto (l'auto in questione ora è ferma da 2 anni), mi si cancellava la flash del micro (Picaxe 18x) eppure avevo un regolatore di tensione L7805 con i canonici 4 condensatori (2 elettrolitici e 2 ceramici) messi come raccomandato da schemi elettrici), quindi considerando che nel mio caso fu un'avviamento difficoltoso a far accadere il problema, (ma si sa, le auto sono piene di Noise EMI) quindi il mio dubbio è, lavorare con l'alimentazione di rete opportunamente ridotta alla tensione di lavoro dell' Arduino mediante trasformatore o altro, la presenza della batteria tampone garantirà che in presenza di interferenze EMI o di alte frequenze in tensione in ingresso si resetti il micro? e se ciò accadesse, i dati in RAM andrebbero perduti?  Quindi come suggerisce Leo, vi dovrà comunque salvare in EEPROM i dati, magari si potrebbe fare a fine giornata lavorativa o dopo un certo periodo di inattività? così anche in eventuale reset, i dati persi sarebbero di qualche 1/2 giornata al massimo.
Hai ragione Lesto, avevo dimenticato l'indirizzamento, magari lo si potrebbe mettere sempre alle prime locazioni, quelle necessarie per indirizzare da 0000 a 1024 (quindi 2 byte no?) voi siete più bravi in questo, a voi la parola!!