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

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

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

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

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

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

The LXI Compliance Testing Bench at the PlugFest

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.

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.

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.”

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.

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.

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.

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.  

Screenshot From the Wheelwright LXI Compliance Testing Suite

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.³

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.

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.

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.

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.¹

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.

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.

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.

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.

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.⁴ 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.

Service Discovery
The second component of discovery is DNS-SD.⁵ 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.

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.

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.

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.

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

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/

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

PDF of this article

View Past Archived Articles

Back to Top

LXI System Setup Is Quick and Easy

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:
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.¹
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.² Install the IVI-COM instrument drivers for the function generator and oscilloscope.

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.

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.

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). 

Figure 1. Modified Visual Basic Code Adding Access for a LAN Address

The following code snippets show how to modify the program to access a LAN address.

Original Code
        ' 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

        ' Open the I/O session with the driver
        Fg.Initialize(addr, True, False, "")

Modified Code
        ' 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

        ' Open the I/O session with the driver
        Fg.Initialize(addr, True, False, "")

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.

Figure 2. Running Visual Basic Application That Outputs a Signal on the Function Generator

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.

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).³  

Figure 3. Instrument Socket Component Property Page

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. 

Figure 4. Function Generator Component Page

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). 

Figure 5. Selecting Signal Outputs From the Scope

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. 

Figure 6. Adding a Scope Display and Control Button for the Function Generator

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). 

Figure 7. Additional Components on the Form for Selecting the Waveform Type and Frequency

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.

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.

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
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