VB2005 Serial Port Read Drop Off

[DaBoonDockSaint]

Still experimenting with the Serial Port component on VB2005 and I have been having issues with my data received event. I set my received bytes threshold to 38 bytes which is the number of bytes that I am expecting every 1 sec and when I get data I read it in my byte array. I use threading.thread.sleep and when I process this data I clear my port buffer using serialport.discardinbuffer method. Now my problem, it appears that ever so many odd seconds I get a problem with my stream and I end up having 44 sometimes 45 bytes coming in and I loose about two seconds of data im wondering if this is something with my read method or if its just the stream being delayed, any experienced programmers have any idea whats going on?

[DataMiser]

I haven't used the receive threshold in a very long time. I find that setting it to 0 and using a timer to check the inbuffer has been more reliable going back as far as VB5 and not just with the MSComm controls but 3rd party tools as well. I also never clear the port buffer during a receive. I always read all the data that is there, que it up in a var until it is a complete packet or whatever I am expecting and if there is garbage I then discard the garbage after reading it out of the buffer.

Sounds like either you are getting some unexpected characters or the second packet is begining to arrive while you are trying to read the first one, in which case clearing the buffer could have very adverse side effects.

[DaBoonDockSaint]

I think you are absolutely correct I will give that a shot today, also do you think my thread.sleep event is causing any issues? Generally have that set to 1 milisecond

[Oblio]

because the receive byte threshold only means that when the data received event fires there will be a minimum of that many characters.

see my post #2 here http://www.vbforums.com/showthread.php?t=530790

the newer version in post#1 is 2008, but you should read post #1 anyway.

[Oblio]

I haven't used the receive threshold in a very long time. I find that setting it to 0 and using a timer to check the inbuffer has been more reliable going back as far as VB5 and not just with the MSComm controls but 3rd party tools as well. I also never clear the port buffer during a receive. I always read all the data that is there, que it up in a var until it is a complete packet or whatever I am expecting and if there is garbage I then discard the garbage after reading it out of the buffer.

Sounds like either you are getting some unexpected characters or the second packet is begining to arrive while you are trying to read the first one, in which case clearing the buffer could have very adverse side effects.

i always set it to 1. the code i created sort of does what you are suggesting. when the rcv handler fires i queue the number of bytes available. i then have another set of routines that put the data back together in the format the user wants. so in the case of this poster he would request 38 bytes and if there were 38 bytes he would get them. if not he would get a zero length buffer.

the routines can be called from a loop, timer, or delegate.

[DaBoonDockSaint]

Thanks for that link Oblio it appears to be exactly what im trying to do so I will give that shot here soon and post my results.

[DataMiser]

i always set it to 1. the code i created sort of does what you are suggesting. when the rcv handler fires i queue the number of bytes available. i then have another set of routines that put the data back together in the format the user wants. so in the case of this poster he would request 38 bytes and if there were 38 bytes he would get them. if not he would get a zero length buffer.

the routines can be called from a loop, timer, or delegate.

That sounds much better than setting it for a higher number. Like I said it has been a very long time since I have used it. The issue I was having was that if the program was busy when the data came into the port the event did not fire causing the data to not be received. It would be there in the buffer but the receive event was lost.

The solution was to add a timer to check the inbuffer count and that worked so well that I ended up just disabling the on comm event for receiving by setting the threshold to 0. Never had another problem so I have continued to do it this way.

Note the original problem I ran into was with VB5 and PDQComm but I also saw it with MSComm and SAXComm so I assumed that it was likely to happen in newer versions as well, which may or may not be the case but the timer method works well in all cases.

[Oblio]

@data - i'd bet that the UI was unresponsive also?

[DataMiser]

No the program was working fine but if a block of code was running when the data came into the port. Let's say for example it was only 4 bytes that I was expecting which would complete very quickly. Also for example the user clicked on something about the the same time the data was arriving although slightly before it arrived the event would not fire. If additional data came in later then the event would fire and the previous data would be there in the buffer waiting and readable but if those 4 bytes were waiting on a response then the response would never be sent as the code would not run.

Adding a timer completely eliminates any possibility that this can happen. If the program is busy when the timer should fire that event also will not fire but the next cycle will see that there is data in the port and retrieve it correctly.

Another issue is when you are getting large blocks of data but also need to receive small blocks of data. The event fires when the data is coming in but has not yet completed. It is possible that while reading data that there is more data coming in that would cause the event to fire but the event is currently running so it can not fire a second time. Code added at the end of the event to check the inbuffer can minimize this possibility but it is still possible though unlikely that data could arrive after the buffercount is returned as 0 but the routine has not exited yet.

Using a timer set at 200 the worst case senario is that there is a 200 milisecond delay in retrieving the first and/or last byte of data where as using the on comm event it is possible not to get the data at all.

On another note if the comm routines are running in thier own thread the odds of running into such issue are greatly reduced but even in such a case I would still add a timer to make sure I get all the data.

[dglienna]

You don't need a timer if it's running in a separate thread. The thread runs until it completes the transfer. The main thread can't see it, or interrupt it

[Oblio]

people make assumptions about the serial port and especially the data received handler.

the routines i wrote receive the data when it is received, whatever size it is, and queues it up. when the user is ready to read the data my routines piece it back together in blocks that the user wants. so if you want 4 bytes at a time, you will either get 4 bytes, or zero. if you want a line terminated by newline, you get a line or you don't.

the routines make it simpler to separate the data reception from the processing of the data.

if you have a modem you should try it out. it uses the loopback feature of the modem to send and receive sample data. it also has a NMEA sentence reader, with checksum checker.

[DataMiser]

Again the issues I ran into were with older versions of VB, running in a seperate thread was not an option there.

Anyway the timer option does work well in pretty much any instance. I have one piece of software that has been running in 100s of locations now for up to 10 years without an issue.

[DaBoonDockSaint]

Thanks again Oblio you i was able to find my mistakes looking at your code from the previous forum.