Opinion: Why Ethernet reigns supreme for test-and-measurement instrumentation

Authored by Eric E. Bloam, Keithley Instruments, Inc., Cleveland. Ohio

The economy, speed, and virtually unlimited distance potential of Ethernet-based communications will fuel growth of Ethernet-ready instrumentation. Increasingly, users are noting the performance and cost disparity between Ethernet and the RS-232, RS-422, and GPIB (General Purpose Interface Bus, or IEEE-488) protocols.

Ethernet 10BaseT can accommodate transmission speeds up to 10-Mbits/s, and 100BaseT operates at up to 100-Mbits/s. What's more, Ethernet cabling is inexpensive, expander hubs cost less than $100, and the price of an Ethernet network interface card for a PC is less than $20.

With Ethernet in high-resolution instruments and switching systems, you can take accurate multi-channel measurements over long distances in a distributed data acquisition environment. Similarly, a plant's production test systems can be monitored, and Pass/Fail decisions can be taken from a central location. Data can then be easily shared with other users.

Click for larger image

With Ethernet devices, it's necessary to install and configure NICs (network interface cards) in a PC controller, install the TCP/IP protocol, and set up TCP/IP addressing.

Depending on the network, an Ethernet hub may be required, too. It basically repeats anything it receives from one port, making that data available to all its other ports.

The first step is deciding which connection type to use.

You can choose a one-to-one connection, which is used when one instrument is connected to a single NIC. A network crossover cable is used, which has its Receive (RX) and Transmit (TX) lines crossed. That permits the Receive line input to be connected to the Transmit output on the network interface.

You can also set up a one-to-many connection. With an Ethernet hub, it's possible to connect a single NIC to as many Ethernet instruments as the hub can support. Straight-through (non-crossover) cables are required for hub connections.

A hub connection supports easy expansion of measurement channels when test requirements exceed the capacity of a single instrument. It can be used with an isolated instrumentation network or with a corporate network attached to the hub.

Alternatively, you can opt for dual NICs for independent networks (see next figure). When the application involves interconnecting independent corporate and instrumentation networks, two NICs are required in the PC controller. However, stations on the corporate network can access the instrumentation, and vice versa, through the same computer.

Finally, you can opt for enterprise network connections. This uses existing network infrastructure to connect instruments to the PC controller.

With enterprise network connections, it's necessary to obtain network resources from a network administrator. Usually, instruments are kept inside a corporate firewall, but the administrator could assign resources that permit their use outside the firewall. With appropriate security methods, it's possible to control data collection and distribution from virtually anywhere.

Warning

When connecting to a corporate network, the network administrator must provide all of the network settings for measuring instruments. Failure to use settings provided by the administrator could result in network failures at other locations.

Using TCP/IP

A PC software driver or socket connection can be used for instrument control, along with an appropriate communications protocol that defines data exchanges between the PC and instruments. Regardless of network connection, each instrument and its location on the network must be identified.

Generally, Ethernet-based instruments use the TCP/IP protocol to communicate with other hosts on the network. A host is defined as any device that can transmit and receive IP (Internet Protocol) packets. This includes instruments, workstations, servers, and routers. Each host is assigned a unique 32-bit logical address.

Assigning IP Addresses

There are two ways to assign an IP address, either or both of which may be available with an Ethernet-ready instrument. For a network server running DHCP (Dynamic Host Configuration Protocol), the IP address is assigned each time the host connects to the network. Typically, this addressing is used for corporate networks.

The other method is static IP addressing, used in the majority of isolated networks, and assigned by the user. A static IP address stays the same each time the host is connected to the network.

An IP address is 32 bits wide and is divided into two main parts: a network ID number and host ID number. The address is expressed as four decimal segments separated by periods. Valid addresses range from 0.0.0.0 to 255.255.255.255.

Each segment represents the decimal value of that segment's 8-bit byte. The way these four segments are assigned for host and network ID depends on the class of network being used. The table shows network classes defined by IP address and subnet mask combinations.

Click for larger table

The network ID must be unique among all subnets connected to the Internet (or corporate intranet). If the subnet is connected to the public Internet, then the network ID must be obtained from the Internet Network Information Center, which assigns and preserves unique IDs. Each host ID must be unique among all the hosts on the same network.

In the TCP/IP protocol, a Subnet Mask separates the network ID from the host ID. The Subnet Mask looks like an IP address, but sets a data bit high for each position of the IP address that makes up the network ID. Three different classes of network are defined with the IP address and subnet mask, as seen in the above table.

Class C networks are the most common and use the subnet mask 255.255.255.0. The first three bytes are the network ID number and the last byte is the host ID on the network. Host ID numbers 1 through 254 are available for assignment.

All hosts on the same isolated network must have the same subnet mask. As a general rule, the top and bottom host numbers are reserved. The top one (nnn.nnn.nnn.255) is the broadcast address and the bottom one (nnn.nnn.nnn.0) is shorthand for the whole subnet.

An Isolated Instrument Network Example

Let's set up a simple isolated Class C network for communicating with two Ethernet-equipped instruments. The network is similar to that shown in the second figure, but without the corporate network connection to the hub. The hub must be connected to a properly configured NIC in the PC.

The next step is to create static IP addresses for the three hosts (the NIC and two instruments). Since this is a Class C network, the subnet mask is 255.255.255.0. From the aforementioned table (above), note that the first three parts of the IP address make up the network ID. For this example, a network ID of 192.68.0 is used. (This happens to be the default network ID that is shipped with a Keithley Model 2701 Ethernet-Ready DMM/Data Acquisition System).

Next, assign the host ID portions of the three IP addresses. For this example, assign a host number of 1 to the NIC; a host number of 10 to the first instrument, and a host number of 20 to the second instrument. The table here provides an illustration.

In the Windows operating system, install the NIC's IP address with the Windows Control Panel. The exact steps differ somewhat for each version of Windows. However, the usual way is to open the Network folder in Control Panel and then double-click on the appropriate TCP/IP component for the NIC being used. Then, enter the IP Address and Subnet Mask in the spaces provided. For an isolated network, the Default Gateway and DNS settings aren't used. Reboot the PC as necessary.

The final step is to assign the other two IP addresses to the instruments. See the instrument's instruction manual for details on this step.) It's a good idea to record IP addresses, especially when changing network settings on the PC; otherwise, they may be lost.

After assigning the IP addresses, verify proper functioning of the instruments and network. Some instruments have a Web page built into firmware, which supports fast setup and verification of proper operation. To access the Web page, start the PC's web browser and enter the IP address in the URL address line.

The IP address for the first instrument is 192.68.0.10 (as in the table, above). Once the Web page loads, there should be a button to initiate measurements, such as "Take Readings." Click this button and make sure that data is being displayed on the Web page. If unable to establish communications, check to see that all network settings are correct.

The next steps are selection and installation of an appropriate instrument driver and/or socket connection. Let's discuss the selection and use of appropriate programming methods in VB (Visual BASIC), for use with an instrument driver or socket connection.

Instrument Control Choices

Once an Ethernet instrument is set up on a network and its internal Web page is accessible, the next step is to select a programming method and write some code for the test application.

Typically, two choices are available-direct socket connection or use of a driver. For example, with the Keithley Model 2701, it's possible to use the IVI (Interchangeable Virtual Instruments) driver or use VISA (Virtual Instrument Software Architecture). The IVI driver is modeled on the IVI Foundation IviDMM instrument driver standard, which defines a class of interchangeable instrument drivers.

The IVI driver is built on the VISA interface layer, which manages the bus interface and supports seamless interchangeability between GPIB, RS-232, and Ethernet. IVI drivers also provide hardware-independent programming syntax for products that perform the same functions. An Ethernet instrument with an IVI driver may make it possible to use the same commands with an RS-232 interface.

By standardizing on a set of fundamental functions, settings, and permissible values, products based on IVI can deliver significant savings to test system developers.

Standard interfaces offer reduced programming time and complexity across different instruments, reduced downtime and maintenance by allowing instrument swapping with minimal test code modifications, and accelerated introduction of new products by facilitating reuse of test code from research-and-development to manufacturing.

The Keithley Model 2701 DMM/Data Acquisition System is used in these examples (with VB programming). However, the selection and use of drivers should be similar for most Ethernet-ready instruments and data acquisition systems. The Model 2701 IVI driver expands on the IVI digital multimeter class, IviDMM. This driver class supports the functionality of basic and complex digital multimeters.

Typical DMMs have a single measurement channel, but some may have a scanner card that supports multiple measurement channels with integrated switching, as well as analog and digital outputs. In that case, application developers need extensions to the IviDMM class that permits the use of channel lists for various DMM functions.

A Few IVI Disadvantages

IVI does have a few disadvantages, particularly for those more familiar with SCPI (Standard Commands For Programmable Instruments) programming. For example, the IVI driver uses function calls, so the syntax is totally different from SCPI. It also has a steep learning curve associated with the commands used in VB coding.

However, instrument manufacturers often provide program code examples to ease the application of IVI drivers. Another disadvantage of IVI is that the interface isn't an ActiveX control. This means that the program will not be able to take advantage of Windows Messaging when communicating with the instrument.

Let's look at Winsock Control. This scheme uses SCPI commands inside a VB program to control the instrument, and Winsock (operating similar to an MScomm object) to communicate with the instrument on the network.

Those already familiar with SCPI don't have to learn a new programming syntax and communicating with the instrument can be event driven. The disadvantage is lack of portability. A program written with Winsock control cannot be used with a different instrument model or to change to another method of communication, such as RS-232.

Consider Update Speed

Besides programming and platform independence, also consider update speed. Both IVI and Winsock are able to scan and store the reading in the instrument's internal buffer at the same speed. The IVI driver simplifies buffer management tasks involved in extracting data from the buffer and loading data into an array. However, if the cause of concern is the speed at which data is returned to the computer at the end of each scan, Winsock allows faster updating through the Ethernet connection.

Configuring an Ethernet instrument for the IVI driver will vary by instrument manufacturer. Typically, the first step is to find the program group where driver utilities are installed. In the case of the Model 2701, opening the Keithley Configuration Wizard leads one through the process.

For this instrument, Microsoft VB must be installed on the host computer along with the IVI driver and test application program. VB uses a COM-type library to interface to the instrument IVI driver.

To reference the type library in VB first select Project/References on the main VB menu. Then scroll through the Available References list to the entry for the instrument, in this case, the "Keithley 2701 Multimeter," and then uncheck the selection box.

Next, click OK to close the dialog. View the type library (KE2701 in this example) using VB's Object Browser (View/Object Browser on the main menu, or press F2).

The IviDMM specification divides DMM functionality into a common base capability group and several optional extension groups for advanced functionality. Depending on instrument features, developers may omit subsets of class attributes and functions from an actual driver. Conversely, IVI drivers may implement vendor-specific attributes and functions that support advanced features not addressed by the IVI class specification.

For example, the IviDMM class functions assume a DMM with a single measurement channel. To use additional channels available on a DMM with plug-in scanning modules, the IVI driver must support test application code that invokes a channel list referencing IviDMM functions and attributes. Otherwise, when the application either calls the instrument with the IviDMM class driver, or calls instrument functions directly, the instrument simply performs as a glorified single-channel DMM.

Standard IviDMM extension groups include:

* AC Measurements

* Frequency Measurements

* Temperature Measurements

* Thermocouples

* Thermistors

* MultiPoint

* Software Trigger

* Device Info

* Auto Range Value

* Auto Zero

In addition to these, the KE2701 driver supports four-wire RTD temperature measurements and multi-channel scans through Keithley extensions to the IviDMM attributes and functions.

IVI drivers model the state of an instrument using attributes. Applications can read or write the attributes to determine or modify the current state.

For example, by reading the KE2701_ATTR_FUNCTION attribute, a test application discovers the current measurement function of this instrument. By writing this attribute, the application can program the instrument to perform another type of measurement.

Using The IVI Driver

With a driver that uses IVI and VISA conventions to reference an instrument on either an Ethernet, GPIB, or RS-232 bus, the application can address the instrument with any of the following:

* Logical Name-user-assigned alias, such as "Oven Test" for a virtual instrument defined in the IVI configuration files.

* Virtual Instrument-user-defined instrument, such as "KE2701_GPIB16" or "vinstr->Oven Test" that binds an IVI driver to a hardware resource.

* Hardware Resource-VISA I/O string, such as "GPIB0::16::INSTR" that defines a hardware I/O connection.

The first step in using the IVI driver is to open a connection with the Instrument. For the Keithley 2701, this is done by invoking KE2701_init or KE2701InitWithOptions. Only one connection at a time is allowed. A KE2701_close vi function is used in conjunction with init.

The code in the figure below uses the CheckError subroutine for expanded error checking. This isn't required but is a Keithley routine, which in case of an error returns the error description (supplied via the Util.bas module with the Keithley 2701). InstrumentName is the hardware resource specified in the IVI driver configuration.

This function performs the following initialization actions:

* Creates a new IVI instrument driver session.

* Opens a session to the specified device using the interface and address specified for the Resource Name parameter.

* If the ID Query parameter (Parameter 2) is set to VI_TRUE, queries the instrument ID and checks that it is valid for the instrument driver.

* If the Reset parameter (Parameter 3) is set to VI_TRUE, resets the instrument to a known state.

* Sends initialization commands to set the instrument to the state needed for driver operation.

* If the initialization call succeeds, returns a ViSession handle that is used to identify the instrument the application opened in all subsequent instrument driver function calls.

The CheckError function returns a value when completed. If the value is zero, no error occurred. Since VI_SUCCESS is a constant with a value of zero, the If...Then statement is checking that init succeeded. Typical error coding uses a zero to represent success, positive values for a warning, and negative values for errors.

If CheckError isn't used, program code for opening an instrument session would be something like that shown in the figure immediately above. While the command is the same, only an error number is returned. The advantage of CheckError is receiving a written description along with the number.

VB programs that illustrate these principles can be downloaded at Keithley's Web site by clicking here and following the links to download center/example programs/2701.

About the Author

Eric Bloam is an applications engineer at Keithley Instruments in Cleveland. His expertise includes test application software, which is used to help users integrate instruments into test systems. He earned his bachelor's degree in Electronic Technology from the University of Akron.