A New Set of VXIbus Specifications Controls Instrumentation Over a Network

Computer networks, the technology that has opened many avenues of opportunity in the business world, can now work for engineers designing and building systems. Through the efforts of the VXI Consortium’s VXI-LAN technical committee, new standards have been defined that enable instrumentation access over a local area network (LAN).

Specification Objectives

The specifications are designed to meet these objectives:

· Allow ASCII messages, including IEEE 488.2 messages and IEEE 488.1 instrument control messages, to be passed between a controller and a device via a computer network.

· Define the protocol to be used for this communication.

· Allow devices built by different vendors to interoperate by way of the protocol.

· Allow the protocol to be used with a variety of application programming interfaces, including existing and emerging industry-standard interfaces, such as Hewlett-Packard’s Standard Instrument Control Library and the VXIplug&play System Alliance’s Virtual Instrumentation Software Architecture (VISA) and VISA’s Transition Library.

· Allow devices to support other networking protocols in addition to the network instrument protocol.

· Define the operation of a Transmission Control Protocol (TCP)/Internet Protocol (IP) VXIbus interface device, which connects a VXI cardcage to a computer network, including the mapping from the LAN transactions to VXI operations.

In addition to defining a VXI mapping for a TCP/IP-VXIbus device, an IEEE 488.1 mapping has been devised for a TCP/IP-IEEE 488.1 device as well as a LAN-based instrument mapping.

Client/Server Measurement Model

The network instrument protocol defined by the specification allows for communication to take place between a client computer running the measurement application and a measurement server which receives the request, performs the operation and returns a reply.

Figure 1 depicts a measurement system which uses the client/server model. Test equipment can be controlled from PCs or workstations both near and far by way of LANs and wide area networks.

By connecting instrumentation to a computer network, you can cover long distances between the controller and the device, use standard computers with built-in networking as controllers, and more easily share measurement resources and data on the network. Interface devices built to the specifications allow instrumentation to be connected to such a network in a cost-effective manner, decreasing both hardware and software costs.

Network Instrument Protocol Stack

The network instrument protocol uses a remote procedure call paradigm and is designed to be used over existing computer networks which support the IP Suite, commonly referred to as the TCP/IP Protocol Suite. The network instrument protocol is based on work originally done at Hewlett-Packard Laboratories. The network protocols which make up the network instrument protocol stack can be described using the International Standards Organization Open Systems Interconnection (OSI) reference model.

The OSI model is a seven-layer model depicted in Figure 2. Each layer represents a different set of functionality required for reliable and effective communications between two computing devices via a computer network.

Physical and Data Link Layers

The physical and data link layers provide for communication between two computers which are directly connected. These layers specify the physical characteristics of the medium connecting the machines as well as the signaling and data formats used at this level.

The network instrument protocol specifies that an Ethernet data link layer and a 10BASE-T physical layer shall be supported. These protocols comprise the implementation of a 10 Mb/s Ethernet over twisted-pair wiring which has become common today. Other media may also be supported by a device meeting the requirements of these specifications.

Network and Transport Layers

The network and transport layers provide for reliable communication between two machines over a network, where the two machines may not be directly connected to one another. The network layer outlines routing of messages through a network, where a message may need to pass through several devices acting as routers prior to reaching its final destination. The transport layer provides for the end-to-end communication between applications running on computing devices.

The network instrument protocol specifies the IP Suite, including the IP at the network layer and the TCP at the transport layer.

TCP/IP was chosen because of its prevalence in the industry. TCP specifically provides the reliability to ensure that messages are received in the order sent and that a request is executed only once. This reliability is important for instrument control where receiving messages out of order or more than once would alter measurement results.

Session and Presentation Layers

The session and presentation layers facilitate message management and definition of the format of data that crosses over the network. This ensures that two computers can communicate even if their native data formats are incompatible. An example would be integer representations on Intel and Motorola processors which store integers in reverse order relative to each other.

The network instrument protocol specifies its messages using Open Network Computing Remote Procedure Calls (ONC/RPC). ONC/RPC uses the eXternal Data Representation mechanism for formatting the data on the wire.

An RPC model supports error handling, versioning and interface extensions, parameter encoding and decoding, function dispatching, and data conversions between machine types.

Application Layer

The application layer is the portion of the protocol stack which concerns the task at hand. It defines a high-level protocol suitable within a particular application domain.

The network instrument protocol specifies the RPCs used for communication between controllers and devices over a computer network. The resulting protocol stack is summarized in Figure 3.

Network Instrument RPCs

The defined RPCs of the network instrument protocol form the core of the protocol. Table 1 summarizes the network instrument protocol’s RPCs.

Link Management

The create_link and destroy_link RPCs provide for the creation and destruction of links to a device from a controller. A link is a network instrument protocol concept that allows a controller to set up a communication pathway to a particular device.

Concurrency Control

Attaching instrumentation to a computer network can allow the instruments to be accessed from multiple controllers. This can be used for resource sharing among a group of engineers or in the design of a distributed application which accesses the instruments from multiple computers. The device_lock and device_unlock RPCs provide a mechanism which can be used to control access to devices so that only one user accesses an instrument at any given time.

Writing/Reading Data

The device_write and device_read RPCs allow ASCII and non-ASCII data, such as that defined by IEEE 488.2, to be passed between a controller and a device.

IEEE 488.1 RPCs

The device_readstb, device_trigger, device_clear, device_remote and device_local RPCs allow for their corresponding IEEE 488.1 messages to be transferred to a device over a LAN.

Service Requests

The create_intr_chan and destroy_intr_chan RPCs allow for the creation and destruction of a communications channel used by the network instrument protocol to send service requests to a network instrument client. The network instrument protocol interrupt channel is implemented as a separate TCP connection between the server and the client.

The device_enable_srq RPC enables or disables a network instrument server’s sending of service requests by way of the device_intr_srq RPC.

Interface Mappings

The mappings from the protocol to the specified interfaces include VXI, IEEE 488.1 and LAN-based instruments.

For VXI, the specifications describe a TCP/IP-VXIbus interface device, a message-based commander which implements the network instrument protocol and converts the protocol to well-defined VXIbus word-serial operations. This device is similar in nature to a 488-VXIbus interface device, but the IEEE 488 interface has been replaced with an Ethernet network interface.¹ A VXI system is shown in Figure 4.

For IEEE 488.1, the specifications describe a TCP/IP-IEEE 488.1 interface device. This device is an IEEE 488.2 controller which converts the network instrument protocol to IEEE 488.1 operations and is otherwise similar to the VXI system.

For LAN-based instruments, the specifications describe a TCP/IP-IEEE 488.2 instrument device. This instrument directly connects to a LAN and supports the network instrument protocol. A LAN-based instrument system is shown in Figure 5.

Link Management and Concurrency Control

The create_link, destroy_link, device_lock, device_unlock, and device_abort RPCs are implemented as part of the network instrument protocol and do not directly map to any interface specific operations. These RPCs function as defined by the network instrument protocol.

Writing/Reading Data

device_write: When a device_write is received, data is transferred to the associated instrument by using the byte transfer or message transfer protocol for VXI, by addressing the instrument and sending the data over IEEE 488.1, or by placing the data into the input buffer of a LAN-based instrument.

device_read: When a device_read is received, data is transferred from the instrument by using the byte transfer or message transfer protocol for VXI, by addressing the instrument and reading the data over IEEE 488.1, or by reading data from the output buffer of a LAN-based instrument.

IEEE 488.1 RPCs

Upon receipt of the RPCs associated with the IEEE 488.1 out-of-band messages, the devices perform in these ways:

device_readstb: When a device_readstb is received, the instrument’s status byte is retrieved by using the VXIbus word serial Read STB command, by serial polling the instrument over IEEE 488.1, or by returning the status byte register of a LAN-based instrument.

device_trigger: When a device_trigger is received, the instrument is triggered by using the VXIbus word serial Trigger command, by sending a group execute trigger to the instrument over IEEE 488.1, or by placing a group execute trigger token into the input buffer of a LAN-based instrument.

device_clear: When a device_clear is received, the instrument is sent a device clear by using the VXIbus word serial Clear command, by sending a device clear over IEEE 488.1, or by sending a device clear active state message to a LAN-based instrument.

device_remote: When a device_remote is received, the instrument is placed in a remote state where all local controls are locked out by using the VXIbus word serial Set Lock command, by enabling remote operation and sending the local lockout message over IEEE 488.1, or by directly disabling local controls of a LAN-based instrument.

device_local: When a device_local is received, the instrument is placed back in a local state where local controls are enabled by using the VXIbus word serial Clear Lock command, by sending the go-to-local message over IEEE 488.1, or by directly enabling the local controls of a LAN-based instrument.

Service Requests

The create_intr_chan, destroy_intr_chan, and device_enable_srq RPCs are implemented as part of the network instrument protocol and do not directly map to any interface specific operations. These RPCs function as defined by the network instrument protocol.

Service requests are sent using the device_intr_srq RPC based on the RQS state of VXIbus devices, the state of the SRQ line of IEEE 488.1, or the RQS message of a LAN-based instrument.

Conclusion

The TCP/IP Instrument Protocol provides the platform for sending messages from controllers to devices over a computer network using the network instrument protocol. The benefits are many, including decreased costs in deploying distributed measurement systems, the capability to use standard computers with built-in networking for instrument control, and the possibility of measurement resource sharing.

References

1. “VMEbus Extensions for Instrumentation: System Specification, VXI-1,” Revision 1.4, VXIbus Consortium, April 21, 1992.

2. “VMEbus Extensions for Instrumentation: TCP/IP Instrument Protocol Specification, VXI-11,” Revision 1.0, VXIbus Consortium, July 17, 1995.

3. “VMEbus Extensions for Instrumentation: TCP/IP-VXIbus Interface Specification, VXI-11.1,” Revision 1.0, VXIbus Consortium, July 17, 1995.

4. “VMEbus Extensions for Instrumentation: TCP/IP-IEEE 488.1 Interface Specification, VXI-11.2,” Revision 1.0, VXIbus Consortium, July 17, 1995.

5. “VMEbus Extensions for Instrumentation: TCP/IP-IEEE 488.2 Instrument Interface Specification, VXI-11.3,” Revision 1.0, VXIbus Consortium, July 17, 1995.

6. Beckman, J., “A Protocol for Controlling Devices Over a Network–A New VXIbus Draft Specification,” AUTOTESTCON Proceedings, IEEE, August 1995.

Acknowledgment

This article is based on “A Protocol for Controlling Devices Over a Network–A New VXIbus Draft Specification” by John L. Beckman of Hewlett-Packard Co., which appeared in AUTOTESTCON95 Proceedings, Atlanta, GA, Aug. 3-10, 1995, pp. 567– 573. ®1995 IEEE.

About the Author

John Beckman, a Software Engineer at HP, joined the company in 1985. Mr. Beckman graduated from the University of Iowa with a B.S. degree in computer science. Hewlett-Packard Co., Measurement Systems Division, 815 S.W. 14th St., Loveland, CO 80537, (970) 679-3544.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Table 1

Copyright 1995 Nelson Publishing Inc.

December 1995