peppeve:
tutti gli arduino in rete sono sempre in ascolto, appena ricevono un comando da loro gestibile lo eseguono e si rimettono subito in ascolto.
Un protocollo 485 standard ha sempre un traffico dati continuo, l'unità centrale interroga entro 10/20ms tutti i componenti in linea, invia un pacchetto con il numero del device (1byte) un secondo byte (o più) con il comando da eseguire, se questo secondo byte è ipotizziamo 0 significa che il device non deve eseguire nulla di conseguenza esso risponde con 0 per dire "sto bene" ma non ho nulla da dirti, altrimenti risponde con un byte >0 per dire "sto bene" ma ho un messaggio per te.
Senza un interrogazione costante come ti accorgi che la scheda in cantina è andata off-line o non funziona correttamente?
Come ti accorgi che c'è un problema sul bus? Solo quando invii un comando...
Grazie per ora sto solo collaudando singolarmente i programmi, poi a metterli insieme tutti gli arduini ..
una domanda hai previsto qualche cosa se devi aggiornare gli arduini ? Cioè devi smontare la scatola dove sono gli devi attaccare il connettore per la progr. - oppure lo devi staccare e portare dove è il pc . Certo ne sono tanti, considera pure se hai un problema sai il diavoletto ci mette sempre il corno, ho letto che vuoi staccare il led della rs485, ma considera che sai che se si accende cè alimentazione.
Mi piacerebbe vedere lo schema del progettino che hai fatto.
Mi è venuta una cosa in mente, ma chi riceve i dati naturalmente è uno slave ?
@pablos
facendo dei test a 28k ho un tempo di risposta di 15 - 17ms , nella libreria ho inserito un timeout di 200ms.
Nel mio caso il problema potrebbe essere nei sensori per inviare i dati per 30 sensori tutti insieme la stringa è un po lunga ed i tempi si possono allungare, non ho fatto ancora test .. ma avendo un timeout di 200ms , posso interrogare minimo 60 sensori.
Nel mio master ho un modulo gsm che deve fare sms e chiamata e puo stare un po di secondi fuori rete 485.
pablos:
Un protocollo 485 standard ha sempre un traffico dati continuo, l'unità centrale interroga entro 10/20ms tutti i componenti in linea, invia un pacchetto con il numero del device (1byte) un secondo byte (o più) con il comando da eseguire, se questo secondo byte è ipotizziamo 0 significa che il device non deve eseguire nulla di conseguenza esso risponde con 0 per dire "sto bene" ma non ho nulla da dirti, altrimenti risponde con un byte >0 per dire "sto bene" ma ho un messaggio per te.
Senza un interrogazione costante come ti accorgi che la scheda in cantina è andata off-line o non funziona correttamente?
Come ti accorgi che c'è un problema sul bus? Solo quando invii un comando...
Ciao
Ho pensato anche a questo......ho 2 arduino con interfacce bluetooth che mi fanno da bridge tra lo smartphone e la rete rs485, da lì posso interrogare tutti miei nodi, sapere in che stato stanno le luci per esempio, e ovviamente posso monitorare tutto il traffico della rete e inviare ogni singolo comando a piacere per simulare lo sfioramento di un pulsante touch oppure l'evento di un sensore qualsiasi.
Non mi serve un traffico continuo in rete....Posso solo dirti che la rete è up da 3 mesi e non ho avuto questo genere di esigenze. Se una scheda non risponde andrò a verifare il problema....spero non succeda mai.
pines:
Grazie per ora sto solo collaudando singolarmente i programmi, poi a metterli insieme tutti gli arduini ..
una domanda hai previsto qualche cosa se devi aggiornare gli arduini ? Cioè devi smontare la scatola dove sono gli devi attaccare il connettore per la progr. - oppure lo devi staccare e portare dove è il pc . Certo ne sono tanti, considera pure se hai un problema sai il diavoletto ci mette sempre il corno, ho letto che vuoi staccare il led della rs485, ma considera che sai che se si accende cè alimentazione.
Mi piacerebbe vedere lo schema del progettino che hai fatto.
Mi è venuta una cosa in mente, ma chi riceve i dati naturalmente è uno slave ?
@pablos
facendo dei test a 28k ho un tempo di risposta di 15 - 17ms , nella libreria ho inserito un timeout di 200ms.
Nel mio caso il problema potrebbe essere nei sensori per inviare i dati per 30 sensori tutti insieme la stringa è un po lunga ed i tempi si possono allungare, non ho fatto ancora test .. ma avendo un timeout di 200ms , posso interrogare minimo 60 sensori.
Nel mio master ho un modulo gsm che deve fare sms e chiamata e puo stare un po di secondi fuori rete 485.
Ho cercato in lungo e in largo un modo per poterli aggiornare via rs485, ma non ne sono venuto a capo. Intanto le interfacce rs485 sono attaccate a una software serial e poi ti servirebbe un segnale per il reset per resettare l'arduino che ti interessa e fare partire il caricamento dello schetch. Troppo problematico da implementare...... se devo aggiornare apro la scatola/punto luce dove si trova la scheda collego i 2 fili input output, un reset e una massa e carico tramite una UNO che mi fa da converitore usb seriale (le pro mini non hanno l'usb).
Non lo metto in dubbio che si up da 3 mesi o 6 anni, è come spedire un piccione viaggiatore, il messaggio arriva sicuramente finché nessuno gli spara ... È un protocollo casalingo funzionante ma non standard, nemmeno si avvicina a quelli proprietari di tipo industriale. Hai fatto un buon lavoro complimenti, ma non rispecchia la perfezione, però se va bene a te va bene a tutti, era solo doveroso evidenziare quale sia il vero scopo di un protocollo 485, è un forum dove si discute degli argomenti su tutti i fronti e si mettono sul piatto pregi e difetti, senza smontare o demoralizzare sia chiaro.
pablos:
Non lo metto in dubbio che si up da 3 mesi o 6 anni, è come spedire un piccione viaggiatore, il messaggio arriva sicuramente finché nessuno gli spara ... È un protocollo casalingo funzionante ma non standard, nemmeno si avvicina a quelli proprietari di tipo industriale. Hai fatto un buon lavoro complimenti, ma non rispecchia la perfezione, però se va bene a te va bene a tutti, era solo doveroso evidenziare quale sia il vero scopo di un protocollo 485, è un forum dove si discute degli argomenti su tutti i fronti e si mettono sul piatto pregi e difetti.
Ciao
Ovviamente il mio protocollo ha tutti i suoi limiti...Però l'ho studiato in modo da essere semplice da interpretare e nel contempo permettermi una certa flessibilità. Per esempio io comando il motore della pompa dell'acqua da 4 diverse postazioni (lavello della cucina, lavello cucinino, bagno grande e bagno piccolo). Lo accendo quando ho bisogno maggiore pressione dell'acqua. Tutti quei 4 pulsanti touch che comandano sto motore hanno un led che segnala se quel determinato punto luce o motore in questo caso è in posizione on oppure off. Mettiamo il motore sia off, pigio il pulsante del bagno grande, l'arduino dove è collegato il pulsante invia in rete 2 byte (09,01) 09 indica motore e 01 lo stato. Gli altri tre arduini interpreteranno quel comando e di conseguenza accenderanno i led nei pulsanti (per segnalare che il motore è on) e un altro arduino nel sottotetto provvederà materialmente a fare scattare il relè del motore in posizione on. Lo sfiorare di un pulsante ha convolto ben 5 arduini. Farlo in modo classico non sarebbe stato affatto semplice....avrei dovuto inviare praticamente 5 comandi a 5 diversi arduini.
Con questo non voglio dire che la mia sia la soluzione più elegante e sicura........di certo il mio protocollo non potrebbe essere usato per inviare una testata nucleare in sicurezza, ma per domotizzare un appartamento penso sia molto azzeccato.
@pines
Le direttive sugli impianti di antintrusione realizzati su bus 485 richiedono espressamente che un apertura sia rilevata in max 20ms altrimenti non è certificabile, considerando che alcune centrali supportano fino a 255 slave espansioni in 485 è molto probabile che sia possibile
Comunque non è normale inserire un delay di 200 ms... Perché così tanto?
pablos: @pines
Le direttive sugli impianti di antintrusione realizzati su bus 485 richiedono espressamente che un apertura sia rilevata in max 20ms altrimenti non è certificabile, considerando che alcune centrali supportano fino a 255 slave espansioni in 485 è molto probabile che sia possibile
Comunque non è normale inserire un delay di 200 ms... Perché così tanto?
Semplicemente se il master interroga e lo slave per qualsiasi ragione non risponde ( guasto , blocco ecc.) non mi deve rimanere in attesa della risposta un tempo infinito.
@peppeve
La mia domanda e curiosità era i dati chi li riceve e dove vanno a finire.
Sarebbe comunque interessante vedere uno schema e un esempio di programma, per valutare, migliorare se necessario, imparare, infondo è lo scopo dell'open
Ciao
Nella pagina precedente ho pubblicato uno de gli sketch. Lo scema è semplicissimo....I vari Arduini sono connessi tutti in parallelo tramite le interfacce rs485
Non mi servono i led rossi, ogni pulsante ha un led che è in fading quando è off e accesso intenso fisso quando è on. Da lì riesco a capire se tutto è apposto. Se guardi il video che ho pubblicato all'inizio riesci a capire meglio. Riguardo ai dati dove vengono memorizzati è semplice. Nello sketch che ho pubblicato puoi vedere che quel pro mini gestisce 2 variabili:cucina strip e cucina centrale. Appena pigio un tasto lui setta o resetta una delle 2 variabili e nel contempo invia il comando in rete, un altro pro mini interpreta il comando, accende il led nel pulsante corrispondente a lui collegato e accende o spegne il rele. Anche quest'ultimo pro mini ha le 2 variabili cucina strip e centrale. Questi 2 punti luce sono comandati da 2 coppie di pulsanti pertanto da 2 arduini differenti...anche se il rele è attaccato fisicamente soltanto ad un arduino.
peppeve:
Nella pagina precedente ho pubblicato uno de gli sketch. Lo scema è semplicissimo....I vari Arduini sono connessi tutti in parallelo tramite le interfacce rs485
complimenti anche da parte mia...un sogno, forse un'utopia...
non riesco a vedere lo sketch, mi interesserebbe moltissimo, specialmente per la parte comunicazione, grazie
Ciao.. Ottimo lavoro, Bellissimo.....
Mi potresti far capire come elimini la collisione tra due arduino, ossia come controlli se c'e' un'altro che sta' gia' comunicando.
Grazie
diodo157:
Ciao.. Ottimo lavoro, Bellissimo.....
Mi potresti far capire come elimini la collisione tra due arduino, ossia come controlli se c'e' un'altro che sta' gia' comunicando.
Grazie
Ci ho sbattuto la testa 2 mesi per sbrogliare la matassa. Come puoi vedere nello schetk che ho pubblicato, alla fine quando chiamo gli invii controllo che la funzione myChannel.isPacketStarted () sia falsa. Quella funzione non è per niente documentata, sono andato a spulciare i file della libreria e mi sono accorto che quella funzione restituisce vero quando ha ricevuto il Byte di inzio trasmissione. Pertanto dal risultato di quella funzione stabilisco se il bus è libero. Le probabilità che 2 arduini vanno a collidere diventa veramente remota. Ho testato con 3 arduini che trasmettono tutti e 3 quando ricevono un particolare byte.......ho ricevuto tre risposte perfette, senza collisioni.
Adesso ho messo sù il wattmetro....anche lui trasmette minimo ogni 2 secondi 2 stringhe di seguito, quindi il bus diventa trafficato....ma collisioni ancora zero.
Ps. sta sera se riesco metto sù il video del wattmetro, una vera bellezza
Quindi il protocollo è veramente ridotto ai minimi termini, nel senso che non hai necessità di inviare un pacchetto contenente anche mittente e destinatario.
Io stavo studiando su carta un mio protocollo e avevo inserito altri byte, in modo da identificare il mittente del messaggio ed eventualmente il destinatario, ma forse questa è una logica più da master/slave, giusto?
E per le informazioni non 1/0, p.es. valori decimali della temperatura, umidità, ecc.?
sai il diavoletto ci mette sempre il corno, ho letto che vuoi staccare il led della rs485, ma considera che sai che se si accende cè alimentazione.
