Sensoray 2600 - Manual (Page 19)

2600 Family Instruction Manual 14 Chapter 3 : IOM Gateway
responsibility for detecting packet content errors by checking
for missing and/or incorrectly sized MRsps in response
packets.
In addition, the Ethernet client must assume responsibility for
the construction of valid MCmds, and the correct addressing of
MCmds so as to direct them to the intended target modules.
3.8.2.2 MRsp Faults
Several conditions can lead to packet content errors that cause
no MRsp to be received from a target module. In all of these
cases, the gateway will detect the absence of the MRsp by
means of a communication time-out:
• The client has directed an MCmd to a non-existent target
module.
• The target module has developed a hardware fault.
• The connection between the MM and target module has
failed.
• On the MM, the IOM port to which the target module is
attached has developed a hardware fault.
• An MCmd is corrupted en-route to the target module.
• An MCmd contains at least one unsupported or improperly
formatted action.
Another situation that can cause packet content errors is
corruption of the MRsp. If an MRsp is corrupted en route to
the gateway, the gateway will detect the faulty MRsp by means
of its invalid MRsp checksum and the MRsp will be omitted
from the response packet.
In all of the above mentioned cases, the gateway receives
either a faulty MRsp or no MRsp at all. Regardless of the
cause, the response packet will be missing an MRsp that
should be present. The client must detect this condition by
checking for the presence of all expected MRsps, and taking
the appropriate action when a missing MRsp is encountered.
3.9 Gateway Actions
This section describes the actions that are supported by the
MM gateway. As discussed in Section 3.3, the Ethernet client
may direct MCmds to the gateway by specifying the special
module identifier value 0xFF; this module identifier is reserved
for gateway controller functions.
All supported gateway actions are listed in Table 6. In most
cases, the supported actions may be executed in any order, and
any arbitrary number of actions may coexist in a single MCmd
so long as the MCmd does not exceed its maximum legal size
of 254 bytes.
3.9.1 GetLinkStatus
Function Returns the Active Port List.
Opcode 0x00
Command none
Response (LinkFlags<15:8>),
(LinkFlags<7:0>)
Notes The MM’s gateway is responsible for
maintaining a list of active IOM ports, called the
Active Port List (APL). As described in Section
3.7, the gateway continuously refreshes the APL.
GetLinkStatus
returns a snapshot of the
APL to the client.
The Ethernet client is permitted to communicate
with IOM ports that are indicated Active in the
APL. If the client attempts to communicate with
Table 6: Summary of Gateway Actions
Command Opcode Function
GetLinkStatus 0x00 Return link states of all IOM
ports.
GetInterlocks 0x01 Return safety interlock power
states.
--- 0x02-0xEF Reserved for future use.
SoftReset 0xF0 Restart module by jumping to
firmware entry point.
HardReset 0xF1 Restart module by forcing a
watchdog time-out.
ResetFlags 0xF2 Clear the specified bit flags in
the Status byte.
SetWatchdog 0xF3 Program the watchdog
interval.
--- 0xF4 Reserved for future use.
GetProductID 0xF5 Return module type identifier.
GetVersion 0xF6 Return module firmware
version number.
--- 0xF7-0xFE Reserved for future use.
NOP 0xFF No operation.
Parameter Function
LinkFlags Link state flags for IOM ports 0
through 15. Each bit is associated
with a single port. For example, bit 4
is associated with port 4. A bit flag is
set to one to indicate active link, or
zero to indicate inactive link.