EADnet Software Protocol for the
EPICURE ARCnet Network
T. Kiper, T. M. Watts
EADnet is a simplified network primarily for the support of communications between Beamline resident ARCnet modules (like 1010 MADC Controllers and 1032 SWIC controllers) and VME front-end resident ARCnet support modules (like The Listener and VME Alarm Monitor Processor). The physical and data link layers of EADnet are based on the ARCnet local area network, a token passing network using 2.5 megabit serial communications on coaxial cables. ARCnet was chosen as a good match for our physical cable plant, cable lengths, and the branching topology of the Experimental Areas. It is low cost means for providing movement of large data blocks, and commercial chips are readily available which handle the ARCnet protocol and token passing.
The physical topology chosen for EADnet is that of a set of global ARCnet links connecting the service buildings to the Epicure VME Front Ends in the Operations Center. Each service building will have at least one EADnet Bridge Processor connecting the internal ARCnet network of the service building to the global network link. The Bridge Processor is a simple system based on the Intel 80960SA RISC processor and ARCnet interfaces in a 3U Repeater Module rack. The bridge system provides a path for eventual upgrade of the global ARCnet links to higher bandwidth serial links without having to incur the expense of modifying ARCnet interfaces embedded on several hundred modules.
The data link layer of EADnet is based on ARCnet datagram packets.
The ARCnet chips used by all systems connected to EADnet must
support Long Packets [1] to handle messages
longer than the standard 253 bytes.
The layout of the Short
ARCnet packet is shown in Figure
and that of the Long
ARCnet packet in Figure
.
Long packets require a minimum length of 257 bytes. That is, messages with data lengths in the range of 254 to 256 bytes must be padded to a length of 257 bytes in order to be handled properly. If the data has not been properly padded, the COM9026 chip will use the old data in the buffer.
ARCnet packets contain a source node, destination node, byte count and data. The source node number is automatically filled in by the transmitter. The source and destination node numbers are relative to the physical ARCnet network. The remainder of the packet is the data and (basically) the count of data bytes. The ARCnet chip provides a positive acknowledge that the packet has reached the RAM buffer at the destination node and that the packet has the proper CRC.
Every ARCnet node has a unique identification or node address in the
range of 1 to 255. Address 0 is used for Broadcast messages
(individual nodes can elect to ignore broadcast messages as desired).
Larger ARCnet systems (see Section
) can be built
by layering a transport protocol on the ARCnet protocol and using
store-and-forward bridges to interconnect separate ARCnet systems.
EADnet is basically a datagram transport service. No packet
acknowledgements beyond those provided by the ARCnet chip at the
data link layer are provided by EADnet.
The EADnet packet illustrated in Figure
is contained
within the data portion of an ARCnet packet. The System Code (or
vendor identification, protocol identification) are the first two bytes
of the EADnet packet, and are used as a general protocol identifier
[1] allowing for multiple, independent message formats to
coexist on a single physical network. A System Code for Fermilab
has been assigned by the DATAPOINT Local Area Networking Group.
EADnet is assigned a value of decimal ( 130) for the System Code and a value of one ( 1) for the Vendor Protocol ID.
EADnet supports long messages (up to 7936 data bytes) by use of a simple packeting scheme originally used by the ACNET Control System network. Each EADnet packet contains two nibbles (fields of 4-bits) which encode the current packet number and the maximum packet number of the message. If both nibbles are zero, then the message occupies a single EADnet packet. Otherwise up to 16 packets (numbered from 0 to 15) can make up a single EADnet message. The two nibbles serve to:
The data in the EADnet packet, is the information used by the EADnet user. In addition to the data, a Data Typecode is kept in the EADnet for the user. This field can be used in many ways by the user code; it might represent an operation requested to be performed, or specify the type of data in the message.
The EADnet addressing scheme is based on the physical heirarchy of the ARCnet network. Any address (both source and destination addresses are in the EADnet packet) is based on a triple containing the ARCnet node number of the service building (DHS), the ARCnet node number of the system on the intrahouse ARCnet (DND), and a Network Task Identifier (NTI) to identify a software object. The NTI's represent network service points, such as the fast time plot task or a name server task. The task which supplies the services of that network object declares its NTI to the local EADnet services so that the connection between the NTI and the local system task identifier can be made dynamically.
Keywords: EADnet, network, ARCnet
Distribution:
