Sensoray 2600 - Manual (Page 18)

2600 Family Instruction Manual 13 Chapter 3 : IOM Gateway
Sync state will repeat. If the IOM responds, but it indicates
that it has not been reset, the gateway will switch to the Reset
state. If the IOM responds and indicates that it has been
successfully reset, the gateway will switch to the Init state.
Communications between the gateway and the connected IOM
(if any) are inhibited in the Sync state.
Init State. The gateway issues a ResetFlags action to the
target IOM to reset its HRST status flag. The gateway now
assumes that an IOM is connected to the port because an MRsp
was received in the Sync state. In the case of an MRsp
time-out, or if the IOM indicates that it has been reset again,
the gateway will switch back to the Sync state. If the IOM
responds and indicates that it has not been reset again, the
gateway will switch to the Connect state. Communications
between the gateway and the connected IOM are inhibited in
the Init state.
Connect State. The gateway issues a LinkQuery action to
the target IOM. The port will remain in the Active state as
long as the IOM responds and does not execute a module reset.
If the IOM fails to respond to an MCmd, or if the IOM
indicates it has been reset, the gateway will switch to the Sync
state. Communications between the gateway and the
connected IOM are allowed while the IOM port is in the
Connect state.
3.7.4.3 APL Management
From the viewpoint of the Ethernet client, each of the
gateway’s IOM port state machines is in one of two states: Link
or Active. The Link state collectively refers to the state
machine’s Reset, Sync and Init states, while the Active state is
synonymous with the state machine’s Connect state. The APL
reflects the current state of each IOM port from the client’s
perspective.
In the APL, an IOM port is indicated active if it is in the Active
state or inactive if it is in the Link (inactive) state. When a port
is in the Active state, communications between the Ethernet
client and connected IOM are enabled. In the Link state, all
communications between client and IOM port are inhibited.
The gateway will reject any client-originated MCmds that are
directed to an IOM that is in the Link state.
3.8 Error Detection
Communication errors can be detected by means of two
mechanisms: integrity checking and content analysis. Both of
these mechanisms may be employed by an Ethernet client to
detect errors in response packets. The MM detects command
packet errors by means of full integrity checking and partial
content analysis, and therefore the MM depends on target
modules for completion of the command packet content
analysis.
3.8.1 Integrity Checking
From an Ethermet client’s viewpoint, integrity checking
consists of ensuring that an expected, intact response packet is
received from the MM in a timely manner. Integrity errors can
result from a variety of conditions:
• Soft errors. Occasionally, Ethernet packets travelling
between the client and MM may be corrupted by noise,
either on the Ethernet physical media or at the transmitter
or receiver.
• Hardware failure on the MM module, the client’s Ethernet
interface, or the communication path between the client
and the MM.
To fully implement integrity checking, the client must employ
a communication watchdog timer. The watchdog timer is
started when a command packet is first sent to the MM. If the
watchdog times out before a matching response packet is
received, an integrity error has been detected.
The overall integrity of a command or response packet is
inherently qualified by the packet’s encapsulating UDP
datagram header checksum. If the UDP checksum is valid, the
encapsulated command or response packet is assumed to be
intact. Conversely, the encapsulated packet is assumed to be
corrupt if the UDP checksum is not valid.
The MM depends on its protocol stack’s UDP checksum
validation mechanism to detect integrity errors in command
packets. In the case of a bad command packet checksum, the
MM will reject the entire packet and cancel the transmission of
a response packet; the client should detect the missing response
packet, and hence, the integrity error, by means of a
communication time-out.
In a similar fashion, the client relies on it’s own UDP
checksum validation mechanism to detect integrity errors in
received response packets.
The possibility exists that the MM might receive and execute a
valid command packet, but the encapsulating Ethernet packet
could become corrupted, thereby rendering the UDP checksum
invalid. In this case, the client’s protocol stack will reject the
packet, and the client must detect this condition by means of a
communication time-out.
3.8.2 Content Analysis
Packet content errors, which are defined here as improperly
formed or missing command/response packet components, can
occur for a variety of reasons:
• Client programming errors.
• Soft errors that occur infrequently, resulting in the
corruption of packets moving between the MM and a
connected IOM.
• Hardware failure of the MM, a connected IOM, or the
interface cable connecting an IOM to the MM.
3.8.2.1 MCmd Faults
The gateway is unaware of the types of modules to which its
IOM ports are connected; it serves only as a gateway between
the client and IOMs. As a result, the client must assume