Newsgroup: it.comp.lang.visual-basic
Titolo: MSComm e USB

Col controllo MSCOMM gestivo il flusso dati da e verso un Fax Modem 
Voice 56K della U.S. Robotics collegato alla porta COM RS232.
 
Avendo cambiato pc, mi ritrovo senza una porta RS232 per cui ho tentato 
la via dell'addattatore da USB a RS232 a cui ho collegato il modem 
suddetto, ma non riesco più a far funzionare il tutto.
 
Ho quindi pensato di utilizzare una FAX MODEM VOICE più "moderno" che 
utilizza come naturale connessione la porta USB, ora, la domanda è la 
seguente: riuscirà secondo voi il controllo MSCOMM a gestire una porta 
COM su USB anzichè su RS232.
 
 
-- 
Gulp®
--
"Partimque figuras retulit antiquas, partim nova monstra creavit."
(La Metamorfosi - Ovidio)

> porte COM, poi devi gestirlo, ma il modem normalmente dovrebbe rispondere ai
comandi AT.   Gli mandi un:
 
 ATZ & CrLf     'e lui deve rispondere.
 
Il controllo MScomm normalmente ha il limite della COM16, ma ricordo che c'era
il modo di bypassare questo limite modificando direttamente l'OCX con un editor
binario.
 
 
-- 
ciao
  Stefano

 funziona anche con un converter usando WinPhone.
....
 
mble.... potrebbe allora trattarsi dei driver?
Eppure da gestione risorse se faccio diagnostica sul modem 
risponde...non a tutti i comandi, ma risponde.... il mio "vecchio"
codice vb però non funziona e tutto sembra muto-sordo...


codice vb però non funziona e tutto sembra muto-sordo...
 
La prova più semplice la puoi fare con un  Hyperterminal o un programma simile,
mandando un comando AT sulla porta COM del convertitore, se USR risponde allora
devi controllare il tuo codice VB.
 
Potresti avere usato i comandi di sincronismo, RTS\ CTS\, o potrebbe essere il
protocollo di handshake, il convertitore potrebbe anche mandare la risposta
quando non lo leggi, devi indagare.
 
 
-- 
ciao
  Stefano

Il 25/10/16 15:19, SB ha scritto:

Allora, funziona, o meglio non è sordo come pensavo.
All'arrivo dello squillo si apre la finestra che dovrebbe visualizzarmi 
la scritta con l' ID del chiamante...ma la stringa, a quanto pare, 
risulta uguale a zero e la finestra rimane vuota. Mah.
 
Questo il "cuore" del codice:
 
Private Sub CallerID()
On Error GoTo errore
If COM1.PortOpen = True Then Exit Sub
COM1.CommPort = PortaModem
COM1.InputMode = comInputModeBinary
COM1.PortOpen = True
COM1.Output = "ATV1Q0" & vbCr
Wait 1
COM1.Output = "AT#CID=1" & vbCr
Wait 1
COM1.PortOpen = False  'per svuotare il buffer
COM1.PortOpen = True
Exit Sub
errore:
ErrTelef
End Sub
 
Private Sub COM1_OnComm()
'Evento sulla porta
If COM1.CommEvent = comEvRing Then
Suona App.Path & "\ringin.wav", 1
End If
AscoltaPorta     'legge i dati in arrivo alla porta
frmCaller.Attesa 'mantiene aperto il form finchè squilla il telefono
End Sub
 
Private Sub AscoltaPorta()
   Dim buffer As Variant
   Dim arr() As Byte
   Dim dato As String
   Dim n As Long
   Dim tsyn As Single
 
   dato$ = ""
   tsyn = Timer + 10
   While dato$ = "" And Timer < tsyn
     ' Controlla la presenza di dati.
     If COM1.InBufferCount Then
       ' Legge i dati.
       COM1.InputLen = 0   'COM1.InBufferCount
       buffer = COM1.Input
       COM1.InputLen = 0
       arr = buffer
       ' Converte i dati letti in una stringa
       For n = 0 To UBound(arr)
          dato$ = dato$ + Chr$(arr(n))
       Next n
     End If
   Wend
stringas = dato$
If InStr(stringas, "DATE") > 0 Then
Dati
End If
End Sub



Qualche osservazione:
 
Non specifichi nell'apertura della porta la proprietà
Handshaking, che dovrebbe essere  comNone o com RTS
a seconda del modem.
 
Meglio sempre specificare tutti i parametri all'apertura della porta.
 
Inoltre prima di ricevere sempre meglio assicurarsi che .RTSEnable
sia nella giusta condizione indipendentemente dal protocollo di
Handshaking selezionato, perchè comanda direttamente il filo RTS,
e se il modem non vede il suo CTS corretto non invia nulla.
 
Normalmente ci vuole  .RTSEnable = True
 
Poi, invece di verificare se il modem ti risponde "OK" tu metti 
un'attesa di 1 secondo, così non sai se il modem ha capito e ha risposto.
 
Infine, dal momento che l'evento comEvRing dipende solo
dallo stato logico del filo Ring che il modem varia comunque quando squilla,
non hai modo di sapere se il modem ha ricevuto i comandi e risponderà.
 
Quindi, meglio fare un loop di attesa della risposta prima di andare avanti,
una cosa così, 
 
Declare Function GetTickCount Lib "kernel32" () As Long
Declare Sub Sleep Lib "kernel32" (ByVal n As Long)
 
 Fine = GetTickCount + 5000     '5 sec  TEMPO LIMITE RISPOSTA 
 
 Do: DoEvents: Sleep 1
   If Comm1.InBufferCount > 0 Then
        [....] 'verifica OK, poi Exit Do
  End If
   If GetTickCount > Fine Then 
     Msgbox "ERROR"  : Exit Do
   End If
 Loop
 
 
Ho Usato due API perchè si controlla meglio l'overtime e si evita
la CPU al 100% durante il loop.
 
Se non risponde prova a variare Il protocollo e  .RTSEnable
 
Se il modem risponde OK guarderemo anche il resto del codice,
che così ad occhio potrebbe anche funzionare.

ciao
  Stefano

 Quindi, meglio fare un loop di attesa della risposta prima di andare avanti
 
Seguirò il tuo consiglio.
 
Comunque il codice che ho postato, prima di avere a che fare con 
l'adattatore di porta ha funzionato per dieci anni senza problemi...
...sempre che si tratti di questo benedetto adattatore.


Mi sembra comunque che per quanto riguarda l'attesa, questa parte di 
codice:
 
dato$ = ""
    tsyn = Timer + 10
    While dato$ = "" And Timer < tsyn
      ' Controlla la presenza di dati.
    If COM1.InBufferCount Then
 
 
svolga più o meno la stessa funzione del loop da te proposto...beh, 
quasi. :)


quasi. :)
 
Si, ma è concettualmente sbagliato.
 
Tu attendi un dato dal modem dopo un evento comEvRing senza prima sapere se il
modem ha ricevuto i comandi AT.
 
Inoltre stai usando la porta in comInputModeBinary, che è una cosa abbastanza
masochistica perchè è parecchio più laboriosa da gestire la risposta.
 
Io non ho mai usato MsComm in binario, e comunque nella stringa che ti risponde
il modem ci possono essere tutti i caratteri da 0 a 255, basta controllare la
presenza di VbCrLf prima di fare il confronto
 
Usando la comInputModeText ti basta verificare che ci sia "OK" & VbCrLf nella
stringa.
 
 
-- 
ciao
  Stefano

...sempre che si tratti di questo benedetto adattatore.
 
E' quello che devi scoprire facendo delle prove, quando si inizia a lavorare con
un modem la prima cosa che si fa è inviare un "ATZ"  & VbCrLf e aspettare la
risposta.
Se non arriva un"OK" bisogna controllare tutto, dai fili ai driver del converter
USB, al setting del convertitore nelle proprietà hardware.
 
Io da qui non posso certo saperlo   ;-)
 
-- 
ciao
  Stefano

 USB anzichè su RS232.
 
Cavolo m'ero perso il 3ad:
 
Il 99% dei convertitori USB/seriali sono trasparenti, nel senso che
il programma manco vede la differenza da una seriale normale, ma
alcuni hardware vedono la differenza ECCOME !!! Ad esempio
i moduli seriale-bluetooth !
 
Attenzione ai segnali CTS e DTR che spesso NON vengono replicati
dagli adattatori USB/seriale "un tot al kilo"... fortunatamente
è possibile aggirare il problema ponticellandoli o eliminando il
controllo di flusso se la periferica (in questo caso il modem) lo
consente.

USB, al setting del convertitore nelle proprietà hardware.
 
Dimenticavo, il Fax Modem Voice 56K della U.S. Robotics ha un connettore RS232 a
25 poli femmina, mentre i convertitori normalmente escono su un 9 poli maschio.
 
Ti serve in ogni caso un adattatore 9F - 25M, il problema potrebbe dipendere
anche da lui.
 
Comunque per provare ti allego un vecchio programma per chiamare che mostra
anche le risposte del modem, e funziona bene con il modem U.S. Robotics.
 
 Mscomm è usata in comInputModeText, e non ci sono problemi.
 
https://dl.dropboxusercontent.com/u/2370367/Dial.zip
 
 
 
-- 
ciao
  Stefano