When building an automated measurement system, you can never have too much performance. Increasing performance has clear implications for production test and GPIB-based data acquisition applications. By increasing your system performance you can:
- Increase test throughput and test more products in less time
- Validate new products quickly to beat the competition to market
- Minimize capital expenditures in test equipment
In essence, saving time translates to exceeding customer delivery expectations, faster product development, and smarter investments in test equipment that have positive effects on the bottom line. Because the IEEE 488 (GPIB) bus is the backbone of many automated measurement systems today, it makes sense to evaluate different options that assist you in increasing GPIB system performance. Test and R&D engineers continue to use GPIB because it is an easy-to-use, time-proven interface that offers the widest selection of measurement devices that you can incorporate into an automated measurement system. For these reasons, this application note will discuss eight options that you can use in harmony with GPIB to help increase system performance.
The eight solutions below span both hardware and software options that you can use directly to increase GPIB system performance. You can use these eight solutions together or independently, and incorporate the suggestions that make the most sense for your particular system.
PCI offers superior data transfer performance once the data is received over GPIB. Unlike an ISA-based computer, in a PCI-based computer there is no dedicated DMA controller that can be shared by peripheral cards to transfer data directly to PC memory. For maximum performance, PCI peripheral boards must have their own onboard DMA controller to transfer data directly to PC memory efficiently so the data can be processed by the microprocessor. Boards with this capability are identified as bus masters, which means they can take control of the PCI bus and transfer data independent of the microprocessor in the system.
Peripheral cards that do not have bus-master capabilities interrupt the microprocessor causing it to stop all processing tasks simply to transfer data. This interruption can bog down your application and significantly impede overall system performance.
HS488 is a high-speed extension to IEEE 488 that increases the maximum throughput capabilities of GPIB to 8 MB/s. Benchmarks have yielded performance improvements from 25 to 3,000 percent. A recent benchmark with an oscilloscope demonstrated data transfer rates up to 7.4 MB/s between the PC and the instrument. HS488 is easy to use because it is implemented in the GPIB controller hardware; you are not required to make any application software changes to gain the advantages of higher performance. HS488 is field-tested and completely compatible with existing IEEE 488 instruments. Both high-speed and standard IEEE 488 instruments can coexist in the same systems without compatibility problems.
HS488-compatible GPIB controllers are available from NI today. For more information on HS488, see the links below.
Processing commands and depositing measurement information into the GPIB output buffer of the instrument can be a time-consuming task when acquiring measurements from a GPIB instrument. Instrument vendors must optimize these potential bottlenecks to ensure the fastest possible measurement performance. The speed and type of onboard microprocessor and internal system bus may give you hints as to the processing capabilities of the instrument. However, powerful hardware cannot fully be taken advantage of without optimized firmware. If the instrument vendor does not offer any specifications or benchmark information in this respect, for the most part, you have to experiment with different instruments to see which ones yield the best performance when configuring and acquiring measurements across GPIB.
IVI drivers are designed to improve system performance by remembering the state of a particular instrument. A state-caching engine keeps track of the state of the hardware settings on the instrument. This feature improves test performance significantly because it helps your system behave intelligently by performing instrument I/O only when the value of a hardware setting needs to be modified. For example, if you are simply sweeping the frequency of an excitation signal, you do not want to resend amplitude, waveform shape, phase, and other types of signal information over and over again because it is redundant. Current VXIplug&play instrument drivers do not offer state-caching capabilities.
With IVI drivers, you can also configure your instrument drivers to run in special modes for best results during test development or system deployment. For example, you can configure the driver to automatically check the ranges of all values you try to send to the instrument and coerce them to valid values if necessary. You can also set the driver to automatically check the status byte of your instrument after each command is sent to it. All of these “development mode” settings can be quickly turned off when you deploy your test program on the production line for fastest possible execution. You get the best of both worlds – superb debug capabilities and faster run times.
Refer to the IVI Driver Help for detailed information on how to take advantage of these capabilities. IVI drivers are created based on an open industry specification published by the IVI Foundation, which consists of more than 20 different user and vendor companies.
Benchmark Example – Measuring the Magnitude of System Response versus Frequency
Consider the task of determining the frequency response of an unidentified system. This requires both a waveform/function generator to generate sine waves at various frequencies and a DMM or an oscilloscope to measure the output voltage(s) of the system under test. You can see below the pseudocode for a test program that uses high-level instrument driver calls to program a function generator and oscilloscope.
Pseudo-code and test setup for swept sine test:
Initialize and Configure Oscilloscope
Initialize and Configure Frequency Generator
While (frequency < EndFreq)
BEGIN LOOP
Generate Sine Wave
Read Stimulus Waveform (Scope Channel 1)
Read Response Waveform (Scope Channel 2)
Calculate Magnitude and Phase Difference between Stimulus and Response Store Magnitude and Phase Increase Frequency
END LOOP
Plot Magnitude and Phase Difference
Close DMM
Close Frequency Generator
This test process was implemented using an HP 33120A function generator and a HP 54645D oscilloscope. Table 1 highlights the difference in performance between IVI and traditional drivers for this particular test.
Table 1. State Caching Benchmark
| State Caching | Test Time (seconds) | Performance Difference |
| Off (Traditional VXIplug&play Drivers) | 35.0 | N/A |
| On (IVI Drivers) | 13.2 | 265% |
5. Consider Off-Loading Data Processing to the Host PC
We continue to see improvements in the processing and analysis capabilities of instruments. However, it is difficult for instrument vendors to remain in lock step with the PC industry to provide you with the latest processing technologies. Many times, incorporating a new processor requires the vendor to redesign the instrument. You may have to purchase a new version of the instrument to take advantage of higher performance capabilities.
To ensure that you are always using the most powerful processing capabilities at your disposal, you should consider off-loading some computation-intensive analysis to your PC rather than relying on the internal and sometimes outdated processing capabilities of the instrument. In general, PC capabilities advance at a more rapid pace than instrument capabilities. Chances are that you will replace your PCs more frequently than your instruments. With each new generation of PC, you can directly realize new performance gains by choosing to use the PC for some of your measurement processing and analysis.
In addition, because instruments are closed boxes, you cannot customize analysis. With the PC, you can easily add customized analysis because many instrumentation software vendors offer complete libraries for signal processing, filtering, and general analysis to greatly simplify the task of defining customized analysis routines.
Multithreading is a method of programming in which the work of an application is divided into different tasks, or threads. These different threads, which are created by the main thread of an application, can execute independently of other threads in the system. When a thread completes its task, it exits. The main thread of an application is responsible for closing the application once all tasks have been completed. If your system has more than one processor, you can increase the performance of your application by simultaneously executing individual threads on separate processors. You can also tune single processor systems to yield greater performance by allocating appropriate processor time slices to each thread in your application. By configuring the amount of processor time allocated for each thread, you can improve the performance of your application because the processor can continue to execute one thread while waiting for external events before executing another thread – a common scenario in GPIB applications.
GPIB applications can take advantage of multithreading in a number of ways. Multithreading can help you isolate separate application tasks to manage system resources more efficiently. You can use multithreading to isolate time-critical tasks in separate threads so you can monitor time-critical events, such as a Service Request (SRQ), while simultaneously processing data already available in memory.
For example, an application might have three threads with different responsibilities – one that manages user input, a second that acquires and logs data, and a third responsible for processing and displaying data. Processing and displaying data can be time consuming and processor intensive. The amount of data and the frequency at which you acquire data can vary. Many times, applications may also constantly check for SRQs from instruments. User interaction may be a sporadic event compared to the other ongoing activities in the application. Using multithreading, you can isolate these tasks and address the processing needs of each individual task. In addition, for applications that use more than one GPIB interface, a single thread can be dedicated to manage each GPIB interface and the instrumentation of each interface control.
NI-488.2 software from NI is multithread safe and delivers complete functionality for multithreaded applications. NI LabWindows™/CVI and LabVIEW also come complete with multithreading capabilities for instrument control applications. See Using LabVIEW to Create Multithreaded Applications for Maximum Performance and Reliability and Multithreading in LabWindows/CVI for more information on multithreading in LabVIEW and LabWindows/CVI.
Microprocessors do measurement calculations in binary format. However, when transferring data across GPIB, many times data is converted to an alphanumeric format (typically ASCII). Performance is affected because time is spent doing two data conversions. The first conversion occurs in the instrument where binary data is converted to ASCII for transfer across GPIB. This conversion can be very time consuming because the processor in the instrument typically has a fraction of the processing power found in the latest PCs available on the market today. The second conversion occurs in the PC where you write a data parsing routine to convert measurement data from ASCII to binary for further processing and analysis of the data. To remove the overhead of both these operations, consider transferring the data in the native data format of the instrument (binary).
For applications that require data streaming, fast, small data transfers, and very precise synchronization and triggering capabilities, consider using a modular plug-in instrument to make some of your measurements. These instruments are available for PCI, PXI/CompactPCI, and VXI platforms. With any of these platforms you can easily control your GPIB instruments, so you gain the best of both worlds.
From a cost perspective, PXI/CompactPCI offers an economical solution for production test environments because it is rugged and is based directly on the same PCI bus you find in your desktop PC. Modular plug-in instrumentation based on PXI/CompactPCI offers many benefits:
Modular instrumentation solutions are attractive options because these systems meet three diverse needs that exist in measurement and automation systems. The first requirement is to be able to stream large amounts of data to and from PC memory. Devices such as oscilloscopes, arbitrary function generators, and high-speed digitizers require enough bus bandwidth to ensure that data is transferred to and from PC memory in the shortest time possible.
The second requirement is efficient communication to devices that transfer very small amounts of data, such as counter/timers, power supplies, and digital multimeters. Efficient communications for these devices depend primarily on the time it takes to send the first byte of information (first-byte latency). This overhead is significant because the overall amount of data to transfer is small. The first-byte latency for PCI, PXI/CompactPCI, and VXI ranges from 10 to 100 ns. For GPIB, first-byte latency is around 100 µs. A small first-byte latency ensures fast communication for devices where the amount of data to be transferred is small.
The third requirement is to be able to interface to existing GPIB instruments that are not available for the modular platform. The readily available GPIB controller boards/modules from NI handle this requirement.
There are many options for increasing GPIB system performance. The options discussed in this application note span the instruments you choose to use, the GPIB controller you purchase, and the software and design methodology you use to build your applications. Formulate a realistic checklist for yourself based on the tips above or other ideas you may think of on your own and then make sure you address them directly with the appropriate measures. You may find that your current GPIB system has performance capabilities you have not fully exploited.
For more information regarding NI's GPIB and Instrument Control interfaces, please refer to the related links below.
The mark LabWindows is used under a license from Microsoft Corporation. Windows is a registered trademark of Microsoft Corporation in the United States and other countries.