PBDLL and Comm

[Scott Turchin]

I'm working on a comm app...

I would like to init the modem, and then display all results to a label on the main dialog.

For some reason I don't seem to be getting the "OK" back from the modem.
I've verified that g_szmdmInit is equal to "ATZ"
And the modem brings up DTR, in fact I can make it dial with no problems...

(Hey you fixed the (CODE) so when I edit it doesn't show the html tags, cool!)


Can someone take a gander at this?
This function is called on WM_INITDIALOG

'----------------------------------------------------------------------------------------------------------------
Function InitializeModem() As Long
Local Start As Long

Comm Open g_szComPort As #hComm
If ErrClear Then Exit Function          'Exit if port cannot be opened

Comm Set #hComm, Baud     = Val(g_szBaudRate)
Comm Set #hComm, Byte     = 8           '8 bits
Comm Set #hComm, Parity   = %False      'No parity
Comm Set #hComm, Stop     = 0           '1 stop bit
Comm Set #hComm, TxBuffer = 1024        '1k transmit buffer
Comm Set #hComm, RxBuffer = 1024        '1k receive buffer

'Send the Init command
Comm Send #hComm, g_szmdmInit
'Comm Print #hComm,g_szmdmInit
Control Set Text hDlg,%IDLABELCOMMSTATUS2, g_szmdmInit

'Begin timer
Start = Timer
Do
    g_Qty = Comm(#hComm, RxQue)
    If IsTrue g_Qty Then
       Comm Recv #hComm, g_Qty, g_szmdmInput
       Control Set Text hDlg,%IDLABELCOMMSTATUS2, g_szmdmInput
    End If
    If Start + Timer > 30 Then Exit Do
Loop While IsFalse g_Qty
Function = %TRUE
End Function

'----------------------------------------------------------------------------------------------------------------

------------------
Scott
mailto:[email protected][email protected]</A>

[This message has been edited by Scott Turchin (edited August 12, 2000).]

[Guest]

Add a $CRLF to Comm Send, g_szmdmInit

Try sleeping for 2-3 seconds after sending the modeminit string.

------------------
Ron

[Scott Turchin]

Yup, that did it, getting a GPF but I'm sure it's related to the receiver buffer, you can' tleave stuff on there too l ong...


Anyone know why it takes 15 seconds to get an "OK" back from the modem???

Is this a timeout thing?


Scott

------------------
Scott
mailto:[email protected][email protected]</A>

[Tom Hanlin]

The modem needs some time to do a "reset". It would be reasonable to allow up to a minute to get a response back.


------------------
Tom Hanlin
PowerBASIC Staff

[Scott Turchin]

Hmmm, I've gotten it working at times (Forgot how) where it's instant...

Using Procomm for Dos, or any other emulator it's instant, I've never heard of a minute to reset a modem, never....

In fact all of my Dos programming, never had an issue like that, unfortunately this is Windows and is new...
If I have to wait a minute for Windows to reset it, that's crazy! LOL

But thanks, I'll keep plugging away


------------------
Scott
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Hmmm.... A minute does seem quite long... maybe your modem has a knot in the lead slowing down the electrons?

On my systems, most modems respond to ATZ within 5 seconds from a PB/CC application, and I usually work to a 10 second timeout to consider the modem as non-responsive, however, if the system is under heavy load, much longer delays can occur as it can add significantly to the time factor. YMMV I guess.

Anyone else have any anecdotal evidence to add?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

> maybe your modem has a knot in the lead

Since all computer data is ones and zeros, another common problem is the "hook" at the top of a 1 getting caught in a cable. Reverse the ends of the cable, the data flow will push the stuck 1 backwards, and data will begin flowing properly.

Seriously, some modems defintely do take 5-10 seconds to respond to an ATZ or an AT&F, but I've been using a 10 second timeout for years, in programs that have run on thousands of computers for millions of hours, and nobody has ever reported a problem. 1-2 seconds is typical, however.

Scott, it could be that your own code is causing the delay. If your DO/LOOP uses 100% of the system's CPU cycles, it might "starve" the part of the OS that is responsible for passing incoming characters to your program, especially on a 95/98 system. Try adding a SLEEP 10 to your loop and see what happens. If that doesn't work, try SLEEP 100.

BTW, the code you posted could "cut the response in half" and cause problems later. For example, if the modem sends "OK"+$CR and your program gets the characters before the $CR has actually "arrived", your loop will exit and the $CR will appear to be the first character of the next string that comes from the modem. Also, there are some old modems out there that will respond "AT"+$CR+$LF. So you should always clear the incoming buffer after receiving a modem-command response.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Scott Turchin]

Thanks, that's sorta the line I was going down too...

It's a USR 56k, USR has always been funny about a character, but always quick to respond...

It's been a while since I wrote comm stuff, I used to be a real guru in Dos on this stuff, wrote door games etc...hehe


I'm flushing the buffer, initializing the modem, and there's a sleep 500 in there...

I'm going to switch it around a bit and try again..

Jim's been working with me too

Function FlushBuffer() As String
Local sPkt As String
'Flush the buffer To be certain it is empty
If Comm(#hComm, RxQue) Then
    Comm Recv #hComm, Comm(#hComm, RxQue), sPkt
End If
Function = sPkt
End Function

------------------
Scott
mailto:[email protected][email protected]</A>