Newsgroup: it.hobby.elettronica.digitale
Titolo: Interfacciarsi RS-485 per comandare relè

Ho aperto un tread "Interfacciarsi su ethernet per comandare relè"
dove spiego la mia situazione/idea.
Mi è stato suggerito di utilizzare rs-485 invece dell'ethernet e
quindi volevo capire differenze di costi/benefici.
Vi riassumo il post precedente:
Sto ristrutturando la casa e già che aggiungo le tapparelle
motorizzate volevo fare una piccola applicazioncina per gestire
l'apertura/chiusura delle taparelle in modo manuale/automatico dal
pc.
Mi spiego:
1. Vorrei poter comandare l'apertura / chiusura delle tapparelle
delle
varie stanze (ne ho 8) dal PC oltre che dal pulsante vicino alla
finestra.
2. Vorrei mettere un sensore di temperatura esterno lato sud e uno
interno e d'estate quando la temperatura esterna è X sopra a quella
interna far chiudere in automatico le tapparelle delle 3 finestre a
sud
3. sempre con i sensori di temperatura esterni/interni vorrei far
partire il ricircolo d'aria, in estate quando la temperatura esterna
è
inferiore a quella interna (essenzialmente di notte)
4. altre cosettine similari.
A questo punto quindi vorrei far partire il bus 485 dalla rs232 del
PC.
Per poter fare il bus ogni scheda deve immagino avere 2 connettori
seriali (uno che arriva uno che parte).
Mi suggerireste una schedina a basso prezzo che ha già tutto il
necessario a bordo per gestire il bus, per gestire I/O (almeno 4 in 4
out e 2 dac)?
Grazie

Chiaramente a questo punto... se ci sono altri metodi ancora piu'
"furbi" per fare un bus con un unico cavo passante in casa
(chiaramente fatto da 1 o più coppie), si accettano suggerimenti.

 (chiaramente fatto da 1 o più coppie), si accettano suggerimenti.
L'RS422 è come l'RS-232, ovvero lo attacchi direttamente alla seriale del
microcontrollore. Usa però due fili anziché uno per trasmettere il segnale,
ottenendo un'immunità al rumore infinitamente superiore.
L'RS485 è come il 422, ma permette di inserire più talker sullo stesso
circuito. Ciò è possibile perché i driver RS485 possono anche essere messi
in 3-state, ovvero ad alta impedenza, insomma in pratica puoi spegnere il
trasmettitore, in modo tale che ce ne sia uno solo acceso.
Dovessi farlo io passerei un cavo CAT5 e lascerei libere le coppie verde ed
arancione, così, se un domani ti serve un collegamento Ethernet...
Userei una coppia per un'alimentazione a 9V, così potrò alimentare piccoli
circuiti con un banale 7805.
Sulla coppia rimanente manderei il segnale.
L'RS485 ha il problema che, se due trasmettitori sono accesi (anche senza
trasmettere dati) contemporaneamente e trasmettono uno 0 e l'altro 1, vanno
in corto.
Ti suggerirei quindi di usare l'astuto sistema del bus CAN: metti l'entrata
dati del driver RS485 (un classico DS485N, ad esempio) a massa e trasmetti
i dati col pin di enable. In pratica col trasmettitore acceso, un filo sarà
sempre a 0, l'altro a 1, così non puoi avere corti anche se hai più
trasmettitori accesi.
Ai due estremi del cavo, in corrispondenza dei due dispositivi più lontani,
metterei una resistenza di pull-up verso l'alimentazione sul filo che a
trasmettitire acceso viene mandato a 0, ed una di pull-down sul filo che il
trasmettitore manda a 1.
In questo modo puoi semplificare la gestione dell'arbitraggio del software
e fare come fa Ethernet: trasmetti, se ti accorgi che c'è qualcun altro a
trasmettere (l'input sarà diverso dall'output), smetti e riprovi dopo un
tempo random.

 Ti suggerirei quindi di usare l'astuto sistema del bus CAN:
O, ancor più semplice ed economico, se trasmetti a basse velocità e quindi
non hai bisogno di tanta immunità al rumore, un solo filo con i pull up
agli estremi ed un transistor che lo tira giù verso massa per ogni nodo.

 agli estremi ed un transistor che lo tira giù verso massa per ogni nodo.
Penso che questo potrebbe già andarmi bene. Devo tramettere pochi byte
ogni volta.
Il fatto è che di elettronica ricordo ben poco... e sti nomi non
ricordo affatto cosa siano...
pull up agli estremi?
I resto capisco cos'è.
Non è che mi sai indicare un link dove c'è un progettino simile già
sviluppato?
Il top sarebbe avere le schede ed il software per la gestione del bus
già fatti, poi le personalizzazioni mi arrangio.
Grazie

 già fatti, poi le personalizzazioni mi arrangio.
Ci sto lavorando a tempo perso... ma visto che mi piacciono
le cose complicate il sistema lo faccio via radio.
Oltretutto via radio costa molto di meno.
(no, non è un refuso. I moduli radio che uso costano 3 dollari l'uno)
Il lavoro sarà finito (salvo imprevisti ed incasinature varie) a fine
ottobre.
Se ti interessa... batti un colpo.
GB
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 già fatti, poi le personalizzazioni mi arrangio.
Anche una fetta di culo tagliata vicino all'osso che così è più saportita?
;-)
Modi più semplici non ne riesco ad immaginare. Cerca su 
www.avrfreaks.net
,
comprati una evaluation board per ATmega8, scaricati GCC ed inizia a
trafficarci.

 (no, non è un refuso. I moduli radio che uso costano 3 dollari l'uno)
Per curiosità che moduli usi? Io avevo trovato dei *chip* a quel costo, 
non moduli.
Ciao!
Marco / iw2nzm

 ha
scritto:

--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> non moduli.
Ah quei chip?
Si si ora ho capito!
Sono ottimi...
:DD
--
salutoni
coals

 > non moduli.
nel post mi si è magnata la risposta
RMF12B presi direttamente in cina, in fabbrica.
www.hoperf.com
pagati con paypal, con 100 euro ne abbiamo presi 50.
GB


 
www.hoperf.com
Slurp :P
Marco / iw2nzm

 GB
Kavolaccio... via radio addirittura... come già detto le onde mi
spaventucchiano... ma terrò sicuramente in considerazione la tua
proposta
Grazie

 Slurp :P
Cioč? Li hai provati?


 trafficarci.
OK sarà fatto :-)

 ha scritto nel messaggio 
news:26455a30-bb50-42db...@a1g2000hsb.googlegroups.com...
Chiaramente a questo punto... se ci sono altri metodi ancora piu'
"furbi" per fare un bus con un unico cavo passante in casa
(chiaramente fatto da 1 o piů coppie), si accettano suggerimenti. 

 Cioè? Li hai provati?
No, ma visto il prezzo e le caratteristiche sembrano ghiotti!
Marco / iw2nzm

 Marco / iw2nzm
Beh, se li vuoi provare, un paio te li posso "prestare"...
GB


 Non è superveloce ma per domotica è piu che suffuciente.
Certo. Non ho bisogno di velocità.
Grazie

Si conosco il modbus, ho qualche apparecchiatura che lo utilizza, ma
se non erro le librerie di gestione del modbus non sono gratuite
(almeno sui PC). Se conosci qualche microprocessore che possa fare al
caso mio e che nel compilatore abbia gią le librerie modbus a buon
prezzo.... sarebbe un bellissimo e apprezzatissimo suggerimento!
Lo puoi fare con qualsiasi micro ... meglio se perņ ha un uart interno
che ti gestisca RX e TX ovviamente... (
p.es
 AVR o PIC vanno benissimo)
Per librerie e cosa gia fatte io sono partito da zero in assembly... ModBus
č molto semplice com struttura, basta avere la descrizione delle funzioni
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

 Beh, se li vuoi provare, un paio te li posso "prestare"...
Ti ringrazio molto, ma ora non avrei tempo di farci nulla... Grazie 
comunque della segnalazione, ci sono tante cose belle in giro (ok, non 
solo moduli RF... :D )
Marco / iw2nzm

(almeno sui PC). 
Sul sito di iclvb c'è questo Master per rete Modbus (RTU V.1.0 ) in visual basic
http://www.it-lang-vb.net/archivio.asp?subMenu=Tutte&FullText=on&TypeRic=AND&keyword=modbus&x=0&y=0
--
ciao
  Stefano

 tempo random.
Il sistema hardware che hai descritto, derivato dal CAN, è 
effettivamente astuto (quando lessi la prima volta come funzionava il 
CAN, rimasi di stucco per la semplicità e al tempo stesso l'efficacia 
della soluzione), però bisognerebbe accompagnarlo ad un trucco software 
nel protocollo.
In altre parole, avresti un bit dominante (diciamo 0) che viene sempre 
trasmesso anche se altri transceiver bloccano il bus.
Quindi devi associare un messaggio numericamente piccolo (con tanti 0 
nei bit più significativi) per continuare a trasmettere tale 
informazione, indipendentemente dal blocco degli altri transceiver.
Se l'obiettivo è solo quello di rilevare conflitti (nel caso 
multi-master) e blocchi, allora questo si potrebbe fare anche senza il 
tuo accorgimento. Basta collegare in loop la linea TX e RX di ogni 
transceiver e confrontare quello che si riceve con quello che si 
trasmette. Se c'è qualche differenza, c'è collisione (o blocco) e si può 
riprovare dopo un tempo casuale.
Ma a questo punto, secondo me, il livello di gestione dei conflitti 
diventa abbastanza complicato ed esiste già una soluzione già pronta 
all'uso: Ethernet. Con un ENC28J60 della Microchip hai già un mezzo 
fisico a bus multi-master con controllo delle collisioni e delle 
ritrasmissioni praticamente gratis.
Unica limitazione, la velocità: 10Mbps... più che sufficiente per la 
domotica.

 
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
Grazie del link utilissimo della guida... ma non mi sembra proprio uno
scherzetto....

> 
http://www.it-lang-vb.net/archivio.asp?subMenu=Tutte&FullText=on&Type.
..
Ottimo grazie, anche se il basic non mi entusiasma... eventualmente lo
convertirò in C

 domotica.- Nascondi testo citato
E ritorniamo alla mia idea iniziale.... perchè inventarsi un bus e
crearsi complicanze quando c'è già bello e pronto, funzionale e
prestazionale?
Il solo 10Mbsp non sono una limitazione.... non devo mica spostare un
video in HD... devo spostare bit.... oppure esageriamo: byte
Stiamo parlando di 1280 byte al secondo.... ma sapete quante cose si
scrivono in 1280 byte? E se le tapparelle iniziano ad abbassarsi/
alzarsi dopo 1 secondo del mio comando... beh... non è certo un
problema.

 problema.
E' quello che ho detto.

 diventa abbastanza complicato
Quante volte al giorno pensi che andrà a menarlo alle tapparelle?

convertirò in C
Siamo complementari, a me non piace il C e vorrei avere tutto in basic...
--
ciao
  Stefano

 a me non piace il C e vorrei avere tutto in basic...
Ugh! Mi crolla un mito. ;-)

Ugh! Mi crolla un mito. ;-)
Purtroppo è così, l'ho incontrato una 20ina d'anni fa e non sono mai riuscito a
farmelo piacere.
Sarà che la prima volta che ci ho lavorato era in un programma di pesatura su
una scheda con lo Z80, il tizio ce ne aveva parlato come il programma del
futuro, una meraviglia, ecc.
Invece il suo software scritto in C non riusciva a fare quello che il mio
scritto in asm faceva anche se l'avevo abbastanza ottimizzato, ricordo che
abbiamo dovuto aumentare la ram (ma con il limite dei 64k era un problema) e
usare uno Z80B a 6Mhz per farlo andare, ma alla fine controllava bene solo 3-4
bilance invece delle 6-8 dell'altro.
Colpa dei floating, diceva lui, mmm forse è una cavolata di linguaggio dicevo
io.
Poi quel casino di graffe e di asterischi vari non mi attirava, e ho fatto la
previsione, rivelatasi clamorosamente sbagliata, che con quell'accrocco di
linguaggio non sarebbero andati avanti molto.
Invece mi è toccato impararlo e pure il suo fratello maggiore C++, ma non mi
sono mai entrati in simpatia.
Dice un mio collaboratore che capisce dalle mie imprecazioni quando sto usando
il C perchè le espressioni tipo 'linguaggio di m...', 'sto punto e virgola del
c...o'  le riservo solo a quello.
Anzi mi dice: 'se sbagli un istruzione in ASM la colpa è tua, mentre se sbagli
qualcosa con il C la colpa è sempre del linguaggio', e c'è del vero, oramai sono
come don Chisciotte con i mulini a vento, me ne rendo conto.
--
ciao
  Stefano

 come don Chisciotte con i mulini a vento, me ne rendo conto.
Eggià. :-)

Eggià. :-)
Checcevoifà  ;-)
--
ciao
  Stefano

 Checcevoifà  ;-)
Pienza a 'a salute. ;-)

 E' quello che ho detto.
Infatti.. lo ho solo confermato per chi i 10mbps gli sembravano pochi

 Ma se sono il bello del C, il "linguaggio dei puntatori"! :D
infatti
hi hi hi

 No, ma il webserver passa su ethernet ;-)
E chi l'ha detto?

 Ottima tutat la discussione su asm e c c++
Peccato per il quoting.

Pienza a 'a salute. ;-)
La salute è sempre la cosa + importante, assolutamente.
--
ciao
  Stefano

hi hi hi
mi ripeto:
sgrunt !!!
--
ciao
  Stefano

 Ne ho usati diversi, ma gli IDE del C mi sono sembrati sempre molto spartani.
Ecco il punto: l'IDE di Visual Basic era di gran lunga la migliore sul
mercato. Su questo ti do pienamente ragione. Ma mi pare di aver sentito che
ora, unificandosi con C++ e J++ sia un  po' regredita.

 ora, unificandosi con C++ e J++ sia un  po' regredita.
Se guardate gli ultimi ide microsoft (tra l'altro GRATUITI) tipo il
visual studio 2008 express, l'ide del vc è praticamente tipo visual
basic... un giochetto. unico neo, ci vuole sotto un pc mostruoso
perchè si muova decentemente. (almeno così mi è sembrato visto che
l'ho guardato pochetto... sono obbligato a rimanere ancora per un po'
con il visual studio 6)

perchè si muova decentemente.
L'ide del .Net è sulla falsariga di quelli precedenti, e permette di muoversi
nei meandri del framework abbastanza facilmente.
Certo che bisogna almeno sapere di che cosa si tratta, con VB classic erano
necessarie molte meno info per partire, poi però quando si volevano prestazioni
migliori e si incominciava ad usare le API nasceveno i casini.
Però per fare cose decenti, in VB come in qualunque altro liguaggio bisogna
avere chiaro che occorre usare il cervello, i linguaggi in fondo sono solo
strumenti.
--
ciao
  Stefano

 un IDE scarso.
Mi hai fatto ricordare cosa disse il professore di programming languages
nell'ultima lezione del corso, dopo averci insegnato per un anno a
programmicchiare con almeno 20 linguaggi assolutamente allucinanti
(ricordo, oltre ad APL, Lisp e Prolog, anche CLU, "il linguaggio dei
cluster", uno di questi giorni lo googlo per vedere se è mai stato
implementato) che, fondamentalmente, dopo l'invenzione di Fortran e Algol,
la sola vera innovazione per la produttività dei programmatori sono state
le IDE.

le IDE.
L'IDE che avevo quando studiavo il Fortran erano delle belle schede perforate.
In effetti rispetto all' IDE di VB6 c'è un pò di differenza.    :-)
--
ciao
  Stefano

   Stefano
ciao
Angelo

velocita'!!!
già
--
ciao
  Stefano

 Quante volte al giorno pensi che andrà a menarlo alle tapparelle?
Beh, la gestione dei conflitti l'hai introdotta tu ed io l'ho solo 
commentata. Effettivamente si può anche evitare di gestire i conflitti. 
Trasmetto con checksum e aspetto l'ACK. Se l'ACK non arriva entro un 
certo tempo, riprovo con un tempo inversamente proporzionale alla mia 
priorità.

 Beh, la gestione dei conflitti l'hai introdotta tu
Certo, ma non per latenze e pippe (vista l'applicazione) analoghe. Solo per
evitare che gli si fottessero i trasmettitori 422 in caso di bachi
software. Scusa se son stato brusco, ma l'ora è tarda...

 software. Scusa se son stato brusco, ma l'ora è tarda...
Ah, ok.
Ma non ho capito perchè ti preoccupano i cortocircuiti sul bus... i 
transceiver non si rompono. Se è per una questione di blocco del bus, i 
trasmetittori 422 potrebbero rimanere comunque accesi sul bit dominante 
e bloccare comunque tutto il bus. Solo se si bloccano sul bit recessivo 
il bus non si blocca. Ma la probabilità è al 50%


http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=561&uiTemplateId=NODE_STRY_PGE_T
Interessanti, grazie, già segnato il link.
--
ciao
  Stefano

 il bus non si blocca. Ma la probabilità è al 50%
Meglio del 100% dell'RS485.

 Meglio del 100% dell'RS485.
Ok, allora ci ho visto bene. All'inizio pensavo ti stessi riferendo alla 
possibilità di evitare completamente il blocco del bus utilizzando il 
"trucco CAN". In realtà riduci soltanto la probabilità del blocco 
sperando che il driver si blocchi sul bit recessivo (tri-state) 
piuttosto che dominante.
Diciamo però che blocchi software di questo tipo possono essere evitati 
facendo uso di watchdog.

 facendo uso di watchdog.
Senz'altro, ma vuoi mettere la complicazione aggiuntiva?
Stiamo parlando di un hobbista con le sue tapparelle, che vuole produrre un
esemplare unico in tempi ragionevoli.
Le tue obiezioni sono validissime, ma forse non pertinenti il caso.
Io stavo solo cercando di evitargli spesa, complicazioni e minore
affidabilità nel lungo termine di mettere chessò, addirittura dei nodi
Ethernet o radio. ;-)

 Ethernet o radio. ;-)
Bravo! Hai colpito al centro. E' proprio quello che cerco. Semplicità.
Ho letto tutti i post, ma vista la mia ignoranza non ho osato
rispondere. Sinceramente vedo molte difficoltà in quello che avete
scritto.
Possibile non esista qualcosa di semplice? Ho le idee molto più
confuse che all'inizio.
Qual'è il sistema migliore per passare su un unico cavo?

 Possibile non esista qualcosa di semplice? 
Certto: hai 8 fili, ne usi uno come ritorno e gli altri sette per comandare
altrettanti relé.

 altrettanti relé.
Troppo semplice :-)
A me serve un bus semplice, quello non è un bus ;-)

 out e 2 dac)?
Non hai pensato al 1wire? Con due soli fili risolvi.
-- 
A bug in the code is worth two in the documentation.
News 2002 [v 2.08] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net