mscomm unable to handle long streams?

[barfo]

hi all,

sorry if this has been addressed elsewhere and i overlooked it, but i've been looking for answers to his for days now - so if anyone can point it out or give an assist it'd be greatly appreciated.

i'm attempting to use mscomm to download via rs232 a long stream of data (now approx 100-500kB and later several MB) from an external device. the data from the external device is in good order - i am able to download endless streams with 3rd party freeware apps and can log the output for verification. that being said, let me give the symptoms from within my VB app.

i'm able to download data perfectly at 38.4k until a limit of approximately 4.8kB, at which point the app starts missing bytes. it doesn't garble bytes together or miss one byte and move on, it starts missing bytes at seemingly random intervals rather frequently, maybe one every 4-5 bytes is completely gone.

i've attempted to use both methods of data capture - polling and the _oncomm event. surprisingly i've had better luck with polling, however at nearly the same point in the download the app starts losing much more data than when event driven.

so far i have been able to improve the transfer success rate to nearly 120kB, but only after adding a 5ms delay between every four bytes on the transmitter's end, which is simply unacceptable. i've placed debug messages at every possible error, and frequently see "comEventRxOver" errors, however this seems unrelated to the problems i'm having with lost bytes, as it occurs very soon into the download and much more frequently. Also, after adding the pause in the xmit side of things, if i leave the app running - spitting the values into an excel sheet - i receive a stack overflow error.

i'm relatively new to vb, but have quite a bit of experience coding - mostly lower-level apps, C/++ and scripting. it seems like this is related to the receive buffer overflowing as well as stack issues, however i'm not aware of a way to manage the stack in vb - is there? i've increased the fifo buffers to the max values possible under the control panel. reducing them just seems to exacerbate the problem, so i suspect it's related.

i've posted relevant code snippets below - thanks a lot for any feedback.

the comm port setup:
Public Sub CmdStart_Click()
' setup com port
With Comm
.InputLen = 4
.RThreshold = 4
.RTSEnable = True
.SThreshold = 1
.Settings = CboRate.Text & ",n,8,1"
.CommPort = Val(CboPort.Text)
.PortOpen = True
End With

CreateWrkSht
End Sub

the _oncomm routine:

Private Sub Comm_OnComm()
Dim strDump As String

Select Case Comm.CommEvent
' Errors
Case comEventBreak ' A Break was received.
OutputBox.Text = "comEventBreak"
'Comm.PortOpen = False

Case comEventCDTO ' CD (RLSD) Timeout.
OutputBox.Text = "comEventCDTO"
'Comm.PortOpen = False

Case comEventCTSTO ' CTS Timeout.
OutputBox.Text = "comEventCTSTO"
'Comm.PortOpen = False

Case comEventDSRTO ' DSR Timeout.
OutputBox.Text = "comEventDSRTO"
'Comm.PortOpen = False

Case comEventFrame ' Framing Error.
OutputBox.Text = "comEventFrame"
'Comm.PortOpen = False

Case comEventOverrun ' Data Lost.
OutputBox.Text = "comEventOverrun"
'Comm.PortOpen = False

Case comEventRxOver ' Receive buffer overflow.
OutputBox.Text = "comEventRxOver"
strDump = strDump & "***"
'Comm.InBufferCount = 0
'Comm.PortOpen = False

Case comEventRxParity ' Parity Error.
OutputBox.Text = "comEventRxParity"
'Comm.PortOpen = False

Case comEventTxFull ' Transmit buffer full.
OutputBox.Text = "comEventTxFull"
'Comm.PortOpen = False

Case comEventDCB ' Unexpected error retrieving DCB]
OutputBox.Text = "comEventDCB"
'Comm.PortOpen = False

' Events
Case comEvCD ' Change in the CD line.

Case comEvCTS ' Change in the CTS line.

Case comEvDSR ' Change in the DSR line.

Case comEvRing ' Change in the Ring Indicator.

Case comEvReceive ' Received RThreshold # of chars.
strDump = strDump & Comm.Input
Call logInput(strDump)

Case comEvSend ' There are SThreshold number of
' characters in the transmit buffer.

Case comEvEOF ' An EOF character was found in the
' input stream.
End Select

End Sub

and the data logging:
Sub logInput(strDump As String)

If Col = 9 Then
Row = Row + 1
RecCount = RecCount + 1
Col = StartCol
End If

If Row > 32752 Then
Row = StartRow
StartCol = StartCol + 10
Col = StartCol
End If

OutputBox.Text = "Record: " & RecCount
ExcelDat.InsertValue Chr(Col + 96) & Trim(CStr(Row)), strDump
Print #nFileNum, strDump

Col = Col + 1
strDump = ""

End Sub

[barfo]

alright, i think the problem is mostly solved.

i can dump the data into a text file without errors creeping in, so it seems like the execution time of the excel methods are causing the ISR to miss data.

[namrekka]

I advice you to check the (hardware) handshaking!

[barfo]

this is definately not a handshaking issue.

[namrekka]

And "comEventRxOver" means? And what is controlling the filling of the buffer?

[barfo]

the data is being uploaded from a micro i coded, and there is no handshaking - it's one-way communication. the buffer is filled as bytes are transmitted at 38.4k and i cannot believe that a dual p4 machine can't read data faster than that. the ISR called by the _oncomm event was being slowed down, or stopped by the routines calling excel... i am baffled as to why excel would be given priority over a hardware interrupt but it is, hence the rx buffer overflow error.

with the excel calls removed, i can download infinite streams of data without problems.

[namrekka]

And that's your problem.
Without handshaking try lowering the baudrate. Or make a gap in the datastream and play with the "InBufferSize" / gap time. In that "gap" Windows gets some time to flush that buffer.