Electronic test and measurement instruments have been used for decades to take measurements, provide product stimulus, and act as the liaison between the computer and the real world. For at least as long, scientific software running on those computers has been used to analyze those measurements or generate stimulus data for testing from models or complex equations.
Instrument drivers built as ActiveX controls make it easy for test and measurement instruments to be used directly from this scientific software. The capability to connect scientific or analysis software to the physical world with test and measurement instruments can help reduce product development times and enhance the quality of the design.
Using Instruments With PC Application Software
Traditionally, instruments have been used with PCs in one of three ways:
With a turnkey software application written for a designated instrument or a specific application. With a test-system language such as National Instruments’ LabVIEW or Agilent Technologies’ HP VEE to implement a custom measurement application.
With a general-purpose language with I/O libraries to control the instruments.
In all three of these cases, usually there is an instrument driver involved to communicate with the instrument. An instrument driver acts like a converter or interface between the particular computer environment being used and the test instrument.
While the instrument driver makes writing and using test instrument applications easier, writing these application programs or even using ones written by others may not be what is really wanted. The real need may be to use the measurement data in an analysis or documentation program. Using an instrument application program is just an extra step.
Generally, instrument drivers are handled as a type of object-code library. By implementing the instrument driver as an ActiveX control instead of as a library, a whole new way of accessing test instruments is possible.
An ActiveX control is a software component, based on PC standards, that allows developers to package software for use from within any application that has been implemented in the control-container category. The instrument driver then becomes an ActiveX instrument control.
There is a long list of applications in this category including word processors, spreadsheets, analysis software, general-purpose programming languages, and even test-system languages like LabVIEW or HP VEE. Documentation and analysis applications now can directly access the measurement functionality of test instruments. This eliminates the need for special programs or applications to control the instruments and transfer the measurement data from those programs to specific applications.
Generating Physical Signals
Scientific software may be used to simulate devices or processes and analyze or visualize data. This software can produce simulations of physical components like transistors or nonphysical phenomena such as complex communications signals.
The easy transfer of measurements to this software for analysis or the physical production of simulations generated by this software can be a powerful tool. It becomes much simpler and more practical to test different circuits and equipment under a variety of conditions. This leads to better product designs and, ultimately, new products finished much earlier in the development cycle.
A simple example using a software application to generate a signal demonstrates the utility of this approach. To test a circuit designed to receive an AM signal, test patterns are necessary. A useful signal for test is simple enough to verify its correctness, but rich enough to be a meaningful test condition.
One such signal might be a modulating signal that is the sum of three sinusoids. The frequencies of these sinusoids could be at the low, middle, and upper ranges of the expected bandwidth of the receiving circuit. An equation for this might look like
m(t) = cos(Ωlt) + cos(Ωmt) + cos(Ωut)
where: m(t) is the modulating signal
The complete AM signal then would be
s(t) = (1+m(t))cos(Ωct)
where : Ωc is the carrier frequency.
A software package like Mathcad or MATLAB can evaluate this equation and generate a set of sample points for the waveform. The ease of use associated with an ActiveX instrument control allows these points to be sent directly from the software to an electronic instrument such as an arbitrary waveform generator (Arb). This Arb output could be connected to the input of a prototype receiver circuit to be tested.
This has been done as a Mathcad worksheet in Figure 1 where the equations and plots of their values can be seen. The variable x is an array of integer values that will serve as distinct time sample points for the signal. The Yx array variable holds the sample values of the AM modulated signal. The Yx array then is sent directly to the Arb by the ActiveX instrument control, represented by the instrument icon, which has been added to the worksheet.
Without an ActiveX control from the instrument driver, procuring the calculated signal’s sample points would be circuitous. The data first would have to be saved in a file or transferred to the Windows clipboard. Then a program must be written that is capable of reading the data from the file and formatting it so the driver could send to the instrument.
Easier Data Analysis
Scientific software also is used extensively for data analysis and visualization. Using test and measurement instruments directly from analyzing software offers advantages in both ease of use and functionality. It eliminates the need to learn how to use multiple applications to do one task. There no longer is a struggle with transferring data into sometimes-incompatible formats. And it is not necessary to write special software simply to deliver the measurement data to where it is needed.
Programs like Mathcad and MATLAB are excellent tools for analyzing data or generating complex signals. However, there is another program that is commonly used by engineers for data analysis and general data manipulation, the Microsoft Excel spreadsheet program, which also can act as a container for ActiveX instrument controls. Since so many engineers use spreadsheet programs, it would be great if it were easy to transfer data directly from an instrument into the spreadsheet.
Figure 2 shows an ActiveX instrument control for an oscilloscope being used within Microsoft Excel to capture a set of waveform data directly into a set of columns. Once the data is contained within the spreadsheet, additional measurement functions can be implemented.
Excel’s chart wizard can be used to quickly graph some or all of the waveform points. The instrument control also could capture a screen image of the oscilloscope, which would be inserted directly onto the spreadsheet as an Excel picture object or other graphical format.
Having the image right next to the data can serve as a check for whatever analysis may be done on the data. A customized toolbar can be added to place some of the more frequently used functions of the ActiveX instrument control close at hand.
Documentation
An often-overlooked part of product development and testing is documentation. Everyone has to do it, but few enjoy it. PC applications are finding their way into the engineer’s toolbox to replace the traditional lab notebook. Incorporating test instrument control directly into the documentation tools offers several benefits:
Reduces the potential for transcribing errors. Eliminates the need for transferring data from specialized instrument control software. Allows for the inclusion of more detail.
Affords the possibility of including supporting measurement data where it would not have been considered feasible to do so before.
One of the most widely used documentation tools is the PC-based word processor. Current word processors have more than the capability of formatting text documents. Simple graphs comprising data and graphic images can be added to documents. With all that capability available, adding a direct interface between the word processor and the test instruments makes the word processor quite a capable substitute for the traditional lab notebook. A word processor like Microsoft Word can be used to contain an ActiveX instrument control as well.
As with the Excel example, an instrument control for an oscilloscope can be added to the Word program. This control then could be used to transfer a screen image of the oscilloscope directly to the word processor, as Figure 3 indicates. This would be handy when, after days of testing different conditions on a circuit under test, you finally catch an elusive transient signal with the scope.
The oscilloscope ActiveX instrument control in the word processor then would copy the screen image into a Word document, using the software’s graphic functions to clearly annotate the incorrect signal. The conditions used to produce the signal and the amount and type of testing conducted on the circuit could be easily added to the context of the oscilloscope screen image, with the document then saved, printed, or e-mailed.
Implications
An ActiveX control style of instrument driver presents a very compelling case to reconsider the way instrument drivers currently are developed and used. Today, the capability to communicate with instruments directly from PC applications is possible by using instrument drivers based on the ActiveX architecture. Because ActiveX is a computer-oriented—not instrumentation—standard, a large number of applications can directly access instrumentation through an ActiveX instrument control.
Application software that already is known and familiar can be used with the instrument without purchasing and learning a new or different program. The data to be transferred from or to the instrument already will be in the application so there is no need to struggle with transferring or reformatting the data. The minimal amount of new learning required leaves more time and opens up possibilities for experimenting with what-if situations, allowing more analysis and experimentation to be conducted early in a product development cycle. The end result: a product’s quality and functionality will be much greater.
About the Author
Rick Hester is the manager of connectivity software in the Basic Instruments Product Generation Unit in the Electronic Products and Solutions Group at Agilent Technologies. He received a B.S.E.E. from the University of Florida and an M.S.E.E. from Stanford University. Agilent Technologies, 815 14th St. SW, Loveland, CO 80537, (970) 679-5000.
Copyright 2000 Nelson Publishing Inc.
February 2000
|
|