Scripting is a powerful and convenient way to provide programmability for instruments in test and measurement applications. Script-based instruments provide architectural flexibility, improved performance, and lower cost for many applications. Scripting enhances the benefits of LXI instruments, and LXI offers features that both enable and enhance scripting.

Users comfortable with conventional instruments will find it easy and straightforward to begin using script-based instruments. They can be programmed in much the same way as conventional instruments are. However, with minor adjustments to system design and programming, the flexibility, improved performance, and other benefits of scripting are easy to incorporate into system configurations.

Programmable instruments have been available for many years. Although specific capabilities vary, a programmable instrument allows the user to create and store a set of instructions in the instrument itself, where it can be executed on demand.

Early programmable instruments generally had quite limited capability and capacity, which restricted the usefulness of the programmability to relatively small and simple applications. Larger or more complex applications required the use of a separate computer that controlled the instrument via a communications interface, often GPIB.

Improvements in computing technology and programming languages and the steadily declining cost of embedded computing capacity have led to a new generation of programmable instruments. This new breed of instruments breaks through the old limits to provide greatly increased capability and flexibility. One key improvement realized in these instruments is the use of a scripting language to provide programmability.

Scripting vs. Macros or Programming Languages
Simply put, scripting is writing programs in a scripting language to coordinate a sequence of actions. Scripting goes well beyond the more conventional use of macros or recorded sequences. It uses the full power of a scripting language, which includes looping, branching, and data processing.

Although macros can be repeated in a way that provides rudimentary looping control, scripting offers a full run-time environment in which values can be stored in variables. These variables then can be used to control both looping and branching decisions.

Unlike other programming languages, script programs do not need to be precompiled before being run. Scripting environments will either interpret the program directly or compile it automatically when needed.

Beyond that, scripting languages offer the full power of a programming language. This includes creating stored procedures or functions for code reuse.

A script need not be compiled as a separate step, so scripting languages are well suited for embedded use in test and measurement equipment. Scripts can be downloaded to the instrument without the need for extra preparation steps for greater user convenience.

One key difference between a scripting language that runs on a PC and a scripting language embedded in an instrument is the environment. When running on a PC, the scripting language generally has access to a file system, virtually unlimited memory, and a graphical display as well as a keyboard and mouse. When running on an instrument, a scripting language does not necessarily have access to any of these amenities, but generally they are not needed.

Scripting in Instrumentation
Popular scripting languages include Perl®, Python®, VBScript®, and JavaScript®. The Lua scripting language is particularly well suited for embedded use because it executes faster than most other scripting languages and is implemented as a library that takes very little code space.

When adding scripting support to test and measurement instrumentation, one of the most difficult choices to make is how to present the scripting to the user. This includes answering tough questions such as “How do I integrate the instrument command set with the scripting environment?” and “How will the user load scripts into the instrument?”. Keithley chose to integrate the scripting environment fully with the command set, which means that all instrument commands also are fully legal Lua statements. Essentially, each command message sent to the instrument is executed as a Lua program.

This choice makes it easy for the user to transition from controlling an instrument with single commands to using scripts because there’s no need to learn a whole new command set. Commands that can be sent to the instrument over a GPIB or LXI interface are the same as the ones used within a script. This greatly simplifies the process of migrating from simple command-based control to script-based control. The user can simply send larger scripts to the instrument instead of individual commands.

There is a drawback to this choice: Instrument commands might seem a little strange to the first-time user. A few examples comparing Keithley’s Model 2400 SourceMeter®, a SCPI-based unit, with the dual-channel Model 2602 System SourceMeter, a Test Script Processor (TSP)-based unit, will help demonstrate this.

The command used to make the instrument source output current on the Model 2400 is

:SOUR:FUNC CURR

The equivalent command for the Model 2602 is

smua.source.func = smua.DC_AMPS

The smua prefix designates Channel A of the Model 2602. The rest of the command is similar to the SCPI command with the exception of the equal sign. This is a Lua assignment operation that sets the value of the smua.source.func attribute to the value smua.DC_AMPS.

Queries are a little bit stranger. Because commands are valid Lua statements, the print function is used to generate output. The SCPI query to return the source function on the Model 2400 is

:SOUR:FUNC?

The equivalent command on the Model 2602 is

print(smua.source.func)

Just as a SCPI instrument supports compound commands by separating individual commands by a semicolon, the script-based instrument can accommodate compound commands by separating the commands with a statement separator. In Lua, the statement separator is a whitespace character.

Let’s assume the instruments are already configured to source voltage. On the Model 2400, the following command message will set the output level and then turn the output on

:SOUR:VOLT 1.0; :OUTP 1

The equivalent command message on a Model 2602 is

smua.source.levelv = 1.0 smua.source.output = 1

Sending Script Messages
The examples illustrate that the scripting instrument can behave very much like the conventional instrument. Only the command syntax has changed slightly.

To take advantage of the full power of the scripting engine, the user simply starts sending messages that use the capabilities of the scripting language. For example, a user could ask the instrument to perform a binary search looking for the source voltage that will generate an output current of 1 mA by sending the following script:

        step = 2.5                        
        smua.source.levelv = step
        while (step >0.1) do          
            if (smua.measure.i() > 0.001) then
               smua.source.levelv = smua.source.levelv – step
           else         
               smua.source.levelv = smua.source.levelv + step
           end                            
               step = step / 2.0
           end    
       print(smua.source.levelv)

A script such as this avoids the communications time required for reading each individual result and sending the commands to source new voltage levels. Although it is reasonable to question how long it takes to send the longer message, it generally will be much faster to send one longer message than to communicate several smaller messages back and forth.

However, one of the advantages of a scripting environment is that the preceding code can be packaged into a function definition and then reused, which would completely avoid sending the large message when used. For example:

    function Search(start, target)
       step = start
       smua.source.levelv = step
       while (step >.1) do
           if (smua.measure.i() > target) then
              smua.source.levelv = smua.source.levelv – step
           else
              smua.source.levelv = smua.source.levelv + step
           end
           step = step / 2.0
       end
       print(smua.source.levelv)
   end

This script does not make the instrument do anything right away, but it creates a stored procedure named Search that can later be invoked with this command

Search(2.5, 0.001)

Instruments can have several features that complement the scripting engine. If the scripting environment provides programmatic access to the instrument’s front panel, the user can create interactive scripts that prompt the user for parameters or display results on the front panel.

The instrument also can provide on-board nonvolatile script storage so that these stored scripts can be automatically executed when the unit powers up. This allows executing a previously loaded application without any user action other than turning on the power for the instrument.

Embedded scripting provides significant benefits for test and measurement instrumentation users. Although it has some minor drawbacks associated with it, such as the unfamiliar nature of queries, most users can work around them or adapt to them readily.

Scripting languages generally manage memory automatically so the user does not need to allocate and de-allocate storage for strings or arrays. Although this is very convenient for the user, the scripting engine periodically needs to reclaim memory that no longer is being used, a process known as garbage collection.

Even though garbage collection is done automatically, it does take time, which can cause problems if it occurs during a time-critical portion of a test sequence. These problems can be prevented, but the user first must understand the impact of the garbage collector and how to avoid it in time-critical test sequences.

LXI and Scripting
The current LXI standards for instrumentation do not require that instruments be programmable or implement scripting. However, several features in the LXI specification anticipate programmable instruments and provide useful functionality that enhances scripting’s capabilities on LXI-compliant instruments.

The LXI specification requires that Class A and B instruments support peer-to-peer messaging via LAN messages, and it permits Class C instruments to support it. LAN messages can be used to notify other LXI instruments of events or to trigger another instrument to perform some function.

Users must be able to specify what action is performed upon receipt of a LAN message. The most flexible way to implement this, and the way recommended by the LXI specification, is to allow the user to download executable code such as a script or program into the instrument, which then is executed upon receipt of the appropriate LAN message. This provides a great deal of flexibility because the user is not constrained to a predefined set of actions.

Furthermore, the LAN message format defined by LXI includes a small space for including arbitrary data as part of the message. It is feasible to transfer executable code, such as a short script, as part of the LAN message. This would allow one instrument to control another via LAN messages without preprogramming the response.

For example, suppose an instrument performs a measurement on a DUT. Based on the result of that measurement, it must change a stimulus applied to the DUT by another instrument. The new stimulus value is calculated based on the first measurement, so it is not known in advance. In this case, the first instrument could send a LAN message containing a short script to the second instrument to adjust the stimulus value.

Benefits of Scripting
Script-based instruments provide several benefits. Many of these are enhanced when the instrument also conforms to the LXI specification.

For many test and measurement applications, using a PC as a controller for communicating to separate instruments or using slot-based systems with integral controllers is perfectly adequate. For other situations, those approaches are overkill—and consequently overly expensive—or not quite up to the task. These applications benefit from the additional capabilities and flexibility that script-based instruments offer.

Architectural Flexibility
Small test systems with a few instruments can be built without a separate computer; one of the instruments acts as the controller and coordinates the operation of the others. Large systems can be divided into subsystems of a few instruments each, with each subsystem coordinated by a script-based instrument. This simplifies system design and can help improve performance. With LXI script-based instruments, subsystems can be physically separated, such as in assembly lines, scientific applications, or RF testing applications.

Improved Performance
Dividing large systems into subsystems coordinated by script-based instruments spreads the control and data-processing functions across multiple processors, increasing the total processing power available in the system and often improving overall speed and throughput. Furthermore, such division of labor allows for parallel testing: Instruments or subsystems do not need to sit idle while a central controller is busy with another task.

Scripts running in an instrument can operate at maximum speed because there are fewer delays due to communications with the controller while each command and piece of data are transferred. This is especially significant when the instrument is performing a repetitive test sequence.

With a separate controller, the sequence of instructions is transferred to the instrument once for every pass, even if the same sequence is run hundreds or thousands of times. Contrast that approach with a script that needs to be transferred to the instrument only once and then executed as many times as desired using a short command.

Conditional processing, such as when the results of one measurement determine the next function to be performed, offers another avenue for performance improvement. Performing the condition check locally in the script can eliminate the delays when sending the first result to the controller, waiting for the controller to process it, and then sending the next commands to the instrument.

In systems with high data rates and large data sets, communications latency, bandwidth limitations, and controller throughput can be serious bottlenecks. Script-based instruments can compress data to reduce bandwidth requirements and buffer it for background transmission when bandwidth is available. They also can filter data, for example, by only transferring data that falls outside of normal limits.

Reduced Costs
Using script-based instruments, smaller or less complex test systems can be built without a separate controller, saving the cost of the controller and that of any separate test-executive software that otherwise would be used to control the instruments. When building subsystems from script-based instruments, the same cost savings can be realized when building large test systems.

Example Scripts
Figure 1 shows how two Keithley System SourceMeters can be controlled from a single script to generate a three-phase AC waveform. In this case, the TSP-Link technology connects the two instruments and makes it easy for a script to control both instruments.

To View Figure 1 click here

Figure 1. Script That Outputs a 3-Phase AC Sine-Wave Voltage Using Three SMU Channels

Figure 2 demonstrates how timers based on LXI Class B technology can control script operation. In the script, a Keithley Model 3706 System Switch, a Class B instrument, uses timers based on IEEE 1588 to sequence a series of measurements. The timing features in Class B are particularly useful for avoiding or minimizing system delays caused by latency or communications delays.

To View Figure 2 click here

Figure 2. Script That Sets Up a Keithley 3706 Switch to Measure DC Volts on Channels

Developing Effective Scripts
Scripts can be developed in several ways. Keithley Instruments provides an Integrated Development Environment (IDE) called Test Script Builder (TSB) for developing scripts for any TSP-enabled instruments. TSB can be used to edit, download, and execute scripts on the instrumentation. It includes a built-in simulator for debugging a script without the need to transfer it to the instrument, which allows developing scripts even when the hardware is unavailable.

Some LXI instruments have a Telnet port that can be used for remote control. For these instruments, using a text editor offers a quick and simple way to write and debug scripts. From the Telnet application, the user can paste script text or download script files directly to the instrument.

Some users prefer to embed scripts directly into the test-executive application. They develop and debug scripts and the test-executive application at the same time.

LXI’s web connectivity has allowed Keithley to use a script-development tool called TSB Embedded in its Series 3700 Switch/DMM products. Users can access this tool via a Web page served by the instrument itself, using a Web browser to develop and manage their scripts without installing any software on the PC.

A function-based or object-oriented approach is advisable when developing scripts for a product with embedded script processing. Functions should be used wherever possible. This not only is good practice for maximizing code reuse, but it also reduces the amount of code stored in the run-time environment of the scripting engine and leaves more memory for additional scripts and data storage.

Embedded scripting can reduce the communications time between the host PC and the instrumentation. A function-based approach maximizes this advantage because the host PC need send only a short message to invoke a stored procedure. If more lengthy messages are often sent to the instrument, the communications reduction advantage is diminished.

Regardless of how a script is developed, scripting brings some new concerns to test management. Although it is useful in some situations to store scripts in nonvolatile memory on the instrumentation, it is not always best to do so. When a test executive expects that a particular version of a script will be on the instrumentation, it is better to load the scripts on the instrumentation when the test executive starts. That way there is complete control over which version of script code the test executive is using.

Script-Based Instruments
Script-based instruments may be used in conventional test systems with a separate controller. The details vary depending on exactly how the manufacturer chooses to implement scripting.

Those accustomed to using instrument drivers to interface the software and the instrument will find that they can continue to use an instrument driver and treat a script-based instrument much like a conventional instrument. However, doing so would eliminate many of the advantages scripting offers. Fortunately, there are methods that allow instrument-driver writers and users to benefit from the extra flexibility and capability script-based instruments offer.

When developing an instrument driver for a script-based instrument, you can choose from three general approaches:

Conventional
The driver is similar to one for a conventional instrument. No use is made of scripting capability. The only adjustment is to accommodate the differing syntax.

Extended
The conventional-style driver is enhanced with functions for transferring scripts to the instrument and perhaps managing return data. This provides a way for users to exploit scripting capability, but the driver itself does not do so.

Enhanced
An instrument driver for a script-based instrument can take advantage of scripting in many ways. For example, such a driver could download scripts that perform many of the functions normally handled by the driver to the instrument itself. Then, calls made to the driver are sent to the instrument as short simple commands rather than as longer series of typical instrument commands.

As always, there are trade-offs with such a design. But script-based instruments provide additional flexibility for optimizing system and software design to achieve the best performance possible for a given application.

The same three approaches apply to writing software that controls a script-based instrument directly without using an instrument driver.

About the Authors
Paul Franklin is the manager of Keithley Labs, the technology development group within Keithley Instruments. He chaired the LXI Consortium’s Technical Committee from 2005-2007. Before joining Keithley Instruments in 2000, he gained more than 20 years of measurement and control industry experience as an engineer and a manager with electronic controls and industrial automation firms. Mr. Franklin earned B.S.E.E. and M.S.E. degrees at Case Western Reserve University and is a member of IEEE, the IEEE-Computer Society, the IEEE-Instrumentation and Measurement Society, and the Association for Computing Machinery. 440-542-8097, e-mail: pfranklin@keithley.com 

Todd A. Hayes is a senior staff firmware engineer at Keithley Instruments. He has more than 15 years of experience in embedded firmware design and was the lead firmware architect on development of the company’s TSP. Mr. Hayes received B.S.E.E. and M.S.C.S degrees from the University of Akron. 440-248-0400, e-mail: hayes_todd@keithley.com 

Keithley Instruments, 28775 Aurora Rd., Cleveland, OH 44139

PDF of this article

View Past Archived Articles

Back to Top

Programming Preliminaries

By Paul G. Schreier, LXI ConneXion Editor, and
Brian H. Powell, National Instruments

In some situations, working with an LXI instrument can be extremely easy. Make an Ethernet connection between a PC and an LXI instrument, enter its IP address into a Web browser, and begin some simple work on the Web pages embedded in the instrument such as taking a reading.

This approach, however, is useful for only the most basic applications and might not work for some LXI instruments. Before you can start to program an LXI test system of any realistic complexity, you must do some minor prep work involving drivers and other support software.

In the process, you’ll run into a number of standards and terms that might not be familiar. Keep in mind, though, that much of this software functions behind the scenes so you won’t have to concern yourself with what is going on at the low level. Nevertheless, knowledge of what is going on is important (Figure 1).

(To View Figure 1 click here)

Start With Drivers
All LXI instruments are programmable somehow. But it’s not always clear what options you have and how to choose among them.

The LXI standard mandates that every LXI instrument must have an Interchangeable Virtual Instrument (IVI) driver. The IVI Foundation defines a standard driver application programming interface (API) for programmable instruments.

Currently, there are two IVI driver formats: IVI-COM for working with COM-based development environments and IVI-C for working in traditional programming languages. However, most LXI instruments can be programmed in ways besides IVI, so it’s not mandatory to work with an IVI driver.

Instead, developers can use other driver technologies or work directly with SCPI commands. This is good news for users of Linux and other operating systems because IVI drivers are certified only for Windows.

Most programmable instruments speak a language called the Standard Commands for Programmable Instrumentation (SCPI). SCPI defines a standard command syntax rather than a standard set of commands. For instruments that support SCPI, the command language works regardless of the bus being used, whether it’s GPIB, RS-232, or Ethernet. But SCPI doesn’t define how you send those commands.

Without such higher-level APIs, users would have to write code specific to each bus. For instance, if you wanted to write to a serial device, you could look up the OS’s serial API, such as CreateFile on Windows, to send and receive ASCII strings. If you wanted to write to a GPIB device, you could use the vendor’s driver that came with the GPIB card. To write to a USB device, you could learn the OS’s USB API and implement a USB test and measurement class layer. And for a VXI-11 device such as an LXI instrument, you could use remote procedure calls (RPC) with an RPC library.

Fortunately, there is a higher-level API called the Virtual Instrument Software Architecture (VISA) that abstracts the different buses into a single unified API. VISA allows you to send SCPI commands to an instrument in an OS-independent, transport-independent way. In the case of LXI, VISA eases the communications between the Ethernet controller in a PC and an LXI instrument.

Over Ethernet, VISA supports two different technologies for communications. One is a protocol called VXI-11 defined in 1995 by the VXIbus Consortium. This standard isn’t specific to VXI hardware. In fact, it’s become the de facto standard for all Ethernet-based instrumentation. It supports concepts familiar to users of GPIB such as the capability for instruments to request service and for computers to interrupt a measurement in progress.

The LXI 1.0 and 1.1 standards required that LXI instruments implement basic VXI-11 capabilities for instrument identification. This will be changed in future versions of the LXI standard.

The other network protocol supported by VISA is a raw TCP/IP socket, which you can use with instruments that do not fully implement VXI-11. Some instrument designers forgo the complexities of VXI-11 and only implement a simple network port through which you can send commands and receive responses. This usually means that those instruments do not implement an asynchronous notification mechanism such as service requests.

VISA also can communicate over other buses. The common implementations of VISA know how to talk to instruments over GPIB, RS-232, USB, PCI/PXI, and VME/VXI.

With VISA, you can concentrate on writes and reads without worrying about RPCs, serial I/O, or lower-level bus technologies. Further, VISA isolates the user software from the instrument bus so users can easily combine LXI instruments with GPIB, serial, or USB instruments in hybrid systems with little effort.

As for commercial VISA implementations, the two most popular are NI-VISA from National Instruments and Agilent VISA. NI-VISA is available as a separate product and included with the company’s instrument control hardware such as GPIB controllers and various software development environments. Agilent VISA comes as part of the Agilent IO Libraries Suite, available as a separate product, and with the company’s hardware products.

Neither implementation is free. You must either purchase a license for it or use one of the companies’ other products to be properly licensed. Suppliers of other application development environments (ADEs) sometimes assume you have a VISA that comes with the instruments you own.

IVI Abstracts Instrument Classes
Where VISA’s role is to abstract the communications layer, IVI’s role is to remove the differences between models of the same class of instrument. For example, the IVI-Scope API presents a standard, interchangeable API that lets you program most commands that most oscilloscopes implement. IVI uses VISA as its transport layer; in other words, IVI calls VISA, which then calls lower-level APIs.

Besides installing an instrument-specific IVI driver, you also must load a set of IVI Shared Components. Because there are some key components to all implementations, the IVI Foundation created these shared components to make it easier for users when they combine drivers and software from multiple vendors.

The components provide services to drivers and clients that need to be common such as the administration of system-wide configuration. They generally are installed with the development environment or as part of an instrument driver’s installation procedure. If not, they can be downloaded separately from the IVI Foundation website.

When speaking of shared components, you’ll sometimes see a reference to the IVI Configuration Store, which is accessed only through the IVI Configuration Server, one of the shared components. The Configuration Store publishes the list of instruments supported by a particular driver.

In addition, an end user can create an alias for an IVI device through utilities such as NI’s Measurement & Automation Explorer (MAX), which will write this information to the Configuration Store. The average user doesn’t interact with the Configuration Store directly but only through installers and higher-level configuration utilities.

Accessing Advanced Features
If you want to take advantage of the advanced features of LXI Class A and B instruments, such as software synchronization over the LAN, you also can work with a special API called IviLxiSync, which comes with each specific driver from each vendor. In IVI-C, it consists of a few more functions in the driver DLL. In IVI-COM, it is represented as yet another interface that COM-aware applications can take advantage of.

With IviLxiSync, you can configure an instrument to participate in IEEE 1588 time synchronization through a Web page and have the data automatically timestamped, or you also can set up LAN and Wired Trigger Bus triggers through normal SCPI commands. The purpose of the IviLxiSync API is to make that job easier. However, because each vendor supplies its own IviLxiSync API with its instrument drivers, you have to use a different library for each instrument.

How users approach LXI instrument drivers varies widely. Some are very happy to have prewritten drop-in drivers they can use right away for system development without worrying how they are implemented. Other users want to look inside to see how the driver is implemented and be able to debug and optimize the driver to meet their needs.

As a result, the availability of source code in a language they’re familiar with for their instrument drivers can be important. Some users feel that drivers without source code can be problematic—they must rely on the driver vendor for explanations, bug fixes, or updates.

Sometimes instrument vendors contract driver work to third parties, making it even more difficult to get good support. On the other hand, drivers that ship with source code native to their development environment are easily understandable by end users.

For instance, engineers familiar with C can dig into IVI-C drivers. NI’s LabWindows/CVI is a popular tool for C driver development. LabVIEW is another application development environment that enables end users to work with driver source code directly.

The Final Step: Discovery
With the instruments now communicating with the central controller, how do you find out what instruments actually are connected and what their network addresses are? This is where you run discovery tools, such as the Agilent Connection Expert (ACE) and NI’s MAX. These tools search a network to discover all available LXI devices and make it easy to identify the instruments and view their Web pages. ACE is included with the Agilent IO Libraries Suite, and MAX accompanies NI’s development environments and driver software (Figure 2).

 
 Figure 2. LXI Discovery Using the Measurement & Automation Explorer 

The LXI Consortium has defined an improved mechanism for instrument discovery and identification in the recent LXI 1.2 standard.1 These updates will be implemented in the discovery tools that instrument vendors offer.

System setup is complete, and the ADE knows which instruments are on the network. Now you can move on to the actual program development.

Reference
1. Barendt, N., “LXI 1.2 Improves Discovery and Identification,” LXI ConneXion, February 2008, pp. 12-16.

About the Authors
Paul G. Schreier, editor of LXI ConneXion, is a technical journalist and marketing consultant working in Zurich, Switzerland. He was the founding editor of Personal Engineering & Instrumentation News, served as chief editor of EDN Magazine, and has since written articles in countless technical magazines. Mr. Schreier earned a B.S.E.E. and a B.A. in humanities from the University of Notre Dame and an M.S. in engineering management from Northeastern University. e-mail: paul@pspr.biz

Brian H. Powell is a software principal architect in LabVIEW R&D at National Instruments. Mr. Powell represents the company at LXI Consortium meetings and has implemented the LabVIEW version of the LXI Class A and B multivendor system demo. He received a B.A. from the University of Texas at Austin. National Instruments, 11500 N. Mopac Expwy., Austin, TX 78759, 512-683-5506, e-mail: brian.powell@ni.com

FOR MORE INFORMATION
on IVI Shared Components
www.rsleads.com/814ee-176

PDF of this article

View Past Archived Articles

Back to Top

---

---

---

Class C Can Be Quick and Easy

By Bill Yonkers and Stephen Kugler, Kepco

The LXI protocol offers a multitude of interfaces for communications with test equipment, including LAN Web pages, VISA sockets, and VISA VXI-11 interfaces. Converting an existing serial instrument to an LXI Class C device can be done quickly and economically using an off-the-shelf Ethernet-to-serial converter.

Choosing the Converter
Since many vendors offer off-the-shelf Ethernet-to-serial converters, make sure that the converter you choose meets the minimum requirements for buffer space, supports dynamic host configuration protocol (DHCP) and static IP addressing, and has in-the-field upgrade capability.

Although most available converters share the same space for code and data buffers, some do have separate areas for those two items. An evaluation of the requirements showed that an LXI Class C device needs a minimum of 24 kB of buffer space to support the required ports.

Kepco designed LXI devices by modifying off-the-shelf converters manufactured by Lantronix and Netburner. Our development cycle time was less than one man-year, and we used a subcontractor for the IVI driver. Our LXI devices have at least 256 kB of space allocated for the program code. With both the Lantronix and Netburner converters, we used 130 kB for the application with almost 70 kB of the space allocated to Web pages.

Ethernet Basics
An Ethernet device uses specific ports to send and receive commands. Figure 1 shows the ports required by an LXI device. Only the SCPI RAW port and VXI-11 port communicate with the Class C device because they receive messages for the device and send responses back to the host computer. The SCPI RAW port is a socket interface and provided on all converters. It usually has the capability to make one or two connections.

Figure 1. Major Functions of a LAN-to-Serial Converter Used in an LXI Instrument

An instrumentation engineer usually has worked with GPIB and is accustomed to having unlimited connections to a device. However, the connections to an LXI device are limited because each one requires dedicated memory for its send and receive buffers.

If an LXI device has insufficient connections, program debug becomes complicated. At least four connections are needed to improve the first-time experience designing and debugging an LXI product.

Another feature helpful during user integration is the Telnet port. While not required by the specification, it provides a way to send commands to a device and get responses, like the features found in the National Instruments Measurement & Automation Explorer and the Agilent Technologies Connection Expert.

Converter Modifications
Although an off-the-shelf converter has many of the functions required to meet Class C compliance, it will not have support for several functions needed in LXI instruments, including a LAN LED display and LAN Reset, which ensure that all LXI devices start up in the same manner; discovery, which encompasses both VXI-11 support and Remote Procedure Calls (RPC) Get Port functionality; and an IVI driver for the device. In addition, many off-the-shelf converters do not support AutoIP and duplicate IP. 

Let’s take a look at implementation details of each of these requirements.

LAN LED
The simplest LAN-activity display can be a one-color LED with three states:
• Off to indicate the LAN detected an error.
• On to indicate the IP address is valid and the unit is able to communicate.
• Blinking when an operator activates the identify function via the Web interface.

If the converter supports AutoIP, then it accommodates duplicate IP detection as well. When an LXI device detects a duplicate IP, it must stop using that IP address. However, if the address in use was selected using AutoIP, device operation over the LAN can continue using a different IP address. Otherwise the LAN LED must be turned off and remain off until either the power is cycled or the LAN Reset is activated.

LAN Reset
In an LXI device, LAN Reset consists of two steps. First, enable DHCP and AutoIP; second, restart the converter to determine its IP address. A designer also can choose to implement many optional features that provide enable and disable capability through the Web interface such as ping, VXI-11 discovery, and multicast DNS (mDNS) support. If these capabilities are configurable, then they must be enabled after a LAN Reset.

Duplicate IP Detection
Duplicate IP detection is accomplished using the Address Resolution Protocol (ARP) over the network. ARP is the method for finding a host’s hardware address when only its IP address is known.

ARP packets have a content that Wikipedia defines as, “On Ethernet networks, these packets use an EtherType of 0x0806 and are sent to the broadcast MAC address of FF:FF:FF:FF:FF:FF. Note that the packet structure shown in Table 1 has SHA, SPA, THA, and TPA as 32-bit words but this is just for convenience—their actual lengths are determined by the hardware and protocol length fields.”

Table 1. Packet Structure for Address Resolution Protocol
Source: Wikipedia

AutoIP Support
The converter’s ARP module will need modification if AutoIP is not supported. The modification must process each received ARP packet by comparing the IP address against the device’s IP address. If the comparison is true, it is a duplicate IP address. The LXI device turns its LAN LED off and stops using the IP address.

An LXI device can use the ARP logic to ask another device to send its IP address. This is done using a special ARP packet called a Null Probe.

The Null Probe is used to ensure that either a static IP address, an address provided by the DHCP server in the system, or an AutoIP address is not already in use on the network. The Null Probe contains the sender’s media access control (MAC) address, a 0 for the sender’s protocol address, the target’s hardware address, and the IP address being verified as the target protocol address.

ARP packets are broadcast to all devices on the network. If the target protocol address matches the device’s IP address, the target responds with an ARP packet to the sender.

Broadcast messages sometimes are lost in large networks, but this can be overcome by sending the Null Probe packet multiple times. This code snippet shows the Null Probe packet is sent three times with different delays and the duplicate address flag is tested:
            EthernetIP=ip_addr;        // so duplicate address will be detected
            Null_Probe(ip_addr);        // send a probe
            OSTimeDly( 7);
            if (Duplicate_address == 0){
                Null_Probe(ip_addr);        // send a probe - second required
                OSTimeDly( 5);
                if (Duplicate_address==0)
                   {
                          Null_Probe(ip_addr);        // send a probe - third required
                          OSTimeDly( 8);
                    }
            }
 

The transmission of three packets is a standard method as defined in RFC 3927. This time-delayed multiple transmission process provides adequate assurance that the packet will be received by all devices in the network. There are multiple attempts to detect the duplicate address, but if the address is duplicated, the routine exits to reduce network traffic.

AutoIP
AutoIP automatically selects an IP address without using a DHCP server. It uses pseudorandom IP addresses to create an IP address and then the duplicate IP address logic to verify that another device on the network is not using the created IP address. If the address is in use, the LXI device probes for a new address.

Not all converters support AutoIP, but you can implement it by trying an address, detecting if it’s in use, and if so, looping until a free IP address is found. AutoIP uses a specific address range from 169.254.000.000 through 169.254.254.254.

We recommend that AutoIP be done using a pseudorandom number generator and that the numbers be seeded using a MAC address. In this way, each device has a unique series of addresses that will be probed.

This method has been proven in networks of 1,800 devices; the number of attempts any device incurs is three to find a valid address. This yields a 30-s time period for all 1,800 units if they powered up at the same time.

Implementing the VXI-11 Protocol 
The LXI device must support the VXI-11 protocol to provide a discovery method. The discovery method requires at least two port connections on the device: Port 110 to receive a Get Port command and another connection on a different port, normally 1024, to perform the VXI-11 commands.

The VXI-11 protocol mimics the IEEE 488.2 interface using Ethernet to make the connection between the host and the device. It has some advantages over a socket interface because it provides the capability to support an interrupt request such as the SRQ line of the GPIB interface and single-byte commands like Selected Device Clear.

The VXI-11 protocol is based on the standard for RPCs developed in the 1970s. The RPC relies on a tool called RPCGEN that creates all the code needed to implement this functionality in an LXI device. When working with a small embedded-processor instrument, this tool generates more code than is required to meet the LXI requirements.

Implementing VXI-11 LXI Discovery 
There are two parts to the LXI discovery process: first, the RPC Portmap command, which is the port number of the VXI-11 protocol, is published, and second, the actual VXI-11 commands are sent. A documents archive found in the LXI Consortium’s LAN and Web groups contains two Zip files that provide code for the two parts of the process.

The LXI specification states, “The VXI-11 protocol shall be supported by all LXI devices for discovery purposes. Discovery shall be accomplished by issuing a broadcast RPC on the host’s subnet. The broadcast RPC shall be to either the portmapper itself on Port 111 (querying for VXI-11 support) or the Null procedure (procedure 0) on the Program Number assigned to the VXI-11 Core Service (0x0607AF).”

The first part of this requirement is creating the portmapper process for a broadcast packet to Port 111. The response to a broadcast command is either the port address or no response at all. This makes the code easy because the packet returned is a constant, and a response is only required if the program number is 0x0607AF. 

The second part of the portmapper is supporting a standard RPC to the Null procedure. When a Null procedure is received, the device should indicate that the port is supported by the device.  

To complete successfully, the discovery process needs five VXI-11 commands: create_link, destroy link, device write, device read, and do_cmd. This functionality is provided in the VXI-11 discovery code available in documents archived by the LXI Consortium’s LAN and Web groups.  

This code offers only minimal functionality for discovery. Without modification, it allows a device to be discovered, but it does not provide a properly formatted *IDN? response. The response to the *IDN? query should be in the IEEE 488.2 format, which is defined as a string consisting of four comma-separated fields with a line feed 0x0a at the end of the data.

The first field is the manufacturer name, the second field is the device’s model number, the third field is the device’s serial number, and the fourth field is the revision level. The fields themselves must not contain any commas, which instead are used by the recommended discovery tool available at the LXI website. This tool parses the response and provides the information in a columnar table.

Creating an IVI Driver  
IVI drivers simplify the job of programming an LXI device. An IVI driver is the next generation of a VXI plug-and-play driver, which provided functions that lowered the development cost for system integrators. But it did not require common function names so each driver was unique.  

The IVI driver specified by its class has common function names. This standardization on functions across instrument classes reduces integration time for users of LXI devices and provides common functionality among vendors of LXI devices.  

For the manufacturer of an LXI device, the creation of an IVI class-compliant driver might appear to be very difficult. However, if supplied in the IVI-COM format, the driver works in LabVIEW, Agilent VEE Pro, MATLAB, Measure Foundry, Visual Basic, and all C environments, multiplying the return on investment.  

Looking at the list of LXI instruments on the IVI Foundation website, almost all provide an IVI-COM driver. A COM driver is not modifiable by the user and gives the instrument vendor control to prevent unintentional changes in the driver. For customers who want to work on the driver or use it in the Linux or other operating systems, the C source code of the COM driver, if available, allows users to work with the driver and make modifications.  

When developing the driver, time is divided into three tasks: creating the driver, testing it, and documenting it. Each task takes about the same time, and driver testing is the most difficult.  

Start thinking about driver development early in the design phase to be sure that any functionality required by the driver is incorporated in the basic instrument. For instance, driver development for our KLP power supplies revealed that a function called Trigger Immediate needed to be added to the basic instrument. It turned out that this function provided a way to debug trigger code quickly and easily, and we have added it to all our products.  

When developing an IVI driver, be aware of available helpful tools such as National Instruments’ LabWindows/CVI as well as those from Vektrex and Pacific Mindworks. A check with LXI Consortium members shows that the overwhelming choice for outside help in driver development is Pacific Mindworks.  

Finally, the LXI specification for Class C requires two Web pages, which must be in valid HTML as defined by the w3c.org validator. When writing the HTML, use cascading style sheets (CSS) styles instead of embedding the formatting. This reduces code size and makes it much easier to change the look of the pages during the design phase.  

Conclusion 
To help keep momentum in the growing number of LXI instruments, Kepco provides its code for both the Netburner and Lantronix modules to members of the LXI Consortium. The Netburner LXI functionality is C source code that can be adapted to work in other environments. The Lantronix code comes as an object file that links to the Lantronix operating code; it cannot be provided in source format.  

We recommend that anyone starting to develop their first LXI instrument join the LXI Consortium, in particular the Technical Committee and the LAN, Web, and Compliance working groups. In these groups, you can gain access to an extensive knowledge base as well as the annotated LXI specification. This annotated specification provides observations on how the specification was created and why some of the implementation requirements were included. We found it extremely useful during product ­development.  

Further, during Kepco’s design process, the capability to test ideas and get feedback at the LXI group meetings and LXI Consortium PlugFests was invaluable in completing the development in a timely manner. Our company joined the Technical Committee and the LAN and Web working groups. The document archives maintained by the consortium and the ability to question members on specific aspects of the design moved us quickly toward successful completion and should prove equally helpful to other designers implementing LXI for the first time.

About the Authors
Bill Yonkers is the embedded systems manager at Kepco. Mr. Yonkers earned a B.A. from Queens College and an M.C.S. from Hofstra University in 1999. Before joining Kepco, he was the senior engineering manager at NAI Technologies. Kepco, 131-38 Sanford Ave., Flushing, NY 11352, 718-461-7006, e-mail: WYonkers@kepcopower.com
 

Steve Kugler is the communi- cation media manager at Kepco. Previously, he had more than 25 years of experience as vice president of operations for Point Industries. Mr. Kugler received a B.A. from Lehman College and holds a Certificate in Engineering Technology from the RCA Institute.

 

PDF of this article

View Past Archived Articles

 

Back to Top

 

---

---

---

PlugFest Offers More Than Conformance Testing

By Paul G. Schreier, Editor

 

Going by the name alone, you might think that an LXI PlugFest is a meeting aimed at helping manufacturers get LXI instruments certified for conformance to the specification and added to the list of approved instruments. The October meeting in Munich, hosted by Rohde & Schwarz at its Training Center, shows that a PlugFest is only partially about instrument testing. 

A variety of meetings provided a great deal of information about the current state of the LXI spec, user tips and tricks, and what to look for in the future. With approximately 50 attendees, mostly consortium members from Europe and North America, this was a gathering of the LXI elite.

A visit to a subsequent PlugFest would be well worth the time if you are thinking about introducing an LXI instrument or deploying an LXI system or have questions about existing systems. The attendees are all very knowledgeable about LXI and more than happy to share their expertise in this open, friendly environment.

If this summary has attracted your interest, the next PlugFest will be held Feb. 11-13 in Anaheim, CA. Best of all, there is no attendance charge. For anyone serious about working with LXI, this is an opportunity that should not be missed. Details are available on the LXI Consortium website.¹

A PlugFest typically is three days long, and participation in the first half is limited to members of the LXI Consortium. During this time, compliance testing takes place, and the technical committees meet to review progress and make plans for improvements to the spec. This time, they also voted to approve Version 1.2 of the specification. See the article about Revision 1.2 in this issue for details.

The second half of the meeting kicked off with a series of tutorials to help developers and users get the most out of their LXI systems. The last day included a series of application talks that illustrated how extensively LXI is being adopted.  

PlugFest Host Jochen Wolle, Rohde & Schwarz, and LXI Consortium President  Bob Rennard, Agilent Technologies

One consortium officer remarked on how the flavor of an LXI PlugFest has changed. Just a year ago there were few products in use while at this one there were quite a few applications for vendors to report.
 
Certification Options
For companies with new products, the focus of the PlugFest was compliance testing. Going to such a meeting isn’t the only way to get new equipment certified, explained Mr. Wolle, chairman of the Conformance Working Group, in a presentation he made to the PlugFest. There are two other ways to get approval: on the grounds of technical justification because a new product is a derivative of an existing product and the LXI portion remains unchanged or by submitting a new product to a consortium-approved independent test lab.

Until this meeting, the only authorized testing lab was run by Wheelwright Enterprises.² Lynn Wheelwright, the owner and a 35-year veteran of Hewlett-Packard and Agilent Technologies, also provides consulting services for companies developing LXI instruments. For the moment, he only tests Class C devices shipped to his facility in Santa Rosa, CA, although he was performing Class A and B testing at the PlugFest.

To give European companies a similar resource, the consortium announced that a second test lab had been approved: the German Hardware Test Center (GHTC), the internal compliance and reliability test lab of Agilent in Böblingen, Germany. Again, this is only for Class C devices although Jochen Schmidt and Marcus Flach, the two engineers responsible for LXI testing, hope to add Class B testing capabilities soon.

Although the GHTC focuses on instruments from Agilent, the services also are available to outside companies. This lab operates independently from the Agilent business unit, offers experience testing non-Agilent devices, and has strict quality and confidentiality processes. In particular, the GHTC has been accredited according to ISO/IEC 17025 by DATech, the German accreditation body for technology.

When companies are preparing new LXI instruments, they also should be aware of the software developed by Mr. Wheelwright that is used during conformance tests. Consisting of a .net application and some PERL scripts, the Compliance Testing Suite steps through a tree structure to test key aspects of conformance to the spec, gives some corrective suggestions if errors arise, and creates the necessary documentation for final signoffs.

Best of all, this same software is a free download to members only on the LXI Consortium website. That way developers can check their new instruments on the same certification software at their own sites and have a good idea of what to expect when they submit the instrument for approvals. 

The LXI Complian