Sensoray 2600 - Manual (Page 12)

2600 Family Instruction Manual 7 Chapter 3 : IOM Gateway
Chapter 3: IOM Gateway
3.1 Overview
This chapter describes the behavior of the MM in its role as
communication gateway to all connected IOMs.
In addition to its primary function, which is to route
communication traffic between Ethernet clients and IOMs, the
gateway also provides clients with access to the following
utility resources:
• Local reset log. This enables a client to determine
whether the MM has been reset.
• Reset control. This enables a client to initiate soft and
hard resets on the MM.
• Interlock status. A client may use this to examine the
states of external power supplies and application interlock
contacts.
• Link status. These status indicators, which indicate the
real time link status for all IOM ports, are dynamically
updated when IOM port connections are changed.
• MM attributes. This exposes local MM attributes such as
the MM firmware version number.
3.1.1 Gateway Packets
An Ethernet client communicates with the gateway, and all
IOMs connected to the gateway, by means of gateway packets.
There are two types of gateway packets: command and
response, both of which constitute the payload portion of a
UDP datagram.
Gateway command packets are transmitted from the client to
the MM, which in turn forwards packet components to their
appropriate target modules for execution. The MM gathers
responses from the target modules, assembles the responses
into a single gateway response packet, and then transmits the
response packet to the originating client.
A gateway command packet consists of a list of one or more
module commands (MCmd) that are packed together in the
command packet without delimiters. Each MCmd is directed
to a specific module for execution. The target module for a
particular MCmd may be any connected IOM or the gateway
itself. MCmds are executed in the order in which they appear
in the command packet.
A gateway module response (MRsp) is produced by a target
module in response to every fully executed MCmd. After
issuing an MCmd to a target module, the MM always waits to
receive the associated MRsp before issuing the next MCmd.
As each MRsp is received, it is inserted into a gateway
response packet. The MRsps are sequenced in the response
packet in the order they were produced, thereby matching the
order of execution of the associated MCmds. When all of the
MCmds belonging to a command packet have executed, the
response packet is sent to the client.
3.1.1.1 UDP Encapsulation
Every gateway packet is encapsulated in a single UDP payload
as shown in Figure 7.
Figure 7: Gateway Packet Encapsulation
Gateway command packets must always be sent to UDP port
10000, and gateway response packets always originate from
UDP port 10000.
3.1.1.2 Retry Management
The first byte of each gateway (and comport) command packet
may be modified by the client so as to enable the MM’s retry
control mechanism.
Figure 8: Modified First Byte
Bits 4 to 6 are replaced with a transaction sequence number
that has a numeric value from one to six. This sequence
number is used by the MM to detect duplicate command
packets resulting from transaction retries.
When the MM receives a first-attempt command packet (i.e., a
command packet that is not recognized as being a duplicate of
an earlier received command packet), all of the packet’s
commands are executed and the response packet is both sent to
the client and cached locally. When the MM receives a
duplicate (i.e., a “retry”) of an earlier command packet, the
packet’s commands will not be executed nor will a response
packet will be generated; instead, the previously cached
response packet will be sent to the client as a reply to the
duplicate command packet.
If the transaction sequence number equals zero or seven, the
command packet is always regarded as a first attempt and the
response packet is not cached. In this case, retries are not
possible.
UDP Datagram
Command Packet Header Payload
MCmd[]
MRsp[]
7
x
6
S2
5 4
S1
3
x
2 1 0
x x x S0
Transaction sequence
number: 1 to 6