Newsgroup: it.comp.lang.delphi
Titolo: Aiuto per rete 485

Qualcuno di voi può aiutarmi nella realizzazione di un software di gestione
di una rete bus (RS485A) gestita tramite scheda(collegata alla seriale) che
effettua la conversione del segnale da RS232C a RS485 A ????
Se la scheda si preoccupa di eseguire la conversione dei livelli elettrici
di tensione dallo standard 232C a quello 485A, devo preoccuparmi di gestire
solo la porta seriale (tramite apposito componente Delphi).....o sbaglio???
Il software da me realizzato crea una string formato
      mittente-destinatario-messaggio testo
Se il ricevente vede che il campo destinatario è uguale al suo
identificativo, visualizza il msg a video.
Il software funziona con normale connessione tramite cavo seriale.
Però, mi sono accorto che la seriale "spezzettava" la stringa: primi otto
caratteri = pacchetto 1......seguito a ruota dal pacchetto successivo
contenente TUTI gli altri caratteri della stringa (non altri 8.....insomma
il msg non è spezzettato in blocchi da 8 caratteri, ma in 2 blocchi: il
primo di 8 caratteri e ilò secondo con tutti gli altri).
per far funzionare il programma l'ho modificato così:
mittente-destinatario-primi 6 caratteri- mittente-destinatario-resto del
messaggio
Montando le schede per lo standard 485, si hanno dei problemi:
1) Uno dei due PC trasmette e l'altro riceve....ma quello che ha appena
ricevuto non riesce a trasmettere nulla al primo PC. Ovvero: PC1invia
correttamente e PC2 altrettanto correttamente visualizza il messaggio. PC2
però non riesce a mandare msg.....PC1 non visualizza nulla.
2)PC1 invia dati....il messaggio inviato viene però rivisualizzato sul PC1
(come se ci fosse un loop tra buffer di ingresso e quello di uscita della
seriale, mah.....). PC non riesce ad inviare nulla......PC1 non visualizza
nulla. Invertendo le schede dei due PC le parti si invertono: PC1 non
trasmette e PC2 si vede tornare indietro quello che invia.
Per chi desidera visionare il software: chiedetemelo e ve lo invierò (via
e-mail). Vi prego aiutatemi....questo progetto è molto importante (lo dovrei
portare all'esame di stato !!)
Se qualcuno di voi ha già avuto a che fare con l'interfaccia 485, si faccia
vivo PLEASE !!!!!
Grazie ancora.

Io sto sviluppando un software per sistemi di sicurezza basato su sensori di
prossimita' collegati ad un pc.
Questi sensori sono collegati tramite un adattatore 485 ad una porta Rs232
del pc.
Ora, i "miei" sensori sono degli apparecchi passivi.
In pratica, devo fare un polling per interrogare un sensore alla volta per
sapere se qualcuno fornito di un trasponder si è avvicinato al sensore.Se
si, mi leggo la stringa ricevuta che non è altro che il codice del
trasponder.
Se il codice è valido, ovvero registrato in una tabella, mando sulla seriale
una stringa che comanda uno o piu' relais che a loro volta mandano un
segnale alle elettroserrature applicate alle  porte dei locali.
Diciamo che, tranne la procedura di polling, il resto è abbastanza facile.
Uso un componente che se vuoi posso inviarti. Magari quello ti risolve il
problema. Il vcl è freeware e lavora tranquillamente su Win95 e Win98. Su NT
no! (sob...!)
fammi sapere
AS
"Se è Microsoft non funziona"

Mr.BadGuy,
tempo fa ho avuto a che fare con una rete di µ interrogati in polling su
485 da un PC (NT4, D2) tramite convertitore; usavo per la gestione della
seriale i componenti della AsynchPro della TurboPower (che costicchiano).
Usi un componente (quale?) o CreateFile, WriteFile... ?
Lo "spezzettamento" del messaggio _credo_ sia opera di Win e non ci si
possa fare molto: prova a modificare in modi diversi il buffering della
seriale.
"Seguito a ruota" che significa? Hai un log con i tempi di
trasmissione/ricezione?
In che modo lo spezzettamento impediva il corretto funzionamento del
programma?
Se sei l'autore del protocollo, considera l'opportunità di mettere
informazioni sulla lunghezza del messaggio e/o un carattere di terminazione
del pacchetto.
Alcuni (molti) convertitori 232-485 hanno bisogno di essere pilotati
tramite (se non sbaglio) RTS (deve essere alzato prima di poter
trasmettere), mentre altri operano in modo automatico lo switch fra modo
sender e receiver. Controlla quindi la documentazione dei convertitori ed
eventuali settaggi hw.
Riesci a comunicare in 485 fra i 2 pc tramite un programma terminale?
Quali sono le impostazioni delle porte nel pannello di controllo?
hth
Paolo Arosio

Ciao Paolo.
Innanzitutto grazie per l'interessamento...sono davvero disperato.
rispondo in ordine alle tue domande...sperando che tu possa capirci un po'
di più sul quale è ilmio problema.
Uso il componente TComPort (freeware) e il programma è fatto con D3:
toh...magari ti fai un'idea di quale è il componente...
" TComPort component version 1.60 for Delphi 2, 3, 4
-------------------------------------------------------
Written by Dejan Crnila, 1998-1999 "
e-mail: 
emilija...@guest.arnes.si
, 
de...@macek.si
Seguito a ruota : intendo che, facendo degli showmessage in xcorrispondenza
dell'evento OnRXChar (per il debug) vedevo arivare un primo showmessage con
i primi 8 caratteri, e il secondo, subito dopo aver cliccato su OK del
primo, con il resto della stringa.
Lo spezzettamento facefva un casino perchè io costruivo il messaggio con
mit-dest-msg......quando il ricevente leggeva il primo pacchetto tutto
ok...prendeva i primi due caratteri, vedeva che era destinato a lui e lo
visualizzava a video, ma al secondo, non essendoci il mittente e il
destinatario ma solo il resto del MSG, lui prendeva i primi due caratteri
(come stabilito dal formato del pacchetto-stringa) per vedere se il msg è
destinato a lui....trovava dei caratteri alfanumerici, hnon certo gli ID
delle macchine di origine e destinazione...per cui non visualizzava il
secondo "pezzetto".
Risultato.....si vedevano solo i primi 6 (8-2 per mittente e destinatario)
caratteri del messaggio...il problema l'ho risolto come ho già illustrato
nel primo post.
per quanto riguarda il funzionamento automatico/manuale....questo è quello
che c'è scritto sull'articolo della rivista di elettronica che proponeva il
progetto:
=====================================================
Impostazione dei dip-switch JP1 e JP2:
Mediante i ponticelli JP1 e JP2 è possibile configurare la scheda in modo
che
funzioni in automatico o che la condizione di ricezione o trasmissione venga
gestita da PC tramite la linea DTR. Inserendo i due jumper nelle posizioni
A-C
(JP1) e B-C (JP2) si imposta la scheda in modo da controllare il flusso dei
dati
in ricezione/trasmissione via computer; in questo caso è necessario che il
software gestisca il segnale DTR in modo da porlo a livello alto quando si
vuole ricevere e a quello basso in caso di trasmissione. Se invece i
ponticelli JP1 e JP2 vengono inseriti rispettivamente tra C e B, e fra A e
C, l'SN75176 si comporta in modo automatico sia da ricevitore che da
trasmettitore. In questa modalità di funzionamento è necessario gestire con
attenzione il software di comunicazione che deve prevedere un MASTER che si
occupa di "interrogare" le periferiche SLAVE tramite un protocollo
specifico.
Gli SLAVE a loro volta comunicano con il MASTER solo quando riconoscono il
messaggio a loro destinato.
===========================================================
Io pensavo, utilizzando le schede in configurazione automatica, di dovermi
preoccupare solo di evitare accessi simultanei al bus, cioè di evitare le
collisioni.....dimmi se sbaglio....devo lo stesso fare l'algoritmo di
polling?? Non è lo stesso se evito a due PC di scrivere contemporaneamente
sul bus??? così manterrei tutte le stazioni a un livelo paritario......(STO
IMPAZZENDO!!)
impostazioni delle porte:
9600 bps
parità : nessuna
bit di dati : 8
bit sdi stop : 1
Grazie......ti prego aiutami !!!!!!!!!!
Alla prossima.
Mr.BadGuy

Mr.BadGuy,
come ti dicevo uso i componenti APD => non conosco il TComPort di D.Crnila
(è su torry? dsp?).
A proposito del "seguito a ruota": penso sia normale che Win notifichi come
desidera un evento sulla seriale; usando ShowMessage non è possibile un
timing accurato degli eventi, che spesso è l'unico modo per il testing di
un programma che usa la seriale; come _base_ si potrebbe usare un log degli
eventi su TStringList con il timing dato da GetTickCount.
Riguardo alla modalità automatica / manuale: se ho ben capito hai messo le
schede in modalità automatica e dal sw implementi l'half-duplex "logico".
Un paio di ulteriori prove/suggerimenti:
a) verifica con hyperterminal se sei in grado di stabilire una connessione
bidirezionale, lasciando le schede in automatico e senza handshake.
b) fai un progetto _minimo_ con una ComPort, un edit (testo da inviare),
una label (testo arrivato) ed un button (invia il testo) da installare sui
2 pc collegati; usalo come terminale minimo.
b2) se non funziona con le schede in modalità automatica, mettile in
"manuale", aggiungi al progetto una checkbox che imposti ed una che mostri
lo stato del segnale usato dalle schede (DTR? in genere è l'RTS) e chiama
gli opportuni metodi di TComPort per impostare/leggere lo stato del
segnale; prova in queste condizioni.
Riguardo al livello paritario: se intendi che ciascun pc della rete può
trasmettere quando vuole, questo mi sembra piuttosto pericoloso: a priori
non hai modo per evitare le collisioni. Potresti inventarti una specie di
token ring logico, ma sarebbe molto vulnerabile alla
connessione/disconnessione di un nodo.
Saluti,
Paolo Arosio