Newsgroup: it.comp.lang.visual-basic
Titolo: [VB6] MSComm ed Handshake

Sapete se esiste on-line qualche guida (a parte MSDN) che spieghi in modo
semplice il funzionamento dell'handshake nel controllo MSComm di VB6 ? ho le
idee abbastanza confuse e con Google non sono stato capace di trovare niente
che mi chiarisse bene le idee, magari con qualche esempio.
Grazie.

ToSka ha detto questo lunedì :

L'handshaking del MSComm è semplicemente una transposizione, in una 
proprietà, dell'handshaking della RS232. E' su questo che chi opera con 
le seriali deve informarsi, non è un discorso di VB.
Wikipedia dovrebbe essere abbastanza preciso sull'argomento 
('dovrebbe', non ci ho mai guardato)
Che poi se vuoi spippolare sovrascrivere l'handshaking di base, ti 
viene offerta anche la possibilità di lavorare sui pin con le varie 
proprietà del MSComm, ma in linea di principio non ne hai bisogno.
Ciao
Alberto
-- 
Charles Baudelaire: C'è un solo modo di dimenticare il tempo: 
impiegarlo.

 ('dovrebbe', non ci ho mai guardato)
In effetti avrei dovuto fare la premessa "di comunicazioni seriali non ne so
praticamente niente" :-)
Seguirò il tuo consiglio e mi darò una letta a Wikipedia, dato che mi dici
che l'MSComm non ha nulla di trascendentale.
Mi sto scontrando con l'errore 8020 e non riesco a venirne fuori :-|  Per
questo pensavo che l'handshake potesse essere la soluzione. chissà se è così
:-)

Nel suo scritto precedente, ToSka ha sostenuto :

Non so cosa sia l'errore 8020.
Se è un errore di runtime del MSComm, è impossibile che derivi 
dall'handshaking.
L'handshaking è semplicemente il modo in cui una seriale gestisce la 
sincronia dei piedini, e in conseguenza dell'handshaking richiesto 
dall'interlocutore, va scelto il cavo adatto.
Ma a livello software, è una cosa di cui, una volta impostato, ci si 
scorda.
Ciao
Alberto
-- 
Chi semina raccoglie,
ma chi raccoglie si china.
E a quel punto è un attimo...



L'handshake in parole semplici è la gestione del sincronismo di una
conumicazione via RS232.
Selezione comRTS:
I terminali RTS (out) e CTS (in) sono collegati insieme in modo incrociato.
Quando si abilita RTS\ (Requesto To Send), la corrispondente linea CTS\ (Clear
To Send) si abiliterà e consentirà la trasmissione, e viceversa dall'altra
parte.
Selezione comXOnXOff:
Viene inviato un carattere Xon (11H =17 dec) per iniziare la comunicazione e un
carattere Xoff (13H =19 dec) per terminarla.
Qui lo spiega meglio:
http://www.it-lang-vb.net/Documentazione/Articoli/MSCOMM.htm#5.3
http://www.giobe2000.it/HW/Seriale/Pag/RS232-40.asp
--
ciao
  Stefano

questo pensavo che l'handshake potesse essere la soluzione. chissà se è così
comReadError error (error 8020).
CAUSE
This problem occurs because MSComm.Input reads only the bytes that are
immediately available in the serial driver. By design, MSComm.Input does not
return any bytes if the serial driver has not received any bytes. Because the
MSComm control does not expect the ReadFile method to return ERROR_IO_PENDING,
MSComm returns the comReadError error if this occurs.
Se ascolti la porta in polling devi mettere almeno una cosa così:
 Do:
   If MAIN.MSComm1.InBufferCount > 0 Then
      Fine = GetTickCount + 3000
       Ch = MAIN.MSComm1.Input '    Debug.Print Ch;
   End If  
 Loop
--
ciao
  Stefano

  Loop
Non faccio il polling della porta con un loop come nel tuo esempio, ma mi
affido all'evento OnComm, con RTHreshold = 0, perchč la lunghezza della
stringa č variabile e non č nota a priori.

 stringa è variabile e non è nota a priori.
Non che cambi molto, comunque.
Anche con OnComm, devi necessariamente fare l'append alla stringa di 
buffer e valutarne la completezza con un parsing...
Esattamente come col polling.
Con l'evento, sei solamente più reattivo, in quanto il tuo software 
viene invocato dall'interrupt anzichè 'passare di lì' ogni tot tempo...
Alberto
-- 
Henry David Thoreau: L'uomo è tanto più ricco quanto meno costano i 
suoi piaceri.



Probabilmente non processi bene gli eventi dell'oncomm, ma prima di fare una
lettura dalla porta metti lo stesso una cosa cosě.
If MAIN.MSComm1.InBufferCount > 0 Then  Ch = MAIN.MSComm1.Input
--
ciao
  Stefano

 viene invocato dall'interrupt anzichč 'passare di lě' ogni tot tempo...
Si, infatti. Volevo solo dire che evidentemente non č la strada giusta per
risolvere l'errore.

risolvere l'errore.
La strada giusta è leggere il buffer di MsComm solo se ci sono dei caratteri
dentro, altrimenti si genererà l'errore 8020.
--
ciao
  Stefano

 dentro, altrimenti si genererà l'errore 8020.
Mi sono accorto solo adesso del tuo post sotto quello di Albe. Farò la prova
con il test che mi hai indicato... certo che se fosse risolutiva sembrerebbe
un baco per cui l'evento OnComm si scatena a volte per nulla.

 un baco per cui l'evento OnComm si scatena a volte per nulla.
Niente, purtroppo l'errore permane anche con questo accorgimento.
Il problema si manifesta usando non una seriale nativa, ma un adattatore
USB/Seriale.
Ulteriori ricerche sul web sembrano convergere su problemi di driver. In
particolare con XP SP2 non ci sono problemi, mentre con lo stesso driver ed
il SP3 si.

il SP3 si.
Naturalmente hai provato a guardare sul sito del produttore del convertitore per
vedere se ci sono i driver aggiornati, vero?
--
ciao
  Stefano

 vedere se ci sono i driver aggiornati, vero?
Mi hai letto nel pensiero :-)
Il fatto è che non riesco a riprodurre la situazione da me, visto che il
problema ce l'ha un utente.
Ho appena ricevuto una sua mail in cui mi dice che ha aggiornato i driver,
come gli avevo suggerito, ed ora uno dei 4 adattatori (un Vivanco) su cui ha
fatto le prove funziona correttamente.
Quindi le info che avevo erano corrette, si tratta di problemi legati al
driver, almeno nel mio caso.
Grazie a tutti per i suggerimenti!



Io ti posso dire che quando devi attaccare qualcosa per fare la
comunicazione, alla fine ciascuno ha il suo protocollo.
L'altro giorno ne avevo da fare uno:
PC1	PC2
enq
	enq
"01"
	ack (nak)
dati+crc
	ack (nak)
enq
	ack (nak)
	dle
	flag risposta 

Sembra che Andrea [Work] abbia detto :

Beh, ma quello è l'hanshaking del layer logico.
L'OP chiedeva lumi sull'handshaking del layer fisico o al limite 
dell'incapsulamento subito superiore. Che è l'handshaking sulla base 
del quale si deve scegliere il cavo.
Che poi il problema non c'entrava niente con l'handshaking...
Ciao
Alberto
-- 
Thomas Fuller: Ci sono persone che sono state considerate coraggiose 
perchè avevano troppa paura per scappare.

 Che poi il problema non c'entrava niente con l'handshaking...
Si sorry, avevo letto a pezzi il post :)