ACC-72EX User Manual
DPRAM Data Processing
63
Client/Server Mechanism
Depending on the message destination or packet protocol, the UMAC program or application can act as a
client or a server. This section explains both methods, but selection of the appropriate method depends on
the destination or protocol option.
Application as Client
The host application may send request packets to the netX firmware at any time (transition 1
2).
Depending on the protocol stack running on the netX, parallel packets are not permitted (see protocol
specific manual for details). The netX firmware sends a confirmation packet in return, signaling success
or failure (transition 3
4) while processing the request.
The host application has to register with the netX firmware in order to receive indication packets
(transition 5
6). Depending on the protocol stack, this is done either implicitly (if application opens a
TCP/UDP socket) or explicitly (if application wants to receive unsolicited DPV1 packets). Details on
when and how to register for certain events is described in the protocol specific manual. Depending on the
command code of the indication packet, a response packet to the netX firmware may or may not be
required (transition 7
8).
Application as Server
The host application has to register with the netX firmware in order to receive indication packets
(unsolicited telegrams). Depending on the protocol stack, this is done either implicitly (if the application
opens a TCP/UDP socket) or explicitly (if the application wants to receive unsolicited DPV1 packets).
Details on when and how to register for certain events is described in the protocol-specific manual.
When an appropriate event occurs and the host application is registered to receive such a notification, the
netX firmware passes an indication packet through the mailbox (transition 1
2). The host application is
expected to send a response packet back to the netX firmware (transition 3
4).