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:

 

struct LLC_MSG {

USIGN8 event;                       service

USIGN8 dstation;                  physical address of destination node

USIGN8 SSAP;                     source SAP

USIGN8 DSAP;                     destination SAP

USIGN8 group;                      group/individual attribute

USIGN8 msbcount;               byte count high

USIGN8 lsb count;                 byte count low

USIGN8 *msgptr;                  message buffer

};

 

 


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.

 

Security, Privacy, Legal