Eight Ways to Increase GPIB System Performance

Transcription

1 Application Note 133 Eight Ways to Increase GPIB System Performance Amar Patel Introduction 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 backbone of many automated measurement systems today is the IEEE 488 (GPIB) bus, 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 can be used in harmony with GPIB to help increase system performance. Solutions Span Software and Hardware The eight solutions below span both hardware and software options that can be used directly to increase GPIB system performance. These eight solutions can be used together or independently, so you can incorporate the suggestions that make the most sense for your particular system. 1. Use Bus-Mastering GPIB Controllers for PCI 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 will 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. Product and company names are trademarks or trade names of their respective companies A-01 Copyright 1998 National Instruments Corporation. All rights reserved. November 1998

2 2. Use 8-Mbyte/s-Compatible GPIB Controllers and Instruments HS488 is a high-speed extension to IEEE 488 that increases the maximum throughput capabilities of GPIB to 8 Mbytes/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 Mbytes/s between the PC and the instrument. HS488 is extremely easy to use because it is implemented in the GPIB controller hardware; users 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 National Instruments today. For more information on HS488, go to or read National Instruments Application Note 96, Using HS488 to Improve GPIB System Performance. 3. Look for GPIB Instruments That Have Optimized Measurement and Command Parsing Capabilities 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 will have to experiment with different instruments to see which ones yield the best performance when configuring and acquiring measurements across GPIB. 4. Use GPIB Instrument Drivers Designed for High Performance A new class of drivers called IVI drivers is 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. National Instruments Application Note 122, Improving Test Performance Through Instrument Driver State Management, offers 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. You can find additional information on IVI and the IVI Foundation at The following is a benchmark showing how state caching can improve GPIB system performance. 2

3 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 a HP 33120A function generator and a HP 54645D oscilloscope. Table 1 below 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) On (IVI Drivers) 35.0 N/A % 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 will be 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. Which 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. 3

4 6. Consider Using Multithreading in Software 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 very 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 each interface controls. NI software for Windows NT/98/95 from National Instruments is multithread safe and delivers complete functionality for multithreaded applications. For more information, read National Instruments Application Note 101, Developing Multithreaded GPIB Applications in Windows NT and Windows 95. LabWindows/CVI and LabVIEW also come complete with multithreading capabilities for instrument control applications. For more information on multithreading using LabVIEW, consult Application Note 114, Using LabVIEW to Create Multithreaded Applications for Maximum Performance and Reliability. 7. Use Native Instrument Data Formats 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). 4

5 8. Consider Using Modular Plug-in Instruments for Demanding Applications 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 will find in your desktop PC. Modular plug-in instrumentation based on PXI/CompactPCI offers many benefits: Seven PCI slots Bus-master DMA capability for data streaming directly to computer memory Extremely rugged and modular packaging Backplane timing and triggering Standard Windows off-the-shelf software just like you use with desktop PCs Software from desktop PC systems work on PXI/CompactPCI embedded computers Lower cost instruments and digitizers without sacrificing measurement accuracy Lower first-byte latency Easy control of GPIB measurement devices 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 between 10 and 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. Our readily available GPIB controller boards/modules handle this requirement. Conclusions 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. 5

6