Serial communication

Hi,

every 250 ms (timer event) I must send several commands via serial
port. The serial unit will answer to each command sent. I must wait the
answer before send the next command.

How can I achieve this? I receive the incoming data in the "data
received" event of the serial port. Furthermore I need to manage a
timeout: if I receive no answer within a specified amount of time an
event will be generated.

Here an example in pseudo-code:

Timer event:
Send command 1
Wait for answer
Send command 2
Wait for answer
Send command 3
Wait for answer... the communication was broken so the timeout event
will be generated

Data_received event:
Store the incoming string into the right variable (selected by the
command sent).

Timeout event:
Message to the user "Communication fault!"

Thank you for any advice

Marco / iw2nzm

"Marco Trapanese" <marcotrapaneseNOSPAM@libero.it> schrieb
> Hi,
>
> every 250 ms (timer event) I must send several commands via serial
> port. The serial unit will answer to each command sent. I must wait
> the answer before send the next command.
>
> How can I achieve this? I receive the incoming data in the "data
> received" event of the serial port. Furthermore I need to manage a
> timeout: if I receive no answer within a specified amount of time an
> event will be generated.
>
> Here an example in pseudo-code:
>
> Timer event:
> Send command 1
> Wait for answer
> Send command 2
> Wait for answer
> Send command 3
> Wait for answer... the communication was broken so the timeout event
> will be generated
>
> Data_received event:
> Store the incoming string into the right variable (selected by the
> command sent).
>
> Timeout event:
> Message to the user "Communication fault!"
>
> Thank you for any advice
>
> Marco / iw2nzm


I would introduce a state variable containing the current state of the
communication. Each time the 250ms timer event fires, check the state to see
if the previous communication is complete. In the data_received event, send
the next command depending on the current state. Also add another timer that
is started each time a command is sent. Stop it each time you receive data,
but if it fires, it indicates a timeout.

I would not wait for an answer in a loop in order not to block the interface
and to keep the thread responsive to the data_received event.


Armin

Armin Zingler wrote:

> I would introduce a state variable containing the current state of the
> communication. Each time the 250ms timer event fires, check the state to
> see
> if the previous communication is complete. In the data_received event, send
> the next command depending on the current state. Also add another timer
> that
> is started each time a command is sent. Stop it each time you receive data,
> but if it fires, it indicates a timeout.
>
> I would not wait for an answer in a loop in order not to block the
> interface and to keep the thread responsive to the data_received event.


Thank you very much for the quick answer! I guess it does the trick
Tomorrow I'll try it.

Bye!
Marco / iw2nzm

Hi,

By far the easiest way to do this is NOT to use DataReceived. Simply poll
the BytesToReceive property in a loop and grab the data needed when the full
response has been received -- or if you have to parse receive data to
determine when a completer message has been received, then append newly
received data to a buffer in the loop and parse it. Exit the loop only when
the data you want is there (or if a timeout occurs).

BTW, the polling method WILL NOT block the receive thread, which executes in
the background. However, if you need yout application to be responsive to
user input during polling, you will need to call Application.DoEvents()
inside the loop.

This approach (IMO) is better than using ReceiveData because state
information does not have to be passed around, AND because timeouts are
easily handled. This makes the code simpler and simpler means both better
performance AND more easily debugged.

The actual constuction of the loop can (and should) be in a method that
allows the code it contains to be reused by other commands and responses.

I have more details on the pros and cons of each approach in my book (see
below).

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.

Dick Grier wrote:

> Hi,
>
> By far the easiest way to do this is NOT to use DataReceived. Simply poll
> the BytesToReceive property in a loop and grab the data needed when the full
> response has been received -- or if you have to parse receive data to
> determine when a completer message has been received, then append newly
> received data to a buffer in the loop and parse it. Exit the loop only when
> the data you want is there (or if a timeout occurs).
>
> BTW, the polling method WILL NOT block the receive thread, which executes in
> the background. However, if you need yout application to be responsive to
> user input during polling, you will need to call Application.DoEvents()
> inside the loop.
>
> This approach (IMO) is better than using ReceiveData because state
> information does not have to be passed around, AND because timeouts are
> easily handled. This makes the code simpler and simpler means both better
> performance AND more easily debugged.
>
> The actual constuction of the loop can (and should) be in a method that
> allows the code it contains to be reused by other commands and responses.
>
> I have more details on the pros and cons of each approach in my book (see
> below).


It sounds very interesting. Thanks for your answer.

Marco / iw2nzm