mscomm inbuffer

[ADoozer]

how do you flush an mscomm control input buffer??

i have been using this code

If MSComm1.InBufferCount > MSComm1.RThreshold Then
MSComm1.InBufferCount = 0
MSComm1.RThreshold = 27
Exit Sub
End If

but i dont think this actually clears the buffer?!?

is there a way to completely drop everything in the buffer, i imagine there is and its really simple but i cant see it!!

any help greatly appreciated!!! If somethings hard to do, its not worth doing - Homer Simpson

 

[LazyMe]

Setting the InBufferCount to 0 surely should clear the receive buffer.
Greetings,
Rick

 

[paulbent]

Reading the Input property clears the receive buffer.

Paul Bent
Northwind IT Systems

http://www.northwindit.co.uk

 

[ADoozer]

lazyme: as you may have read in one of my other posts today... for whatever reason MSComm1.InBufferCount = 0
does not clear the buffer, the way i understand it, it should, but its not doing for me!!...

paulbent: ive not tried this aproach yet but i will tommorow (im limited to 5 seconds between each oncomm event so there may be a time issue)

im still looking for a sure fire way of cleaning out the buffer, if anyone knows one!! If somethings hard to do, its not worth doing - Homer Simpson

 

[LazyMe]

ADoozer, I'm sorry to tell you....

I always use InBufferCount, OutBufferCount to flush the buffers. And it always works for me.

Maybe your device is sending characters again after you set the count to 0, which will fill up the receive buffer again. I mean; flushing the receivebuffer is just a momentary action, you can't prevent it from receiving characters again from a device directly after flushing the buffer(unless you close it).
Greetings,
Rick

 

[ADoozer]

is it possible then for a inbuffer to fill while code is executing in the oncomm event

example: the hardware fires every 5 seconds, alternatively 27bytes and 141bytes, initially my rthreshold is set to 141, so if the hardware fires 27bytes first followed by 141bytes i have a theoretical buffer of 168bytes (which is not true because if i debug.print the inbuffer at the top of the oncomm event it says it only has 147bytes) i then set the bufferincount to 0, where are the other 21bytes, are they lost in the system, or sitting and waiting in the inbuffer or should they have been flushed when inbuffercount=0????

thanks for input so far! If somethings hard to do, its not worth doing - Homer Simpson

 

[LazyMe]

What you should do is read the inputbuffer until you get the number of bytes you expect (of course with a timeout).

Here's a very small example, excluding the timeout checking:


dim strInput as string

While your_comm_control_object.InBufferCount < expected_bytes
DoEvents
Wend

strInput = your_comm_control_object.Input


Not even necessary to act upon any event now!!
Greetings,
Rick

 

[ADoozer]

arggh!! doevents... had nothing but problems when doing events with an mscomm control!!!

i do get your point though!

id rather avoid this process if possible, its a lot a faffing for what it does!!

can anyone tell me exactly what happens with the inbuffer when the oncomm_event is called.

does it stop filling, does it buffer in another buffer, should it empty completely when i set inbuffercount to 0

i realise i keep asking this question but i still havent come across the answer!

thank you to lazyme for taking the time,

any further input appreciated!! If somethings hard to do, its not worth doing - Homer Simpson

 

[LazyMe]

The receivebuffer is not bound to any comm event. You need to understand that the buffer can get filled up any time you don't even expect it. Characters are put there whenever your serial device is transmitting. They will remain there until you read them out of the receive buffer.

You reading the buffer in the oncomm event is just a momentarily action. If you emtpy it by reading it (or setting the inbuffercount to 0) immediately after that a new character may arrive at the serial port (and therefore put in the buffer again).

And it does not matter if you do this in the oncomm event or in whatever other piece of code you might want to.

The mscomm control is so kind as to offer you to raise an event if the number of characters in the buffer exceed a certain threshold, but this does not interfere with any other communication processes that may happen (such as receiving more characters after the threshold has been exceeded, or after you've read from the receive buffer). You don't even have to read the entire buffer at once, you could read the characters byte by byte, block by block etc. And while you're doing this characters may still be arriving in the buffer.
Greetings,
Rick