A problem with MSComm at 38400b

Visual Basic >> A problem with MSComm at 38400b

I have a project where I use MSComm to receive data entering every
second at 38400 bauds. The data is made of NMEA sentences that need
processing for decoding purposes.

(!AIVDO,1,1,,,13:r`R5P1orpG60JeHgRSj4l0000,0*56) is an example of a
sentence received.

My routine to receive data goes like this (where commAIS) is the
name of the MSComm control:

Private Sub commAIS_OnComm()
If commAIS.CommEvent = comEvReceive Then
inbuf = inbuf & commAIS.Input
End If
End Sub

Then, with a timer, every second, I check for new messages in the
buffer, call the routine to decode the messages, then flush the buffer. I
can get 10 or so sentences like the one above every second.

The algorithm to detect the sentences goes like this:

Do I see the character indicating the beginning of a sentence ?
If yes, get the sentence until the end character is dectected.
Proceed with the routines to decode the sentence.
Is it the end of the buffer ? If no, redo the above.
If it is the end of the buffer, flush it.

All this works Ok as long as I don't do nothing else. I mean by that
that if I open a menu, point an object with the mouse, sometimes (too often)
everything will hang. No error reported but everything is frozen. No more
data received. I can work with other apps with <Shift><Tab> but mine has to
be closed with <Ctrl><Alt><Del>.

Do I need to put a DoEvents somewhere ? I don't know a thing about
priorities of the interrupts.

Thank you for the help.

Jacquelin Hardy

Visual Studio200

Visual Basic >> A problem with MSComm at 38400b Get rid of the timer - you don't need it.

In the OnComm event, be sure inbuf is dimmed as a static variable.
Every time the OnComm event fires, add whatever came in to inbuf just
like you're doing. Then check in inbuf for your end-of-sentence
character. If it's not there, don't do anything else - just exit the
sub. If it is there then do your processing. Before getting out, be
sure to reset inbuf to "".

HTH

On Thu, 10 Mar 2005 12:37:23 -0500, "Jacquelin Hardy"

> I have a project where I use MSComm to receive data entering every
>second at 38400 bauds. The data is made of NMEA sentences that need
>processing for decoding purposes.
>
> (!AIVDO,1,1,,,13:r`R5P1orpG60JeHgRSj4l0000,0*56) is an example of a
>sentence received.
>
>
> My routine to receive data goes like this (where commAIS) is the
>name of the MSComm control:
>
>Private Sub commAIS_OnComm()
> If commAIS.CommEvent = comEvReceive Then
> inbuf = inbuf & commAIS.Input
> End If
>End Sub
>
> Then, with a timer, every second, I check for new messages in the
>buffer, call the routine to decode the messages, then flush the buffer. I
>can get 10 or so sentences like the one above every second.
>
> The algorithm to detect the sentences goes like this:
>
>Do I see the character indicating the beginning of a sentence ?
>If yes, get the sentence until the end character is dectected.
>Proceed with the routines to decode the sentence.
>Is it the end of the buffer ? If no, redo the above.
>If it is the end of the buffer, flush it.
>
>
> All this works Ok as long as I don't do nothing else. I mean by that
>that if I open a menu, point an object with the mouse, sometimes (too often)
>everything will hang. No error reported but everything is frozen. No more
>data received. I can work with other apps with <Shift><Tab> but mine has to
>be closed with <Ctrl><Alt><Del>.
>
> Do I need to put a DoEvents somewhere ? I don't know a thing about
>priorities of the interrupts.
>
>Thank you for the help.
>
>
>Jacquelin Hardy
>

Visual Basic >> A problem with MSComm at 38400b

> Get rid of the timer - you don't need it.
>
> In the OnComm event, be sure inbuf is dimmed as a static variable.
> Every time the OnComm event fires, add whatever came in to inbuf just
> like you're doing. Then check in inbuf for your end-of-sentence
> character. If it's not there, don't do anything else - just exit the
> sub. If it is there then do your processing. Before getting out, be
> sure to reset inbuf to "".
>
> HTH
>
>

Or set inbuf equal to whatever is after the end-of-sentence character in
case you're using an RThreshold>1 and a second stream arrives.

HTH
Chris A. Kusmierz

> On Thu, 10 Mar 2005 12:37:23 -0500, "Jacquelin Hardy"

>
> > I have a project where I use MSComm to receive data entering
every
> >second at 38400 bauds. The data is made of NMEA sentences that need
> >processing for decoding purposes.
> >
> > (!AIVDO,1,1,,,13:r`R5P1orpG60JeHgRSj4l0000,0*56) is an example of a
> >sentence received.
> >
> >
> > My routine to receive data goes like this (where commAIS) is the
> >name of the MSComm control:
> >
> >Private Sub commAIS_OnComm()
> > If commAIS.CommEvent = comEvReceive Then
> > inbuf = inbuf & commAIS.Input
> > End If
> >End Sub
> >
> > Then, with a timer, every second, I check for new messages in
the
> >buffer, call the routine to decode the messages, then flush the buffer. I
> >can get 10 or so sentences like the one above every second.
> >
> > The algorithm to detect the sentences goes like this:
> >
> >Do I see the character indicating the beginning of a sentence ?
> >If yes, get the sentence until the end character is dectected.
> >Proceed with the routines to decode the sentence.
> >Is it the end of the buffer ? If no, redo the above.
> >If it is the end of the buffer, flush it.
> >
> >
> > All this works Ok as long as I don't do nothing else. I mean by
that
> >that if I open a menu, point an object with the mouse, sometimes (too
often)
> >everything will hang. No error reported but everything is frozen. No more
> >data received. I can work with other apps with <Shift><Tab> but mine has
to
> >be closed with <Ctrl><Alt><Del>.
> >
> > Do I need to put a DoEvents somewhere ? I don't know a thing
about
> >priorities of the interrupts.
> >
> >Thank you for the help.
> >
> >
> >Jacquelin Hardy
> >
>

Visual Basic >> A problem with MSComm at 38400b Thank you Martin

> Every time the OnComm event fires... ... check in inbuf for your
> end-of-sentence character
But don't you think this is too many checks? I get more than 1000
characters per second via MScomm.

Jacquelin H

> Get rid of the timer - you don't need it.
>
> In the OnComm event, be sure inbuf is dimmed as a static variable.
> Every time the OnComm event fires, add whatever came in to inbuf just
> like you're doing. Then check in inbuf for your end-of-sentence
> character. If it's not there, don't do anything else - just exit the
> sub. If it is there then do your processing. Before getting out, be
> sure to reset inbuf to "".
>
> HTH
>
>
> On Thu, 10 Mar 2005 12:37:23 -0500, "Jacquelin Hardy"

>
>> I have a project where I use MSComm to receive data entering
>> every
>>second at 38400 bauds. The data is made of NMEA sentences that need
>>processing for decoding purposes.
>>
>> (!AIVDO,1,1,,,13:r`R5P1orpG60JeHgRSj4l0000,0*56) is an example of a
>>sentence received.
>>
>>
>> My routine to receive data goes like this (where commAIS) is the
>>name of the MSComm control:
>>
>>Private Sub commAIS_OnComm()
>> If commAIS.CommEvent = comEvReceive Then
>> inbuf = inbuf & commAIS.Input
>> End If
>>End Sub
>>
>> Then, with a timer, every second, I check for new messages in the
>>buffer, call the routine to decode the messages, then flush the buffer. I
>>can get 10 or so sentences like the one above every second.
>>
>> The algorithm to detect the sentences goes like this:
>>
>>Do I see the character indicating the beginning of a sentence ?
>>If yes, get the sentence until the end character is dectected.
>>Proceed with the routines to decode the sentence.
>>Is it the end of the buffer ? If no, redo the above.
>>If it is the end of the buffer, flush it.
>>
>>
>> All this works Ok as long as I don't do nothing else. I mean by
>> that
>>that if I open a menu, point an object with the mouse, sometimes (too
>>often)
>>everything will hang. No error reported but everything is frozen. No more
>>data received. I can work with other apps with <Shift><Tab> but mine has
>>to
>>be closed with <Ctrl><Alt><Del>.
>>
>> Do I need to put a DoEvents somewhere ? I don't know a thing about
>>priorities of the interrupts.
>>
>>Thank you for the help.
>>
>>
>>Jacquelin Hardy
>>
>

Visual Basic >> A problem with MSComm at 38400b

> Thank you Martin
>
>
>>Every time the OnComm event fires... ... check in inbuf for your
>>end-of-sentence character
>
> But don't you think this is too many checks? I get more than 1000
> characters per second via MScomm.

The Comm event fires ... as often as the Comm event fires.

Visual Basic >> A problem with MSComm at 38400b > The Comm event fires ... as often as the Comm event fires
Good one Bob o Bob :-)

What I meant to say is : is it better to run a routine everytime the OnComm
event fires, rather that checking for a specific character in the buffer
once a second or so, knowing that I will have to check as many characters as
the number of times the OnComm event fired, more or less ?

And while I am treating the data, what could make the MsComm to stop sending
? Should I put DoEvents during my routine to treat the data ?

Regards

Jacquelin H

>
>> Thank you Martin
>>
>>
>>>Every time the OnComm event fires... ... check in inbuf for your
>>>end-of-sentence character
>>
>> But don't you think this is too many checks? I get more than 1000
>> characters per second via MScomm.
>
>
> The Comm event fires ... as often as the Comm event fires.

Visual Basic >> A problem with MSComm at 38400b Think of it this way?

You want to accept all data and just throw it into a buffer
until you get a completion signal. After you have all the sent
data, then start processing whats in the buffer. If you have
two threads set up, you can insert an end of processing
signal/character into your buffer / and use a wait for more
data signal/character to process the data as it's coming in.

Is there an end of data signal/character?

The end of data signal is used quite a bit in alot of different
technologies. When working with recordsets, there is an end
of file signal. It's actually a variable that is set to to true when
you've reached the end of file.

It becomes handy in loops to read through all the records
in a recordset.

Do While Not rs.EOF
sFirstName = ReadDAOString(rs.Fields("FirstName"))
sLastName = ReadDAOString(rs.Fields("LastName"))
sAddr1 = ReadDAOString(rs.Fields("Addr1"))
'and so on
rs.MoveNext
End While

The only use I see for the timer, would be in the event that
data gets lost for some reason and you'd need to send a
request to resend last packet.

Someone let me know if I'm off base or on target. <g>

--
Jim Carlock
Please post replies to newsgroup.

> The Comm event fires ... as often as the Comm event fires
Good one Bob o Bob :-)

What I meant to say is : is it better to run a routine everytime
the OnComm event fires, rather that checking for a specific
character in the buffer once a second or so, knowing that I
will have to check as many characters as the number of times
the OnComm event fired, more or less ?

And while I am treating the data, what could make the MsComm
to stop sending? Should I put DoEvents during my routine to
treat the data?

Regards

Jacquelin H

"Bob O`Bob" a écrit:

>
>> Thank you Martin
>>
>>>Every time the OnComm event fires... ... check in inbuf for your
>>>end-of-sentence character
>>
>> But don't you think this is too many checks? I get more than 1000
>> characters per second via MScomm.
>
> The Comm event fires ... as often as the Comm event fires.

Visual Basic >> A problem with MSComm at 38400b Hi,

I suggest that you parse your receive data in the OnComm event. If you get
a copy of my book (see below), you will see how I do it. After you parse
the data, and have a complete sentence, make sure that you set inbuf = ""
(or, use Mid to set it to the balance of inbuf AFTER the completed
sentence).

Using a Timer will not save any useful processing time, and it complicates
the program logic. IMO.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.