Instrumentation Software: The Key to the System There has always been a need for software programmers to write application programs for ATE. Over the last few years the market for these software tools has grown considerably with numerous software products in the marketplace. With the introduction of VXIbus instruments the need for these tools has also increased, since instruments no longer have front panels that help during program development. There are several software tools available from several manufacturers. This makes it confusing as to which software package is best for your application. This paper examines the major software tools available, as they relate to VXIbus instruments, providing the user a starting point for software selection and evaluation. VXIbus Control Methods Before examining different application software packages it is important to understand a few techniques used to control VXIbus instruments. The most common are: 1. GPIB to VXIbus With this approach the system controller (e.g. IBM compatible personal computer) is external to the VXIbus chassis and executes the application software. This system controller communicates via the VXIbus instruments over the GPIB bus. The VXIbus chassis houses a GPIB to VXIbus translator (referred to as a Slot 0 module) which converts the GPIB instructions to VXIbus instructions. This conversion is transparent to the user and the application software only needs to be concerned with the GPIB interface card and software (e.g. NI-GPIB) residing in the external computer. 2. Embedded Computer In this approach the system controller resides within the VXIbus chassis and interfaces to the VXIbus backplane directly. The application software normally resides on this embedded controller and communicates with the instruments via VXIbus I/O driver software as opposed to GPIB I/O software. An example of this type of I/O driver software is NI-VXI from National Instruments. 3. MXIbus to VXIbus This approach is very similar to the GPIB approach, but as opposed to communications over the GPIB, communications are via the MXIbus. The MXIbus is an industry standard that extends the VXIbus communications backplane out to the external controller. The external computer houses a MXIbus interface card, and the VXIbus chassis houses a MXIbus/VXIbus card. In order for the application software to communicate over the MXIbus interface, MXIbus I/O driver software must exist. An example of this is NI-VXI from National Instruments. Other Control methods such as Ethernet or VMEbus also exist but for purposes of this application note will not be discussed. VXIbus I/O Software It is important to note that regardless of hardware communication method selected, there exists a need for VXIbus I/O driver software. All VXI application software packages require interface driver software for communication except for the GPIB approach above. The industry leading provider of this software is National Instruments. National Instruments has a version of VXIbus I/O driver software that resides on their embedded Intel based and Motorola based controllers, or on external computers via the MXIbus interface. This package is the NI-VXI software, and handles all communications to VXIbus instruments (message or register based), either via driver calls from application software or interactively by the user. It is important to note that the NI-VXI driver software uses the same interface for over 26 platforms, i.e. SCO Unix, Windows NT etc. It is important to understand the different VXIbus hardware control techniques and I/O driver software packages are available because standard programming languages such as C, Basic, ADA, etc. do not come with VXIbus capability. VXIbus and GPIB capability is added through VXIbus interface software packages. The selection of this software determines the hardware, operating system, programming language and even application software. VXIbus I/O software interfaces to the following system components: Controller Operating system Programming language and/or application software package. Instrument Drivers Selecting the correct software interface software is therefore very important, in fact if this is standardized it makes system compatibility easier. Differentiating Graphical Software Packages Graphical application software packages can be divided into two main categories. They can be best described as "code generator applications" and "program generator application" software packages. The categories can be summarized as follows: A code generator includes software packages like LabWindows and LabWindows/CVI. These provide a package of tools to facilitate test program development and debugging in a particular software language. A typical modern code generator provides a graphical user interface (GUI) that emulates an instrument front panel and creates lines of code corresponding to instrument setups. The user can make use of additional tools within the software package such as data logging or data analysis. Some of the reasons for choosing a code generator software package include: Experience with or preference with a particular language such as C, Basic, Atlas etc. Desire to use ones own editor or compiler Need for traditionally available source code (i.e. documentation, distribution, etc.) For problems that do not yield to data flow diagram analysis (i.e. a program generator will not be useful) Graphical language application includes software packages like National Instruments' LabVIEW. A program generator application provides a completely enclosed test development and execution environment. These packages are there own programming environment. Graphical language applications use graphical methods to define the data flow within a test program. Some reasons for selecting a program generator may be: Desire to focus on process rather than programming semantics Desire to use graphical techniques to express the test process, allowing users to easily modify and interact with program as well as programmers. Desire to use object-orientated programming techniques where the icons become the objects. Considerations when Choosing a Test Software Tool Perhaps the most important consideration when choosing a software tool is to ensure that the package will provide an open systems environment. With the VXIbus offering the ability to configure open architecture systems, it would not make sense to select a software tool that closes the architecture by limiting multi-vendor instrument choice, or make it difficult to utilize the VXIbus to its fullest. It makes sense to build a test facility upon commonly accepted standards that will ensure support for years to come. A software tool therefore should be selected that allows for maximum flexibility when selecting instruments, writing tests, and changing development platforms. Some important considerations in selecting a software package (either code generator or program generator) are: Instrument drivers. Products with large libraries of instrument drivers already written to support products of all manufacturers are the most favorable. This not only reduces the driver development time, but ensures an open instrument selection environment; the best instruments for a particular application can be selected from all manufacturers as opposed to limiting it to only one manufacturer. For future changes and documentation reasons it makes sense to select a tool that provides driver documentation, either in source code or in any easy to read format. Instrumentation manufacturers also provide drivers for their instruments, and should be solicited for what software packages they have drivers for. Operating Environments. It is useful for a software package to support many operating environments since the same software package can be used for many applications. At a minimum the software package should be able to run on PC based machines under Windows. This will ensure a low cost, easily supportable runtime system. For more advanced applications the software package should also have the ability to run on multi-tasking workstations. Ideally a flexible software package should allow programs to be developed on one platform and transported to another if required, i.e. a Sun workstation can be used to develop a program during the engineering phase of the product where high performance may be required, and then a subset of the program transferred to a PC in production. Compiled vs. Interpreted test execution. Compiling adds an extra step in development, unless it is automatically done by the application software. If the application software automatically compiles, it will also provide the benefits of an interpreted environment. Compiled execution should be an important consideration in selecting a software tool since the VXIbus architecture can allow test times to be considerably reduced. Data Analysis Tools. Most modern software packages include analysis libraries. These analysis libraries include standard functions for calculating means all the way to high performance functions such as FFT analysis. Results Presentation Tools. Tools within a software package for results presentation can be very useful. These tools enable the user to create Graphical User Interfaces (GUIs), that include graphs, dials, knobs, etc. This ease of creating GUIs should be considered strongly since presentation can make user interfacing very easy. Test Executives. The majority of graphical software packages were designed for data acquisition applications, but do also lend themselves to manufacturing and test applications. In test applications however there is a need to perform test management functions, such as password protection, help menus, serial number control of UUTs, operator logging, individual test selection, and mixed signal test management. Graphical software packages do not traditionally perform these functions and hence test executives are required. It is therefore important to consider what test executives are available for a particular software package. Comparison of Software Packages This section of the paper is not intended to perform an in-depth comparison of all software packages, but is merely outlines differentiating features between the major software packages. Code Generators The most common code generators available are from National Instruments (LabWindows and LabWindows/CVI). The differentiating features of each package are as follows: LabWindows/CVI Portable software development. Supports Windows NT. Allows LabWindows for DOS programs to be transported. ANSI C programming environment. Includes source editor, compiler, debugger encompassed within interactive development environment. Easy Graphical user interface development. Utilizes NI-VXI (VXIplug&play compatible). LabWindows DOS operating system. Microsoft C and Microsoft Basic test programs supported. Instrument Drivers for over 200 multi vendor products. Utilizes NI-VXI (VXIplug&play compatible). Easy Graphical User interface development. Program Generators The most major program generator on the marketplace is LabVIEW from National Instruments. Significant features are as follows: LabVIEW Sun workstations, Windows based PC's, and Mac's. Instrument drivers for over 250 multi-vendor instruments. Software transportable across platforms. Instrument driver development very easy. Complied code created, providing magnitudes of speed difference from interpreted operation. Supports NI-VXI. Summary There are many reasons for selecting an appropriate software package, with only some of the main reasons being discussed in this application note. Program generators are gaining more and more popularity in the industry due to the reduction in test programming times that they produce as well as allowing the user and the test programmer to modify the test program interactively if needed. There is no simple answer to the software package for your needs, and is dependent on many issues. Racal Instruments can provide support and advice in your selection process if needed. TOC 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13