Wsystem, ovvero nascita di un sistema domotico.

[walterword]

Il WSystem quasi terminato

 

Modificato: 13 ottobre 2015 da Livio Orsini

[Livio Orsini]

Walter se non descrivi un po' quello che dovrebbe fare il tuo sistema, difficilmente ci saranno persone che si interesano.

[walterword]

ho dei problemi con I2C e schedine varie ....uffff ...poi faro' la descrizione

[walterword]

Il WSystem è un sistema di controllo , consigliato per applicazioni in campo domotico o terziario

Per motivi inerenti all'incompatibilità elettromagnetica ect, attualmente e' sconsigliato l'uso in ambiente industriale-automazione

Il sistema e' composto dalle seguenti parti :

-Arduino Due 32 bit ARM processor

- Wshield che interfaccia Arduino ai sensori

-16 Input optoisolati , max 24V su bus I2C

-16 Output optoisolati a rele' su bus I2C

- Alimentatore switching 24V , 5A

- 2 DC-DC converter step down per alimentazioni schede I/O e Arduino

- Hub I2C con traslatore di segnali 3V3 <--> 5V

- Hub power supply

- Sensore pioggia

- Sensore umidità relativa del terreno

- Sensore luminosità

- Sensore I2C barometro , pressioni atmosferiche assolute e relative e temperatura

- Modulo HC-06 Bluetooth

- Modulo micro SD card per gestione files

- Real time clock , DS3231

[walterword]

lo schema ufficiale del WShield , la scheda innestata sull 'Arduino Due , che fa parte del WSystem

Questa invece e' la scheda ingressi optoisolati del WSystem

Modificato: 31 luglio 2015 da walterword

[Wolfy]

Quelle schedine le riconosco, ne ho prese un po' pure io per usi simili ma poi ho scoperto che servono uscite open-collector, una porta NOT per relè è stata la mia stessa soluzione, devo solo trovare la voglia di montare una piccola "interfaccia"

Modificato: 31 luglio 2015 da Wolfy

[dott.cicala]

Interessante

Se includi un anemometro puoi controllare l'apertura/chiusura di eventuali tende e/o implementare una stazione meteo

[Wolfy]

Un' altra cosa che secondo me ci si sposa molto bene è, direttamente o indirettamente, un web server per il la lettura e la gestione in real time del sistema tramite IP, molto più versatile del dente blu

[walterword]

si possono fare tanti accorgimenti , inserimenti ect.

Adesso c'e' il bluetooth e sto implementando il WProtocol tra android e arduino in formato binario, non ASCII

Io credo che prima di implementare servizi complicati o comunque che richiedono piu risorse sia il caso di appurare e raggiungere una certa affidabilità di comando da un punto di vista locale per cui bluetooth e' piu che valido , i costi del modulo sono accessibili ect

Poi ci sarebbe il wifi piu potente , poi la scheda ethernet ect

Ma a questo punto i servizi e le funzionalità diventano corposi per cui si puo' optare per un sistema basato su udoo che incorpora su una stessa scheda sia linux-ubuntu che Arduino due .

comunque anche cosi basta inserire una shield ethernet solo che per arduino due non esiste e allora bisogna integrare un arduino uno che comunica in seriale col due .

queste cose le intendo come estensione dell'applicazione , prima bisogna far funzionare il minimo indispensabile , architetturare in moduli e strutturare la comunicazione

L'anemometro serio costa troppo e a lviello progettuale non e' altro che un ingresso analogico che si puo' implemetnare quando si vuole

comunque ci sono dei problemi legati al MCP23017 dedicato alle uscite .

Quando alimento il circuito iniziano a sfarfallare le uscite come se il chip MCP fosse nel terzo stato e instabile

Basta sfiorare la schedina che sfarfallano tutte le uscite

Poi quando ricarico il programma in arduino due allora tutto si sistema ma non sempre , qualche volta bisogna caricarlo 2-3 volte

Parlando con livio si parlava di mettere un circuitino sul reset del chip e procedere in vari modi ma per ora il problema non l'ho ancora risolto .Non capisco quale razza di problema possa essere

Modificato: 31 luglio 2015 da walterword

[Wolfy]

Stai facendo un ottimo lavoro già così, le aggiunte suggerite non dovrebbero essere comunque di difficile implementazione

Parlando con livio si parlava di mettere un circuitino sul reset del chip e procedere in vari modi ma per ora il problema non l'ho ancora risolto

Un semplice timer RC, al massimo negato con un NPN, dovrebbe bastare credo

PS: Più che al wifi secondo me conviene restare sul cablato, come affidabilità le reti wireless domestiche non sono il massimo.

Modificato: 31 luglio 2015 da Wolfy

[walterword]

ora ho fatto cosi ma non va bene

[giacomo56]

Ma le porte del MCP23017 al reset non sono programmate come ingressi?

Ciao.

Modificato: 31 luglio 2015 da giacomo56

[walterword]

io per gli ingressi leggo i due registri del chip dopo averli selezionati

Per le uscite , che son quelle che mi danno problemi , indico i registri e poi gli dico che devono essere uscite

Il reset non e' programmabile ,se c'e' lo 0 si resetta altrimenti funziona correttamente , e anche li sarei curioso di capire perche non mi è molto chiaro

[giacomo56]

Quindi finchè non programmi i piedini come uscite il loro stato è in alta impedenza come tu stesso hai rilevato.

[walterword]

il fatto e' che l'arduino due dovrebbe gia essere programmato .....

[giacomo56]

Se riesco la settimana prossima mi procuro l'integrato e lo provo.

Ciao.

[walterword]

[Livio Orsini]

comunque ci sono dei problemi legati al MCP23017 dedicato alle uscite .

C'è un unico modo per avere la sicurezza che integrati come questo non abbiano uno stato non sicuro all'accensione: tagliare l'alimentazione e subordinarla all'avvio del programma.

Avevo un problema simile 40 anni fa qaundo realizzai il mio primo PLC. lo risolsi con un transitor che taglia l'alimentazione e che vine messo in conduzione dal programma.

Anche questo non è sicuro al 100% (non potrebbe essere certificato) però è ragionevolmente sicuro.

VOlendo si può realizzare un sistema elettromeccanico veramente sicuro al 110% ma, secondo, me nion ne vale la pena.

[walterword]

Dunque , le alimentazioni sono separate per cui se il micro sta girando e stacco l'alimentazione ai rele' e al MCP succede il pasticcio

Ora pero' credo di aver risolto il problema .....

Ho messo la funzione che uso per settare lo stato delle porte nel caso sia uscite iin modo tale che sia esguita sempre

Mi piego , prima avevo nel setup , quindi una volta sola all'avvio , il settaggio delle porte di uscita , ora invece lo faccio ogni ciclo prima di scriverci sopra e sembrerebbe funzionare molto meglio

void configI2C()
{
	Wire.beginTransmission(0x21);    // chip MCP23017 impostato come uscite digitali
	Wire.write(0x00);                // registro IODIRA  1° byte del chip
	Wire.write(0x00);                // impostato come uscite digitali , porta A
	Wire.endTransmission();
	//delay(5);
	Wire.beginTransmission(0x21);
	Wire.write(0x01);                // registro IODIRA  2° byte del chip
	Wire.write(0x00);                // impostato come uscite digitali , porta B
	Wire.endTransmission();
}

poi ad ogni ciclo del micro leggo e scrivo

void readInput()
{
	byte dato1,dato2;
	Wire.beginTransmission(0x20);
	Wire.write(0x12);               // imposto la lettura a partire dal registro GPIOB 
	Wire.endTransmission();
	Wire.requestFrom(0x20, 2);      // richiesta di lettura di 2 bytes dal chip MCP20317
	dato1=Wire.read();              // leggo il primo byte , primi 8 ingressi optoisolati
	dato2=Wire.read();                                 // leggo il secondo byte , rimanenti 8 ingressi optoisolati
	globalData.n_input._Word= dato1 | dato2 << 8;  // compongo la word di ingressi digitali dai due bytes letti dal dispositivo MCP20317
	
}

void writeOutput()
{
	 configI2C();
	 byte output0=globalData.d_output._Word & 0x00FF;
	 byte output1=(globalData.d_output._Word & 0xFF00) >> 8 ;
	
	 Wire.beginTransmission(0x21);      // seleziono il dispositivo MCP20317 con indirizzo 0x21
	 Wire.write(0x12);                  // seleziono il suo registo GPIOA
	 Wire.write(output0);               // scrivo il primo byte sulla porta  A
	 Wire.endTransmission();
	
	 Wire.beginTransmission(0x21);
	 Wire.write(0x13);                                  
	 Wire.write(output1);               // scrivo il secondo byte sulla porta  B
	 Wire.endTransmission();
}

Modificato: 1 agosto 2015 da walterword

[Livio Orsini]

Dunque , le alimentazioni sono separate per cui se il micro sta girando e stacco l'alimentazione ai rele' e al MCP succede il pasticcio

perchè mai dovrebbe?

Se tagli l'alimentazione alle bobine dei relè questi se ne stanno li belli e tranquilli, senza nesun pasticcio. La normale condizione di sicurezza dovrebbe essere con i relè con bobina disalimentata.

Questo vale per tutti i dispositivi di uscita e comando. La condizione di sicurezza è quella neutra ovvero assenza di alimentazione sul comando.

Mi piego , prima avevo nel setup , quindi una volta sola all'avvio , il settaggio delle porte di uscita , ora invece lo faccio ogni ciclo prima di scriverci sopra e sembrerebbe funzionare molto meglio

Questa è un'ulteriore miglioramento di sicurezza, ma è un'altra cosa.

Ti manca anche la condizione di sicurezza generale, non so se ne abbiamo parlato in questa sede, ma sicuramente una volta te ne ho parla.

E' il famoso CCZ (Computer Crazy) che ho sempre usato anche sulle schede micro embedded.

In pratica ad ogni ciclo di main si inverte lo stato di un'uscita generando così un segnale ad onda (quasi) quadra, questo segnale lo si integra con una costante di tempo tale che se, ad esempio, il periodo scende sotto i 20ms si apre un'uscita che darà l'allarme e manda gli attuatori in sicurezza.

In questo modo se per un errore di programma, un disturbo, un guasto il micro va per ranocchie non succede nulla di irreparabile.

E' un watch dog Hw di massima sicurezza.

[walterword]

interessante il watchdog....

L'alimentazione dei rele' alimenta anche il MCP23017 , ho scritto sopra .....per cui devo modificarlo nel senso che MCP deve essere alimentato dalla 5V di arduin per esempio , e i rele dimangono cosi ...

Per tagliare l'alimentazione ai rele' cosa dici di fare , mettere un fet ?

[Livio Orsini]

MCP deve essere alimentato dalla 5V di arduin per esempio

Sarebbe meglio, anche dal punto vista EMC.

Per tagliare l'alimentazione ai rele' cosa dici di fare , mettere un fet ?

Un FET, un MOS o anche un altro relè.

Fa attenzione al pilotaggio dei relè. E' vero che la bobina ti garantisce l'isolamento galvanico dal carico però tiri dentro tranquillamente tutti i disturbi (sono in tanti, anche aziende affermate che si son scottate le dita con questo problema). Per evitare meglio pilotarlo attraverso un opto isolatore.

[walterword]

le scehde a arele sono optoisolate solo che i due header dell'alimentazione sono gli stessi che alimentano lo stadio di ingresso opto e le bobine e sinceramente con le pisterelle fini e sottili che ci sono no nme la sento di star li a tagliare per isolare i due circuiti

comunque gia la modifica sw funziona a meraviglia , adesso stacco e riattacco senza problemi e senza dover ricaricare il programma .

Ho quasi finito il WProtocol , protocollo binario con una serie di comandi e funzioni .

Per ora lato android ho gia implementato la paginetta dei comandi

e quella principale ...sono che android non e' come visual studio bisogna capire un po di cose prima di viaggiare....

Modificato: 1 agosto 2015 da walterword

[Livio Orsini]

comunque gia la modifica sw funziona a meraviglia , adesso stacco e riattacco senza problemi e senza dover ricaricare il programma

Questo già sta a significare che c'è come minimo una corruzione della programmazione della periferica.

[walterword]

cosa intendi per corruzione?