By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,212 Members | 1,110 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,212 IT Pros & Developers. It's quick & easy.

Timer won't start from serial port receive routine

P: n/a
Hi to all.
I have a application that receives data via the serial port. I don't
know the number of bytes that are going to
be coming in. It could be 10 up to 150. (9600 baud)
I have decided to start a timer when the first byte arrives and wait
for a pre determined time and then check
the serial buffer for the data.
I can't seem to get the timer to start from within the serial receive
routine though.
I enable it , start it and set the interval , but tick event never
fires.
What could be causing this?
Also , is there a better way of tackling this problem , without the
use of a timer?

Cheers
Rob
Oct 29 '08 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"seegoon" <se*******@yahoo.comschrieb
Hi to all.
I have a application that receives data via the serial port. I don't
know the number of bytes that are going to
be coming in. It could be 10 up to 150. (9600 baud)
I have decided to start a timer when the first byte arrives and wait
for a pre determined time and then check
the serial buffer for the data.
I can't seem to get the timer to start from within the serial
receive routine though.
I enable it , start it and set the interval , but tick event never
fires.
What could be causing this?
Also , is there a better way of tackling this problem , without the
use of a timer?
Haven't done it yet, but the example in the documentation reads in another
thread in a loop. You can specify a Timeout while reading. (ReadTimeout
property).

Independently answering the question about the Timer: you should mention
which kind of Timer. There are three. I guess it's a Windows.Forms.Timer. I
also guess you start it in the DataReceived event. Then, it doesn't work
because, as the documentation on the DataReceived event says, the event is
raised in another thread. That thread does not have a message loop like your
main thread. Therefore, a Forms.Timer is not the right choice.
Armin

Oct 29 '08 #2

P: n/a
Hi,

Don't use a timer. Use code. For example,
Dim StartTime As Long = Now.TimeOfDay.TotalMilliseconds

To start timing, the call Now.TimeOfDay.TotalMilliseconds subsequently, and
subtract StartTime from it to measure elaplsed time. I do this to handle
similar protocols, and it works well.

Dick
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
Oct 29 '08 #3

P: n/a
On Oct 29, 2:04*pm, "Armin Zingler" <az.nos...@freenet.dewrote:
"seegoon" <seegoo...@yahoo.comschrieb
Hi to all.
I have a application that receives data via the serial port. I don't
know the number of bytes that are going to
be coming in. It could be 10 up to 150. (9600 baud)
I have decided to start a timer when the first byte arrives and wait
for a pre determined time and then check
the serial buffer for the data.
I can't seem to get the timer to start from within the serial
receive routine though.
I enable it , start it and set the interval , but tick event never
fires.
What could be causing this?
Also , is there a better way of tackling this problem , without the
use of a timer?

Haven't done it yet, but the example in the documentation reads in another
thread in a loop. You can specify a Timeout while reading. (ReadTimeout
property).

Independently answering the question about the Timer: you should mention
which kind of Timer. There are three. I guess it's a Windows.Forms.Timer.I
also guess you start it in the DataReceived event. Then, it doesn't work
because, as the documentation on the DataReceived event says, the event is
raised in another thread. That thread does not have a message loop like your
main thread. Therefore, a Forms.Timer is not the right choice.

Armin
Thanks.
Used a different timer(system.timers.timer) , and it works great.
Is there a more elegant way of handling unknown serial data lengths?

Cheers
Rob
Oct 30 '08 #4

P: n/a
On Oct 29, 5:55*pm, "Dick Grier" <dick_grierNOSPAM@.msn.comwrote:
Hi,

Don't use a timer. *Use code. *For example,
Dim StartTime As Long = Now.TimeOfDay.TotalMilliseconds

To start timing, the call Now.TimeOfDay.TotalMilliseconds subsequently, and
subtract StartTime from it to measure elaplsed time. * *I do this to handle
similar protocols, and it works well.

Dick
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
Seewww.hardandsoftware.netfor details and contact information.
Thanks , I'll look at this as an option.
Cheers
Rob
Oct 30 '08 #5

P: n/a
"seegoon" <se*******@yahoo.comschrieb
Used a different timer(system.timers.timer) , and it works great.
Is there a more elegant way of handling unknown serial data lengths?
My latest serial port experience is from VB6 times. :) I'd do it as shown in
the example that I mentioned: Run in a separate thread and read and read
and.... add everything to your buffer and do with it what you need.
Armin

Oct 30 '08 #6

P: n/a
You can do what I suggested (I do this on occasion), or use
Windows.Timers.Timer. I also use it. Some care is required, because of
threading issues, but it should be OK, too.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
Oct 30 '08 #7

P: n/a
It depends on the message. For instance, GPS data is variable length, but
since the message format is defined by the header label, it's relatively
easy to detect the end of the message. Just keep retrieving data from the
buffer and adding it to a data queue. Handle the serial port in the
separate thread and add received characters to the queue as received. When
the data in the queue is a complete message remove it from the queue and
process it. Or, if your messages have an end of message indicator, process
into the queue until the EoM indicator appears, then remove and process the
queue contents. You don't need a timer unless you want to watch for
interruptions to the transmission, or perhaps you want to process a partial
message if the remainder isn't received within a reasonable time (for GPS,
partial messages are usually discarded, as they can't be checked for
accuracy). Depending on what other processing is required, you may also want
to use a timer to control how frequently the queue is checked for a complete
message.

"seegoon" <se*******@yahoo.comwrote in message
news:95**********************************@l42g2000 hsc.googlegroups.com...
On Oct 29, 2:04 pm, "Armin Zingler" <az.nos...@freenet.dewrote:
snip <
Thanks.
Used a different timer(system.timers.timer) , and it works great.
Is there a more elegant way of handling unknown serial data lengths?

Cheers
Rob

Oct 30 '08 #8

This discussion thread is closed

Replies have been disabled for this discussion.