Apparato Focardi-Rossi

[SGF]

Ciao "SGF"
Grazie per la disponibilità, appena sarai riuscito ad assemblare l'apparato sperimentale, dovremmo proprio fare i test che ti ho proposto. Tieni conto che lo spazio di cui avrei bisogno, all'interno della "camera di reazione" è piuttosto limitato [11*37*4mm - ho lasciato un minimo di franco]

Lo spazio nel reattore e di 10 x 25 cm.

Gli LM35 sono simpatici, ma il package non è proprio il massimo se devi misurare la temperatura di liquidi... In ogni caso, se li vorrai usare basta collegarli agli ingressi 0-5 ausiliari

Gli inerisco dentro dei tubetti metallici e sigillati con resina.
Quindi che si fa? Compro un arduino, e ci resta solo da sviluppare il circuito di condizionamento della TC ?

Rampa, stai costruendo un tubo per raggi X ?

[rampa]

...
Rampa, stai costruendo un tubo per raggi X ?

Quelli sono sotto vuoto, questi possono avere 1-2 Atm di H2...
L'idea sarebbe di farne una trentina, fissarli su un tavolato appeso ad una parete e filmarli con una videocamera RI, ripeto, ad 1 ft/Min.
Sarà sufficiente provocare delle scariche elettriche a varie intensità e potenziale... e vedere di nascosto che effetto che fa...
La prova termica sarebbe comunque compresa in questa....

[Quantum Leap]

Ciao SGF e complimenti per la costanza dei tuoi test,

pur tenendo presente limitazioni di ordine economico, ti consiglio, per le tue acquisizioni, di rivolgerti a hardware National Instruments e software in ambiente LabView.
Puoi trovare combinazioni interessanti e certamente economiche nel mondo dell'usato.
Hanno praticamente tutto per l'acquisizione e l'analisi dei dati, quindi anche relativamente al condizionamento delle termocoppie.

Se riesci a mettere su un sistema di misura e analisi che sia stabile e 'robusto', le misure saranno certamente più sicure, più pulite e riproducibili.

In bocca al lupo e vai avanti.

[BEPO]

Se vi serve un softwarista "ignorante"...

Salve a tutti, è il mio primo post in questo forum e la prima cosa che vorrei dire anche a nome di tutti coloro che vi hanno letto è un "grazie" sentito. Quale che sia la convinzione che chi legge ha (bufala o rivoluzione) avete reso e state rendendo un enorme servizio di divulgazione a chi pur ignorante nello specifico ha voglia di capire e magari sperare...

Finita la sviolinata iniziale vorrei anche dirvi che credevo di essere io messo male in quanto a virus del DIY (nota di moderazione: DIY = Do It Yourself = Fai da te. Quando si mette una sigla nuova per i più, occorre spiegarne il significato. nll), ma vedo che c'e' chi mi batte ampiamente di diversi ordini di grandezza: io mi limito al quadricottero radiocomandato con telecamera wireless costruito con la "scusa" di ispezionare lo stato delle tegole del tetto di casa; mai pensato di costuire un reattore nucleare in garage...

... pero' l'idea non è male, devo dire.

Venendo a qualcosa di più concreto direi che se per il progetto vi serve la competenza di uno sviluppatore software che attualmente si occupa di architetture distribuite ma con un passato pesante nei sistemi di controllo di processo industriale, io sono qui...

Se posso dare un minimo di contributo fin da subito avrei da fare qualche considerazione:

1. Scelta della piattaforma per il sistema di acquisizione e controllo
Concordo pienamente con la scelta di una piattaforma tipo Arduino (btw lo sapevate che il progetto Arduino è tutto italiano ? Arduino - Wikipedia, the free encyclopedia http://arduino.apogeolab.it/); nello specifico sarebbe l'ideale ArduinoMega (Arduino - ArduinoBoardMega2560) con fino a 16 ingressi analogici e 54 I/O digitali (di cui 14 usabili per generare PWM da cui generare altrettanti segnali analogici in uscita).
2. Architettura HW di massima
Già è stato detto correttamente da altri: l'architettura di massima dovrebbe comprendere una scheda dedicata al condizionamento "grossolano" dei segnali in ingresso (si è parlato di op-amp, differenziali, ecc... - non è dominio mio; la parte analogica la lascio a chi la conosce bene). Io a questo aggiungerei che ci dovrebbero essere nel sistema almeno altre tre componenti (vedi schema allegato):
- la scheda di elaborazione/comunicazione con il PC (Arduino)
- una scheda "speculare" a quella di acquisizione per il comando di attuatori
- un modulo opzionale di data storage locale (flash) per un eventuale funzionamento off-line dal pc o per registrare sequenze di dati a velocità piu' alta di quella con cui si puo' comunicare via USB con il pc.

3. Organizzazione del firmware
La mia proposta sarebbe quella di realizzare un sitema essenzialmente di acquisizione/controllo con il minimo di intelligenza possibile, vedendolo come un mero esecutore, delegando ad un software piu' facilmente gestibile lato pc il compito di prendere decisioni "strategiche" circa il funzionamnento del pentolone (es la preparazione del processo di svolgimento di un test). Lascierei al firmware solo compiti di I/O (linearizzazione, taratura, ecc..) e l'implementazione di eventuali sicurezze attive (sovrapressioni, sovratemperature, ecc..).
4. Software su PC
Il software sul pc dovrebbe essere in grado di salvare in tempo reale (e in modo affidabile visti i precedenti di "dati persi") la stream di informazioni provenienti dalla scheda acquisizione, agendo di conseguenza con "comandi" di ritorno sulla base di una ricetta precostruita.
5. Licensing...
E' assolutamente vero che non è improponibile chiedere a F&R di licenziare in stile wiki (o meglio open software/open hardware), ma nessuno vieta di fare lo stesso per un progetto come quello di cui si sta farneticando qui...
Secondo me, se mai si arrivera' a qualcosa di concreto dovra' essere sotto una qualche licenza open (GPLv3, CreativeCommons, ...).

Mi scuso per la prolissità del post, ma proprio non ho potuto trattenermi .

In qualsiasi modo, grazie ancora per avermi fatto capire qualcosa di piu'...

[GabriChan]

Ciao SGF credo che i prezzi siano purtroppo in sterline però se ordini nel carrello lo correggono in €.

[Vettore]

Ciao Bepo, benvenuto.

1. Scelta della piattaforma per il sistema di acquisizione e controllo
Concordo pienamente con la scelta di una piattaforma tipo Arduino

Visto che è stato proposto da più parti, mi accodo: in fondo ha dei vantaggi in termini di riproducibilità. Anche io del resto pensavo di usare un ATMega. L'avere come riferimento una scheda "standard" facilita sicuramente la progettazione e la condivisione dei moduli periferici.

2. Architettura HW di massima
[...]
- la scheda di elaborazione/comunicazione con il PC (Arduino)

Credo che qualche versione di Arduino abbia già una interfaccia con il PC, seriale o USB (FT232). Si eviterebbe di doverla costruire...

- una scheda "speculare" a quella di acquisizione per il comando di attuatori

Si, serve una scheda con qualche relè per il comando delle resistenze e eventualmente delle valvole.

- un modulo opzionale di data storage locale (flash) per un eventuale funzionamento off-line dal pc o per registrare sequenze di dati a velocità piu' alta di quella con cui si puo' comunicare via USB con il pc.

Lo eviterei: complica il firmware e alla fine un PC serve sempre, soprattutto se fa girare il software id controllo dell'esperimento. In fondo un portatilino tipo netbook è più che sufficiente.

3. Organizzazione del firmware
[...]

D'accordo al 100%. La vedevo anch'io così.

4. Software su PC
Il software sul pc dovrebbe essere in grado di salvare in tempo reale (e in modo affidabile visti i precedenti di "dati persi") la stream di informazioni provenienti dalla scheda acquisizione, agendo di conseguenza con "comandi" di ritorno sulla base di una ricetta precostruita.

Si, esatto. Da questo punto di vista posso fornire routine già pronte o qualche dritta per una comunicazione robusta se serve.

5. Licensing...
[...]
Secondo me, se mai si arrivera' a qualcosa di concreto dovra' essere sotto una qualche licenza open (GPLv3, CreativeCommons, ...).

Ma a cosa ti riferisci?
Riguardo al sistema di acquisizione o ai suoi pezzi si può fare... ma non mi sembra un punto essenziale.
Riguardo ad eventuali scoperte sulle reazioni la faccenda sarebbe più delicata: non ha senso parlare di licenze, non è roba copyrightabile. O è di pubblico dominio o lo si tiene riservato in qualche modo (più in là farò qualche considerazione filosofica sull'opportunità di rivelare eventuali scoperte o meno), non ci sono comunque vie di mezzo secondo me.

Ah, una cosa: costo di Arduino più periferiche. Non è detto che venga a costare meno di un sistemino di acquisizione base di National Instruments, che come di Quantum Leap darebbe maggiori garanzie (non solo sostanziali ma anche formali).

x SGF:
se si usa Arduino, vi posterò gli schemi dei circuiti periferici da collegargli.
Riguardo l'LM35 il problema è che se lo metti in un tubetto i piedini possono cortocircuitarsi accidentalmente (succede purtroppo...) oppure se decidi di metterci qualche isolante, tipo silicone, si riduce di molto la consicibilità termica che in gran parte passa proprio dai piedini. Comunque, costa poco ed è facile da usare, quindi non abbandonerei l'idea.

x Piolos
Riduardo al riscaldamento con il laser, io avrei una buona alternativa: utilizzare direttamente un arco elettrico per scaldare il materiale. Il vantaggio sarebbe che il riscaldamento sarebbe dato da ioni accelerati che urtano il campione: due effetti in uno! Del resto i laser che riscaldano sono moooolto costosi e impegnativi da usare...

[SGF]

Quantum Leap Ciao SGF e complimenti per la costanza dei tuoi test,

Ti ringrazio per i complimenti e i consigli. Purtroppo ogni tanto dovrò rispolverare la valigia per questioni di lavoro, quindi la costanza è condizionata.

Quelli sono sotto vuoto, questi possono avere 1-2 Atm di H2...
L'idea sarebbe di farne una trentina, fissarli su un tavolato appeso ad una parete e filmarli con una videocamera RI, ripeto, ad 1 ft/Min.
Sarà sufficiente provocare delle scariche elettriche a varie intensità e potenziale... e vedere di nascosto che effetto che fa...
La prova termica sarebbe comunque compresa in questa....

Mi sembra una buona idea, si potrebbe usare vetreria da lab. chimico.

E' assolutamente vero che non è improponibile chiedere a F&R di licenziare in stile wiki (o meglio open software/open hardware), ma nessuno vieta di fare lo stesso per un progetto come quello di cui si sta farneticando qui...
Secondo me, se mai si arrivera' a qualcosa di concreto dovra' essere sotto una qualche licenza open (GPLv3, CreativeCommons, ...).

Intanto benvenuto, Non ho ben capito cosa dobbiamo licenziare....
Bene bene, vuoi far parte del team dei programmatori, dividendoci il lavoro la cosa si fa più leggera per tutti.

se si usa Arduino, vi posterò gli schemi dei circuiti periferici da collegargli.
Riguardo l'LM35 il problema è che se lo metti in un tubetto i piedini possono cortocircuitarsi accidentalmente (succede purtroppo...) oppure se decidi di metterci qualche isolante, tipo silicone, si riduce di molto la consicibilità termica che in gran parte passa proprio dai piedini. Comunque, costa poco ed è facile da usare, quindi non abbandonerei l'idea.

Mi prendi per uno stolto...? :-)

Se siamo d'accordo sul da farsi, odino arduino mega!? ( ma non doveva essere un prodotto italiano? su Ebay provenienza Hong kong, Singapore, Australia, Canada, in italia niente...

LabWiev professiona costa solo 5 Euri....strano una cosa che costa poco.

Non conosco la velocità di acquisizione di arduino, ma penso sia possibile inserire direttamente una routin di conteggio per la sonda geiger

[Alexf17]

LabWiev professiona costa solo 5 Euri....strano una cosa che costa poco.

colto da irrefrenabile curiosità son andato a googlare un pò, se ho ben capito si parla di € 5.000,00; (se preso una cantonata colossale autorizzo sin da ora chi può a cancellare questo mio messaggio)

[BEPO]

Ciao Bepo, benvenuto.

Grazie del benvenuto!

Credo che qualche versione di Arduino abbia già una interfaccia con il PC, seriale o USB (FT232). Si eviterebbe di doverla costruire...

Esatto. In linea di massima tutti hanno un intefaccia usb o un connettore standard a cui connettere un adattatore USB/seriale (tipicamente un FTDI).

Lo eviterei: complica il firmware e alla fine un PC serve sempre, soprattutto se fa girare il software id controllo dell'esperimento. In fondo un portatilino tipo netbook è più che sufficiente.

Sono abbastanza d'accordo, ma ne avevo fatto cenno non sapendo che genere di misure potrebbero essere necessarie, in caso ce ne siano che generano quantità elevate di dati che è più veloce salvare localmente che inviare via seriale/usb; se non serve tanto meglio, risulta tutto più semplice.

Ma a cosa ti riferisci?
Riguardo al sistema di acquisizione o ai suoi pezzi si può fare... ma non mi sembra un punto essenziale.
Riguardo ad eventuali scoperte sulle reazioni la faccenda sarebbe più delicata: non ha senso parlare di licenze, non è roba copyrightabile. O è di pubblico dominio o lo si tiene riservato in qualche modo (più in là farò qualche considerazione filosofica sull'opportunità di rivelare eventuali scoperte o meno), non ci sono comunque vie di mezzo secondo me.

La mia era una considerazione di approccio generale. Personalmente credo fermamente nel modello open in tutto (software, hardware, progettazione, ecc...) per il semplice fatto che se tutto è pubblico e verificabile chiunque, anche dalle ceneri di un progetto morto, fallimentare o indirizzato verso fini diversi da quelli originali, è in grado di estrapolarne il buono e partire da quello per migliorare (nel mondo dell'open source si parla di "fork" di un progetto in questo caso).
Quello che volevo dire, magari non avendi esperesso bene la cosa, è che se tutto il progetto nella sua parte realizzativa meccanica/elettronica/software è ben documentata, pubblicamente accessibile, non soggetta a vincoli di copyright e riproducibile, se anche non funzionasse un accidente, magari qualcun altro potrebbe basarsi su quello per tirarne fuori qualcosa di buono. L'adozione per documentazione, disegni, schemi circuitali e software di uno schema di licensing open source lascia libero chiunque di usare quei documenti liberamente, obbligandolo a sua volta a rilasciare i propri con lo stesso schema di licensing e citare la fonte originale.

Ah, una cosa: costo di Arduino più periferiche. Non è detto che venga a costare meno di un sistemino di acquisizione base di National Instruments, che come di Quantum Leap darebbe maggiori garanzie (non solo sostanziali ma anche formali).

Sono perfettamente d'accordo che un "sistemino" di acquisizione di National da' maggiori garanzie e vorrei anche vedere! Pero' pur non conoscendo i costi, immagino che siano ordini di grandezza superiori a quelli di un "sistemino" Arduino-based.
Per quello che riguarda i costi di Arduino, a seconda delle configurazioni si va dai 30 ai 60 euro (Futura Elettronica-Home Page) se acquistati in italia, e dai 18 ai 40 usd se negli usa (News - SparkFun Electronics). Oltre a quello va considerato il costo di un alimentatore di buona qualità abbondandemente sovradimensionato per evitare rogne (20-30 euro) e il costo di un adeguato contenitore (qualche euro). Quello che è difficile stimare è il costo delle schede di acquisizione e attuatori: dipende enormemente da che cosa devono fare queste schede e dalla qualità della componentistica che serve...

[SGF]

Ciao BladeRunner, Beh...lo sappiamo dall'inizio di questa discussione...e il ritardo di 6 mesi da un mese

Signori...ho tagliato la testa al toro, Arduino mega in arrivo e 74 euro in partenza....4/5 giorni e arriva (anche sé o acquistato in Italia...e di colore azzurro e di sembianze paro paro a quelli cinesi...mumble mumble....
Vettore se mi confermi l'uso del ina126 né ordino subito qualcuno.

Ho scaricato L'editor di programmazione di arduino, ma che linguaggio è? sembra molto semplice ma non ci ho capito gran che, devo ancora sintonizzarmi.

colto da irrefrenabile curiosità son andato a googlare un pò, se ho ben capito si parla di € 5.000,00; (se preso una cantonata colossale autorizzo sin da ora chi può a cancellare questo mio messaggio)

No, stava fregando anche me, quando ho visto 4,835 euro ho dovuto bere un po' d'acqua per riprendermi, ma informandomi bene ho capito che erano 4,centesimi di euro...

Citazione:
Originariamente scritto da Vettore
Lo eviterei: complica il firmware e alla fine un PC serve sempre, soprattutto se fa girare il software id controllo dell'esperimento. In fondo un portatilino tipo netbook è più che sufficiente.

Sono abbastanza d'accordo, ma ne avevo fatto cenno non sapendo che genere di misure potrebbero essere necessarie, in caso ce ne siano che generano quantità elevate di dati che è più veloce salvare localmente che inviare via seriale/usb; se non serve tanto meglio, risulta tutto più semplice.

Qualora si renda necessario, ho appena visto un blocco di istruzioni che permettono il dataloger su scheda SD controllata direttamente da arduino con il PC off line. Un altro problema in meno.

[Galileo]

Fate come volete ragazzi, Io però punterei su una schedina CPU con connettori(comprata) da agganciare a scheda con analogica e potenza costruita da noi. A bordo scheda CPU microcontrollore 16Bit con 128Kb flash memoria programma, 8 kb flash boot, 8kB data flash (si usa come una EEPROM) e 8 kb data ram tutto on chip!. Compilatore gratis dalla casa fino a 64Kb. Pensavo firmware scritto in C opensource.
Ma soprattutto è già disponibile gratis freeware dalla casa(freescale) software PC e firmware per CPU che ti permette di monitorare in tempo reale, tramite cavo seriale, ogni variabile del firmware SENZA SCRIVERE UNA RIGA DI SOFTWARE!! (con triggers e tempi di campionamento dati programmabili in tempo reale)
Un'altra piccola chicca: si aggiorna il fimware direttamente dal cavo seriale. Il programma di caricamento automatico è già fornito dalla casa.
Per la precisione delle temperature non impazzirei (+/-1°..2° ?) visto che lo scopo è ottenere rese ben oltre l'unità!
saluti

[SGF]

Ma scusa, ad eccezione del software del pc che sara LabWiev, non stiamo facendo quello che di dici tu?
Per la precisione, se raggiungiamo 5% sara già troppo.

[BEPO]

x Galileo
Come ti ha già risposto SGF la soluzione ipotizzata è proprio del tipo che descrivi tu, basata sulla piattaforma Arduino

x SGF
Ho paura che sul PC non sarà fattibile l'uso di LabView della National visto che la versione Base costa 1312 euro e quella developer 4948...

La mia idea era di sviluppare lato PC una applicazione ad hoc che abbia fondamentalmente le seguenti funzionalità di base.

1. Configurazione e taratura sensori e attuatori

• range di funzionamento
• linearizzazioni
• fattori di conversione
• precisione
• ecc...

Avendo magari la possibilità di definire magari più profili diversi di taratura alternativi.

2. Definizione di parametri derivati
Dai valori letti dai sensori si potrebbero facilmente derivare dei parametri calcolati (con calcoli semplici ovviamente) quali

• valori on/off generati applicando una isteresi
• combinazioni lineari e non tra valori diversi
• valori statistici quali media e varianza
• ecc..

Il senso di tali parametri non lo intendo come finalizzato ad una analisi dei risultati dei test, in quanto tale analisi è sensato farla dopo l'acquisizione dei dati "grezzi" dei sensori direttamente sul pc; piuttosto lo intendo funzionale alla identificazione di comportamenti anomali a cui far seguire un eventuale allarme (vedi punto seguente). Come per i profili di taratura anche le definizioni dei parametri derivati potrebbero essere piu di una.

3. Definizione degli allarmi
Sulla base dei valori letti dai sensori e/o dei valori derivati, dovrebbe essere possibile definire degli allarmi (es sovratemperature, sovrapressioni, ecc..) a cui poter eventualmente asociare anche l'azione da intraprendere in caso l'allarme venga attivato: dal semplice warning, fino al limite allo shutdown forzato del sistema. Come per i punti precedenti le definizioni di allarmi ed eventuali azioni di emergenza possono essere molteplici (diversi profili di sicurezza possibili)

4. Definizione della "ricetta"
Con questa funzionalità si dovrebbe poter definire il comportamento richiesto al sistema attraverso un qualche strumento di definizione e modellazione del ciclo di funzionamento. A mio parere il modo migliore per programmare il sistema cosi' come lo si prevede è quello di definire un FSA (Finite States Automaton o Automa a Stati Finiti - Finite-state machine - Wikipedia, the free encyclopedia). In pratica ogni stato dell'automa corrisponderebbe ad una specifica configurazione dei valori in uscita degli attuatori, mentre le transizioni di stato sarebbero triggerate dai valori letti dai sensori e/o dai parametri derivati ed eventualmente da opportuni timer software (transizioni temporizzate). La ricetta di un determinato test dovrebbe contenere

• un profilo di taratura dei sensori
• una definizione di parametri derivati
• una definizione di allarmi
• un automa

5. Esecuzione del test
Questo sarebbe il vero cuore del software, almeno dal punto di vista del funzionamento, ma di fatto si dovrebbe "solamente" occupare di prendere tutti gli ingredienti della ricetta, metterli insieme e "far girare" l'automa che descrive il test ovviamente registrando istante per istante tutti i dati provenienti dai sensori e visualizzandoli anche a video nel frattempo.

[Vettore]

Mi prendi per uno stolto...? :-)

No, affatto! E' solo che il problema che ho descritto l'ho visto succedere diverse volte. Un LM35 comunque dovrà essere montato sulla scheda delle termocoppie perchè servirà per la compensazione dei giunti freddi.

Non conosco la velocità di acquisizione di arduino, ma penso sia possibile inserire direttamente una routin di conteggio per la sonda geiger

La velocità di acquisizione analogica si aggira sui 10-15KHz, quella digitale (da utilizzare per il Geiger) può essere molto più elevata. Il micro ha dei contatori dedicati tra l'altro, non è neanche necessario implementarli in software.

Vettore se mi confermi l'uso del ina126 né ordino subito qualcuno.

Si può usare, ma sto valutanto un'altra possibilità (tra l'altro anche più economica) che consentirebbe di avere un segnale meno rumoroso e valido su quasi tutto il range di temperatura della termocoppia.

x Bepo
Ok, ho capito a cosa ti riferivi quando parlavi di licenze. Però per come la vedo io comunque sono sofismi pressocchè inutili in relazione alle leggi italiane in materia di proprietà intellettuale (in altre parole: una licenza su cose del genere non vale niente).

x Galileo
Se facciamo le cose bene possiamo arrivare a 0.1°C col sistema "artigianale".

[Galileo]

Si SGF è quasi uguale. Ho usato per anni ed ho progetti in produzione con ATmega ma vi assicuro che come potenzialità, facilita di debug e periferiche questi CPU/DSP sono una bomba.
Dal lato Pc non vorrei sviluppare un'h visto che ho sviluppato software a PC e so il tempo che ci vuole per farli bene soprattutto per il fatto che esiste già fatto e bellissimo e freeware.
Per darvi l'idea delle potenzialità che offre: in seriale e possibile ottenere il campionamento di una o più variabile/i ai microsecondi che si vuole con trigger su ciò che su cambio di stato di altre variabili (si include nell interrupt base tempi la routine da loro fornita ed è tutto fatto) vi allego qualche figura..
P.S. non sono un venditore di componenti elettronici o rappresentante di qualcosa ma un modesto prog.

[piolos]

quesiti vari!

rif. VETTORE n. 903
quando parli di laser che scaldano a cosa ti riferisci esattamente, mi potresti fare un esempio (costano mooolto, ma qual'è l'ordine di grandezza?).
Il discorso laser è semplicemente una verifica per capire se può essere un sistema di trigger della "reazione Ni-H" ad applicare allle mie lamine di Ni.
Ovviamente ritengo che la strada migliore sia quella del adsorbimento/assorbimento di H (superficie, difetti, vacanze reticolari del metallo) realizzato in una camera di reazione in cui venga immesso idrogeno a relativamente alta pressione (modulabile), con temperature di alcuni centinaia di gradi in modo che Ni - da buon catalizzatore -scinda la molecola H2 e si carichi di H.
Vediamo come procede il lavoro di "SGF" per la preparazione del reattore e del set-up di controllo e poi spero di poterlo testare con una delle mie piastrine!

ciao e buon lavoro
Piolos

[SGF]

Piolos, Temo che i tempi non saranno tanto brevi, ma se vogliamo qualcosa di serio.....

Una volta scritto il codice, per farlo girare LabWiev non serve, mi sembra di aver capito che ce una applicazione free che permette al codice di girare. In tal caso se conosciamo qualcuno che ne è in posseso....

Galileo, Quel programma e solo per i grafici ?

Bepo, non è un po pesante doversi inventare tutto software di sana pianta nei termini in qui lo hai esposto?

[Galileo]

x SGF il programma permette di salvare dati che arrivano sulla seriale in realtime su file testo per eventuale elaborazione su fogli di calcolo. Permette di esportare immagini bmp, jpg..etc dei grafici fatti. Permette di leggere con la cadenza che vuoi ms, sec, minuti, le variabili che vuoi anche contemporaneamente. Permette ci manipolare la variabile che aqrriva in realtime e mostrarla nella sua nuva codifica: per esempio mi arriva un 16 bit dato lo moltiplico per 0,987654 e gli sommo 32 etc.
Permette la scalatura automatica degli assi X,Y o manuale. Fa lo scrolling automatico del grafico man mano arrivano dati.
Permette di modificare ogni variabile del firmware scritto.

[Vettore]

rif. VETTORE n. 903
quando parli di laser che scaldano a cosa ti riferisci esattamente, mi potresti fare un esempio (costano mooolto, ma qual'è l'ordine di grandezza?).

Un laser a CO2 costa decine di migliaia di euro (non ho numeri precisi, ma dai 10 ai 50 a spanne a seconda delle dimensioni), quelli NdYAG più o meno pure, altri più esotici anche centinaia di migliaia di euro...

Il discorso laser è semplicemente una verifica per capire se può essere un sistema di trigger della "reazione Ni-H" ad applicare allle mie lamine di Ni.

Sembrerebbe di si (viene citato mi pare sia nel brevetto di Rossi ed in quello di Piantelli), però non è che il laser abbia qualche proprietà particolare in se: è solo un modo pratico in certe situazioni di trasmettere e concentrare energia. In realtà da diverse fonti viene fuori che quello che innesca queste reazioni sono le condizioni di "non equilibrio" (variazioni e gradienti di pressione, temperatura e forse anche campo elettrico e magnetico).

[GabriChan]

Ciao Galileo che protocollo usa il software per comunicare con la seriale, perchè si potrebbe implementare anche su arduino, il ho scitto un software per una applicazione simile che usava il MODBUS RTU su RS232

[Galileo]

Protocollo di somunicazione

Ciao GabriChan, ti allego un file pdf che lo descrive. Io non l'ho mai controllato/modificato. Dal software su PC (Freemaster) si carica il file simbolico (nome.elf) che genera il compilatore C contenente tutte le variabili dimensione, indirizzo etc. Si scelgono su PC le variabili che si voglino visualizzare/modificare etc.
Si capisce quindi che il compito tuo/nostro resta solo quello di scrivere il firmware per la macchina che ci interessa e non per altro.

[SGF]

Non ho capito da dove devo scaricarlo?

[Galileo]

protocollo freemaster

Ciao,
In allegato un progetto con sorgenti C del protocollo freemaster come generato automaticamente dal compilatore C freescale Codewarrior per micro MC56F8345.
Il progetto e solo un main() nel file "test.c" vuoto con in interrupt a 10Khz, file "event.c" entro cui è chiamata la routine di campionamento dati.
Ci si puo collegare direttamente con il software da PC Freemaster con la scheda in esame... da comperare costruire.
Io ne ho di varie tipologie ma sono schede di progetti che abbiamo in produzione (settore industriale).
(Cerca e scarica Freemaster dal sito freescale)

[Vettore]

Circuito di condizionamento per termocoppie K

Vi allego il circuito per il condizionamento dei segnali delle termocoppie K. Considerando le caratteristiche del sistema di acquisizione, questo circuito risulta il più semplice possibile, il meno costoso, ed ha prestazioni potenzialmente molto buone (soprattutto per le temperature che ci interessano). Come si può vedere non è necessario utilizzare un amplificatore per strumentazione, basta un opamp semplice ed economico ma dalle buone qualità come il MCP6001 di Microchip. I componenti R4 e C1 sono opzionali (servono per filtrare il rumore captato dai fili della termocoppia) ed i loro valori non sono critici. In qualche misura questo vale pure per R3 e C2. I resistori R2 ed R1 che determinano il guadano dovrebbero essere con tolleranza dell'1%. Il circuito è alimentato a 5V (niente tensioni duali) e fornisce un'uscita che può variare da 0 a 5V (0V corrisponde alla temperatura ambiente, 5V a circa 1200°C in più). La dipendenza dalla temperatura ambiente è data dal fatto che la termocoppia misura la differenza di temperatura tra la sua "giunzione calda" (la punta) e la "giunzione fredda" (i morsetti della termocoppia). Per questo motivo serve misurare anche la temperatura ambiente assoluta, cosa che viene fatta con un LM35 che dovrebbe essere posto in contatto termico o comunque vicino ai mordetti. Se si vogliono utilizzare più termocoppie basta un solo LM35.

[SGF]

Bene, semplicissimo, visto che non abbiamo regolazioni sull'hardware nel software del pc dobbiamo prevedere un sistema di taratura su due punti, uno alto e uno basso, equazione della retta. Idem per cip dell' arduino, per adattare l'lm35.

[Vettore]

Bene, semplicissimo, visto che non abbiamo regolazioni sull'hardware nel software del pc dobbiamo prevedere un sistema di taratura su due punti, uno alto e uno basso, equazione della retta. Idem per cip dell' arduino, per adattare l'lm35.

Si infatti: sarebbe servita in ogni caso la taratura a due punti, quindi tanto vale semplificare il circuito e prendere dati "grezzi", e poi rimettere tutto a posto (come scala e offset) via software. A volere essere pignoli, nel circuito che ho postato c'è un piccolo difetto: l'uscita inizia ad essere valida a partire da qualche grado sopra la temperatura ambiente, prima rimane a 0V. Questo è inevitabile ed è una caratteristica di tutti gli operazionali (anche quelli per strumentazione): la tensione di uscita non raggiunge mai le due alimentazioni, è limitata a qualche decina di mV sopra e sotto. Per la tensione superiore non ci interssa visto che arriveremo a 1200°C, per quella inferiore invece si incappa in questo effetto, che comunque ai fini della prova non dovrebbe influire visto che non lavoreremo vicino alla temperatura ambiente. Per evitare questo inconveniente ci sono due soluzioni: usare un'alimentazione duale (+5V, -5V), cosa molto scomoda, o introdurre un'offset che poi si può sottrarre in software (questo è molto più semplice e se serve lo possiamo fare). L'LM35 invece non ha questo problema, visto che misura la temperatura in °K, e quindi in genere è lontana dallo 0...

amir:
-il sistema utilizzato dal Prof. Levi fa uso di una sonda per determinare il titolo di vapore la quale sonda secondo la scheda tecnica nell' arco di misura (temp. circa 100 °C, umidità relativa circa 100%) di interesse può avere un errore del 3,5%; un errore dell' 1% nella determinazione del titolo di vapore genera un' errore del 75% nella determinazione dell' energia necessaria a portare il fluido in uscita dal "reattore" a quella temperatura (http://www.mail-archive.com/vortex-l...sg41849.html);

Quel calcolo è sbagliato!!!
Se vaporizzo il 90% di acqua ed il 10% rimane in fase liquida, l'energia che mi serve è il 90% di quella stimata, non il 0.qualcosa%...

-il fatto di scaricare il "vapore" in un condotto non ne permette l' analisi qualitativa. Ovvero non permette di escludere la presenza nel fluido in uscita dal reattore di azoto e/o CO2, che sarebbero i residui di una [...] combustione, per esempio di alcool;

Moltissime persone hanno frainteso completamente l'esperimento di Bologna, e questo ha generato gran parte della confusione che si è scatenata in rete. L'esperimento non voleva dimostrare che la "fusione fredda" esiste e funziona, e non voleva dimostrare un fenomeno nuovo e sconosciuto, era soltanto la misura di energia e radiazioni da una "black box", ossia: guardate che ho questa "cosa" che prende 400W, ne da 12000, non emette radiazioni pericolose, ma forse all'interno ne produce qualcuna. Vediamo se è vero oppure no. Punta e basta. Gli esperimenti sono stati fatti ed è venuto fuori che la "cosa" produce l'energia dichiarata in base a quanto dato in ingresso ed in uscita, non è pericolosa, ma non ha manifestato neanche alcune radiazioni che ci si aspettava all'interno. Non è forse questa una prova scientifica valida e ben definita?
Che senso ha chiedere di aprire la scatola, invocare la riproducibilità, la pubblicazione su riviste, questioni brevettuali, la fusione fredda che non esiste, le teorie che sono sbagliate, potenziali frodi etc.? Sono cose che non hanno niente a che vedere con l'esperimento. Chi fa questo o non ha capito lo spirito della dimostrazione, o non ha ben chiaro il metodo scientifico... (e ci metto dentro pure un sacco di scienziati che non si trattengono da dare giudizi critici pur avendo a disposizione soltato informazioni di dubbia origine e qualità reperite su Internet).

[SGF]

Amir, abbiamo capito che i calcoli gli sai fare, bravo, ma ti ostini dannatamente a non volerne afferrare la parte concettuale....(perseverare è diabolico)... Informati meglio sul calabrone...vola e sa anche perché ?!!!

X Vettore, andare sotto zero non ci serve quindi va bene cosi. Sono in possesso di un po di lm324 pensi ci siano problemi se' al posto del mcp6001...

[GabriChan]

@Amin il vapore è acqua in formato gassoso e ci vuole una certa energia per farla evaporare.

Comunque queste sono chiacchiere inutili per di più nella sezione sbagliata....
La vera controprova è verificare che il fenomeno esiste, per questo bisogna sostenere chi ci stà provando a replicare e aspettare i risultati.

@Vettore basta sommare il valore letto dall' LM35 al valore della termocoppia, poi bisogna vedere la linearità delle sonde e vedere in che fascia di temperatura si lavora per le eventuali correzioni.
Facendo riferimento ai filmati Celani diceva che rilevava un valore più alto della misura di fondo, dei gamma nella stanza del reattore.
Credo che sia quello più che altro a segnalare l'avvenuta reazione.
Ciao

[Vettore]

Era così difficile aumentare la portata dell'acqua sullo scambiatore e conseguentemente farla rimanere liquida? Le misure sarebbero state meno equivocabili.

La modalità di misura che hanno scelto è la più sensata (sempre tenendo presente che lo scopo è ottenere una misurare affidabile dell'energia in uscita, non sventare i trucchi degli illusionisti...). Se avessero usato acqua liquida cosa ci avrebbero guadagnato? Sarebbe stato complicatissimo misurare l'energia: dovevano usare un flusso molto più grande, e non è detto che lo scambiatore interno al reattore poteva gesritlo, servivano riserve d'acqua grandi da tenere in contenitori grossi che dovevano essere ben isolati termicamente, e la temperatura durante l'esperimento non è detto che fosse costante. Tutto questo a che pro?
Invece producendo vapore si è sfruttato un fenomeno che richiede una grande quantità di energia e che avviene a temperatura costante, e per questo è inequivocabile: entrano 14 L d'acqua, esce solo vapore (la temperatura è quella giusta per forza), il calcolo è immediato e con piccoli margini d'incertezza o errore.
Non si capisce perchè questa cosa, nella sua lampante semplicità ma assoluta correttezza metodogolica scatena perplessità ed obiezioni di ogni genere (che da un punto di vista puramente tecnico non hanno quasi nessuna validità)...

amir:
Sostituiamo la parola "volume" (evidenziata da me) con "mass", e dica gentilmente Vettore perché trova questo calcolo sbagliato, tenendo presente che la succitata sonda ha per il campo di umidità relativa di interesse...

Amir, è inequivocabile e molto semplice:
- sono entrati 8.8 Kg di acqua;
- il calore di vaporizzazione dell'acqua è 2260 J/g;
- se supponiamo che siano stati vaporizzati per intero sono 2260*8.8 = 19,888 kJ
- se supponi che l'1% di quell'acqua non sia stata vaporizzata, cioè 8.8*0.01=0.088 Kg avrai che l'energia necessaria per vaporizzare la restante è 2260*8.712 = 19689 kJ. Se addirittura il 10% (quasi 1 Kg) dell'acqua fosse rimasto allo stato liquido si avrebbe 2260 7.8 = 17628 kJ.
La quantità di energia è simile! Se anche fosse uscito un rigagnolo ammontante ad 1 Kg di acqua oltre al vapore, a parte che non sarebbe passato inesservato (nel senso che non ci voleva un rivelatore di qualità dell'aria per misurarlo), ma comunque l'energia sarebbe stata dello stesso ordine di grandezza! Ecco perchè la prova tecnicamente è stata fatta in maniera ineccepibile secondo me.
In questo ragionamento semplicissimo non conta assolutamente nulla il volume dell'acqua ne quello del vapore (che infatti non è neanche stato misurato), ne tantomeno la portata di massa. Quello che ha scritto Mr. Heffner su Vortex-1 non ha nessun senso, è una vera e propria "super*****la" per confondere le idee (anche il discorso che fa di seguito sui sensori capacitivi e sugli errori strumentali). E la cosa bella è che oramai è diventato praticamente una reference, perchè viene citato più il suo post che non quelli che lo correggono... Che potenza la Rete, vero?

Abbiamo un dato, la quantità acqua in entrata, ma manca un altro dato, essenziale, la quantità di acqua in uscita.

Ai fini dei calcoli, ma anche praticamente, non serve a nulla, per il principio di conservazione di massa ci sono solo tre possibilità: o l'acqua che entra ed esce in fase liquida, o esce come vapore, o viene accumulata dentro il reattore (non può "sparire"). Dal momento che il reattore è stato pesato prima e dopo, la terza ipotesi si può escludere, l'acqua liquida in uscita non c'era (o c'era in minima parte), quindi era tutto vapore.
Ripeto, volere trovare a tutti i costi delle falle in un test così banale, mi sembra veramente incredibile...

SGF:
Sono in possesso di un po di lm324 pensi ci siano problemi se' al posto del mcp6001...

No, non vanno bene. Ho fatto anche una prova per scrupolo, ma non sono adatti: ci vuole un opamp rail-to-rail sia in ingresso che in uscita, con bassi offset ed alta impedenza d'ingresso. Ce ne sono diversi, ma l'MCP600x (il 6004 ha 4 operazionali) è uno di quelli che costano di meno e facili da reperire.

GabriChan:
@Vettore basta sommare il valore letto dall' LM35 al valore della termocoppia, poi bisogna vedere la linearità delle sonde e vedere in che fascia di temperatura si lavora per le eventuali correzioni.

Non si può fare perchè hanno fattori di scala diversi ed avresti come minimo una risposta a forma di spezzata, che non è bella da calibrare... Molto più facile leggerli separatamente e fare una somma.

eroyka:
a dimostrazione di come il brevetto di Rossi non sia nulla di nuovo (o quasi) riporto qui il giudizio dell'Ufficio Brevetti Europeo rilasciato pochi giorni fa.
Questo giudizio consta in 3 punti (novità; Invenzione; Applicabilità industriale), ognuno dei quali analizza 15 aspetti.

In effetti non ne esce benissimo... I 15 numeri sono i claims del brevetto, e non hanno tutti la stessa importanza: quello fondamentale è il numero 1, che è stato ritenuto non nuovo e non inventivo... Purtroppo c'era da aspettarselo per come è scritto il brevetto (e l'avevo anche previsto diversi post fa), però questo esame non è una bocciatura, gli inventori hanno facoltà di riorganizzare il testo, e tutto sommato l'iportante è che regga qualche claim se ne cadono altri... In ogni caso Rossi si è tenuto una serie di assi nella manica, quindi anche se il brevetto non fosse concesso la sua invenzione è salva da un punto di vista industriale...

[umbi]

E usare un PLC per il controllo ? Una CPU (Siemens x es. io conosco quelle) ha integrati 5 canali analogici di lettura, 2 analogici di uscita, un 20na di I/O digitali, compatta, affidabile e comunica con PC con 485 ed ha una buona velocità di campionamento se necessaria.