The Magazine Dedicated to the Next Generation of Test Systems that Harness the Power of Ethernet
Articles
Customer Demand Draws Suppliers Into LXI Camp
By Paul G. Schreier, Editor
IEEE 1588 to Transform Timing Synchronization
By Paul G. Schreier, Editor
Selecting Your Optimum LXI Feature Set
By Paul G. Schreier, Editor
By Paul G. Schreier, Editor
The Need for Conformance Testing
By Jochen Wolle, Rohde & Schwarz, and Lynn Wheelwright, Wheelwright Enterprises
Tools for Developing LXI Systems
By Paul G. Schreier, Editor
By Paul Franklin and TODD A. Hayes, Keithley Instruments
By Paul G. Schreier, LXI ConneXion Editor, and
Brian H. Powell, National Instruments
By Bill Yonkers and Stephen Kugler, Kepco
PlugFest Offers More Than Conformance Testing
By Paul G. Schreier, Editor
LXI 1.2 Improves Discovery and Identification
By Nick Barendt, VXI Technologies
LXI System Setup Is Quick and Easy
By Tim Ludy, Data Translation
Customer Demand Draws Suppliers Into LXI Camp
By Paul G. Schreier, Editor
The number of vendors supplying LXI instruments continues to grow. The first to make introductions, as you might expect, were the larger instrument houses. Now, however, many other companies are getting into the action.
Powering LXI
A look at the list of all LXI products
reveals that power supplies are one of the largest categories.
Recently, Magna-Power added LXI as an option for its entire line
of supplies, whether the units have traditional front panels or
blank panels with software-only control. The company usually has
dealt in high-power supplies ranging from the XR Series (2 to 6
kW), PQ Series III (3.3 to 10 kW), TS Series III (5 to 45 kW),
and MS Series III (30 to 75 kW) to the MT Series IV (100 to 150
kW).
Customer demand led the company to develop LXI versions of them all, reported Adam Pitel, director of business development. He explained that all the products previously had Ethernet links, but customers often want to drop a new power supply into existing configurations. LXI seems to be a trend among power supplies, and this puts his company in a competitive position with the very large companies who have LXI-based supplies.
Magna-Power’s Software User
Interface With Flash Implementation
In addition, Magna-Power is moving into the lower power market with its associated higher quantities. LXI reduces system development time and provides other advantages such as the capability to drop in a supply and use its autoconfiguration features.
And while the LXI interface has only been available for a relatively short time, Mr. Pitel explained, "One of our customers is using LXI standards to minimize setup for a project currently in the R&D stage. His company purchased two LXI power supplies with intentions to buy dozens more after R&D is complete. Using the VXI-11 discovery protocol, he plans to simply drop in the future supplies and minimize communications setup."
In addition, the IVI driver has received a positive response. A user can write a customized control interface with the language of his choice without being burdened with the details of the underlying communications mechanism. The same program/code can be used to communicate with the power supply over RS-232, GPIB, or Ethernet. The IVI driver’s DCPwr API also allows users to apply the same code across multiple models and even multiple manufacturers.
Magna-Power also wanted a way to update its LXI Web pages on the fly. So, in addition to a standard LXI Ethernet implementation, the company included an embedded Web server. Mr. Pitel noted that with any browser-enabled Ethernet-controlled instrumentation there’s a need for dynamic presentation; that is, real-time communications between the instrument and the browser-based software. Provisions for this type of control are not built into Web browsers, which instead use third-party plug-ins such as flash, Java, or Microsoft’s Silverlight.
"We wanted our LXI implementation to require zero installation and have a universal form of control available to anyone on the network. In addition, we needed to minimize the memory requirements on our power supplies’ embedded Web server. Accordingly, our choice of flash, with its 99% market penetration, assured that virtually anyone can access our instruments’ Web servers. Flash also allows us to do things graphically that, on other platforms, would be very costly in terms of storage."
LXI Coming in Low-Cost Versions
Another power supply manufacturer, Thurlby
Thandar Instruments (TTi), now has two LXI models among its
linear programmable supplies: the first was the PL-P Series 90-W
lab supplies and more recently the QPX1200L, a 1.2-kW unit
featuring PowerFlex regulation that offers combinations between
60 V/20 A and 20 V/50 A. A linear output stage within the
PowerFlex regulator gives it an output noise of <3-mV rms and a
transient recovery time typically 10x better than conventional
switch-mode units.
Sales Director Mark Edwards explained that the company adopted LXI as a standard interface on new developments because of the availability of LANs and the lower infrastructure cost for customers. The company decided to add LXI compliance to provide what it expects will become the industrial norm for a LAN interface, one that is proving popular for fully automated test systems and semiautomated test procedures.
Customers still are not completely clear about the benefits that LXI compatibility offers, he said. Hopefully, this will improve as they start using LXI products from a range of manufacturers, which all provide the same protocols for the interface.
Implementing a LAN-based test system is less expensive than a GPIB system, especially when comparing the costs of LAN vs. GPIB ports and cables. However, TTi continues to maintain a GPIB interface on new products because some traditional engineers with legacy test systems still prefer an interface that they have used for many years.
But as a wider range of LXI products becomes available, the company expects to see more test systems being developed that use only the LAN interface. Presently, most new test systems still offer traditional RS-232, GPIB, or USB interfaces mixed with LAN or LXI instruments. In every reported implementation of the LXI interface, said Mr. Edwards, customers have found the implementation of the products uncomplicated.
"We at TTi produce low-cost products with often limited amounts of onboard processing. The implementation of LXI compliance compared to a simple LAN interface can add significantly to the per-unit cost and required development time," he continued. "For that reason, we’ve developed a communications board that we hope will enable us to implement LXI interfaces on all new instruments, even for those selling below $700."
Large Acquisition Memory for LXI
One of the most recent scope manufacturers to
join the LXI ranks is Yokogawa Corp. of America with the DL9000
Series of digital-sampling and mixed-signal scopes and the
SB5000 Vehicle Serial Bus Analyzer, which can analyze FlexRay,
an emerging bus technology used by advanced electronic control
units (ECUs) and electronic vehicle control applications. The
DL9000/9100/9200 units provide four analog channels, four math
channels, bandwidth of either 500 MHz or 1 GHz, and either 2.5
or 6.25 Msamples/channel of onboard memory. The DL9700
Mixed-Signal Scopes add 16 or 32 logic channels, and all have
6.25 Msamples/channel of memory.
In recent years, explained Joseph Ting, product manager for high-frequency instruments, the available acquisition memory in waveform-measuring instruments, including oscilloscopes, has been increasing at an exponential rate. Memory itself has never been a limiting factor, he added. Rather, until recently, the display and data-processing engines of the instruments didn’t have the computing power to maintain the waveform and display update rates in combination with long memory. This trend of larger acquisition memory also causes increased demands for the transfer of waveform data to host computers, and legacy interfaces such as GPIB no longer are viable or practical.
LXI has emerged as a new standard for instrument communications, one that provides high speed, low cost, relatively simple migration from legacy interfaces, and ease of use. Yokogawa has concluded that LXI is the most suitable next-generation instrument communications and automation technology platform. In addition, the company has seen an increase in customer requests for LXI support in its instruments.
DL9000 family scopes can provide high-speed waveform acquisition in combination with advanced waveform-analysis features. For example, they feature real-time analysis capabilities such as digital filtering, FFTs, histograms, trending, serial bus decode, switched-mode power supply analysis, user-defined math, and automatic waveform-parameter measurements. By using the scope’s high-speed analysis capabilities and then LXI to transfer analysis results to a host computer, the performance of an automatic test system can be increased while simultaneously reducing software development cost. If such functions are implemented in software on a host computer, it will take far more time and cost to develop and debug the software.
For instance, Mr. Ting explained, when ADC or DAC engineers evaluate the characteristics of a data converter, they often convert pre- and post-converted digital bits to analog data. In many cases, they use a logic analyzer to capture these digital bits and then must write their own analog-conversion routines.
In contrast, a DL9000 mixed-signal unit operates as a simple logic analyzer and provides a virtual D/A function that converts digital data from the logic inputs to corresponding analog data in real time. By using this feature with LXI, a converted waveform from digital data can be viewed and analyzed much faster than through a logic analyzer with additional software. It reduces test, development, and debug time.
Tegam’s 1830A RF Power Meter
New Instrument Types in the LXI List
While you can find a number of traditional
multimeters in the LXI format, perhaps the only dedicated LXI RF
power meter is Tegam’s Model 1830A, which comes with LXI and USB
compatibility. Thermistor RF power sensors are universally
recognized as the most accurate means to measure and transfer RF
power. This unit works with all types of thermistor sensors and
a power range from -30 to +14 dBm, a frequency range from 100
kHz to 40 GHz, meter uncertainty of ±0.05% of reading ±5 µW, and
four-digit calibration factor resolution.
As for the decision to add LXI functionality, Tegam’s President Adam Fleder said, "Several factors drove this decision. When you design any new box instrument today, you must consider a range of interfaces: GPIB, RS-232, USB, and LXI. The lowest-cost interfaces to implement these days are Ethernet and USB.
"We evaluated the applications for this product against the development costs and found that most users weren’t interested in paying more to include GPIB," he continued. "RS-232 also is not available on most computers these days so it was unattractive."
He added that an RF power meter has some unique requirements and is more complicated to operate than a standard DMM or signal generator. These meters are used in conjunction with RF power sensors, each of which has a multipoint calibration factor correction table that must be loaded and managed. With the LXI interface, users can directly and remotely access the meter’s internal functions without writing or loading software on a PC.
Likewise, the calibration tables for sensors can be uploaded without additional effort. You simply click on a link in a browser and select the tables on the computer. You could be sitting with the 1830A on a bench, or you could be updating a table for a customer in Singapore. Tegam used the same capability to load new firmware into the instrument and can remotely add functionality through the LXI interface anywhere in the world where there is an Ethernet connection.
Another unique capability, said Mr. Fleder, is the addition of an HTTP server to implement an internally hosted, fully guided, and self-documenting calibration procedure. It tells the technician which equipment is needed, has diagrams that show how and when to connect it, and then updates the instrument’s internal calibration settings. To Tegam’s knowledge, this is the first commercial implementation with this capability. This internal automation simplifies what once was a manual process or has been automated with external equipment.
TTi’s QPX1200L Power Supply With Communications Board
Movement Into Other Classes?
All of the LXI instruments discussed in this
article are Class C so they don’t benefit from the Ethernet
precision timing protocol or the wired trigger bus of Class A
and B units. Can we expect these instruments to soon appear in
upgraded versions? Likely not.
For instance, TTi feels that the Class C standard more than meets the expectations of customers for general-purpose instrumentation. Further development of Class C would add requirements and cost, leading manufacturers of low-priced units to resort to a LAN interface without LXI conformance.
Magna-Power decided to stay with Class C because the certification is consistent with the offerings from other power supply manufacturers. Tegam didn’t consider Class A or B for its power meter because this instrument has a fairly low data rate without any need for tight synchronization. However, the company indicated that it certainly would develop a Class A or B design when the application requires it.
About the Author
Paul G. Schreier 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 written
articles for countless technical magazines. Currently, he is the
editor for LXI ConneXion at EE-Evaluation Engineering. 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
View Past Archived Articles
IEEE 1588 to Transform Timing Synchronization
By Paul G. Schreier, Editor Over the past few months, and especially in
our update on Class B instruments in the September 2008 issue
"The Killer Bs Are Coming," we have been reporting on the
advantages of the IEEE 1588 precision timing protocol (PTP) and
the application areas it is opening up for LXI instruments.
There are, however, considerable 1588 interest and emerging
activity in other industrial branches. In some cases, it even
could initiate a switch away from some of today’s dominant
timing methods. Application areas already involved are power
generation/grids, industrial automation, and electronic test
while telecom, consumer/professional AV, military test, and even
financial applications are showing very high interest and
conducting trials. According to Bill Seitz of IXXAT, a company
that provides protocol stacks, "A better question is this: What
applications won’t be converting to 1588?" He also reported that in the last year his
company received an average of one inquiry per day from
companies wishing to put together a 1588-based system. And even
in this business environment, the frequency of inquiries
continues to pick up. "There’s no recession in 1588 that we can
see," he added. Endorsing this feeling was Doug Arnold, a
product architect at Symmetricom, a company that manufactures
timing equipment. "As timing mechanisms go, 1588 is going to be
bigger than anything we’ve ever seen before due to its broad
appeal. It’s easy to add 1588 as an extra feature to any number
of products, and it will become very pervasive," he explained.
What’s the Attraction?
So how does this PTP work? Every 1588-based
system must have a grandmaster clock. Through the multiple
exchange of timing and verification messages, each slave clock
can determine the amount of delay that message-passing takes and
then synchronize its own local time to that of the grandmaster
(Figure 1).
To account for variations in network loads,
synchronization messages are resent every second. At this rate
in most circumstances when using a hardware-assist, boundary
clocks, and other assists, it is quite easy to get
synchronization of 50 ns or better. Synchronized time does not necessarily have a
relation to the absolute time of day; rather, here a 1588
network consists of an island of highly synchronized devices
working on their own agreed-upon time scheme. You can, however,
coordinate this system time to absolute time by adding a GPS
receiver to the grandmaster. It’s instructive to compare the performance
of 1588 to precision timing schemes that have dominated until
now (Figure 2). One that also is based on standard
Ethernet is network time protocol (NTP), which has been in use
for more than 20 years. Its big drawback is accuracy: It can
deliver 1 to 2 ms performance on a LAN or 1 to 20 ms on a WAN.
But this is not guaranteed because of the delays inherent in
switches and routers and because many NTP clients run on
non-real-time operating systems. Windows, for instance, often
can add clock corrections of 10 to 50 ms because the system is
performing tasks deemed more important than timekeeping. Another popular scheme is the Inter-Range
Instrumentation Group (IRIG), developed in the 1960s and very
popular in mission-critical applications such as military,
aerospace, and power utilities. It increases accuracy to 1 to 10
µs. The big drawback is that a dedicated timing cable, typically
coax or optical fiber, must go to each slave device being
synchronized. And so the appeal of IEEE 1588: It improves
precision beyond that of IRIG while using commercial Ethernet
equipment and sharing timing data with regular network traffic
as does NTP. Devices such as Ethernet switches can add
nondeterministic latency and jitter to packet transit times from
a 1588 master to a slave. With enough switches and routers in a
system, 1588’s performance can drop to that of NTP. In these
cases, system designers often set up subnets controlled by a
boundary clock, a switch with multiple 1588 ports. It is a slave
to the grandmaster or another boundary clock on one port, and on
all other ports, it serves as a master for further downstream
subnets. Because so many industries were involved in
the IEEE 1588 committee, the standard ended up with almost a
superset of features. As a result, many industry groups are
defining profiles of the specific feature sets they need. There
still is some question as to what degree these profiles will be
interoperable.
IEEE 1588 in Action
While 1588 is just starting to gain traction
in the test world, other industries have been on-board for
several years. The industry currently using the most 1588 clocks
is power generation. Because it found what it needed in Version 1
of 1588, released in 2002, GE was an early adopter. The company
has since built in excess of 50,000 IO packs with 1588 clocks
that work in its Mark VIe Control Platform, reported Mark
Shepard, a consulting engineer with GE Energy’s Controls & Power
Engineering Center of Excellence. This platform is used widely in GE Energy
products from wind turbines to large gas and steam turbines as
well as on distributed control system applications. For
instance, when a utility suddenly sees large loads being added
or shed, such as when a big factory suddenly starts multiple
large machines, it must adjust the routing of its power to that
location, adding turbines within microseconds, if necessary. A
high level of synchronization is a common requirement for motion
control, robotics, and sequential CNC operations as well as
timestamping events for debugging. IEEE 1588 is used on GE’s IONet to maintain
synchronization of the controllers and I/O packs in a system for
both sampling and diagnostics. Using 1588, all input I/O packs
in a system autonomously sample inputs at exactly the same time
and simultaneously put their data packets on an Ethernet network
where the switches take care of queuing everything up for
transmission to the controllers. Then the control software makes
its calculations, and the output packets are sent and applied
simultaneously. Frame synchronization is achieved with the
1588 protocol. Every device knows what time it is, what the
precise frame period is, and the epoch for the start of Frame 0.
From there, each device can calculate the start-of-frame time
for every subsequent frame, and no other communications are
needed to maintain complete system synchronization. IONet is a closed network and not used as a
general-purpose LAN. Interoperability with other 1588 devices is
not supported by GE’s products. And although GE uses the
protocol, it is careful not to claim full compliance with the
standard. This is the model that other fieldbus manufacturers
follow with schemes using 1588 including ProfiNet and CIPSync, a
time-synchronization enhancement to the CIP factory network. Before 1588, such Ethernet-based schemes
relied on NTP, which is suitable for applications that don’t
need the highest level of accuracy. But in motion-control
applications, such as with multicolor printing presses moving
paper at incredible speeds, resolutions in the microsecond range
are necessary. ProfiNet doesn’t use every part of 1588.
Instead, it has its own profile, explained Franz-Josef Goetz, a
communications system architect at Siemens. He added that 1588
is simpler to implement with higher performance, and it places
fewer requirements on the PLLs used to maintain accuracy for
time synchronization. We might have to wait a while before there is
a universal standard for PTP in the heavily regulated
energy/power sector. However, a standard called IEC 61850
defines, among other things, Ethernet-based communications in
that sector, noted Heiko Gerstung, director of technical sales
and marketing at Meinberg. The company develops timing equipment
for a variety of protocols. The standard currently mentions only simple
network time protocol (SNTP) as a network time-sync protocol,
but people are working to add PTP to it. This work is not yet
completed, but Mr. Gerstung believes we will see something like
this as soon as standardization bodies integrate it and that
steps will lead to a significant increase in the number of
1588-capable devices. And while Meinberg sells many NTP devices
into this market, its 1588 business in power generation,
transmission, and distribution has been limited to a few
grandmaster devices used mainly in R&D and test labs.
When Mobile Phones Are in Motion
For the last few decades, telecom networks
have used digital sampling to provide high-quality voice
services over any distance. The regular sampling rate of voice
services has been matched by the use of time-division
multiplexing (TDM) in both switching and transmission equipment.
Nonvoice services, such as data and video, also have been
carried, quite often on dedicated links known as leased lines
where the service is maintained to a very high degree of
availability—and for a high fee. Until just a few years ago, voice service was
predominant, but nonvoice services now consume a greater
capacity. Leased lines have been a lucrative offering, but
guaranteed availability carries its own costs, and leased lines
are difficult to adapt to load changes. Carriers have been searching for a way to
converge all types of traffic onto a single network for cost and
flexibility reasons, and for this they’ve chosen packet
networks. They don’t want to lose revenue from leased lines, and
customers don’t want to replace their interfaces so techniques
have been developed to carry the leased line services over
packet networks. There are other implications of moving to a
packet network. TDM services are tied to a very stable reference
clock. This clock makes possible the use of relatively small
storage buffers in switches, allowing the voice service to have
very low levels of latency. A complete synchronization network then is
implemented to distribute this stable reference around the
carrier’s network. However, packet switches usually have
considerable amounts of buffer storage so a packet network does
not inherently need synchronization. When a service is provided via a pure packet
link, there is no connection to the carrier’s reference source.
This means the customer has to get synchronization from
somewhere else. This is where 1588 Version 2 comes into play,
explained Dave Tonks, a principle engineer at Semtech, an analog
and digital semiconductor company that has added the 1588-based
timing over packet synchronization (ToPSync) products to address
the needs of telecom companies. Taking a cellular wireless network as an
example, there are two key requirements:
The first requirement is satisfied by serving
the cell site with a small number of T1/E1 leased lines. In many
cases, the second requirement also can be met using the
traceability of the leased lines. Some cellular equipment, though, needs to tie
the transmissions to timeslots. These cell sites use GPS
receivers to provide this timing, although GPS is notoriously
easy to jam. Leased lines are something of a straightjacket;
they are expensive and very inflexible. With the growth in wireless data traffic,
cell sites need more leased lines, yet these take a long time to
procure, and their high cost impacts the profitability of the
wireless operator. A better way is to connect the cell sites
using a packet network. This offers inherent flexibility and can
be paid for on a packet-by-packet basis, matching cost to
demand. However, the use of a packet network divorces the cell
site from the carrier’s timing reference point and spoils the
stability and accuracy of the air frequencies. Telecom providers have been looking for a way
to deliver synchronization within the data packets themselves.
NTP doesn’t have the necessary accuracy. IEEE 1588 Version 2 now
allows systems to carry timing information from one end of a
packet network to the other end. In addition, it can provide the
UTC traceability needed by some cell sites. IEEE 1588 Version 2 meets other telecom needs
since it allows for shorter message formats and higher update
rates and defines the concept of a transparent clock, a means of
compensating for the message delay through network elements.
Further, a 1588 profile for telecom is being developed in ITU-T
SG15, Q13 which is responsible for timing and synchronization in
telecom networks, and this ITU-T recommendation may include
other material that is not part of the profile.
Lips Sync With Audio Today, you could transport digital content
over conventional Ethernet as long as the line is dedicated to
that purpose. As soon as you start transporting another
best-effort stream such as file transfer or Internet access, it
likely will significantly degrade the quality of the AV stream.
There must be some means to synchronize the packets so audio
matches the lip movements of actors or the sound coming out of a
pair of loudspeakers is in phase, especially in Wi-Fi speakers.
It’s also necessary with satellite receiver
streaming that the clock rates in the receivers be identical
because you can’t tell the satellite to change its speed. In
addition, manufacturers want to develop a plug-and-play scheme
that will ensure equipment from all vendors is compatible with
an absolute minimum of customer adjustments. In response to this requirement,
consumer-electronics manufacturers are working with IEEE on the
standardization of the required timing with IEEE 802.1AS. The
group also is focused on parallel standards, 802.1Qat, 802.1Qav,
and 802.1BA, to address other needs including streaming,
queuing, and profiling. IEEE 1588 allows profiles, that is,
collections of 1588 options and defaults, to be defined for
various applications, such as telecom and AVB. 802.1AS includes
the 1588 profile defined for AVB. It takes much of what it needs
from 1588 but not all of it. It then adds aspects not included
in 1588 such as support for 802.11 wireless networking. The 802.1AS jitter and wander specs are
defined by existing requirements in the Audio Engineering
Society (AES) AES3 digital audio standard for professional audio
equipment and the European Broadcasting Union (EBU) and
Sony/Philips digital interface format (S/PDIF). S/PDIF is a
specification for carrying digital audio signals that is part of
IEC 60958 and represents a minor modification of the original
AES/EBU standard for consumer use, requiring less expensive
hardware. These specifications for jitter and wander are quite
tight, in the range of 10 ns for jitter and long-term frequency
offsets of ±50 ppm for consumer interfaces and ±1 ppm for
professional interfaces for wander. Manufacturers indicate that the
synchronization of multiple speakers in different locations
should be less than ±500 ns for an acceptable consumer
experience. None of these values are close to the accuracy
afforded by 1588. There will be AVB-capable devices available
in the near future, starting with professional audio/video
systems and working down toward consumer electronics over time,
explained Geoff Garner, a consultant in AVB timing and
synchronization for Samsung Electronics and the editor of the
802.1AS standard. He added that the standard is stable but still
being worked on, and it is expected to go out for sponsor ballot
at the end of this year. All other industries are watching 802.1AS
with great interest. If the consumer industry adopts 1588 in
this way, it will make enormous investments to drive prices
down. IXXAT’s Mr. Seitz agrees that 802.1AS is an
area of tremendous interest. In addition to home electronics, he
mentioned possible uses in large systems such as concert stages
and stadiums where unsynchronized loudspeakers can lead to
barely intelligible speech or distorted music. In fact, his
company is working on a project for a large baseball park that
will run 1588 to synchronize the entire stadium, with a trial
planned for spring of this year.
The Military Reevaluates IRIG-B Further, added Meinberg’s Mr. Gerstung, these
test beds are a living infrastructure continually being changed
and expanded. With 1588, engineers find it much simpler and less
expensive than replacing all their dedicated connections. And if you’re going to invest in
infrastructure, he noted, why not add nanosecond accuracy?
Besides, companies such as Meinberg sell 1588 synchronization
units that can generate IRIG timing codes to allow the use of
legacy equipment. This will be a huge market for 1588 because
there are literally hundreds of millions of dollars of IRIG test
gear that can easily be upgraded. So far, we’ve mentioned some obvious
candidates for the use of 1588, but there are many others you
wouldn’t normally suspect. For instance, IXXAT has received
inquiries from financial institutions that want to detect when a
message has been received with greater than the millisecond
resolution of NTP. A large trader might receive a thousand or
more trading orders in a microsecond and must be able to resolve
the order of reception and make trades on that basis. If the
resolution of the messages with NTP is only 1 ms, all these
messages have the identical timestamp. "These companies have
told us that this capability can save them hundreds of millions
of dollars per day," said Mr. Seitz from IXXAT. Clearly, 1588 has started something big. It
will be fascinating to see which other industries find ways to
use this exciting technology. Acknowledgement
Reference
For More Information
View Past Archived Articles
Selecting Your Optimum LXI Feature Set
By Paul G. Schreier, Editor More than a year ago, a few suppliers of LXI
instruments were starting with LXI Class C to develop enhanced
instruments.1 Class C makes up the core LXI features
on which Class B and A instruments are built.2 Now
the LXI Consortium has formalized such expanded feature sets in
Version 1.3 of the specification, which recently was approved.
Integrating Additional Features to a Class C Instrument
Users don’t have to pay for features they
don’t necessarily need. This aspect will be especially important
for instruments at the lower end of the market such as portable
or other low-cost units that use microcontrollers with limited
resources to save cost or power consumption. Users also can
benefit from a broader selection of instrument products with
added features that can be brought to market sooner. Manufacturers can use such a partial
implementation of Class A or B as a steppingstone to a higher
class instrument without holding back on the instrument’s market
launch. Designing a Class C instrument isn’t as major an
undertaking as developing a Class B or Class A instrument,
especially now that so many instruments already have Ethernet
ports. However, and this is especially true for
companies new to the LXI market, it can take significant time to
develop a full Class A or B instrument and go through the
conformance testing. If a manufacturer can select only certain
features, it can get its products to market faster and at a
lower cost. For example, a user may find the LXI LAN messaging
feature of Class A and Class B is useful, but the addition of
IEEE 1588 and the triggering API is less useful and creates
trade-offs elsewhere. There is nothing in the current or past LXI
specifications that prohibits LXI Consortium members from
introducing these additional features. In fact, some Class C
instruments have included the wired trigger bus (WTB) from Class
A for some time. But because such an instrument doesn’t
include all Class A features, it’s not eligible for Class A
certification. And even though the LXI Consortium may have
tested the WTB implementation and declared it compliant to that
section of the specification, until now there has been no
official way to tell users about this fact. Such certification is important for users to
gain full confidence in the interoperability of a non-Class A
instrument’s WTB in an LXI system. Interoperability testing is
one of the strengths of LXI. It has been very effective. Among
the LXI-certified instruments on the market, there have been no
interoperability problems, which is a great asset to anyone
assembling a test system. With Version 1.3, vendors of Class C
instruments now can submit selected features from Class A/B for
testing: trigger bus, event messaging, clock synchronization
using IEEE 1588, timestamped data including clock
synchronization, and event logs including clock synchronization.
So how will users know that these extra features exist? There are no plans for a special label on the
front of the instrument, but these extra capabilities can be
indicated on the instrument’s welcome page on the Web. Then a
product description will include a phrase such as Class C plus
LXI Trigger Bus. Those capabilities also can be listed on the
LXI Consortium website in the master list of products and in the
company’s marketing materials and corresponding help files and
manuals. Only Certain Features Qualify
The exception would be if all of the features
of another class were added to the device. For example, if a
manufacturer were to implement and test all five of the Class A
features in a Class C instrument, the result would be a Class A
instrument. Most of the Version 1.3-added Class A/B
features are relatively self-explanatory. However, the
difference between timestamped data and event logs is worth
mentioning. With timestamped data, samples can be correlated
among many instruments so that you could, for example, see how a
change in a power supply was reflected in a UUT. An event log,
in contrast, records actions in an instrument such as trigger
received, alarm detected, measurements started, or error
occurred. Adding WTB
Rohde & Schwarz was the first to receive
conformance certification for adding the WTB to its FSL Spectrum
Analyzer (Figure 1). The box has a slot that accepts an
option card populated with an FPGA that implements the routing
of the trigger signals across the bus. According to Jochen Wolle, head of software
R&D, external triggering is traditional in instruments such as
spectrum analyzers, signal generators, and scopes. Customers
know how to use it. But because it defines a standard connector,
the WTB eliminates problems with incompatible cable connector
types. Further, with the WTB there’s no longer a need to go
behind the instrument and reconfigure the wires on each setup
because the lines on the WTB are software configurable. At the moment, the FSL is Rohde & Schwarz’s
only LXI instrument with the WTB. The LXI trigger bus can
connect to almost any other triggered instrument if users add
the Model 60-982 LXI Wired Trigger Bus Adapter from Pickering
Interfaces. This small external device measuring 30 x 84 x 100
mm converts low-voltage TTL (LVTTL) signals to the M-LVDS
signals on the eight-line WTB or vice versa, and it supports all
modes of WTB operation. Two versions are available: the thru-line
model provides two WTB connectors along with 16 SMB connectors
for the LVTTL inputs and outputs from other instruments, and the
other includes just one WTB bus connector and a WTB termination
along with the 16 SMBs. The unit can be configured manually or
with digital I/O. Another early adopter of the WTB as an extra
feature was C&H Technologies. When it introduced the EM-405-8
LXI Ethernet M-Module Carrier/LXI Bridge two years ago, that
company added the WTB to this Class C instrument and has
received conformance certification for the WTB functionality (Figure
2). The box, housed in a 19"
rack-mount 1U-high enclosure, provides Ethernet connectivity for
up to eight ANSI/VITA 12-1996 single-wide M-modules or a
combination of double- and triple-wide modules. An IVI driver
supports control of all bridge functions. The -0001 version
implements the eight LVDS triggers required for the LXI trigger
bus.
This capability was added because many C&H
customers are familiar with VXI and its high-speed backplane
triggers, explained Gary Guilbeaux, vice president and CTO.
Also, many of the firm’s products are M-modules with clocking
features. With this LXI bridge product, not only can eight
modules trigger among each other, but using a common clock they
also can trigger among multiple bridge boxes. To make the EM-405-8 a Class A instrument,
C&H still needs to add IEEE 1588 clock synchronization,
timestamping, event log, and event messaging, but Mr. Guilbeaux
noted that doing so is more difficult to implement than the WTB.
Besides, he added, until now there has been limited customer
demand for 1588, but it is starting to pick up. The company does
plan to add the features necessary to allow this instrument to
jump directly to a Class A. More recently, ZTEC Instruments has combined
Class C with WTB capabilities in several of its digital storage
scopes, which are packaged in half-width 1U chassis in the LXI
versions (Figure 3). All of them digitize with 8 bits of
resolution, offer either two or four channels, and spec
interleaved sampling at rates to 1 GHz (ZT 4211/12) or 4 GHz (ZT
4611/12). WTB enables users to configure multiple
instruments to trigger using either point-to-multipoint (driven
mode) or multipoint-to-multipoint (wired-OR mode). The beauty of
the WTB is that multiple LXI instruments can be daisy-chained
together to achieve very low timing uncertainty since there is
no software latency, according to Boyd Shaw, director of
marketing and product strategy at ZTEC. A very simple example would be where an LXI
oscilloscope triggers on a pattern of signals such as CH1 – H,
CH2 – H, and CH4 – L. Upon detecting this pattern of inputs, the
scope could use the WTB to trigger an LXI power supply to
decrease its output level and to trigger an LXI switch to change
its settings. LAN Messaging
In this lab supply, the voltage/current
limits automatically are recalculated, forming a constant-power of up to 1,200 W
hyperbolic-shaped boundary between the voltage and current
modes. This curve, which replaces the single max-power operating
point of conventional power supplies, provides the user with a
greatly expanded choice of maximum-power
V-A combinations. With LAN-based events and alarms, multiple
power supplies can intercommunicate without the need for a
central PC by multicasting messages to all LAN devices and
synchronizing the activities of multiple supplies within 100 µs.
The KLP can send LAN event messages that are alarms to other
devices. The alarms are triggered when a unit reaches its
current limit or has a fatal error such as missing sense
connections. Upon receipt of such an alarm, another KLP
can take one of three actions: change its status from Off to On
after a time period from 10 ms to 1 min, change its status from
Output On to Output Off after a similar time span, or shut down
the unit within 5 ms in Immediate Output Off. Accordingly, if
one supply determines that it has an overcurrent condition, it
can send an alarm message to shut down any other supplies in a
large test system and prevent the UUT from getting damaged—and
again, without any PC intervention. Attractive Feature Sets
Adding 1588 initially was a major task for
most companies. Suddenly, though, with the emergence of 1588
chipsets, the barrier now is lower, and it becomes interesting
to suppliers of low-end equipment. A lightweight
data-acquisition box or process-control system could benefit
greatly from such synchronization. However, a vendor might not
want to add all Class B functionality because of additional
development expense and increased end-product price. Certain combinations of feature sets will
likely prove very popular, added Mr. Owen. Market forces will
come to bear, and users will tell suppliers which combinations
they want. For instance, he sees that the combination of 1588
and event logging makes a lot of sense because it will be great
for debugging distributed systems. It will be very interesting
to follow developments along these lines and see what innovative
new instruments come on the market. References
View Past Archived Articles
The Killer Bs Are Coming
By Paul G. Schreier, Editor Undoubtedly, there are many compelling reasons for working with Class C LXI instruments. But the real excitement in the industry today comes with Class A and B instruments, particularly with the time-aware nature due to the implementation of the IEEE 1588 Precision Timing Protocol (PTP).
Roughly 95% of the LXI products currently on the market are Class C. Only a small number of Class A products are available, and just two Class B products, the Keithley Instruments Model 3706 Switch/DMM System and the Agilent Technologies E5818A Trigger Box, have begun shipping.
These time-aware instruments are opening up totally new test and measurement scenarios and application possibilities. When test engineers see these killer B products, they will wonder how they ever got along without this functionality.
Class A, B, and C Overview Time-Aware Instruments “Never has there been a test technology that automatically synchronizes time across instruments and distances to this level with theoretical synchronization levels of single-digit nanoseconds,” said Chuck Cimino, marketing director for multi-application products at Keithley Instruments.
Class B (as well as Class A) provides a mechanism for allowing multiple distributed instruments to have a fairly accurate notion of absolute time even if they don’t share a common clock source. The instruments are time aware: Each knows what the other is doing and when it is doing it and with high time resolution.
After a group of Class B instruments synchronizes themselves in time with PTP, they can timestamp local events and know that these records correspond very closely to timestamps on other instruments. Next, when one instrument detects an event, it can send a LAN message to other instruments within milliseconds or even hundreds of microseconds so they can act accordingly.
One instrument also can instruct others to perform an action at a future time. Instrument-to-instrument communications happen considerably faster and more accurately than is possible with a PC using software running under operating systems such as Windows.
Given the fact that the LXI spec is now four years old, it might seem it’s been a slow process in getting Class A and B products onto the market. Conrad Proft, technology product planner at Agilent, noted that Class C is purely a software change to any existing instrument that already has a LAN port. In fact, Agilent has an internal mandate for Class C compliance for all new products with a LAN port and already has updated some older products to Class C such as the 33220A and the N5700.
Mr. Proft feels that it is more likely that Class B with submicrosecond PTP accuracy will be introduced with new instruments rather than through upgrades, and LXI vendors are requesting and validating input from users on how precise and accurate the PTP timing must be for various applications. PTP accuracy below 1 µs requires hardware assistance to monitor PTP time packets while submillisecond accuracy can be performed in firmware.
Most data acquisition equipment might need only 1-ms time accuracy, and those products would likely be updated from Class C to Class B by using a software implementation. However, any existing instrument requiring submicrosecond accuracy will need a hardware modification, and it’s often not practical for suppliers to upgrade existing instruments.
Whether a software or hardware upgrade, in either case, it represents a significant R&D effort. However, once the Class B technique is established for a particular instrument platform, it tends to migrate to the other products using that same platform.
There’s another reason why many companies have been holding back on developing Class B products: There will be a major change to the LXI spec with regard to IEEE 1588 time synchronization. LXI Version 1.2 products based on 1588-2002 will not be backwards compatible with Version 1.3 products based on the latest 1588-2008. At the PlugFest scheduled for October in Munich, there likely will be the first trickle leading eventually to a flood of certified Class B products going to market.
Class B Applications Here all the instruments are running with a synchronized clock established over the net. Each instrument can operate its own scan/measure sequence at prescheduled times with full confidence that it is in sync with other instruments in the test system.
Consider an antenna test where a signal generator sends a signal through one antenna, and a spectrum analyzer on the receiving antenna is several hundred meters away
(Figure 1). Running trigger lines to coordinate the instruments would be a challenge, but LAN lines are no problem.
You even could implement longer distances with wireless LANs and directional antennas. Then, the instruments can pass LAN messages back and forth. The signal generator could tell the spectrum analyzer when to start taking data, and the spectrum analyzer would tell the signal generator that it has completed its measurement and is ready for the next frequency.
What happens when the antennas are sending signals via satellite whether the signal generator and the spectrum analyzer are next to each other or miles apart? You know there’s a delay of several hundred milliseconds before the signal reaches its destination. If both instruments start at exactly the same moment, you not only acquire unnecessary data before the signal actually arrives, but it also takes some postprocessing to find the data of interest.
Accordingly, a Class B-enabled signal generator could send a LAN message to the spectrum analyzer saying, “I’m going to send my test signal at t = T; you start collecting data at t = T + 300 ms.” Then, when the spectrum analyzer successfully collects and stores its data, it can send a LAN message to let the function generator know that it can move to the next frequency in the sweep and continue the test procedure.
Another application is the sequencing of instruments such as in a controlled power shutdown. In some cases, very expensive DUTs receive power from multiple supplies that must be applied and disengaged in a specific order or the DUT will be damaged or destroyed. If one Class B instrument receives a signal indicating a system error, it can issue LAN messages to other instruments controlling the power supplies so that each shuts down at a particular time.
Sequencing takes on another meaning when you work with two Class B data acquisition units and synchronize their
A/Ds to effectively double the sampling rate. You could align the sampling clocks and then shift one of them as needed to acquire interleaved data that you later reconstruct in software.
Besides allowing instruments to talk to each other quickly if something goes wrong, Class B timestamps can help engineers analyze what happened in a given test sequence, a tool extremely valuable for troubleshooting. Each instrument can have its own event log of triggers and other activities.
If a system malfunctions, an engineer can read time logs from various boxes into a single spreadsheet, sort the data by time, and see the sequence of events throughout the system at a glance. In addition, it doesn’t matter if events are microseconds, minutes, or hours apart; the resolution of the timestamp remains in the range of nanoseconds.
And if you do need the timestamps on distributed Class B instruments to correspond to real clock time, it is possible to synchronize them to a GPS receiver rather than to a local master Class B instrument. GPS then provides an absolute time reference that can be obtained globally, and many applications use it as a reference for testing and data stamping.
Introducing the First Bs
Fully loaded, the compact mainframe can support 576 two-wire mux channels. These feed into a DMM that features a single-channel reading rate that ranges from >10,000 DCV or two-wire Ohms readings/s at 3½-digit resolution to 60 readings/s at 7½-digit, 26-bit resolution.
Another feature is the embedded Test Script Processor. Users can write scripts with complete test routines including complex decision-making and control so the instrument can perform autonomously.
Meanwhile, anyone can use Agilent’s Class B E5818A Trigger Box to make their products Class B to preserve legacy investments
(Figure 3). It comes with a 5,000-entry event log with timestamp resolution of 20 ns.
To interface to traditional instruments, the E5818A provides two TTL trigger output signals and two digital timestamp input lines, and each channel can generate LAN messages intended for other LXI instruments. With this Trigger Box, you get most of the capabilities of a true Class B instrument, which can timestamp virtually any condition and respond to a LAN message to initiate some testing activity.
When 1588 Just Isn’t Enough While Class B instruments could start the clocks of all the units at the same time, that’s not sufficient according to Tom Sarfi, business development manager at VXI Technology. The 55-MHz sample clocks that drive the sigma-delta A/D converters also must be tightly correlated to single-digit nanoseconds throughout the acquisition run so there is virtually no skew, which is not feasible with the free-running clocks on distributed Class B instruments.
Instead, the application uses the Class A wired trigger bus so each EX1629 remote strain-gage measurement shares a master sample clock. In this way, a single clock edge can govern the sampling of all the distributed A/Ds with very minimal skew. To keep skew sufficiently low, the company uses equidistant cables to all the boxes.
To handle long distances, VXI Technology also employs the EX2116 LXI Trigger Bus Extender. The EX1629 accepts 48 channels and produces sampled data at rates to 25 kHz using a 24-bit A/D on each channel. Software-configured strain and voltage conditioning and excitation allow the connection of quarter, half, or full bridge or voltage inputs to any channel.
About the Author
For More Information on the E5818A Trigger Box View Past Archived Articles
The Need for Conformance Testing
By Jochen Wolle, Rohde & Schwarz, and Lynn Wheelwright, Wheelwright Enterprises LXI as a standard continues to support the latest technical developments in LAN products and techniques. This is particularly evident in the adoption of the newest, most convenient discovery mechanisms.
However, changing standards present challenges to companies developing LXI instruments. To help them in two ways—to give guidance on design issues and to officially certify that an instrument meets all the qualifications—the LXI Consortium regularly runs PlugFests where members of an independent testing laboratory examine new products to verify full compliance with the spec.
During PlugFests, the Compliance Working Group plays an advocacy role. Rather than being adversarial, the group makes every attempt to help LXI instrument manufacturers understand what is required and gives them tips on how to reach these goals.
For most of the PlugFests, the Conformance Working Group has seen many of the same problems repeated from product to product. The LXI spec includes a multitude of details, some of which are easy to overlook. Many of these are simply small oversights that can be corrected quickly. If a problem is identified early during a PlugFest and the fix is relatively quick and easy, which often is the case, a manufacturer still has time to get an instrument certified the following day.
Version History
In October 2007, the consortium adopted Version 1.2, and its major focus deals with discovery mechanisms. This means that when you plug an instrument into an LXI system, it automatically is recognized and registered as part of the test system so the user and other instruments can work with it.
Specifically, LXI 1.2 includes enhancements to support plug-and-play identification of LXI devices. This feature, in addition to the existing mandatory identification scheme based on VXI-11, is defined as a future rule and will become a requirement with Version 1.3 scheduled for release this month.
With the new multicast domain name system (mDNS) and DNS Service Directory (DNS-SD), the combination of both better known as the open-source protocol Bonjour from Apple, installation and automatic recognition of LXI devices are as easy as connecting a printer to a PC. The identification information for an LXI device is transferred via an XML file, which provides much more information than the VXI-11 protocol with the *IDN? query command.1
Currently, the LXI Consortium is working on other essential parts of Version 1.3. Key among them is the incorporation of the 2008 version of IEEE 1588 for synchronizing time among instruments. 1588-2008 was approved by the IEEE last March and is the successor of the 1588-2002 Precision Time Protocol (PTP) standard (see sidebar).
The IEEE 1588-2008 PTP
LXI Class A and Class B devices require the implementation of the IEEE 1588 Precision Time Protocol, which is used to synchronize real-time clocks in modules of a networked distributed system down to the nanosecond range.
The synchronization process consists of two phases: Since the introduction of PTP, interest in its capabilities has grown rapidly in many industries. A wide range of applications and different requirements in the areas of process control, telecommunications, power distribution, and test and measurement led to Version 1588-2008, which incorporates two synchronization protocols and additional extensions.
The interaction of the clocks on the network is characterized by 1588 profiles, with 1588 parameters optimized for specific applications. LXI defines such a profile to which all future LXI Class A and Class B devices must comply. Consequently, 1588-2008 is no longer backwards compatible to 1588-2002.
Looking Ahead
The next really big step will be Version 2.0 that, in addition to the mandatory XML-based discovery, will incorporate even more significant changes. These functionalities include the extension of LXI device Web pages to support instrument configuration and interactive testing of different LXI trigger capabilities such as LAN peer-to-peer messages, IEEE 1588 time events, or the wired trigger bus of LXI Class A devices. Logging of all the events in LXI devices will improve as will the ease of troubleshooting LXI-based test systems.
Resource Management is another major extension that enables management and allocation of LXI devices in a network with more than one controller accessing instruments. Yet another working group is dealing with the standardization of script downloads into LXI devices. Execution of custom scripts can be done without the system controller, simplifying the development of test software and increasing the throughput of test systems.
PlugFests and Certification
In closed sessions, future extensions to the LXI standard are discussed during face-to-face meetings in working groups. However, the public is invited to attend tutorials intended for both users and manufacturers interested in joining the LXI ranks.
One important function of a PlugFest is to help LXI instrument manufacturers deal with changes in the specification, test implementations, and certify new products as LXI conformant. An independent testing lab hired by the LXI Consortium to provide its services during the PlugFest is available without charge to all LXI Consortium members. The last LXI PlugFest was held in Toronto, and a major effort was testing various LXI Class B implementations to the 1588-2008 specification. In addition, the definitions of the LXI 1588 profile were verified and refined.
These PlugFest findings were important for the development of test cases for the certification of Class B devices. A first set of test cases has been defined and will be used by the LXI Conformance Working Group for the extension of the LXI Conformance Test Suite (CoTS), a tool for vendors to test the LXI implementation prior to actual conformance tests. The software, which covers all the required rules and sections of the LXI standard for Class C, B, and A devices, can be downloaded from the Members Area of the LXI Consortium website.
To date, more than 516 instruments from 14 vendors have been certified as LXI compliant. And in the course of conducting its work, the Conformance Working Group has been able to track which issues occur most frequently during testing
(Figure 1).
The Most Common Problem Areas
Topping the list are issues that arise because the IVI driver for a potential LXI-compliant instrument must be registered at the IVI Foundation website. These are the drivers that allow users to program instruments using a variety of application-development environments. Some vendors prefer not to register their drivers until they have verified instrument functionality at a PlugFest. In this case, the Conformance Working Group can grant preliminary acceptance of the instrument conditional upon the driver being registered at the website.
Another frequent problem deals with the validation of the Web pages that are part of an LXI instrument’s firmware. These Web pages must be in compliance with definitions from the World Wide Web Consortium (W3C). It often happens that manufacturers focus on the instrument and the LXI implementation and then make last-minute changes or additions to their websites that break compliance with W3C requirements.
Frames are another common concern. It’s not enough to inspect the content of a Web page; manufacturers sometimes forget to check the frame page itself. Such problems can be easily fixed because these Web pages are easy to test and repair.
Manufacturers can take advantage of the tools on the W3 website to check the compliance of their Web pages. The principle tool used for Web-page conformance can be accessed via an online markup validation service.
DNS hostname issues also are frequent. Routines in instrument firmware make it possible for the device to talk to a net server and have it assign a meaningful name, such as LXI_DMM_1, so it’s not necessary to work with IP addresses. The net server must, for instance, verify that a given name still is available and then assign it to the specific instrument. However, sometimes this mechanism doesn’t work for new LXI instruments, or the hostname isn’t properly displayed on the LXI instrument’s home page.
The LXI standard dictates that each instrument must have an LED that indicates LAN status and activity, and it also provides a state diagram of what the LED must display under certain conditions. For example, LED requirements might be slightly different depending on if DNS is performed or if a device is using Auto-IP or manual IP.
In addition, a user must be able to toggle the LED from the LXI instrument Web page to make it easy to identify a specific device sitting in a rack full of devices. In 11% of the cases, the LED functions do not adhere exactly to requirements in the LXI standard.
Another area that frequently needs fixing is a provision for a LAN Reset LAN Configuration Initialization (LCI). A user must be able to push a button to force the unit to return to its default status. In some instruments submitted for compliance testing, this functionality is either missing or doesn’t work properly.
Almost as many users have trouble with their IP configurations. The LXI standard recognizes two styles of IP configuration: an Auto/Manual selection, where Auto includes both DHCP and Auto-IP; and three separately enabled selections: DHCP, Auto-IP, and Manual. In the latter case, all three selections must have a check box or equivalent to be conformant. Sometimes, developers forget to include all of the required configuration fields that make for good citizenship in the LAN environment.
A few issues deal with labeling and, although seemingly mundane, are nonetheless important. More times than you might expect, the LXI version displayed on an instrument’s Web page does not actually correspond to the version of the LXI specification the instrument complies with.
Or, manufacturers forget to add the mandatory label on the LAN connection that indicates if it does not support automatic medium dependent interface crossover (MDIX) where the instrument can detect if the LAN cable is a standard cable or a crossover cable as needed for peer-to-peer communications. This gets tricky because 1-GB Ethernet in general needs MDIX support where 10-/100-MB Ethernet does not.
Similarly, the LXI specification requires that the LXI logo appear on an instrument’s front panel or display, and the instrument’s media access control (MAC) address must be clearly visible. These are details that sometimes are forgotten in the heat of a development project with a tight deadline.
PlugFest Coming in October
Reference
About the Authors
Jochen Wolle is the head of R&D for software, spectrum, and network analyzers at Rohde & Schwarz. He is a member of the LXI Board of Directors and chairman of the LXI Conformance Working Group. Rohde & Schwarz, P.O. Box 801469, D81671 Munich, Germany, e-mail:
Jochen.Wolle@rohde-schwarz.com
Lynn Wheelwright received a B.E.S. and an M.S.E.E. from
For More Information
on registering IVI drivers on checking Web page on tools for validating View Past Archived Articles
Tools for Developing
LXI Systems
By Paul G. Schreier, LXI ConneXion Editor With more LXI hardware coming to market and engineers taking a closer look at this technology, questions from developers and system integrators also involve software issues: What tools are available to help me program an LXI system, and how do they differ? For example, what debug facilities are at my disposal?
Several vendors—most notably Agilent Technologies, Data Translation, The MathWorks, and National Instruments—have adapted their application development environments to support LXI system development. Are there significant differences?
Well, today not every one supports all LXI instrument classes, not all accommodate both IVI-COM and IVI-C drivers, and some require that you purchase advanced versions or extra modules to gain LXI access. You aren’t limited to these tools if you, instead, program LXI instruments directly with SCPI commands.
When working with familiar development environments, programming an LXI instrument isn’t considerably different than programming other classes of instruments. In fact, it’s possible to create hybrid systems that combine LXI instruments with those using other bus or backplane schemes.
For MATLAB You can either download a preconfigured MATLAB instrument driver from the MATLAB Central File Exchange at mathworks.com/matlabcentral or create it using the command-line function makemid. To customize the new driver, open it in the MATLAB Instrument Driver Editor (midedit) where you can create, delete, modify, and rename properties, functions, or groups; add M-code around instrument commands for analysis; and create, connect, and disconnect code.
Once the MATLAB IVI instrument driver is created, you next create a device object using the icdevice command. icdevice is part of the Instrument Control Toolbox, an add-on module necessary to interface MATLAB to external instruments.
MATLAB works with every VISA implementation that The MathWorks can find. Several years ago when VISA didn’t have good discovery utilities, the company wrote its own utility that works within MATLAB for VXI-11.2. But with the new discovery mechanisms in LXI 1.2, there seems to be little need for the company to do a Bonjour version of its own discovery utility unless some bugs appear in the VISA implementations.
To get information from a discovery table into MATLAB, use instrhwinfo, a command that gets all the details VISA can provide including information about instruments on the network. This information is automatically loaded into the MATLAB environment, and you can gain access to it using other command-line functions.
The Instrument Control Toolbox provides a MATLAB-friendly way to communicate with instruments such as through IVI drivers. Within it, you can issue the tmtool command to bring up the Test & Measurement Tool to configure and control resources such as instruments, drivers, and interfaces without writing MATLAB script (Figure 1). This tool allows you to detect available hardware and drivers, connect to an instrument or device, configure instrument or device settings, read and write data, automatically generate MATLAB script, visualize acquired data, and export acquired data to the MATLAB environment.
Once you have become familiar with the instruments using that toolbox, you typically proceed to application development by writing a script in M-code. Since MATLAB is an interpreted language that also serves as a debug tool, at any time you can send a command to examine data going to the instruments and review their responses without the need to compile a program. You also have a command history and can edit that file to create a final script with the desired commands.
If desired, you then can compile it with a separate product to create an .EXE or a .DLL. However, according to Tom Gaudette, a development manager at The Mathworks, most users prefer to stay in the MATLAB environment for its interactivity and debugging capabilities.
If an IVI driver supports Class A and Class B as well as Class C operation, these capabilities are mapped into MATLAB. For instance, within MATLAB it is possible to send an LXI trigger by issuing a command over the TCP/IP link available in the Instrument Control Toolbox. You can work with low-level SCPI commands to set up triggers or use the IVI driver. Once the instrument is looking for the trigger, you can generate the trigger using straight TCP/IP commands, even outside the instrument driver if desired.
Some instruments that integrate PC capabilities now come with MATLAB connectivity preinstalled. This makes it possible to do scripting directly on the instrument and removes any issues with bus latency or network traffic. You don’t transfer a full waveform to a host PC but rather perform the filtering/analysis on the instrument itself and then send only high-level results to the host. As yet, LXI instruments with MATLAB preinstalled are not on the market.
For Measure Foundry In its present implementation, Measure Foundry supports only Class C instruments, but Data Translation is planning to add support for Class A and Class B instruments for a future release. Also, Measure Foundry works only with IVI-COM.
“The LXI standard says that software must support one or the other, said Tim Ludy, product marketing manager at Data Translation. But any new development in the last five years will have COM and C only for legacy applications.”
To ease programming, Measure Foundry presents all IVI commands as property pages to eliminate command-line programming. With the Instrument Socket component, you can access an instrument’s property pages and configure its initial properties, which you can change at runtime using other controlling objects.
A socket connection is required for each instrument being accessed. For instance, you drag a component onto the form, such as the Function Generator component, and then select the IVI device driver from the pull-down menu to associate this box with the socket connection.
For program debugging, Measure Foundry captures and displays every event among objects. You also can set filters to see what one component does in conjunction with another component. If you have NI or Agilent VISA installed, you can look at Measure Foundry’s IVI-COM object. Just open NI VISA, for instance, to see details such as the number of characters in a message.
On the application side, Measure Foundry offers the VISA Script Component, which has a VISA Assistant. With it you can send any command, even those outside the IVI structure for a particular instrument class, which makes it easy to access an instrument’s unique capabilities.
With Measure Foundry, the standard way to program LXI instruments using property pages and no coding is with the Professional Version, a requirement for installing either the Instrument Pak or Advanced Instrument Pak, both of which add objects to access the IVI-COM interface through property pages. The Instrument Pak supports four basic instrument classes: function generator, scope, DMM, and power supply. The Advanced Instrument Pak adds other types including RF generators, spectrum analyzers, power meters, and switches. However, if you don’t mind programming with SCPI calls in a script, you can work with the base version of Measure Foundry by using the VISA object.
For VEE Pro Also during installation, the software checks for the presence of other I/O software on the PC. If it finds another vendor’s VISA libraries, such as those from NI, it automatically installs them in a side-by-side mode that allows you to work with existing I/O software and the Agilent software together in a multivendor system.
The VISA Open Report module identifies conflicts between Agilent VISA and NI-VISA. Once it detects a conflict, VISA Open Report gives instructions on how to fix the problem. To support hybrid systems, the IO Library is compatible with any instruments connected over GPIB, USB, RS-232, and LAN.
With Agilent VEE Pro, the software can load drivers automatically for a specific instrument. VEE can find whether an IVI-COM driver is installed in the computer and then configure it. VEE does not support IVI-C drivers. No extra modules are required to support LXI; VEE only needs the modules provided by the IO Library that control any instrument interface or bus.
In VEE, you go to the Instrument Manager to create a simulated instrument and set its properties including a link to the corresponding IVI-COM driver. Next, you create an instance of that driver in your workspace.
Specifically, to automatically configure an IVI-COM driver for an instrument, start the Instrument Manager. In Auto Discovery, click Find Instruments. Select the instrument for which you want to configure drivers, then in Auto Discovery click Configure Drivers. You also can do this work manually.
In either case, to access the To/From IVI-COM object, bring up the Instrument Manager from the I/O menu. Select an instrument, then in Create I/O Object select IVI-COM Driver. In addition, you can use an IVI-COM driver with a class-compliant interface in much the same way.
Finally, you can use an IVI-COM session that is defined in the IVI Config Store and contains resource information about the instrument. You can do so with or without a class-compliant interface.
For advanced Class A and Class B capabilities, VEE can access two APIs that are part of Agilent’s IO libraries: the LXI Event Manager and an LXI Precision Time Protocol (PTP) Manager. The Event Manager allows you to programmatically send and listen for LXI event messages. The PTP Manager provides tools for controlling and monitoring the IEEE 1588 PTP clocks.
For debugging, you can use the Watch Window tool to view variables and data values on terminals. In addition, the IO Monitor tool integrated in VEE lets you monitor communications such as to view commands going to an LXI instrument and its responses.
For LabVIEW Although it can be done, LabVIEW Plug and Play drivers are not readily transportable to other programming environments. As for the availability of prewritten drivers, Alex McCarthy, senior product manager for VXI and instrument control, added that LabVIEW is the only development environment where the end users write most of the instrument drivers, and very often the one you need already is written.
“The strength of the NI user community has a major impact on the number and quality of our instrument drivers,” Mr. McCarthy said. “Compared to other vendors, we have many end users who help us refine our driver technology, help drive our own prolific instrument-driver development, and develop their own instrument drivers to donate to the community.”
When installing IVI drivers, all the components that support IVI-COM and IVI-C come as part of the LabVIEW installation. Instrument drivers are installed separately, regardless of type.
LabVIEW has an Instrument Driver Finder utility that assists you in locating drivers for the instruments. From within LabVIEW, you can go to IDNet and automatically pull down any drivers you want. In programming instruments, you have access to VIs for Class A and Class B instruments and all their functionality as well as Class C units.
For instrument discovery, NI supplies a utility with LabVIEW called Measurement and Automation eXplorer (MAX), a configuration utility that helps separate LXI hardware from LXI software. In MAX, you can discover devices on the network, open Web pages, perform instrument configuration over the Web, and set up aliases that later ease test-system programming
(Figure 2).
One strength of LabVIEW is its capability to work with multiple bus systems to facilitate building hybrid test systems. Not only does it support virtually every type of test hardware, but NI also sells the PCI-1588 and the PXI-6682 cards that synchronize 1588-based instruments.
Under LabVIEW, an LXI system can combine the functions of LXI Class B with non-LXI 1588 instruments as if they were all Class B. The PCI-1588 also allows for the synchronization of non-1588 devices such as traditional instruments. An RTSI bus interface synchronizes other PCI boards in the same PC; the PXI-6882 does the same for PXI systems.
In debugging phases, NI Spy included with LabVIEW is a useful utility. This tool monitors instrument I/O communications while an application runs, and it also can log commands sent over any instrument bus. Sometimes these commands are not immediately obvious, especially when using high-level IVI or Plug and Play drivers that provide function calls translated into instrument-specific commands.
But with NI Spy, which acts as a software bus analyzer, you can see the SCPI command sent to the instrument and the responses. NI Spy only works when using NI software, and you’ll see VISA calls only if you use NI-VISA.
LabVIEW now supports multicore processors. While LabVIEW users cannot dictate task partitioning, they can set task priorities. For instance, you could try to dedicate all LXI bus traffic to one processor and leave the other cores free to run the LabVIEW VIs for processing and display.
Finally, LabVIEW runs on Linux, making it the only high-level program development environment for LXI under that OS. NI-VISA also supports Linux, so you can run LabVIEW Plug and Play drivers or VISA calls directly from a LabVIEW block diagram.
TCP/IP functions are available for a low-level approach. You can make direct SCPI calls just like under Windows. And while the IVI Foundation has drivers only for Windows, you can run IVI-C drivers under Linux even though they’re no longer official IVI drivers in a technical sense. But, said Brian Powell, LabVIEW R&D, in general, well-written drivers won’t need to be modified, only in rare cases where compilers are picky.
Direct Programming With SCPI
An important aspect of SCPI and direct I/O programming under Linux is portability across the many variants. Commercial software tool vendors usually support the top two or three distributions but won’t guarantee support for the hundreds of Linux distributions available. Consequently, using open-source programming tools such as the GNU tool chain and direct I/O programming is the only way to achieve true portability.
Some engineers insist on using Linux and will go to great lengths to do so. They don’t care if there are no drivers. Development is more complex, but these engineers have complete control and a deep understanding of the system. Using open-source tools, they also get the rights to adapt and recompile their environment, and they are totally independent of revision changes that come about with Windows.
“This is especially important for areas such as aerospace and defense where applications can sometimes serve for 30 to 40 years and engineers are reluctant to use XP or Vista in such a system,” said Stefan Kopp, sales development expert for Agilent. Especially for support for specific I/O interfaces, the open-source paradigm is very powerful. “Chances are that someone in the world has already solved your problem. You then can get the source code and port it to your system,” he concluded.
A number of commercial VISAs are available for Linux, but they are distributed in binary format and typically supported on a limited number of popular distributions such as RedHat. In contrast, with direct I/O programming, you make API calls directly into the OS to run the Ethernet controller and LXI instruments. Especially for Ethernet, this is fairly easy to do. There is a different API for every I/O interface while VISA offers a common abstraction layer for all of its supported interfaces.
LXI instruments typically use VXI-11 based on RPC or TCP for remote control. Both protocols are available through standard OS calls.
By definition, LXI uses VXI-11 for instrument identification. You can perform a discovery by sending a broadcast and then querying the identification strings of the instruments found via VXI-11. From there on, you can use either VXI-11 or TCP to do regular instrument programming beyond the initial instrument identification.
Most Agilent instruments can do both VXI-11 and TCP communications, and direct TCP removes several layers of overhead. According to Agilent’s Mr. Kopp, there could be a significant performance increase depending on the application and average packet size, but the boost can be up to 100% or more. With VXI-11, each SCPI command is implemented through several back-and-forth TCP transactions. If you’re dealing with large waveforms, the overhead is less significant. But if you’re doing many individual transactions such as opening and closing relays, there will be a significant improvement moving to direct TCP communication.
Finally, for debugging, you use any plain-vanilla Ethernet analysis tools including Wireshark.
About the Author
For More Information on using Linux to control on papers describing IVI drivers View Past Archived Articles
Benefits of LXI
and Scripting
By Paul Franklin and Todd A. Hayes, Keithley Instruments 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 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 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 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 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) 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 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 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
Improved Performance 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 Example Scripts
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.
Figure 2. Script That Sets Up a Keithley 3706 Switch to Measure DC Volts on Channels
Developing Effective Scripts 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 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 Extended Enhanced 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 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
View Past Archived Articles
Programming Preliminaries
By Paul G. Schreier, LXI ConneXion Editor, and 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). Start With Drivers 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 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 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
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 About the Authors
FOR MORE INFORMATION
View Past Archived Articles
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 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 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 Let’s take a look at implementation details of each of these requirements.
LAN LED
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
Duplicate IP Detection
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.”
AutoIP Support
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:
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
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 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 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
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 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.
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.1
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.
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. Until this meeting, the only authorized testing lab was run by Wheelwright Enterprises.2 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.
Along these lines, manufacturers should note that obtaining certification is just one reason to attend a PlugFest. Another is to see how well a product in progress performs and get guidance on where to focus further engineering efforts. Or, when a product is almost complete, most of the compliance testing can take place at the PlugFest, and the remaining details then can be completed at the vendor’s facility.
In all, four companies submitted products for review: Data Translation, GOEPEL electronic, Agilent, and Rohde & Schwarz. Of these, Data Translation and GOEPEL presented their first LXI products.
At the conclusion of the PlugFest, the consortium announced that two products had been certified. However, the specifics were not disclosed, per consortium policy, because some companies might have a later official launch planned. We did learn that Data Translation was getting advice on the development of an LXI thermocouple box and that Rohde & Schwarz received conformance for its Model AMU 200A Arbitrary Waveform Generator. Next on the agenda was Bill Yonkers from Kepco, who addressed key points for developing LXI instruments. His presentation had a very interesting perspective because Kepco did all the development in-house for a series of Class C power supplies. He noted that the company had no previous experience with networks or HTML. Even so, the project took only 10 man-months; of that, only two man-months were spent on testing.
Mr. Yonkers shared a number of areas in which he had some difficulty or confusion and his experiences in IVI driver development, where testing was half of the effort. The first-time developer suggested several items that can speed up progress. He also recommended joining working groups to gather and swap information and getting a copy of the annotated specification with more details and rationales on several aspects of the standard.
As Mr. Yonkers said, “It’s not scary, it’s not very hard, and it’s straightforward. Just make sure your microprocessor has plenty of RAM so you can open all the necessary ports.”
Mr. Eidson related some information he learned while attending the recent IEEE 1588 meeting in Vienna. Among the most exciting bits of news was the announcement of new silicon from National Semiconductor that will make it much cheaper and easier for LXI instruments to incorporate Class B capabilities.
With Class B synchronization, one instrument can establish itself as the grandmaster, and all system measurements can be made in reference to this clock with an accuracy of just a few nanoseconds. To do so, the key is keeping the accuracy of timestamps associated with events.
Until now, the preferred approach was to design an FPGA that acted like a packet detector/sniffer to pull out timing packets early in the stack; you want to generate the timestamps as far down the stack as possible for peak accuracy. Then the scheme attached the timestamp to the data after it had worked its way through the communications stack.
But, Mr. Eidson added, the days of doing this implementation with an FPGA are gone thanks to the DP83640 from National Semiconductor. This is the industry’s first Ethernet transceiver with integrated hardware support for IEEE 1588. It incorporates all the external logic that previously was needed for accurate clock timestamping into a PHY layer chip. This PHYTER transceiver synchronizes the distributed network nodes to a master clock with 8-ns accuracy.
The chip integrates hardware timestamping of receive and transmit packets, a high-accuracy 1588 clock, and 12 general-purpose I/O pins that handle simultaneous real-time events or multiple triggers. The device interfaces with any controller, FPGA, or ASIC that has an Ethernet MAC.
The announcement of this device certainly caught everyone’s interest, and it could lead to a rapid proliferation of Class B products. As Mr. Eidson said, “Implementing 1588 is now the easy part, especially with these new chips. Deciding how to use these clocks is where careful design is needed.”
He pointed to three general uses of synchronized clocks among instruments in a system: to timestamp data, generate events or triggers, and produce signals such as periodic triggers that are synchronized with the clock. The next company to review some of its applications was the German company LXinstruments, which designs custom racks of equipment, much of it LXI but with some legacy equipment running on the GPIB bus. The company discussed automobile antenna tuning with RF stimulus-response, GSM wireless testing for remote heating-energy management, and automotive quality-assurance applications. While the LXI spec mandates the delivery of IVI drivers, this company does not use them and instead works with VISA and directly with SCPI commands.
At this point, the attendees went to the certification room for a demonstration by Rohde & Schwarz on how to coordinate the activities of the Class A hardware Wired Trigger Bus with those of Class B IEEE 1588 LAN triggering. The company developed a Web interface in which users can configure the triggers to interact. Consortium members were quite appreciative of this work and curious about how they can incorporate such features into their systems.
Pickering Interfaces then discussed a number of switching applications. Because PXI forms the largest part of their sales today, the speaker was able to discuss some clear areas of differentiation between LXI and PXI.
PXI has advantages, the Pickering representative added, such as support for a large variety of functions in a small package. Also, for simple functions, LXI has high overhead because of the need to include an embedded controller. He illustrated these concepts with applications the company has implemented in an RF matrix, switching video inputs to a bank of displays for soak testing, and testing cables in an airframe.
Xantrex then reviewed a programmable power-supply controller for spacecraft environmental testing. Much of this work has been described in a previous article in LXI ConneXion.3
The final applications presentation came from Agilent, one that focused on the use of LXI when running Linux. This is a particularly interesting issue because the IVI-C and IVI-COM drivers mandated by the LXI standard are designed for Windows and do not work under Linux. An alternative is to work directly with SCPI commands. Further, LXI instruments can be controlled either through the VXI-11 protocol based on RPC or direct TCP socket communications. This talk covered some of the issues involved in working with each of these.
Mr. Franklin concluded by saying that LXI is reaching a turning point. The consortium has been working hard on usability, ease of use, and interoperability. Now the members want to further their work in getting devices to recognize each other automatically and learn about each other—without user intervention.
LXI already is quite advanced, but by no means is it standing still. The consortium will continue to leverage the latest technological advances and work to make the process of setting up and programming a test system easier than it has ever been before. Meanwhile, you can get even more information about some of the key happenings at the PlugFest by watching a series of podcasts that were made there as well as examining the slides from public sessions.1
About the Author
By Nick Barendt, VXI Technologies
Since the initial version of the LXI specification was released in 2005, the Technical Committee of the LXI Consortium and its constituent working groups have been improving and refining the standard. Revison 1.2 (LXI 1.2) is their latest effort. It includes a number of upgrades in functionality and clarifications to improve interoperability.
• Discovery of the addresses of all instruments on the bus.
• Identification to obtain information such as manufacturer, model, serial number, and version for each instrument.
To perform these two tasks, the LXI Consortium chose VXI-11 for the 1.0 standard because it fulfilled the goal of leveraging existing technologies as much as possible. VXI-11 already was supported as part of VISA, and most VISA libraries provided at least rudimentary utilities for discovering VXI-11 instruments. LXI 1.0 used the SCPI command *IDN? through a VXI-11 connection to each instrument, and each one responded with a 4-tuple of information: manufacturer, model, serial number, and revision.
However, there are several shortcomings with VXI-11. So even before LXI 1.0 was ratified, the technical working group was discussing alternative protocols.
From an instrument-implementation perspective, the open network computing remote procedure call (ONC-RPC) protocol on which VXI-11 was built presented some difficulties for certain instrument platforms, particularly for applications constrained in resources such as CPU and memory.
From a user-perspective, there were three primary issues to overcome with a VXI-11 replacement:
• Locked devices generally are unidentifiable, effectively disappearing from the network.
• There is no straightforward mechanism to discover instruments attached to VXI-11 bridges for other instruments’ buses such as GPIB, VXI, or PXI.
• VXI-11 is relatively slow. Discovery can be fast, but identification by connecting to each instrument, issuing a *RST command, and querying and parsing results can be time-consuming, especially with a large collection of LAN instruments.
As replacements for VXI-11, the technical working group chose two different but complementary technologies: one for identification and one for discovery. Generally, additional information would be useful to users and applications, such as a list of connected instruments and description of the network configuration. In the end, the goals for a new identification mechanism were the following:
• Provide more information than in the *IDN? response.
• Support bridges and other devices that allow multiple instruments on a single IP address.
• Minimize instrument implementation and overhead.
• Support extensibility so vendors can add custom information.
The technical working group considered several solutions. The most promising was based on an analogous operation: How would a human gather the required information from an LXI instrument?
Given the IP address/hostname of an LXI instrument, one common way to determine the instrument’s identity is to open the instrument’s Web page in a browser. Any compliant device presents a table of information on the Welcome page as required by the LXI standard (Figure 1).
But while that Web page is easy for a human operator to read and interpret, it generally is difficult for a software application to locate salient data amid the HTML and Javascript. As a result, LXI 1.2 adds a requirement for a new Web interface that returns detailed identification information in an easy-to-parse eXtensible Markup Language (XML) document. (To view code please click here.)
Because XML is so extensible and flexible, the working group was concerned that vendors would develop identification documents with a variety of formats and contents, again making it difficult for users and applications to find the desired information. Clearly, a template or format of some form is required—a schema. This adds another requirement: It is insufficient for a document to be just well-formed XML. It also must conform to the schema to be valid.
After considering several XML schema languages, the technical working group chose the World Wide Web Consortium’s XML Schema language, which results in an XML Schema Definition (XSD). The LXI Consortium has published such a schema for LXI 1.2.1
Accessing an LXI instrument’s identification document is as easy as opening a Web page. To construct the URL given an IP address or hostname, simply concatenate the string http://<address> with /lxi/identification. For an instrument at 192.168.1.10, that document can be retrieved from http://192.168.1.10/lxi/identification.
As part of LXI 1.2, all URL paths beginning with /lxi are reserved for use by the LXI Consortium. /lxi/identification will likely be the first of several URL paths defined by the consortium for programmatic use as opposed to URLs that typically would be used directly by a Web browser.
The LXI Identification Document, as constrained by the XSD Schema, provides basic instrument information plus LXI-specific information such as LXI Class A, B, or C and LXI standard revision. The document also can offer additional hints to applications and utilities such as the IVI software module name or the page on the manufacturer’s website where the latest software drivers can be downloaded.
Device manufacturers are free to add their own proprietary data in a carefully demarcated section of the Identification Document, an XML element called Extension. For instance, a data-acquisition instrument could include information on the expiration date of the current calibration or information about the last calibration such as date and serial numbers of equipment used during the calibration.
To accommodate bridges and other devices that support multiple instruments at a single IP address such as a two-channel DMM, the Identification Document may optionally list ConnectedDevices. This section consists of a list of base URLs for the connected devices that the LXI instrument hosts on the network. Client applications can append the same lxi/identification URL path onto the end of the base URL and query that URL for the identification information for each ConnectedDevice. (To view code please click here.)
The identification documents for connected devices must conform to the LXI Identification Schema as well, but vendors are permitted to derive a new schema for connected devices. This allows vendors to extend the XML document and add information as needed.
For example, an LXI bridge device, such as the VXI Technology EX2500 Gigabit VXI Slot-0 Module, might use a derived schema specific to VXI bus devices and return identification documents conforming to the schema for each VXI module present. For VXI devices, the Schema and Identification Document would likely include a logical address and possibly the values of a few required A16 registers that client applications may find useful.
Ideally, the process of getting all the IP addresses should proceed quickly. Just as importantly, though, the discovery operation should not generate so much traffic on the network that it becomes a burden.
A number of technologies exist for discovery including UPnP, Bonjour, and an LXI proprietary scheme. The technical working group investigated several options before settling on multicast domain name service (mDNS) and DNS service discovery (DNS-SD).
The combination of mDNS and DNS-SD is alternatively known as Zero Configuration networking (Zeroconf)2,3, and Apple’s variation is called Bonjour. The LXI standard already requires support for another Zeroconf technology: Auto-IP, also known as Dynamic Configuration of IPv4 Link-Local Addresses, which is used by devices to choose a unique address in the 169.254.0.0/16 subnet on a LAN when no dynamic host configuration protocol (DHCP) server is found.
Zeroconf technology has been incorporated into a wide variety of network devices. For example, nearly all network printers now support mDNS/DNS-SD, making the task of discovering and configuring them almost trivial. Some operating systems, such as Apple’s OS X, have built-in support for these technologies while other OSs, such as Microsoft Windows XP and Vista, require some additional software.
On the instrument side, it is very straightforward to add support for mDNS and DNS-SD to most of the embedded operating systems commonly used on LXI products. In many cases, free and open-source options are available.
First, a query is performed against the centrally maintained name servers for google.com to determine which name server is responsible for the google.com domain. Then an additional query is made to look up the IP address of the www host within that domain. With this IP address in hand, the Web browser can open up a TCP/IP connection to www.google.com.
The DNS system works amazingly well, but for smaller or ad hoc networks like those often seen in test and measurement networks, the administrative overhead and complexity of configuring and managing a DNS server are hard to justify. This is where mDNS comes into play.4 It makes a few modifications to the traditional unicast DNS model.
As its name implies, mDNS takes advantage of multicast, a network transport that allows all interested network devices to receive and monitor particular types of messages on the LAN. Like broadcast, multicast traffic typically is limited to just a LAN and possibly just a portion of that LAN, depending on how the LAN infrastructure is configured. Broadcast messages are received by all LAN devices; multicast messages are received only by all devices participating in the multicast set.
mDNS essentially provides the same services as traditional unicast DNS. However, instead of querying a centralized database on the Internet, queries are directed to a multicast address and port number on the LAN, allowing any network device with pertinent information to respond.
In a similar manner to how network devices select nonconflicting addresses using Auto-IP, devices supporting mDNS choose a unique hostname in the .local domain—.local being equivalent to the google.com in the www.google.com example.
Unlike the Auto-IP case where any random IP address in 169.254.0.0/16 is as good as any other, you would prefer that a particular device reserve a hostname with some mnemonic value. So, a DMM that supports mDNS might choose a hostname such as dmm.local.
If two devices attempt to reserve the same hostname, the mDNS standards provide procedures for resolving the conflict, with each device acquiring a unique hostname. One DMM would likely get the desired dmm.local while the other DMM would get a numeral appended such as dmm-1.local.
What can you do with these mDNS hostnames? With OS support, the mDNS hostname can be used anywhere you might use an IP address or unicast DNS hostname. As a result, a Web browser could contact the DMM with a URL such as http://dmm.local.
When a Web browser attempts to access the http server at dmm.local, an mDNS lookup for dmm.local is performed. This multicast message to all mDNS servers on the network asks if anyone knows the IP address of dmm.local. The DMM itself, which contains an mDNS server, would send a reply like dmm.local’s IP address is 10.1.3.57, permitting the Web browser to open up a connection to the DMM’s Web browser.
Given the multicast nature of this communication, all mDNS servers on the network such as laptops, desktops, and other instruments see the query/response and can update their local caches with this information. When another device on the LAN needs to communicate with dmm.local, it likely already knows the IP address and can open the connection without performing a network query.
Such cache records have limited lifetimes, controlled via time-to-live (TTL) fields that keep the caches from filling up with stale data. Additionally, if no answer is received to the query, all mDNS servers observe that and remove dmm.local from their caches. While the support provided by DNS and mDNS for resolving a hostname to an IP address is useful, it does not really assist with telling network devices what services a particular host is offering. For instance, most networked printers support multiple network protocols for sending jobs to be printed as well as a Web server for configuring the printer and checking status.
For a service advertisement, DNS-SD uses a DNS record type known as a service (SRV) record. While SRV records can be used with traditional unicast DNS, they find wider use with mDNS.
SRV records allow a networked device to advertise services along with the hostname and port number where the service can be contacted. So a DMM that supports a Web browser might advertise an SRV record that contains a hostname of dmm.local and a port number of 80.
Just as importantly, though, the SRV record includes a service name. Much like the way hostnames are built on domain names, SRV service names are built on an analogous hierarchical domain.
A Web server running on a DMM might have a service name of ACME DMM._http._tcp, with the particular service name of ACME DMM in the _http._tcp service domain, because the Web server supports the http protocol over the TCP/IP transport layer protocol. The underscore characters before http and tcp in this example are required for SRV records and there to disambiguate service names from hostnames, which cannot contain underscores.
Unlike hostnames, which must be short and use a limited set of characters, service names can be long and can use any unicode transformation format (UTF-8) characters including spaces and punctuation. Service names typically are not typed in by users but rather selected from a drop-down menu or similar selection component, encouraging long and descriptive names to be used. Just as with .local hostnames, there are conflict resolution procedures to guarantee that each service name is unique.
LXI 1.2 requires two services to be advertised: http because all LXI devices contain a Web server and lxi, a new, LXI-specific service.
The new lxi element advertises LXI services on the LAN, beginning with the new identification document. This specialized Web service could likely have additional capabilities added in future versions of the LXI standard.
For now, though, it is sufficient to detect LXI Identification Services. A client application then might do an mDNS query for all _lxi._tcp services on the LAN for discovery and perform a normal http query to retrieve the identification document from each.
In many cases, an additional related record known as a text (TXT) also will be of use in discovery and identification. Each SRV record must have an associated TXT record that allows information about a service beyond just the port number to be advertised, encoding information in key/value pairs, formatted as key=value.
For the _lxi._tcp service, LXI 1.2 requires four key/value pairs of interest: Manufacturer, Model, SerialNumber, and FirmwareVersion. These correspond exactly to the response to the IEEE 488.2 *IDN? query. This allows you to retrieve a bare minimum of useful identification information during the discovery operation. The identification document can be queried for further details when needed.
With mDNS and DNS-SD, when a device is first connected to a network or is powered on, it sends messages advertising its services. Because all mDNS servers receive these messages including controller PCs running mDNS software, client applications always have an up-to-date list of services available on the LAN. The more traditional operation of clicking a discover button and waiting 10 seconds for all devices to respond before displaying a list of all devices is replaced with a continuously updated list of all active services.
While devices can send updated advertisements when being shut down to notify clients they are going away, it is unusual for instruments or most embedded devices to enjoy such orderly shutdown operations. Often, power is just unceremoniously removed.
How is a client informed that a device and its services are no longer available? For this, mDNS/DNS-SD offers a few mechanisms. First, all records include a TTL field that tells recipients how long the record should remain in their caches before it should be removed and forgotten. Services eventually disappear as their SRV and TXT records age and the device is no longer available to send out replacement records. Additionally, due to the multicast nature of mDNS, as soon as one client fails in an attempt to contact an advertised service, all mDNS servers observe that fact and remove the associated records from their caches.
The effort needed to add support for the new identification mechanism to an LXI instrument is small. LXI 1.2 still requires VXI-11 support, so all instruments, regardless of LXI version, can be discovered via VXI-11, but LXI 1.2 instruments also will respond to the new identification mechanism.
Because the new LXI 1.2 identification mechanism is innocuous, it can be safely performed on pre-LXI 1.2 instruments. Accordingly, software utilities can perform a VXI-11 discovery operation and then attempt to use the LXI 1.2 identification mechanism on all discovered instruments. LXI 1.2 instruments will properly respond, and pre-LXI 1.2 instruments will return an error, after which the software utility can fall back to using the VXI-11 identification mechanism on them.
LXI 1.2 includes mDNS and DNS-SD as future rules and recommendations. A later version of the LXI standard will require instruments to follow the rules regarding mDNS and DNS-SD support, but that requirement does not apply to instruments tested against 1.2 for conformance.
Vendors are encouraged, however, to treat the future rules as recommendations for LXI 1.2 devices. This use of future rules is intended to minimize the short-term impact of adding requirements on new instruments but make the LXI Consortium’s technical direction clear.
When the next version of the LXI standard is released, future will be dropped, making those rules required on all compliant instruments although many LXI 1.2 instruments are expected to offer support for those rules. This includes the mDNS and DNS-SD. Software utilities can begin to use both the new discovery and identification mechanisms. 2. Steinberg, D. and Cheshire, S., Zero Configuration Networking: The Definitive Guide, O’Reilly Media, 2006.
3. Zeroconf, www.zeroconf.org/
4. Multicast DNS, www.multicastdns.org
5. DNS Service Discovery, www.dns-sd.org/
By Tim Ludy, Data Translation
Because LXI physical connections are so simple, creating an instrument setup and programming it are easy and quick. To illustrate the point, this step-by-step example describes how to configure multiple instruments on a private LAN using a commercial PC and a router. The recommended router utilizes the dynamic host configuration protocol (DHCP), which automatically assigns an IP address for an instrument. Most new routers come with this DHCP server capability.
This example uses two instruments from Agilent Technologies: a Model 33220A Function Generator and a Model MSO6014A Oscilloscope. Beginning with a running PC and router equipped with DHCP, follow these steps to configure each LXI instrument: Now design the desired application, which consists of this simple task: Configure the LXI function generator to output a 1,000-Hz sine wave. Make a physical connection between the function generator’s output and the input of the LXI oscilloscope. Then configure the function generator to create the signal and set up the scope to acquire and send it to the PC for display and analysis.
As written, the sine wave output program for the function generator and the scope-input program accept GPIB and USB addresses but not a LAN address. For that reason, the first thing to do is change the programs so they also accept an IP address. Do so by adding an I/O type and a corresponding text box (Figure 1).
The following code snippets show how to modify the program to access a LAN address.
Original Code ' Open the I/O session with the driver Modified Code
' Open the I/O session with the driver
This example now instructs the function generator to output an arbitrary waveform.
When the program finishes running, a new dialog box appears (Figure 2). At this time, the signal is being displayed on the oscilloscope.
The next step is to modify the second example program to address the scope, capture the signal over the hardwired connection between the two instruments, and read it in on the PC. Then, tie the two examples together to create the finished application. On the property page, enter the instrument’s IP address. Or, if you set up an alias name for it, choose the alias from the list to make connection to the device. Click Connect and then click OK to open a connection to the instrument.
A socket connection is required for each device being accessed. Next double-click the Function Generator component you dragged to the form to open its property page. If the device driver has been installed, select it from the available drivers in the pull-down menu (Figure 4). This associates the Function Generator component with the socket connection. The socket and device objects combine to provide the easiest access to standard LXI instruments.
You also want to access the scope, so drag and drop another Instrument Socket component and an IVI Oscilloscope component onto the form. Configure the second Instrument Socket to connect to the scope. Double-click the IVI Oscilloscope component to open its property pages, and then click Next to access additional properties.
The oscilloscope driver publishes many measurements that can be very useful to include in an application. In this case, select the Waveform and Frequency channels for the component to publish as data channels to the rest of the application (Figure 5).
In the application, you also want to start/stop the function generator’s waveform output and display the waveform from the hardware oscilloscope. For these purposes, add a Control Button and an Oscilloscope display component from the Foundry as shown in Figure 6.
To make the application even more useful, next add control components for the waveform type and frequency setting as well as a display component that reads the frequency measurement from the oscilloscope (Figure 7).
The Windows application controls the amplitude and signal type that is output from the function generator. It also captures the signal back from the oscilloscope and displays both the waveform and the frequency-measurement data.
Utilizing the standards that exist today and eliminating the complex nature of traditional programming, this new breed of test-and-measurement development tools allows the engineer to build complete applications faster and make them easier to maintain. Test engineers now can focus on what needs to be tested and what results they require rather than how to do it.
References
What, exactly, are these advantages? IEEE
1588 allows any number of devices connected with low-cost
commercial Ethernet cable, hubs, and switches to synchronize
their operations within roughly 500 µs using software alone.
Devices equipped with hardware-assisted PTP clocks increase
accuracy to the nanosecond range. A number of companies now are
selling microcontrollers and Ethernet controllers with the
hardware assist, making it easy to incorporate this
functionality into slave devices.
Figure 1. Synchronization of IEEE 1588 Slave Clock Time to Master Clock Time
Courtesy of Agilent Technologies
Figure 2. Comparison of Hardware-Assisted IEEE 1588 PTP With the Other Most Popular Precision Timing Schemes
Courtesy of Symmetricom
As you’ve read previously in this magazine,
test engineers are starting to take advantage of these benefits.
Some of the most common applications for 1588 so far involve
distances where dedicated triggering buses won’t reach. With
1588, for instance, it’s possible to synchronize the acquisition
of data from widely distributed sensors or perform a
stimulus/response test where the two pieces of equipment are
many meters or perhaps even a kilometer or more apart.
Many other industries are embracing 1588 with
great enthusiasm. One of them is telecom which is the most
active for new developments, according to John Eidson of the
Agilent Technologies Measurement Research Lab and chairman of
the 1588 standards committee. Representatives from the industry,
he added, make up at least 30% of the 1588 committee that
produced IEEE 1588-2008. And with the added features in that
recent update, the doors are open for telecom and other new
applications.
• Cell sites must reliably distribute their
traffic to customers, whether on other cell sites or on a
landline.
• On-air frequencies used by the cell site
must be stable and reliably held within a tight frequency margin
to aid hand-off and avoid interference with neighboring
channels.
It’s nothing new that all sorts of digital
media are streaming into our homes today, primarily into our
computers or digital settop boxes. Consumer electronics
manufacturers, however, have the dream that we will be able to
route high-quality audio and video throughout our homes with a
guaranteed quality of service using inexpensive Ethernet links,
routers, and switches. Originally dubbed residential Ethernet,
the concept now is referred to as audio/video bridging (AVB).
These techniques also will be applied to professional audio and
in-car AV systems.
IEEE 1588 offers an excellent alternative to
IRIG-B, which is used heavily in military test installations.
Engineers are looking for ways to get rid of the dedicated coax
or fiber-optic cables needed for timing in their sensor beds,
especially projects such as large-scale weapons tests across
large distances or airborne tests. Eliminating the weight of
extra cables will be especially attractive in things that move
like ships, subs, and planes.
A special acknowledgement goes to John Eidson
for providing considerable information and contacts that were
invaluable in preparing this story.
Eidson, J. C., Measurement, Control, and
Communication Using IEEE 1588, 2006.About the Author
Paul G. Schreier 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 written
articles for countless technical magazines. Currently, he is the
editor for LXI ConneXion at EE-Evaluation Engineering. 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
on 1588 PTP and
timing networks white papers
www.rsleads.com/904ee-176
Why is it desirable to add features to a
Class C LXI instrument in this way? Here’s the situation:
Suppose a supplier of a Class C instrument believes that its
customers would benefit greatly from more but not all features
that fall under the other classes. The capability to add
selected functions is a boon to both manufacturers and users.
One aspect the LXI Consortium must deal with
in establishing added features to Class C instruments is
conformance testing, which ensures that these features meet all
the requirements in the spec. It is important to note that the
unit remains a Class C device.
A handful of vendors added extra features to
Class C instruments even before Version 1.3 allowed them to be
promoted as LXI approved. At the moment, these instruments fall
into two categories: those that have added the LXI trigger bus
and those that have added LXI event messaging.
Figure 1. Rohde & Schwarz FSL Spectrum Analyzer With Class C and LXI Trigger Bus
Figure 2. C&H Technologies EM-405-8 LXI Bridge With Class C and LXI Trigger Bus 
Figure 3. ZTEC Instruments ZT 42XX Series Oscilloscope With Class C and LXI Trigger Bus
LAN messaging was a requirement that Kepco
found among its users, so that feature was built into the Class
C Model KLP-600-4-1.2K Hyperbolic Power Supply from the start (Figure
4). Now with Version 1.3, the only thing holding the company
back from getting conformance certification as a Class C and LXI
Event Messaging product is an LXIivisync interface, which the
company expects to have shortly. 
Figure 4. Kepco KLP-600-4-1.2K Power Supply With
Class C and LXI Event Messaging
Beyond WTB and LAN messaging, other features
such as adding 1588 clock synchronization from Class B will
likely turn out to be a big driver in sales. So believes David
Owen of Pickering Interfaces, who also is chairman of the LXI
Technical Committee. With 1588, users gain the ability to
synchronize events and record what has happened across a
distributed test system.
1. Schreier, P. G., "Climbing the LXI
Learning Curve," LXI ConneXion, September 2007, page 25.
2. Schreier, P. G., "The Killer Bs Are
Coming," LXI ConneXion, September 2008, page 50.
3. LXI Consortium,
www.lxistandard.org
About the Author
Paul G. Schreier 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 written
articles for countless technical magazines. Currently, he is the
editor for LXI ConneXion at EE-Evaluation Engineering. 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
Here’s a CliffsNotes™ summary of the LXI instrument classes. Class C is the baseline with LAN capabilities, a Web interface, and IVI drivers. To that, Class B adds expanded triggering, such as multicast and peer-to-peer communications between instruments and time-based trigger events. The time-based triggering is made possible by implementing the PTP, which can distribute a precision timing source across many Class A and B devices over a LAN. Class A devices build upon Class B devices by adding a wired trigger bus for precision triggering.
Remember action movies where a group of commandos gathers to synchronize their watches so each knows exactly when another makes a particular move even if miles away? That’s the basic principle behind 1588.
There are a number of applications where Class B instruments shine. An obvious case is when you need to synchronize triggers or measurements across long distances. This could be on a physically large item like a bridge or a large test chamber or when test instruments need to be hundreds of feet, miles, or even continents apart.
Figure 1. Class B Instruments Using LAN Messaging to Coordinate the Measurement of Satellite Signals
The first true Class B instrument is from Keithley Instruments with the Model 3706, a six-slot system switch with an integrated 7½-digit DMM
(Figure 2). The slots accommodate a variety of mux cards designed for different speeds, currents, and voltages.
Figure 2. The Model 3706 Switch/DMM From Keithley Instruments
Figure 3. The E5818A Trigger Box From Agilent Technologies
In some applications, even the synchronization capabilities that Class B delivers aren’t precise enough, and the Class A wired trigger bus is needed for the ultimate in phase alignment. That was the experience of VXI Technology when a major commercial aircraft company wanted to measure stresses on the wings of its most recent aircraft design. More than 10,000 channels were distributed over the structure, and it was very important that minimal skew occurred in the arming/initialization/triggering process. Otherwise, it would be difficult to correlate data and achieve dependable results.
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
on the Model 3706 System Switch
www.rsleads.com/816ee-188
www.rsleads.com/816ee-189
Before looking at specific problems, let’s consider the evolution of the specification. In September 2005, the LXI Consortium released Version 1.0 of the LXI standard. Just one year later, Version 1.1 followed with minor corrections and clarifications.
• First, offset correction is performed. It defines the time difference between master and slave clocks. For that purpose, the master periodically sends a synchronization (Sync) message to all slaves. In parallel, the time at which the message is sent by the master is measured as precisely as possible and preferably with hardware support. The master then sends a second FollowUp message with the exact transmission time of the corresponding Sync message to the slaves. The slaves measure the receive time of these messages, allowing them to calculate the correction value (offset) to the master. The slave clock then corrects the offset to the master clock. If the transmission were to have no delay, then both clocks would be synchronized.
• The second phase of synchronization determines the delay of messages between slave and master. This is done through Request Delay and Delay Response messages in a similar way, and the slave clocks are adjusted accordingly.
Starting with Version 1.3 of the LXI standard, the LXI Consortium will adopt the new 1588 version as quickly as possible so systems using LXI Class A and Class B devices will synchronize with each other based on the 1588-2008 PTP. We expect to see a significant number of new LXI devices conforming to LXI Classes A and B shortly after the release of Version 1.3.
The members of the LXI Consortium meet roughly three times a year at PlugFests held around the world. Previous meetings have taken place in California, China, Munich, and Canada, and the next is scheduled for Munich in October.
Figure 1. Common LXI Conformance Mistakes
Source: Wheelwright Enterprises
Interestingly, the leading areas of potential pitfalls have nothing to do with the instrument’s technical capabilities but rather are administrative in nature. In addition, as manufacturers become more familiar with the spec and bring their next instruments in for testing, the number of problems has been dropping significantly.
Following the PlugFest planned for the end of October in Munich, there should be a large number of LXI introductions. And companies that want to get LXI products certified—or simply advice on how to more easily design an LXI instrument—should be sure to attend this or a subsequent PlugFest.
1. Barendt, N., “LXI 1.2 Improves Discovery and Identification,”
LXI ConneXion, February 2008, pp. 12-16.
Brigham Young University and then joined Hewlett-Packard and Agilent Technologies where he worked for 35 years. His honors include five patents relating to instrumentation and measurement techniques. Mr. Wheelwright also has participated in many standards groups and committees including the LXI Consortium and the IVI Foundation Spectrum Analyzer Working Group. He now runs his own consulting company. Wheelwright Enterprises, 3751 Porter Creek Rd., Santa Rosa, CA 95404, e-mail:
lynnw@sonic.net
on PlugFests
www.rsleads.com/816ee-184
www.rsleads.com/816ee-185
LXI compliance
www.rsleads.com/816ee-186
Web-page conformance
www.rsleads.com/816ee-187
In MATLAB, you can work with graphical tools, but most development is done from the command line. With many programming environments, you work directly with vendor-supplied IVI drivers, but to run them in MATLAB, you must first create a MATLAB IVI driver that acts as a wrapper for the IVI-COM or IVI-C driver which must remain installed on the system.
Figure 1. Test & Measurement Tool in MATLAB
Courtesy of The Mathworks
Now move on to some familiar codeless development environments, starting with Measure Foundry. This software has no built-in discovery mechanism, but when working with commonly available tools, you set up an alias, which then appears automatically in Measure Foundry. Alternatively, you can use an IP address directly so discovery is not mandatory.
A key to working with Agilent VEE is to first install the Agilent IO Library Suite. During installation, the software dynamically identifies smart defaults based on hardware and previously installed software. After installation, the software automatically discovers instruments connected to the PC, then configures and verifies the interfaces independent of the hardware or software application being used.
LabVIEW supports the full range of LXI drivers and others: IVI-COM, IVI-C, LabVIEW Plug and Play, VXIplug&play, C DLLs, and direct I/O so you can write to Ethernet devices with direct SCPI commands. NI’s philosophy is that the best instrument drivers for an environment are designed specifically for that environment, in this case LabVIEW Plug and Play drivers with source code and calls to SCPI. When using LabVIEW to write a driver, you can peel away software layers, see the SCPI calls into VISA, and use it as is or modify a driver, such as to remove extraneous calls to improve efficiency.
Figure 2. LabVIEW Program for LXI Control (bottom)
and the Associated User Interface (top)
Courtesy of National Instruments
The capability to run under Linux is increasingly important. A survey by Agilent roughly a year ago revealed that about 50% of their customers, including those using Windows, are not using instrument drivers and instead program their instruments directly with SCPI commands. They appreciate the higher degree of control and flexibility offered by direct SCPI programming. Also, many instrument vendors haven’t developed IVI drivers for Linux, which the IVI Consortium defines only under Windows
(Figure 3).
Figure 3. Programming an LXI Instrument Within Linux Using SCPI Commands
Courtesy of Agilent Technologies
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
on the IVI-based
Hello-Instrument Program
www.rsleads.com/815-176
LXI Instruments
www.rsleads.com/815-177
and how to work with them
www.rsleads.com/815-178
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.
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.
The examples illustrate that the scripting instrument can behave very much like the conventional instrument. Only the command syntax has changed slightly.
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)
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
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.
Script-based instruments provide several benefits. Many of these are enhanced when the instrument also conforms to the LXI specification.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Brian H. Powell, National Instruments
All LXI instruments are programmable somehow. But it’s not always clear what options you have and how to choose among them.
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.
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 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
1. Barendt, N., “LXI 1.2 Improves Discovery and Identification,” LXI ConneXion, February 2008, pp. 12-16.
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
on IVI Shared Components
www.rsleads.com/814ee-176
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.
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
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.
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.
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 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.
Table 1. Packet Structure for Address Resolution Protocol
Source: Wikipedia
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.
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);
}
}
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.
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.
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.
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.
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.
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.
PlugFest Host Jochen Wolle, Rohde & Schwarz, and LXI Consortium President
Bob Rennard, Agilent Technologies
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.
The LXI Compliance Testing Bench at the PlugFest
Tutorial Sessions
The PlugFest schedule included a series of very interesting tutorials. John Ryland of Keithley Instruments, head of the LAN and Web Working Group, started off with a review of some issues experienced during compliance testing and how to use various software tools to ease the job. He also explained the rationale behind some of the minor changes to the spec. He then reviewed the things that most instrument developers struggle with when developing LXI instruments and presented a list of pitfalls to watch for when performing LAN and Web testing.
Precision Time Protocol
The presentation on IEEE 1588 Precision Time Protocol (PTP), the scheme used for precise timing over the Internet that forms the basis of Class B LXI instruments, was made by John Eidson of Agilent. The LXI Consortium is very lucky to have such a qualified individual advise them on this topic. Not only is he considered the father of the 1588 scheme, but he also is the chair of the IEEE 1588 standards committee as well as the LXI Timing and Synchronization Working Group.
Application Examples
The final PlugFest day focused on applications. VXI Technology showed examples for pavement testing with more than a thousand channels distributed among a test track, spoke about NASA Rotorcraft testing, and reviewed its large-scale structural test using a distributed backplane from Boeing that has 10,000 channels at 200 Hz and another 2,000 channels at 5 kHz. The speaker also discussed how LXI could revolutionize calibration where it is possible to embed calibration routines in an instrument itself.
Screenshot From the Wheelwright LXI Compliance Testing Suite
Looking Ahead to Version 2.0
Keithley’s Paul Franklin, chair of the LXI Technical Committee, reviewed future directions for the consortium based on discussions the working groups had during the PlugFest. The target date for Revision 2.0 is late 2008. It will address major aspects such as resource management, how to incorporate IEEE 1588-2008, Web support for triggering, and improved event-logging capabilities.
References
1. LXI Consortium, www.LXIstandard.org
2. Wheelwright Enterprises, www.wheelwrightenterprises.com
3. Dewey, M. and Allen, P., “LXI Simplifies Satellite Environmental Testing,” LXI ConneXion, January 2007, pp. 12-17.
Paul G. Schreier 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. He 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
LXI 1.2 Improves Discovery and Identification
Discovery and Identification
The most interesting and involved changes in LXI 1.2 deal with improving the user experience, especially for initial device setup. Two fundamental operations on any instrument bus are the following:
Identification Document
The identification task is this: Given an instrument’s IP address/hostname, identify its manufacturer and model number. At a minimum, the result of an indentification operation should be equivalent to the 4-tuple result from the *IDN? query.
Figure 1. LXI Welcome Page
mDNS and DNS-SD Discovery
With an LXI instrument’s IP address or hostname, it is very straightforward to access its identification document. But getting the list of IP addresses for all LXI devices on the LAN is the topic of discovery.
DNS and mDNS
The first piece of the new discovery technology is a peer-to-peer name service. Traditionally, DNS is used to convert hostnames to IP addresses. It is important to understand that the Internet works only with IP addresses. Hostnames such as www.google.com are never used directly but first converted to IP addresses by looking up the hostname in a specialized database of hierarchical name servers running on the Internet.
Service Discovery
The second component of discovery is DNS-SD.5 Note the subtle distinction that DNS-SD is for service discovery and not device discovery. When we refer to service in this context, we mean a piece of software that clients can interact with over TCP or user datagram protocol (UDP) by communicating via a predefined protocol.
Phased Introduction Plan
A phased introduction plan for improved identification and discovery was driven by a desire to begin addressing various identification problems as soon as possible but without placing an undo burden on implementers. The new identification mechanism is required in all LXI 1.2 instruments.
Conclusion
The new identification and discovery technologies introduced in LXI 1.2 focus on improving LXI instrument usability, particularly the out-of-the-box experience. The goal was to make initial setup and connectivity to an LXI instrument as easy as the effortless plug-and-play experience of using a network printer on an Apple computer.
References
1. LXI 1.2. Schema, LXI Consortium, www.lxistandard.org/InstrumentIdentification/1.0
About the Author
Nick Barendt is a software engineer for VXI Technology, specializing in embedded, real-time, and distributed test and measurement systems. He also is a co-chair of the LXI Consortium’s LAN/Web Technical Working Group. Mr. Barendt holds B.S.E.E. and M.S.E.E. degrees. VXI Technology Cleveland Instruments Division, 5425 Warner Rd., Suite #13, Valley View, OH 44125, e-mail: nbarendt@vxitech.com
LXI System Setup Is Quick and Easy
1. Connect the instrument to the router using a standard Ethernet cable.>
2. Power on the instrument.
3. Reset the instrument to the default LAN configuration using the instrument’s LAN reset.
4. Discover the instrument’s IP address using an LXI discovery tool. This example uses a discovery utility written by Xantrex that is available as a free download from the company and the LXI Consortium website.1
5. Open a standard Web browser and enter the IP address for one of the instruments taken from the discovery utility to access its Web page.
6. Perform a LAN identify within the Web browser that causes the instrument to identify itself as a device being accessed. Not only is this helpful when using multiple devices in a rack, but it also is an LXI requirement.
Working With Drivers
Now that the instruments are configured and communicating over the network, the next step is to create an application using the software of choice. IVI drivers ship with all LXI-compliant instruments, and they simplify instrument programming by wrapping up functions in a common programming interface. The IVI shared component library is required to communicate with the instrument drivers and can be found on the IVI Foundation website.2 Install the IVI-COM instrument drivers for the function generator and oscilloscope.
Visual Basic Example
One way to do this is to write a Visual Basic application that provides the desired functionality. You can get the required code by downloading example programs from the Agilent website and modifying them to communicate over the LAN. For this example, we will download FGen and Scope.
Figure 1. Modified Visual Basic Code Adding Access for a LAN Address
' Get the instrument address from the text box
If GPIBType.Checked Then
addr = UCase$(gpibaddr.Text) + "::INSTR"
Else
addr = "usb0::2391::1031::" + usbaddr.Text + "::INSTR"
End If
Fg.Initialize(addr, True, False, "")
' Get the instrument address from the text box
If GPIBType.Checked Then
addr = UCase$(gpibaddr.Text) + "::INSTR"
End If
If usbtype.checked Then
addr = "usb0::2391::1031::" + usbaddr.Text + "::INSTR"
End If
If LANtype.Checked Then
addr = "TCPIP::" + LANaddr.Text + "::INSTR"
End If
Fg.Initialize(addr, True, False, "")
Figure 2. Running Visual Basic Application That Outputs a Signal on the
Function Generator
The Drag-and-Drop Method
A second application-building option using Measure Foundry demonstrates the same concept with another type of program-development environment. When you open Measure Foundry, a form appears on the screen. To start, drag and drop an Instrument Socket component and a Function Generator component onto the form. Double-click the Instrument Socket component to access its property pages and configure its initial properties, which you later can change during run time using other controlling objects just as in programming languages such as Visual Basic and C (Figure 3).3
Figure 3. Instrument Socket Component Property Page
Figure 4. Function Generator Component Page
Figure 5. Selecting Signal Outputs From the Scope
Figure 6. Adding a Scope Display and Control Button for the Function Generator
Figure 7. Additional Components on the Form for Selecting the Waveform
Type and Frequency
Better Tools Are Here
Software simply is a tool, but it tends to be complicated for nonprogrammers to use efficiently when developing test applications. To speed creation and maintenance of automated test equipment, engineers need better tools.
1. Discovery Utility, www.lxistandard.org
2. IVI Shared Component Library, www.ivifoundation.org
3. Measure Foundry Video, www.measurefoundry.com/support/videos/default.asp
About the Author
Tim Ludy is product marketing manager at Data Translation. He received a B.S. in computer science from Northeastern University. Data Translation, 100 Locke Dr., Marlboro, MA 01752, 508-481-3700, e-mail: tludy@datx.com
