Getting started
Copyright IXXAT Automation GmbH
28
IEM Manual, 1.5
2.3.3 Service Channel access
EMI_stsStatusGet()
EMI_evtEventCheck()
EMI_srvServiceHandle()
query for indication
query for response
Figure 2-6: Service channel access
The service channels provide a handshake messaging between module and
host. Therefore the channels have to be processed cyclically to ensure that
request/response and indication/confirmation mechanisms work properly.
The demo application implements a way to serve the channels in an asyn-
chronous manner. For each service channel event (request, response, indica-
tion, confirmation) a separate callback function is registered inside the EMI
during
the
startup
(
APPdemo_EventRegisterGeneric()
using
). So consecutively response and indication events
lead to an execution of the appropriate callback function in which the message
could be saved. In case of the demo application the indications and responses
are stored inside a pool which is cyclically polled and worked by
APP_RespQueueHandle()
respectively
APP_IndQueueHandle()
inside
AP-
Pdemo_ProcessServiceChannels()
called by
DemoMain()
.
Commonly for all protocols the set value respectively get value function (for
variables
created
on
the
host
side)
has
to
be
executed
by
APP_IndQueueHandle()
. Furthermore all protocol specific actions could be
initiated by the decoding of the received message.
2.3.4 Creation of variables
Each variable which should be accessible through the module has to be regis-
tered on the module side. This is commonly done via command channel during
the startup phase of the application. Nevertheless the creation of new varia-
bles is possible during runtime.
Basically the module distinguishes between three types of variables:
Variables in the IO area section of the DPRAM
Variables in the acyclic area of the DPRAM