Sensoray 2600 - Manual (Page 13)

2600 Family Instruction Manual 8 Chapter 3 : IOM Gateway
3.1.2 Gateway Thread
All of the gateway’s IOM ports share a single, multiplexed
communication interface on the MM. As a result, all
communications between the MM and its connected IOMs
must take place in a serial fashion, and only one IOM may
communicate with the MM at a time. Since the MM
multiplexes/demultiplexes communications between the client
and the IOMs, the gateway employs a single thread to
communicate with all IOMs.
Upon receipt of a gateway command packet, the MM will
launch its gateway thread. As the gateway thread parses the
packet, each MCmd is extracted and forwarded to its target
module for execution. The gateway waits for an MRsp, which
is appended to the gateway response packet, and then the
parser moves on to the next MCmd. When all MCmds have
been processed in this way, the gateway response packet is sent
to the Ethernet client and the gateway thread terminates.
In preparation for communicating with an IOM, the gateway
connects its IOM communication interface to the target IOM.
After sending the MCmd to and receiving the MRsp from the
target IOM, the gateway disconnects its multiplexed interface
from the IOM port.
3.1.2.1 Overlapped Transactions
As long as at least one of the MM’s fifteen packet buffers are
available, the MM will queue any gateway command packets
that are received while the gateway thread is running. When a
gateway response packet is sent, the MM will process the
oldest gateway command packet pending in the queue.
An Ethernet client may perform overlapped gateway
transactions. This means that after it transmits a gateway
command packet, a client may send another command packet
before the first response packet is received. Any client that
implements overlapped gateway transactions must specify a
different sender’s UDP port number for each transaction so
that it will be able to match each response packet to its
associated command packet. In general, this implies that the
client is running a separate thread for each overlapped gateway
transaction.
Similarly, an Ethernet client may send a command packet to
the MM while the MM is processing another command packet
from a different client.
3.2 Action Lists
Every module command contains an action list (AL). The AL
contains a list of one or more operations that are to be
performed.
Each action list (AL) member, which is called an action,
specifies a single operation that is to be performed. Actions
are packed end-to-end in the AL without delimiters.
Actions are executed in the order they appear in the AL, until
either all actions have been performed, or an unsupported or
improperly structured action is encountered in the AL. In the
latter case, the non-compliant action is not executed, further
AL processing is immediately terminated, and the target
module will not generate a response.
3.2.1 Action Structure
Every action has a one-byte header that contains an opcode,
followed by any required command-specific parameters.
Actions may vary in length depending on the number and types
of any parameters that are needed to completely specify the
action.
Any AL that targets a specific IOM (via the gateway) is limited
to a maximum length of 252 bytes, including the AL header. If
the size of a target IOM’s actions exceeds this limit, the actions
may be distributed among two or more ALs such that the
resulting ALs do not exceed the length limit.
Figure 9: Structure of a Single Action
3.3 Module Commands (MCmd)
Every MCmd begins with a two-byte header that consists of a
target module identifier and a command byte count. A
variable-sized field, which follows the header, contains the
action list (AL), which is a list of actions that are to be
performed by the target module.
MCmds may vary in length, depending on the number and
character of the actions to be performed. The total length of an
MCmd, including its header, may not exceed 254 bytes. This
maximum length limit may be further constrained by the target
IOM; refer to the documentation for individual IOM types for
details.
Field Type Function
Opcode BYTE Action opcode. This opcode instructs the
target module as to what action is to be
performed.
ActParms[] BYTE Action-specific parameters. This field
contains zero or more bytes, depending on
the number and sizes of the supplied
parameters. Regardless of their actual
types, these parameters are treated as a
single byte array by the MM because in its
capacity as a client-to-IOM gateway, the
MM has no knowledge of the actions
supported by IoModules.
Opcode ActParms[]