MSComm and RS-232 in RealTime


Thread Starter

Jim Hebbard

We are currently monitoring a balance (scale) that transmits 9600,8,no parity, no handshaking or XonXoff as a continuous stream of text spaced at about 0.11 seconds per transmission. We have a VB program reading that data using MSComm (under win2000 Prof). Depending on how we set a timer or counter, the database contains "skips" every 29 or 30 or so counts, each count supposedly a second.

We have flipped the skips from time errors (weight updates every count, but two seconds elapsed between counts every 30 seconds) to weight errors (time stream matches counts perfectly but weight stream repeats a reading every 30 seconds) and back several times by programing changes. The "skips" are easy to see in a spreadsheet made from the data file, as in Case one every 30 counts two seconds elapse between counts, and in Case two the "2" that showed up in the delta t column is a zero (0).

We believe that it may have something to do with buffer activity in MSComm, which essentially sleeps until the next second appears, thus is not processing the scale data in the interim. However, we poll the scale by spending "SI" when we want the data, which should bring fresh data, only 0.11 second old, at the worst, from the scale.

Can anyone tell me if we could be getting stale data from MSComm in this situation? So far MSComm is called inside the Private SUB that does the calcs and data handling

We need help!

Jim Hebbard
Try using a VB event instead of a timer. Have the event fire after a certain number of characters are in the receive buffer.
I didn't have a lot of time this morning to digest all of what you wrote, but I wanted to quickly pass along a recent experience that I had with MSCOMM. A custom HMI/SCADA system I worked with last month uses MSCOMM to transmit text to
several large scrolling message displays. (I don't recall the name of the manufacturer.) Every so often a display would cease to update. Because this system was 'in production' a quick work-around was very appealing. The work-around involved nothing more than doubling up on message transmits. I suppose, in this case, if one message did not update the display the second
would. Not having a serial-data analyzer wth me I did not ever really discovered the reason. The message protocol contained a checksum and I suspect MSCOMM inserted some data, perhaps null characters, or, perhaps the OS allows MSCOMM to insert time gaps in the message transmit. For what ever reason, the messages probably failed to validate and the display ignored them.

I consider Windows 2000 by itself not to be a 'hard' real-time OS, and, MSCOMM not to be a real-time service. Perhaps you should build in to your application the ability to handle the skipped messages.

[email protected]

Robert Scott

I read a scale in real-time using C/C++ calls. It had a similar update rate. I used the primative Win32 API calls as follows:

CreateFile("COM1",..,FILE_FLAG_OVERLAPPED) to open.
SetupComm() to ensure a nice big input buffer.
dcb.EvtChar = 0x0a; to cause a COMM event whenever
the terminating LF was received.
WaitCommEvent() in overlapped IO mode to wait for
that terminating LF.
GetOverlappedResults() to poll for the state of
the overlapped WaitCommEvent()
ClearCommError() to find out how many characters
are in the buffer that was just terminated.
ReadFile() to read that number of characters.

We never missed a read, and we were reading eight separate scales at once through eight separate serial ports.
I'm confused. Are you polling the scale every .11 seconds, as you seem to be saying in the first paragraph, or are you polling the scale every 1 second as you seem to be saying in the third paragraph?

On the surface it seems to me that you may be experiencing some jitter in your "1 second" timer (maybe try a higher resolution timer mechanism?). If the MSComm control really is receiving unsolicited messages (compised of ???? characters) at a rate on the order of 10 messages per second, you might be running into some issues there, especially depending on CPU horsepower. Keep in mind that the MSComm control is relying on the windows message queue to "notify". I assume you are using the OnComm event and checking for data available AGAIN, before you leave the OnComm event, because it is definitely possible to loose OnComm events and end up leaving data in the buffer until more new data comes along. I've been told it is actually ok to use recursion (calling OnComm from within OnComm) to simplify the problem here, but it's probably just as easy, and more readable, to put a "while(InBufferCount>0)" spin loop in the OnComm event code. Also, without know the size of you messages, it hard to guess whether you've got a receive buffer of sufficient size to avoid overflow... If you have fixed length responses from the device, I would suggest you set RThreshold to match this value and pick an appropriately large buffer size (2-3 times the message size) as opposed to handling OnComm events for every single character coming in.

Bob Peterson

[email protected] wrote:
> The message protocol contained a checksum and I suspect MSCOMM
> inserted some data, perhaps null characters, or, perhaps the OS allows
> MSCOMM to insert time gaps in the message transmit. For what ever
> reason, the messages probably failed to validate and the display ignored
> them.

I ran across a similar problem once with an HPIB to RS232 interface. Periodically, and quite inexplicably, the interface would insert null
characters. Sometimes hundreds of them. Why it did this was a mystery to everyone involved, including the supplier of the device. But, I could show it by setting a VT100 terminal to display control characters, and now and then a bunch of nulls would just appear in the middle of a string. Sometimes it was a whole screen full (or more) of them. Best thing to do with all
ASCII streams is to ignore null characters all together.

Bob Peterson
please can u send a visual basic program to display a character generated by pic microcontroller transmitter. i have developed pic programming but vb progamming is giving me some problems,so please send literiture about that to
my e-mail as soon as possible

[email protected]