MSComm application hangs - comEventRxOver

1 Feb 2006 8:35 PM

DRBarkley

Hello,

My VB6-SP5 program hangs up after receiving a stream of data for a while.

The stream is continuous, at approximately 115.2K Baud (it showed ~113K in
testing).
I have no control over this--it is usually repeating 6 similar bytes (a
marker, and 5 status bytes)
The RThreshold is set to 12, so it should always contain two markers with
the five bytes between them.

MSComm1 is set as follows:
    InputMode = comInputModeBinary
    RThreshold = 12
    InputLen = 0
    InBufferSize = 16383
    Settings = "115200,n,8,1"

Even when the code in the MSComm comEvReceive event is limited to:
    ByteArray = MSComm1.Input
it can't seem to keep up with it.

Before I commented it out, I was Debug.Printing the ByteArray, and it would
grow in length.
I expect that was due to it not being serviced soon enough.

All of the MSComm Errors are Debug.Print'd and I have seen comEventRxOver
and comEventFrame occur.

Any ideas?

DrBarkley

1 Feb 2006 9:08 PM

Ken Halter

Show quote Hide quote

"DRBarkley" <David.NOSPAMBarkley@L-3NOSPAMCom.com> wrote in message
news:ec99N82JGHA.3260@TK2MSFTNGP11.phx.gbl...
> Hello,
>
> My VB6-SP5 program hangs up after receiving a stream of data for a while.
>
> The stream is continuous, at approximately 115.2K Baud (it showed ~113K in
> testing).
> I have no control over this--it is usually repeating 6 similar bytes (a
> marker, and 5 status bytes)
> The RThreshold is set to 12, so it should always contain two markers with
> the five bytes between them.
>
> MSComm1 is set as follows:
>    InputMode = comInputModeBinary
>    RThreshold = 12
>    InputLen = 0
>    InBufferSize = 16383
>    Settings = "115200,n,8,1"
>
> Even when the code in the MSComm comEvReceive event is limited to:
>    ByteArray = MSComm1.Input
> it can't seem to keep up with it.
>
> Before I commented it out, I was Debug.Printing the ByteArray, and it
> would
> grow in length.
> I expect that was due to it not being serviced soon enough.
>
> All of the MSComm Errors are Debug.Print'd and I have seen comEventRxOver
> and comEventFrame occur.
>
> Any ideas?
>
> DrBarkley

What kind of flow control are you using? Dick Grier mentioned in a post, not
too long ago, that Serial I/O without flow control, at speeds above 9600
baud is just begging for things to blow up. Personally, I like to fire an
event on each character and handle the buffering myself.

--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm

1 Feb 2006 10:02 PM

DRBarkley

Show quote Hide quote

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:O7GSeO3JGHA.2336@TK2MSFTNGP12.phx.gbl...
> "DRBarkley" <David.NOSPAMBarkley@L-3NOSPAMCom.com> wrote in message
> news:ec99N82JGHA.3260@TK2MSFTNGP11.phx.gbl...
>> Hello,
>>
>> My VB6-SP5 program hangs up after receiving a stream of data for a while.
>>
>> The stream is continuous, at approximately 115.2K Baud (it showed ~113K
>> in
>> testing).
>> I have no control over this--it is usually repeating 6 similar bytes (a
>> marker, and 5 status bytes)
>> The RThreshold is set to 12, so it should always contain two markers with
>> the five bytes between them.
>>
>> MSComm1 is set as follows:
>>    InputMode = comInputModeBinary
>>    RThreshold = 12
>>    InputLen = 0
>>    InBufferSize = 16383
>>    Settings = "115200,n,8,1"
>>
>> Even when the code in the MSComm comEvReceive event is limited to:
>>    ByteArray = MSComm1.Input
>> it can't seem to keep up with it.
>>
>> Before I commented it out, I was Debug.Printing the ByteArray, and it
>> would
>> grow in length.
>> I expect that was due to it not being serviced soon enough.
>>
>> All of the MSComm Errors are Debug.Print'd and I have seen comEventRxOver
>> and comEventFrame occur.
>>
>> Any ideas?
>>
>> DrBarkley
>
> What kind of flow control are you using? Dick Grier mentioned in a post,
> not too long ago, that Serial I/O without flow control, at speeds above
> 9600 baud is just begging for things to blow up. Personally, I like to
> fire an event on each character and handle the buffering myself.
>
> --
> Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
> DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
> Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm
>
Hey Ken,

I am home (away from the code) now, so I may not be able to answer
everything.

I'm not sure is its the same as Flow Control, but Handshaking is set to 0
(comNone).
I knew the stream was output from the sending unit without handshaking.

I usually buffer myself, also, but, I was anticipating a problem processing
every character.
I was trying to keep the processing inside the receive event as minimal as
possible.

I realize that Dick is the MSComm Guru, here. Perhaps he will jump in with
something.

But anyone feel free to add comments.

I appreciate the help,

DRBarkley

6 Feb 2006 8:58 PM

DRBarkley

Still no ideas, eh?

I have continued searching, and trying, and testing, and ... No luck, here,
either.

I guess the problem is that the message stream is just coming too fast to
process.
That, coupled with the lack of hand-shaking.

Just wish there was a way of ignoring what I couldn't get to, without the
app getting hosed.

Thanks, anyway,

DRBarkley

Show quoteHide quote

"DRBarkley" <David.NOSPAMBarkley@L-3NOSPAMCom.com> wrote in message
news:ec99N82JGHA.3260@TK2MSFTNGP11.phx.gbl...
> Hello,
>
> My VB6-SP5 program hangs up after receiving a stream of data for a while.
>
> The stream is continuous, at approximately 115.2K Baud (it showed ~113K in
> testing).
> I have no control over this--it is usually repeating 6 similar bytes (a
> marker, and 5 status bytes)
> The RThreshold is set to 12, so it should always contain two markers with
> the five bytes between them.
>
> MSComm1 is set as follows:
>     InputMode = comInputModeBinary
>     RThreshold = 12
>     InputLen = 0
>     InBufferSize = 16383
>     Settings = "115200,n,8,1"
>
> Even when the code in the MSComm comEvReceive event is limited to:
>     ByteArray = MSComm1.Input
> it can't seem to keep up with it.
>
> Before I commented it out, I was Debug.Printing the ByteArray, and it
would
> grow in length.
> I expect that was due to it not being serviced soon enough.
>
> All of the MSComm Errors are Debug.Print'd and I have seen comEventRxOver
> and comEventFrame occur.
>
> Any ideas?
>
> DrBarkley
>
>