Error 69 Communication buffer overflow

[Guest]

I have a PBDOS program that monitors the status of a serial port
looking for data coming from a callerid id box. The program works
fine, but after several days the program reports an error 69
commm buffer overflow.

We have this program running on lots of machines. This is the
only install that gives us this error. It is attached to a diff callerid
box. I do not see how that can make any differenece.

Anyone have any ideas how to solve the problem? We did increase
the LEN value in the open comm statement which made the problem
less frequent.

Help?

------------------

[Gustavo Asplanatti]

Evidently the port received more data that it can read, that is to say it is not read with enough regularity. You should empty the buffer more often.
You can use the LOC function to verify the existence of data in the buffer of the open port.
You can also create a errors routine , ask for the type of error (69) and to empty the buffer, for example with LINE INPUT OR INPUT.

Ex.:

ON ERROR GOTO ErrTrap
...
ErrTrap:
IF ERR = 69
WHILE LOC(1) > 0
Data$ = INPUT$( LOC(1) , #1)
WEND
RESUME NEXT
ELSE
PRINT "ERROR " + STR$(ERR) + " IN " + STR$(ERADR)
END
END IF

Hope this help...



------------------
Gustavo Asplanatti
[email protected]

[Lance Edmonds]

You might also try extending the internal COM receive buffer with the $COM metastatement.

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

[Guest]

Here is the source code. See any problems?

ComPort$ = Using$("COM#:",ComPortNo)
ON COM(ComPortNo) GOSUB CallerID
COM(COMPortNo) ON
COMPortFileNo = FreeFile
OpenFile$ = ComPort$+BaudRate$+","+Parity$+","+DataBits$+",1,CS0,DS0,CD0"
OPEN OpenFile$ as COMPortFileNo Len = 8192 ' 03-28-02

CallerID:
COM(ComPortNo) OFF
INPUT #COMPortFileNo, CallerData$
LineNo$ = Mid$(CallerData$,1,2)
FileName$ = "\TELCOMP\LINE"+LineNo$+".DAT"
Replace any " " with "0" in FileName$
F% = FreeFile
OPEN FileName$ for Output as #F%
PRINT #F%, CallerData$
CLOSE #F%
F% = FreeFile
OPEN "\TELCOMP\LOG.DAT" for Append as #F%
PRINT #F%, CallerData$
CLOSE #F%
COM(ComPortNo) ON
RETURN


------------------

[Tom Hanlin]

While you have COM OFF, comm trapping is disabled, and any comm events
get thrown out. What happens if more characters are received after
the INPUT# but before the COM ON?

Try replacing the COM OFF with a COM STOP, which will preserve any comm
events. That may be enough to take care of it.

I'd probably be inclined to replace the INPUT# with a polling loop,
myself-- using INPUT$ and LOF, accumulating a string, and terminating
on either an expected end character or a timeout. It would be a bit
more complex than what you're using, but would provide finer control.


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

[Gustavo Asplanatti]

Doug:

As Tom says, I think that it is not necessary to use COM OFF / COM ON in the routine " CallerID ".
I don't believe that adding a COM STOP solves your problem, since when a event occurs, an implicit COM STOP statement is executed to prevent the trap subroutine from bieng called recursively, when closing RETURN of subroutine an implicit COM ON executes.

I believe that the solution should be something as this:

CallerID:
WHILE LOC(ComPortNo) > 0
INPUT #COMPortFileNo, CallerData$
LineNo$ = MID$(callerData$,1,2)
FileName$ = “\TELCOMP\LINE”+LinNo$+”.DAT”
REPLACE ANY “ “ WITH “0” IN FileName$
F% = FREEFILE
OPEN FileName$ FOR OUTPUT AS #F%
PRINT #F%, CallerData$
CLOSE #F%
F% = FreeFile
OPEN "\TELCOMP\LOG.DAT" for Append as #F%
PRINT #F%, CallerData$
CLOSE #F%
WEND
RETURN



------------------
Gustavo Asplanatti
[email protected]

[Mel Bishop]

I don't see any flow control in your example. Are you using
hardware or software flow control?


------------------

[Barry Erick]

I always trapped for error 69 and if that, went to empty the buffer.
On a machine error, and I think that was 27, I would resume. Not
resume next, but resume. I used that in xmodem, qmodem, and all the protocals
and still have it in serial programs at work.
--Barry

------------------

[Guest]

I am relying on hardware flow control.

------------------