Instrumentation Network Protocol

 

Epicure Design Note 136.4

11 May 1996

Paul Kasley

 

This document describes a proposed protocol for the Instrumentation Network ("InNet"), an Arcnet LAN intended to provide communications between NIM-based instrumentation modules and the Epicure data acquisition system. The protocol is built around ControLink, a commercial set of Arcnet link-layer services.

 

1. ControLink

 

ControLink is a set of ANSI C routines providing Arcnet datagram transport between application mailboxes called "Service Access Points" (SAPs). A SAP is defined as a logical address within a node. Incoming messages are sorted by ControLink and sent to the appropriate SAP buffer. Each Arcnet device will have several SAPs associated with its physical node number. A SAP may be defined as individual or group and may be dynamically opened and closed on a node. Messages addressed to a group SAP are received simultaneously by all nodes in a group while an individual SAP is addressed uniquely on a single node. Identical SAP numbers may be used for group and individual access. Thus, an individual SAP might be assigned for device initialization while the same SAP having the group attribute can be used to initialize all devices on a network. ControLink allows a maximum of 64 individual and 64 group SAPs per node.

 

A short ControLink packet has the following format on the data link:

0	ALERT BURST
1	SOH
2	SID
3	DID
4	DID
5	COUNT
6	SC
7	DSAP
8	SSAP
9	CONTROL
10
	INFO
n-2
n-1	CRC
n	CRC

The application code interfaces to the SAPs through ControLink LLC services. The LLC services use the following structure to parse ControLink packets:

The message buffer contains the InNet packet. Event, SSAP, and DSAP are passed to LLC services as arguments. All other parameters, including the dstation, must be set up by the application before calling an LLC service. The control field in the packet is filled in by the LLC service.

 

The LLC message buffer view of a ControLink packet is:

Data pointer+0	SID
+1	DID
+2	Byte Count MSB
+3	Byte Count LSB
+4	System Code
+5	DSAP
+6	SSAP
+7	Control Byte
+8	User Information
.	.
.	.
.	.
+n	User Information

 

Note that the buffer view is the same for short and long packets. The actual transmission packet is adjusted by ControLink for packets of over 253 bytes.

 

InNet is layered on top of ControLink to provide communications between InNet nodes. To accomplish this, the InNet protocol assigns a number of ContoLink SAPs for node and network management, defines fields within the ControLink information block, and describes network transactions and procedures.

 

Throughout this document, the acronym "ISAP" (Initiating SAP) refers to the SAP that initiates a transaction and "TSAP" (Target SAP) refers to the SAP that is the target of the ISAP. During a transaction between two nodes, the ISAP and TSAP values will be used as both SSAP and DSAP in the ControLink header depending on the direction of the packet flow.

 

2. InNet Packet Format

 

2.1. Packet structure

 

The information (INFO) field of a ControLink packet used for InNet has this structure for single packet messages:

10	0	PACKET COUNT=1
	1	PACKET SEQ. NR.=1
	2	CONNECT FLAGS
	3	(reserved)
	4	DATA LENGTH=2-65535
	6	(data)
	.	DATA LENGTH=2-65535
	.	(data)
	.	...
	.	...
	.	DATA LENGTH=2-65535
	.	(data)
n-3, n-2	k-1, k	END-OF-LIST FLAG=$0000

 

Note that the data length value for each data segment is to include the two data length bytes. For example, a segment containing four information bytes has a data length of six. A data length value of 0 is interpreted as end-of-list. A data length of 1 is not allowed. A segment with a length of 2 contains no information.

 

Batching is accomplished by including multiple data segments in a single message.

 

2.2. Message continuations

 

Continuations are handled by stripping all header information from the packets and concatenating the data segments. The entire message is then parsed based on the linked list of data segments and the DSAP. Multiple packet transmissions to InNet modules are discouraged since most modules will use an 8051-derived microcontroller having extrememly limited memory and processing resources. The DSAP and SSAP are the same in all packets of a multiple packet message and are assumed to apply to all data segments in the reconstructed message.

 

The following is an example of a multiple packet message:

 

PACKET COUNT=3

PACKET SEQ. NR.=1

CONNECT FLAGS

(reserved)

DATA LENGTH 1

(data segment 1)

DATA LENGTH 2

(data segment 2)

...

...

DATA LENGTH 3

(data segment 3)

 

PACKET COUNT=3

PACKET SEQ. NR.=2

CONNECT FLAGS

(reserved)

(data segment 3 contd)

...

...

...

 

PACKET COUNT=3

PACKET SEQ. NR.=3

CONNECT FLAGS

(reserved)

(data segment 3 contd)

DATA LENGTH 4

(data segment 4)

...

...

DATA LENGTH 5

(data segment 5)

END-OF-LIST FLAG=$0000

 

The reconstructed message is:

 

DATA LENGTH 1

(data segment 1)

DATA LENGTH 2

(data segment 2)

...

...

DATA LENGTH 3

(data segment 3)

(data segment 3 contd)

...

...

...

(data segment 3 contd)

DATA LENGTH 4

(data segment 4)

...

...

DATA LENGTH 5

(data segment 5)

END-OF-LIST FLAG=$0000

 

2.3. Byte ordering

 

Fields within a packet use big-endian ordering unless explicitly noted otherwise. This means that the most significant byte of a multiple byte field will be positioned closest to the message header.

 

2.4. Reserved fields

 

Reserved and undefined fields are to be set to all ones.

 

2.5. Null packet

 

A packet count and packet sequence of zero indicates a null InNet message being used by a ControLink utility. All other fields will be ignored and need not be present.

 

2.6. Empty packet

 

The minimum packet size is 17 bytes plus the alert burst: 7 bytes standard Arcnet header and trailer, 4 bytes ContoLink header, and 6 bytes InNet header and terminator. An empty packet may be used in lieu of actual traffic to maintain a connection between SAPs.

 

3. Connections Between SAPs

 

A SAP sending a multiple packet transmission may optionally establish a connection with the destination SAP to ensure exclusivity during the entire transfer.

 

Connection establishment and termination may occur in parallel with data transfer. Devices that support the connection mechanism must be able to conditionally accept data at all phases of a session, although the decision to include data with set-up packets is left to the module programmer.

 

3.1. Connection establishment

 

A connection between two SAPs is established by a sequence of handshakes that use the connect flags byte. The ISAP initiates the process by sending a CONNECT REQUEST to the TSAP. The TSAP may respond with either a CONNECT ACCEPT or a CONNECT REJECT. The TSAP is free to establish its own policies for granting a connection to the ISAP. A connection is considered to exist when the ISAP receives an acceptance packet from the TSAP.

 

3.2. Connection maintenance

 

The connection is maintained by the continued exchange of packets having the CONNECT AFFIRMATION flag set. Unsolicited packets from other node/SAPs and packets not having the CON-AFRM flag set will be ignored.

 

3.3. Connection termination

 

A connection is severed when one side sends a DISCONNECT. The receiver of the disconnect returns a DISCONNECT ACKNOWLEDGE. If a connected SAP does not receive a packet having the CON-AFRM flag set within any 500 msec interval, the SAP should attempt to disconnect and then unilaterally sever the connection.

 

3.4. Connection Flags Byte

 

Bits 0 and 1 are  reserved for future use and must always be sent as zero.

 

3.5. Example SAP Connection Dialog

 

Sent by ISAP	Sent by TSAP	Comment
Connect Request
	Connect Reject	Initial request by ISAP rejected by TSAP. Packet data is ignored by TSAP.
Connect Request
	Connect Accept	Subsequent request is accepted. Packet data is accepted by TSAP.
Connect Affirm		Affirm flag is set by both ends during the entire dialog. Data is transferred between ISAP and TSAP.
	Connect Affirm
Connect Affirm
...	...
...	...
Connect Affirm
	Connect Affirm, Disconnect Request	TSAP is hanging up. Final data packet to ISAP is included.
Connect Affirm, Disconnect Acknowledge		ISAP acknowledges TSAP on-hook with an empty packet.

 

 

4. InNet SAPs

 

SAPs are grouped as mandatory or optional, and reserved or un-dedicated/available. All nodes respond in the same fashion to the mandatory and optional SAPs. Reserved SAPs are used for network and node management. All nodes must support reserved mandatory SAPs. Reserved optional SAPs may be implemented at a node. Undedicated SAPs are available for general use; however, the response of a node to an undedicated SAP is not defined. The user must ensure that all nodes on a network respond to an undedicated SAP in a non-disruptive fashion. To enforce adherence to SAP conventions and assignments, a registry is to be maintained on the Warner VAX cluster in the directory "USER$DISK1: [HDWDOCS.INNET]".

 

5. The Node Object Table (NOT)

 

The Node Object Table provides a mechanism for a network host, such as an Epicure bridge, to independently acquire the information needed to manage the network. The NOT is sent as a message having a single data segment.

The NOT is composed of three sections:

1. A header that identifies the hardware module,

2. A listing of the logical instruments on the module, and

3. A series of tables that describe the registers for each type of logical instrument.

 

5.1. NOT Header organization

 

header length	2 bytes
module type identifier	2 bytes
module serial number	2 bytes
major hardware revision	1 byte
minor hardware revision	1 byte
major firmware revision	1 byte
minor firmware revision	1 byte
node options	1 byte
reserved	5 bytes
physical memory records	9 bytes each

 

5.1.1. Node  Options

 

The Node Options byte in the NOT header is used to indicate to a host the capabilities of the hardware node:

 

 

MPM: When set, MPM indicates to a host that the node can accept multiple packet messages. A node with MPM cleared returns an error code when a multiple packet message is received. The message is ignored. However, the node may still return multiple packet responses (for example, in response to the Send NOT command).

 

SAP02: When set, SAP02 indicates that the debug facility is available.

 

SAP03: When set, SAP03 indicates that the downloader is available.

 

NIH: When set, NIH indicates to the originating node that target node is an InNet master and that there are "no instruments here".

 

5.1.2. Physical memory record list

 

The list of physical memory records identifies each block of memory on the module that may be accessed via the network for downloads and diagnostic uses. A null list means that no external access to physical memory is provided.

 

5.1.3. Physical memory record format

 

physical start address	4 bytes
block length	4 bytes
memory type	1 byte

 

5.1.4. Physical memory types

 

Valid memory types are:

00	Reserved
01	Flash-ROM
02	Battery-backed static RAM
03	Static RAM
04	EEPROM
05-FF	Reserved

 

5.2. Logical Instrument list

 

The logical instrument list is used to identify each instance of a type of instrument on a hardware module. The logical instrument (LI) abstraction allows the host to deal with each device as if it were a separate physical entity. For example, a quad loss-monitor-integrator is a single physical card having four logical instruments. Modules may have any number and mix of logical instruments.

 

ASCII name fields are included in the various LI entries. These names provide the possibility for a future control system to locate and access data by name from INET bridges.

 

5.2.1. Accessing an LI

 

Each LI is accessed by directing packets to its SAP on a module. The SAP is found in the LI list in the NOT.

 

5.2.2. LI list format

 

The LI list appears immediately after the NOT header. The first field in the LI list is a two byte length field.

 

The LI list consists of one or multiple records formatted as:

 

Instrument SAP	1 byte
Instrument type index	1 byte
Reserved	2 bytes
Instrument name	16 byte character string*

*Truncated to six characters when referenced by Epicure

 

Each LI is uniquely addressed by its SAP.

 

The Instrument Type Index links each instance of a logical instrument to its characteristics as defined in an Instrument Type Table.

 

5.3. Instrument type tables

 

The instrument type tables contain lists of the registers used by each LI type. The type tables appear immediately after the LI list. Each table consists of a header followed by one or more instrument register records.

 

5.3.1. Instrument type table header

 

Table length	2 bytes
Instrument type index number	1 byte
Reserved	1 byte
Instrument type name	16 byte character string*

*Truncated to six characters when referenced by Epicure

 

5.3.2. Instrument type table register record

 

Register logical address	2 bytes
Register physical address	4 bytes
Register name	16 byte character string*
Register length, bytes	2 bytes
Data type index	1 byte
Attributes	1 byte
Reserved	2 bytes

*Truncated to six characters when referenced by Epicure

 

The Register Logical Address identifies each register within an LI. An LI may have multiple registers.

 

The Register Physical Address directly addresses the memory of the module for debugging and diagnostic purposes. Use of this field is optional.

 

The Register Length and Data Type Index give the formatting of data within a register. Note that a register may be set up to contain a single dimensional array of values. For example, a register containing a sequence of four longword measurements would use data­_type=06, length=16 bytes. Users may define their own data types for multidimensional arrays and for structures that group related variables having different data types.

 

5.3.3. Register Data Types

 

Data Type	Index	Length (bytes)
(reserved)	00	0
Unsigned byte	01	1
Unsigned short Integer	02	2
Unsigned long Integer	03	4
Signed byte	04	1
Signed short Integer	05	2
Signed long Integer	06	4
ASCII character	07	1
Ext ASCII character	08	1
Sngl precision float	09	4
Dbl precision float	0A	8
(reserved)	0B-7F	0
User-defined structures	80-FF	?

 

5.3.4. Register Attributes Definitions

 

 

6. SAP Assignments and Definitions

 

6.1. SAP Classes

 

SAP Value	Class	Usage
00	Reserved	Local node management
01-07	Reserved	Network management
08-3F	Undedicated	Available for general use
40-FE	Unusable
FF	Reserved	Global SAP

 

6.2. Network Management SAPs

 

SAP	Usage		Attribute
01	Node management	Mandatory	Group and Individual
02	Debug console	Optional	Individual
03	Download	Optional	Individual
04	Reserved
05	Reserved
06	Reserved
07	Reserved

 

6.3. SAP Number 00, Local

Attribute:         Individual

Description:

            Reserved by ControLink for local node management.

Data format:  

            Undefined

 

6.4. SAP Number FF, Global SAP

Attribute:         Group

Description:

            not defined and unused by Innet

Data format:

            none

 

6.5. Node Management Commands (SAP 01, Mandatory)

 

6.5.1. Send NOT

 

Description:

            The node returns the object table for the node to the ISAP and uses the AU_node_number and AU_SAP_number fields as the return address for unsolicited Auto-Update packets. AU_node_number=$00 is invalid. A device that receives a value of zero simply makes no entry into its return address list. Note that on a network with multiple masters, a device may have to copy Auto-Update packets to multiple destination nodes.

 

Command format:

                       

SN=01	1 byte
(reserved)	1 byte
AU node number	1 byte
AU SAP number	1 byte

 

The node responds with the NOT message (may be transmitted in several packets):

 

2	NOT header length=18+9m
16	NOT header
	Physical Memory Record
m*9	...
	Physical Memory Record
2	Logical Instrument List length=2+20n
	Logical Instrument Record
n*20	...
	Logical Instrument Record
20	Instrument Type Table Header
	(length=20+28p)
	Instrument Type Register Record
p*28	...
	Instrument Type Register Record
...	...	One Instrument Type Table for each Logical Instrument type
2	Instrument Type Table length=22+28q
20	Instrument Type Table Header
	Instrument Type Register Record
q*28	...
	Instrument Type Register Record
2	End flag=$0000

 

6.5.2. Reset Module(s)

 

Description:

                        The command causes a complete node hardware reset upon receipt. This command may be directed to a single node or to a group.

Command format:

                       

RM=02	1 byte
(reserved)	1 byte
(unused)	2 bytes

 

No response is generated.

 

6.5.3. Send Device Status

 

Description:

            The node responds to the ISAP with a status packet.

 

Command format:

 

SS=03	1 byte
(reserved)	1 byte
(unused)	2 bytes

                       

The node response consists of a one-byte message to the ISAP:

 

Device Status

On-line:     device initialization is complete and is fully functional

Fail:           device failed self-test procedure

 

6.5.4. Diagnostic

 

Description:

            Perform the diagnostic operation specified by the command byte using the accompanying data and return a response to the ISAP.

 

Command format:

 

DIAG=04	1 byte
(reserved)	1 byte
(unused)	2 bytes
Operation code	1 byte
Optional message	n bytes

 

            The ISAP sends a single command byte followed by optional message string. The node responds to the ISAP with an appropriate message.

 

Operation codes

00        (reserved)

01        Echo attached message to ISAP

02        Accept message with no response

03-FF (reserved)

           

6.5.5. Flush Tasks

 

Description:

                        Stop all tasks running on the module. This command may be directed to a single node or to a group.

 

Command format:

FT=05	1 byte
(reserved)	1 byte
(unused)	2 bytes

           

A status message is returned to the ISAP (see 6.2.4.).

 

6.5.6. TeV Event

 

Description:

            TeV_Event is a broadcast service indicating the occurrence of a TeV Event. Enabling of the service and of specific events is handled locally at the broadcasting node. There should be only one TeV service provider on a network. No response is returned to the ISAP.

 

Command format:

TEV=06	1 byte
(reserved)	1 byte
(unused)	2 bytes
Clock event code	1 byte

 

            ISAP broadcasts a single byte TeV Event number. No response is returned.

 

6.5.7. Set Spill Number

 

Description:

            Load the data value into the local spill number variable. SSN is a broadcast service.

 

Command format:

 

SSN=07	1 byte
(reserved)	1 byte
(unused)	2 bytes
Spill number	4 bytes

 

            The ISAP broadcasts a single unsigned big endian longword. No response is returned.

 

6.5.6. Set_Clink_Count

 

Description:

            Set_Clink_Count is a broadcast service of the current accelerator time. Enabling of the service is handled locally at the broadcasting node. There should be only one Clink service provider on a network. No response is returned to the ISAP.

 

Command format:

CLINK=08	1 byte
(reserved)	1 byte
(unused)	2 bytes
Clink Count	4 bytes

 

            ISAP broadcasts a 32 bit Clink Count value. No response is returned.

 

6.6. Debug Console (SAP 02, Optional)

 

Description:

            Debug requires that a connection be established between the ISAP and the TSAP. Upon receipt of connect acceptance from the TSAP, the ISAP may send a series of text messages to the node. The text strings are loaded into the target's debugger input buffer. The debugger sends its output as text strings terminated by a CR to the ISAP until the connection to the ISAP is closed.

 

Data format:        

            Each debugger input string to the TSAP is single data segment containing a text string. The TSAP returns text strings to the ISAP. Multiple text strings may be batched into each message from either end. All text strings are terminated by a CR.

 

6.7. Download Commands (SAP 03, Optional)

 

6.7.1. NOT Download

 

Description:

            Node Object Table download requires that a connection be established between the ISAP and the TSAP. Upon receipt of connect acceptance from the TSAP, the ISAP may initiate a NOT programming session with the TSAP. The session consists of the exchange of programming commands, responses, and data. The session continues until either SAP disconnects.

 

Command format:

 

NDNLD=01	1 byte
(reserved)	1 byte
(unused)	2 byte
NOT message	n bytes

 

            ISAP and TSAP send one or multiple text strings per message. All text strings are terminated by a CR.

 

6.7.2. Code Download

 

Description:

            Code download requires that a connection be established between the ISAP and the TSAP.  Upon receipt of connect acceptance from the TSAP, the ISAP may initiate a node programming session with the TSAP. The session consists of the exchange of programming commands, responses, and data. The session continues until either SAP disconnects.

 

Command format:

 

CDNLD=02	1 byte
(reserved)	1 byte
(unused)	2 bytes
Intel hex records	n bytes

 

            The ISAP sends one or multiple Intel hex records or terminated text strings  per message. The TSAP responds with terminated text strings.

 

7. Host SAP Commands

 

To obtain measurements from and manipulate a logical instrument, all InNet modules must respond to a basic set of commands from the host. Support of optional commands may be included. Users may also implement their own extensions to the command set. The arguments used in a command message must be consistent with the configuration data received by the host in the node's NOT.

 

Command messages are directed to a node TSAP and responses are returned to the ISAP in the command message header. The host uses the ISAP to associate a response message with a command. The host may either sequence through a pool of SAPs to uniquely label each transaction, or independent tasks running on the host may each use a unique SAP to identify its own transactions.

 

Multiple, unrelated commands may be batched into one message. Similarly, data return and responses can be batched into a single return message. However, the SSAP and the DSAP in the packet header is understood to apply to all segments of the message. When batched, commands are executed in the order in which they appear in the message.

 

If an LI receives a command that it cannot handle, it returns a negative acknowledge to the ISAP. A NAK response is formatted:

 

echo of received command	1 byte
(reserved)	1 byte
echo of logical register address ($0000 if none specified by ISAP)	2 bytes
completion code	1 byte

 

Completion codes:

00	no error (operation successful)
01	unknown command
02	unspecified error
03	non-existent register
04	register is read-only
05	incorrect argument length
06	incorrect bit mask length
07	multiple packet message not accepted
08	instrument busy or not available
09	master node or non-existent instrument

 

7.1. Mandatory Host SAP Commands

 

7.1.1. Send Register

 

The Send Register command instructs the LI to return the current content of one  logical register. The command is a single data segment consisting of the Send Register command, a pad byte, and a logical instrument register address:

 

SR=01	1 byte
(reserved)	1 byte
Logical register address	2 bytes

 

The response message has one data segment for each register listed in the command messsage:

 

01 (SR echoed)	1 byte
(reserved)	1 byte
logical register address	2 bytes
completion code	1 byte
data	var., depends on data type

 

7.1.2. Accept register

 

The Accept Register command instructs the LI to load the data accompanying the command into a logical register. The command is one or multiple data segments consisting of the Accept Register command, a pad byte, a logical instrument register address, and data:

 

AR=02	1 byte
(reserved)	1 byte
logical register address	2 bytes
data	var., depends on data type

 

The response message contains a response for each data segment in the command messsage:

 

02 (AR echoed)	1 byte
(reserved)	1 byte
logical register address	2 bytes
completion code	1 byte

 

7.1.3. Send All Registers

 

The Send All Registers command instructs the LI to return the current content of all of its logical registers. The command is a single data segment consisting of the Send Register command and a pad byte:

 

SA=03	1 byte
(reserved)	1 byte

 

The response message has one data segment for each register listed in the LI register table:

 

03 (SA echoed)	1 byte
(reserved)	1 byte
logical register address	2 byte
completion code	1 byte
data	var., depends on data type

 

7.2. Optional Host SAP Commands

 

7.2.1. Accept Register Masked

 

The Accept Register Masked command instructs the LI to load the data accompanying the command into a logical register. The command is one or multiple data segments consisting of the Accept Register command, a pad byte, a logical instrument register address, a bit mask, and data:

 

ARM=04	1 byte
(reserved)	1 byte
logical register address	2 bytes
bit mask	var., depends on data type
data	var., depends on data type

 

The response message contains a response for each data segment in the command messsage:

 

04 (ARM echoed)	1 byte
(reserved)	1 byte
logical register address	2 bytes
completion code	1 byte

 

7.2.2. Reset and Initialize LI

 

The Reset and Initialize LI command instructs the LI to reset all its registers to predetermined states and restart LI operation:

 

RELI=05	1 byte
(reserved)	1 byte

 

Response:

echo of received command	1 byte
(reserved)	1 byte
$0000	2 bytes
completion code	1 byte

 

7.2.3. Begin Unsolicited Data

 

The Begin Unsolicited Data command directs the LI to schedule one-shot or cyclic data return messages for a register. Acquisition begins at the trigger plus delay specified in the frequency/time descriptor (FTD). The return message is built and sent immediately after data is acquired. Each BUD occupies one data segment. BUDs may be batched with other commands in a message.

 

BUD=06	1 byte
(reserved)	1 byte
logical register address	2 bytes
FTD	4 bytes

 

A BUD response is formatted as:

 

06 (BUD echoed)	1 byte
(reserved)	1 byte
logical register address	2 bytes
FTD echo	4 bytes
completion code	1 byte
data	var., depends on data type

 

Frequency/Time Descriptor:

 

 

7.2.4. Begin Unsolicited Data Extended

 

The Begin Unsolicited Data Extended command directs the LI to schedule one-shot or cyclic data return messages for a register. Acquisition begins at the trigger plus delay specified in the FTD and continues for the specified number of points. The return message is built and sent immediately after data is acquired. When the cycle flag is set, acquisition is triggered at every occurrence of the trigger. Each BUD occupies one data segment. BUDEs may be batched with other commands in a message.

 

BUDE=07	1 byte
(reserved)	1 byte
logical register address	2 bytes
Extended FTD	8 bytes

 

A BUDE response is formatted as:

 

07 (BUDE echoed)	1 byte
(reserved)	1 byte
logical register address	2 bytes
EFTD echo	8 bytes
completion code	1 byte
data	var., depends on data type and number of points acquired

 

Extended Frequency/Time Descriptor:

 

 

7.2.4. Stop Unsolicited Data Returns

 

The Stop Unsolicited Data Returns command instructs the LI to unmark all logical registers for cyclic, unsolicited data reads:

 

SUDR=08	1 byte
(reserved)	1 byte

 

Response:

08 (SUDR echo)	1 byte
(reserved)	1 byte
$0000	2 bytes
completion code	1 byte

 

8. Revision History

 

24 January 1995                   Original Issue

8 March 1995                        Revised sections 1, 2.1., 2.2., 3.4, and 6.

23 October 1995                   Added Epicure name notes, added NIH bit,sec.                           5.1.1., added Clink broadcast, sec. 6.5.6., added                                    completion codes 08 and 09, sec. 7.

4 December 1995                Added Auto_Update bit, sec. 5.3.4., added                                                                      Auto_Update return address, sec. 6.5.1.

11 May 1996                         Added explanations to sec. 5.2 and 5.3.