Echelon Neuron C - Manual (Page 148)

136 How Devices Communicate Using Application Messages
The following example indicates one way asynchronous and direct processing
cannot be combined. Do not include message completion events in a task
associated with a message completion event clause:
when (msg_completes)
{
post_events();
if (msg_completes)
// not recommended
x = 4;
}
You can use asynchronous event processing in programs that also do direct event
processing. Asynchronous event processing is the typical method for processing
events. This method results in smaller application programs. You should call
the flush_wait( ) function before the transition from asynchronous to direct event
processing. The flush_wait( ) function ensures that all outstanding completion
events and response events are processed before switching to direct event
processing.
Here is an example of sending a message and processing the completion event
directly (that is, checking the event inside a task rather than inside a when
clause):
msg_tag motor;
#define MOTOR_ON 0
when (x==3)
{
// send a message
flush_wait();
msg_out.tag = motor;
msg_out.code = MOTOR_ON;
msg_send();
// check completion status
while (!msg_succeeds(motor)) {
post_events();
if (msg_fails(motor))
node_reset();
}
}
Using the Request/Response Mechanism
Request/response messages provide a mechanism for an application running on
one device to request data from an application running on another device. The
request/response mechanism is used automatically by the Neuron firmware to
poll input network variables and can also be used by application programs that
use application messaging.
A request is a message that uses the request service. Sending a request message
is similar to polling a network variable. A poll receives the most recent value
from the scheduler for a particular network variable. A request, in contrast, can
force the application on the responding device to evaluate the request
at the time
of the request and then send back a response.