Is GPIB or Ethernet Better for Instrument Automation?

Automating traditional instruments is an important activity for many engineers as new products move from design through validation to production. The choices of instruments, instrument control buses, and software significantly impact test times -- from the benchtop through validation to the manufacturing floor. While all industrial standards aim for similar operation, not all implementations offer similar performance. How important are the specific implementations of the instrument control interfaces? How important is the instrument control bus selection? Consider two engineers working at the same company on similar products as they discover the impact these often overlooked decisions have.

Setting the Comparison Stage
The engineers have two oscilloscopes from which to choose. One is the new Agilent MSO6032A with GPIB, USB, and 10/100 Ethernet instrument control options. The other is a Tektronix TDS5104B with GPIB, high-speed GPIB (HS488), and 10/100 Ethernet instrument control options. Both scopes meet the devices under test (DUTs) functional measurement requirements. The first engineer chooses the Agilent scope, while the second engineer uses the Tektronix scope. Both engineers use the National Instruments LabVIEW graphical development platform and NI-VISA universal I/O interface software throughout their testing, and both products go through the company's standard release process.

Different Test Needs from Design to Validation to Production
Each phase in the standard release process has a different weighting for small, medium, and large data transfers. For the sake of this analogy, small transfers include state setting (for example, CHAN1:RANGE 8), queries (for example, WFMO:NR_P?), and data transfers with less than 256 B. Medium transfers are data transfers between 512 B and 8 KB, and large transfers are greater than 16 KB. The number of each type of task required for each phase is summarized in Figure 1.

Tasks	Design Review	Validation Complete	Production Test
Set State	200	100	10,000
Query	100	1,000	1,000
Small Transfers	50	10	100
Set States, Queries, Small Transfers (<256 bytes)	350	1,110	11,100
Medium Transfers (512 -2048 bytes)	10	100	100
Large Transfers (>8 KB)	100	1,000	10
Iterations during Process	50	10	100

Figure 1. Varying task mix impacts optimal instrument control bus selection.



During design, automation becomes important in reproducing and documenting any defects as well as in proving they are fixed. When the product is ready for a final design review, engineers generally run a standard set of tests to form a baseline for the product specification. The automated tests are usually very short and typically take longer to set up than to run. They frequently involve lots of small data transfers, state setting, and queries with some large file transfers for either screenshots or waveform documentation.

Validation testing requires a different mix of tasks because it is aimed at showing how the product meets specifications at various operating conditions. Because these tests usually take a long time to complete, they are generally automated. Also, engineers often collect a lot of data to help understand product failure mechanisms and set manufacturing test tolerances.

Production testing requires yet another mix of tasks. These tests are fully automated with little operator intervention. There is a much higher proportion of state setting, queries, and small transfers because most transitions require only simple state changes. Also, the instrument responses are usually simple values or pass/fail indicators. Some medium transfers are used for programming memory, tracking lot numbers, and recording timestamps.

Transfer Performance Comparison
The engineer using the Agilent scope plans on using Ethernet throughout program development because it has higher theoretical bandwidth and does not require an additional interface card. He does not profile his instrument control performance. The engineer using the Tektronix scope wants to use the best bus for his tests. The profiling tests he develops form the basis for his debug and review documentation testing, validation testing, and, ultimately, production testing. During profiling, he tests the Tektronix scope GPIB, high-speed GPIB (HS488), and Ethernet bus implementations. This costs him a day to develop and run the profiling tests and the additional price of the GPIB controller. The transfer performance results for both scopes are summarized in Figure 2 below.



[+] Enlarge Image

Figure 2. The HS488 transfer performance is the fastest for up to 8 KB, and the Tektronix IEEE Standard 488/HS488 and VXI-11 implementations are 7 times/41 times and 38 times faster, respectively, than the Agilent scope transfer performance.


The transfer performance results in Figure 2 show that HS488 on the Tektronix scope is the best choice for transfer sizes up to 8 KB, and the Tektronix TCP/IP for Instrument Control standard (also known as VXI-11) implementation is the best choice for transfers larger than 8 KB. The Tektronix implementations for IEEE Standard 488-1978, HS488, and VXI-11 are 7 times, 41 times, and 38 times faster than the Agilent IEEE 488 and VXI-11 implementations, respectively, when comparing the sum of the transfer times for each transfer size from the raw profile data.

The Tektronix engineer gains two advantages. His first performance advantage is using HS488 in design and production, where there are more small transfers, and VXI-11 in validation, where there are more large transfers. The Tektronix engineer gains his second test performance advantage by using the better instrument control implementation.

To compare test transfer times for each phase, the number of tasks is divided by the average tasks per second and then multiplied by the number of iterations in each phase (Example 1). For example, the Agilent engineer sees a design test transfer time per iteration of 8.9 seconds.



[+] Enlarge Image


This is then multiplied by the number of iterations to provide the total test transfer time of 446.8 seconds per iteration (Example 2).

The overall test transfer time is the sum of the three phases. The test suites from Figure 1 and performance results from Figure 2 produce the results in Figure 3.

Tasks	Final Design Review	Validation Complete	Production Test Hand-Off	Total (s)
Set State	200	100	10,000
Query	100	1,000	1,000
Small Transfers	50	10	100
Set States, Queries, Small Transfers	350	1,110	11,100
Medium Transfers	10	100	100
Large Transfers	100	1,000	10
Iterations during Process	50	10	100
Agilent Engineer
MSO6032A
Primary Bus Used	Ethernet	Ethernet	Ethernet
Test Time per Iteration (s)	8.9	85.9	17.8
Total Test Time (s)	446.8	858.8	1779.0	3084.6
		Final Production Test Time (s)	17.8
Tektronix Engineer
TDS5104B
Primary Bus Used	HS488	Ethernet	HS488
Test Time per Iteration (s)	0.6	4.5	2.9
Total Test Time (s)	28.9	44.9	287.0	360.8
		Final Production Test Time (s)	2.9

Figure 3. The Tektronix implementation produces a 6 times faster production test time and the Tektronix engineer requires 8 times less test transfer time.


Shorter Production Test Time Benefits
The engineers realize that transfer performance delivers the major difference between production test times. The 6 times faster test time more than pays for the cost of the initial profiling test time and a GPIB controller. The savings are especially true if the profile results prevent the engineer from putting the slower scope on the production line in the first place.

The Tektronix engineer's test transfer time was 8 times shorter than the Agilent engineer's time. This was due to the Tektronix engineer's better instrument control implementations and validation test time optimization by temporarily switching to VXI-11 for validation.

Tips for Saving Time and Money
Like most analogies, this example serves as a simple way to point out important principles that are readily applicable in a much more complex world. The four main principles to remember from this analogy are:

1. Profile your instrument's bus performance. Do not assume one bus is always the best for every application. Use VISA-based software for easy switching between buses. Visit NI Developer Zone for example code used to profile the Agilent MSO6032A and the Tektronix TDS5104B scopes
2. Keep in mind that not all standard implementations are created equal. While both Agilent and Tektronix offer 488.2 on GPIB and Ethernet, as was demonstrated, the Tektronix implementations are 7 times/41 times and 38 times faster, respectively.
3. Use the test and measurement-specific features in 488.2 to further optimize and reduce your test time and costs. Though this analogy did not include 488.2 functions, remember that triggers, service requests, control registers, and commands are important ways to optimize test time and repeatability.
4. Optimize your test development and execution time by using the transfer performance profile results to select the best bus with the best hardware -- in this case, HS488 GPIB and Ethernet controlling the Tektronix TDS5104B scope.

Obtain more information on improving instrument control performance and evaluating other buses.

Alex McCarthy
GPIB and VXI Marketing Group Manager
alex.mccarthy@ni.com

This article first ran in the December 6, 2005, issue of NI News.

Reader Comments | Submit a comment »

Something overlooked in the comparison
The article focus' strictly on performance issues however, it overlooks the security issues when dealing with ethernet. Some of the same features that make ethernet attractive also create problems by exposing your test equipment on a network. Todays Windows based test equipment is just as vunerable to virus' as any other computer and it is often more difficult to eradicate / restore due to the specialized configuration / application software. When using ethernet in a corporate environment, the typical IT department implements a variety of security measures in order to protect the company. These measures will impact ethernet performance. In addition, there are the limitations imposed by bandwidth, number of users, etc. GPIB - It's a good thing.
- Joseph Travis, Nokia. joseph.travis@nokia.com - Apr 26, 2006