Integrating VXI Plug&Play Drivers with PAWS

This application note gives information on the integration of VXI Plug&Play drivers into PAWS CEM ‘C’ coded drivers and on use of the ‘Soft Panel’ displays with these drivers. The first section will present an overview of PAWS CEM drivers. The second section will present an overview of VXI Plug&Play, and the third section will present an example of integrating a Plug&Play driver into a CEM and implementing or creating a ‘Soft Panel’.

The PAWS system allows for several methods for controlling ATE instruments. The simplest method involves CIIL instrumentation. The native output of the PAWS ATLAS compiler is MATE CIIL, so all you need to do for these types of instruments is write a resource static description. Most instruments don’t have CIIL options, so you will probably need to have some other software driving the instruments. The remaining options are PAWS macrocode, which uses PAWS IDBDL (Instrument Database Description Language) a ‘C’ like language, and integrating external drivers using the PAWS WCEM (Windows CIIL Emulation) process.

In the WCEM process you will create a DLL that contains all the instrument driver code. The RTS will call functions in the DLL when an ATLAS statement is allocated to an instrument that is controlled by a CEM driver.

Figure 1 shows the WCEM DLL communicating directly to the ATE. However when you build the CEM DLL you will include the driver software for the instruments you need to control. The WCEM may also contain references to VXI plug&play drivers, other drivers delivered by the manufacturer, or functions that you write yourself to control instruments. The WCEM may also reference other DLL’s that contain driver code. These other DLL’s will be loaded when the WCEM DLL is loaded by the RTS.

When referencing VXI plug&play drivers the system architecture of WCEM will include the following elements shown in figure 1b.

The WCEM will call functions in the VXI plug&play driver. That driver in turn calls the low-level functions in the VISA driver which interface with the hardware level. The WCEM is, when it is created, only an interface between the RTS and whatever instrument drivers are being referenced, in this case the VXI plug&play driver.

The VXI plug&play driver follows a defined architecture and provides a standardized interface for the application programmer. It insulates the programmer from the implementation details of low-level communications with the VXI instrument. The actual low-level communications are performed through the VISA (Virtual Instrument System Architecture) library.

The VISA library provides the low level functions that control opening and closing of sessions to VXI instruments, and communications with VXI devices. The VISA API (Application Programmers Interface) is defined in the VXI plug&play standards vpp4x which are available on the VXI plug&play consortium website at www.vxipnp.org.

The only part of the VXI plug&play standard you need to be concerned with is the actual plug&play driver for the instrument you are integrating. You need to have VISA installed on your system, and include the library when building your WCEM, but you will not be referencing any of the VISA function directly. You will be declaring variables of some VISA defined data types however, and will need to include the header visatype.h in your ‘C’ files. This will be discussed later in the example of integrating a plug&play driver.

The PAWS Developer’s Studio uses a WCEM Wizard to create the functions that will be called for each instrument and ATLAS single action verb. When you select an instrument, FNC number, and single action verb, a list of ATLAS modifiers is presented as shown in figure 2.

From this list you will select which modifier values you want to pass to the WCEM function.

The WCEM Wizard will automatically select a function name for you, or you can type in your own. The Wizard maintains a list of functions that have been defined so you can keep track of your work.

To create a WCEM using the PAWS Developer’s Studio you need to start with a resource static description for your instrument. The static description will define the functionality of the instrument and gives the WCEM Wizard the keys to create the template for the WCEM. The static description will be the same as for any other type of driver, with a few additional rules.

First, you must use function numbers. The WCEM Wizard will create functions based on the instrument you assign in the static description, the single action verb being implemented, and the FNC number you assign.

Second, the FNC numbers must appear at the lowest functional level in the static description. This means if you have a begin FNC = x statement, you can’t have any begin/end structures nested inside that structure. If you do, the WCEM Wizard won’t be able to find them.

When you use the WCEM Wizard a series of source files are created. The source files are the foundation for the WCEM.DLL that will be created when you build the CEM process. The files created by the Wizard are:

Wrapper.c	Contains dispatch functions that retrieves ATLAS data and passes it to the interface functions defined in the Wizard.
Key.h	Key table definitions used in Wrapper.c that define ATLAS nouns, modifiers, dimensions, etc.
Error.c	Error handling routines called from Wrapper.c
<device_name>.c	Instrument C file. Contains the interface functions defined in the Wizard. These functions are passed the ATLAS data from the dispatch routines in Wrapper.c. This is the only file you need to modify.
Ctlr.c	Contains the DoIfc() and DoDcl() functions which are used to setup the ATE to a quiescent state when the ATLAS program is loaded and reset the ATE when a program is unloaded.

In addition to these files you can add any other source files that you want to become part of the WCEM. These can be user defined C source files, plug&play drivers or other driver files. Pathnames for include files and libraries, and required libraries for the linker are specified in a WCEM options window.

These files will be discussed in greater detail later in this application note.

The VXI plug&play specification provides a standardized approach for developing instrument drivers that provides the end user with familiar set of files and functions no matter who the manufacturer of the instrument was. Instrument drivers must be registered with the VXI plug&play consortium before they can be labeled with the VXI plug&play logo and certified to be in compliance with the specification.

The plug&play specification defines the interface that the application programmer will use to access the functions of the instrument. The overall system architecture of a system running plug&play is:

The user program in the case of writing a WCEM is the <instrument name>.c, or ctrl.c file created by the Wizard. The access to the application functions and component functions of the plug&play driver is through the programmatic developer interface. This provides access to the functions of the driver through either Function Panels or through the C header file that contains the prototypes of the library functions in the driver. The contents of the function body of a plug&play driver are defined by the VXI plug&play specification, so all instruments will have an initialize function, a close function, and other functions that will be grouped as shown. These functions access the instrument through the VISA interface. This insulates the programmer from the low level implementation details of controlling the instrument.

You need only open a session to the instrument with the initialize function, program the device with one or more calls to the application functions, and when you are finished end the session to the instrument with a call to the close function.

The contents of a plug&play driver are targeted to one or more ‘system frameworks’. The system frameworks define all the required elements for a VXI system under different operating systems. The system frameworks defined for VXI plug&play include WIN, WIN95, WINNT, SUN, and HP-UX. We will focus on the WIN95/WINNT frameworks as these are the systems that the PAWS Developer’s Studio runs under.

The system framework for WIN95 defines that a system will have a VXI framework consisting of a VXI mainframe and a VXI slot 0 computer or resource manager. The WIN95 framework defines that a system will include:

• A computer that is 100% IBM compatible with
• 486 33 Mhz or greater CPU with floating point
• at least a 500 MB hard drive
• a VGA monitor or higher
• a 3.5-inch, 1.44-MB floppy disk drive
• 16-MB or more of RAM
• a Windows95 compatible mouse.
• The ability to control VXI message-based and register-based instruments.
• The VISA API dynamic linked library VISA32.DLL.

Most PC’s or slot 0 computers easily meet these requirements. The VISA library is installed when you install the VISA driver on your system. National Instruments NI-VISA is an example of this driver. It typically installs under the directory C:\VXIPNP, which is the default for all your plug&play drivers. The file VISA32.DLL is installed under C:\WINDOWS\SYSTEM.

The plug&play driver will provide the following files as defined by the VXI plug&play specification:

• ANSI C source code (.c, .h files)
• A Windows 32-bit DLL (*_32.DLL file)
• A Windows 32-bit import library (.lib file)
• A function panel (.fp file)
• A Visual Basic function declaration file (.bas file)
• A VXI plug&play Knowledge Base text file (.kb file)
• Driver documentation in a Windows help file (.hlp file)
• An executable softpanel program.

The ANSI C source code provides source code for the driver functions, and the header file contains the prototypes for the functions. The header file will need to be included into WCEM instrument ‘C’ file. The driver source code is best left alone unless you know exactly what you want to modify.

The Windows 32-bit DLL contains the driver functions for the instrument. The file name will be the name of the instrument followed by ’32.DLL’ or ‘_32.DLL’.

The Windows 32-bit import library will need to be added to the library list for building the WCEM and its path name included in the library search paths.

The function panels are of particular interest if you are using LabWindowsâ /CVI. A function panel consists of a tree of functions that include the functions previously shown in the plug&play architecture. Each function call has a panel that shows it’s prototype, provides a field for each argument, and provides help on each of the arguments. CVI contains a function panel editor which allows you to load the instrument, open a function panel, and insert the call to the function directly into your ‘C’ file. This process will be discussed later in the application note.

The knowledge base file provides information about the instrument as it pertains to the VXI system. The WCEM process does not use the knowledge base.

The Windows help file is a useful reference that provides a description of each of the functions in the plug&play driver.

The softpanel is used initially to verify the functionality of the driver, and can also be used as a learning tool to teach instrument control concepts. When you first install your instrument and driver, run the softpanel program to verify that your instrument works. This also gives you confidence in the instrument library for the plug&play driver.

The softpanel supplied with the driver is typically much more complex than is required by an ATLAS runtime environment. The vendor-supplied softpanels are standalone executables that show all of the features of the instrument in multiple windows. A softpanel that would be used at runtime with the ATLAS RTS would typically function as an indicator, displaying the current mode and measurement. The functions in the DLL supplied with the driver do not reference the softpanel. If you want to have a softpanel as an indicator in your program, you probably want to design and implement your own using a tool like LabWindows/CVI.

When you install a plug&play driver the default directory is C:\VXIPNP. Under this director there will be a Kbase directory where all of the knowledge base files are stored, and a directory for each of the different frameworks that you install. If you installing the plug&play driver for the Hewlett Packard E1412A Digital Multimeter under the WIN95 framework they would be installed in the directory ‘C:\VXIPNP\WIN95\HPE1412’. Additionally under the WIN95 directory would be the directories of BIN, INCLUDE, and LIB. The BIN directory contains the DLL files for each instrument under the framework. The INCLUDE directory contains all the header files for instruments under the framework, and the LIB directory contains subdirectories for each ‘C’ compiler supported which contain the driver source code specific to that compiler.

As you install more VXI plug&play drivers they will be added to the VXIPNP\WIN95 directory. This provides a common location and an organized structure for maintaining all of the plug&play driver source files, which also makes setting up the WCEM easier, as it reduces the number of paths that need to be added for include files and libraries.

In this section we will demonstrate integrating a plug&play driver by using a simple example and a plug&play driver for the Hewlett Packard E1412A Digital Multimeter.

Before attempting to integrate a plug&play driver you need the following:

• TYX PAWS Developer’s Studio version 1.2.0 or later and Run-Time System.
• Microsoft Visual C++ version 4.0 or later
• National Instruments NI-VISA driver version 1.2 or later. (Downloadable from national instruments).
• The VXI framework required elements
• The WIN95/WINNT framework required elements
• The VXI Instrument and plug&play driver
• (optional) National Instruments LabWindows/CVI version 4.0 or greater.

LabWindows/CVI is optional but it makes the job of integrating plug&play drivers much easier as will be shown in this example.

The first step in writing any instrument driver is to learn the capabilities of the instrument and how they relate to ATLAS. Remember that all calls to the plug&play functions will be in the context of an ATLAS signal oriented statement. You need to look at the instrument capabilities, what is needed to make a measurement, and then map those to the ATLAS single action verbs, nouns and modifiers that will be used in the test programs.

For simplicity we will implement only the DC voltage measurement features of the E1412A. The DMM is capable of measuring –300 vdc to +300 vdc in five ranges. We will see that the design of the functions for the E1412A allows you to specify a max voltage, and not worry about the range to place the instrument in.

The ATLAS nouns and modifiers that can reference the DC voltage measurement will include DC SIGNAL/VOLTAGE, AC SIGNAL / DC-OFFSET, SQUARE WAVE/DC-OFFSET, and any other noun that allows the DC-OFFSET to be measured.

The ATLAS statements that will be used to measure the dc voltages include:

Additional modifiers could be added to further describe the signal, such as the VOLTAGE and FREQ of the AC SIGNAL or SQUARE WAVE, but these are the basic ATLAS statements we would use to control the instrument. There are other nouns that support DC-OFFSET, but we will just use these for this example.

You could also write single action verbs to test the function of the driver. This depends on your specification for your ATE. If you require full single action verb control over all signals, then this will change how the driver is written. There are functions for the instrument that will configure the DMM and make the measurement in one call. But if you need to have full single action verb control (SETUP, CONNECT, CLOSE, INIT, FETCH, OPEN, DISCONNECT, RESET) then you will probably need to use lower level function calls to implement each single action ATLAS verb.

Like any project the better your specification is, the better your final product will be. If you have defined up front all the system requirements you will save yourself a lot of effort redesigning the driver later.

The resource static description defines the functionality of the instrument for the resource allocation process. All instruments will be defined in terms of a resource name, a function description, ATLAS modifier ranging, and connection ports.

The resource name defines the name that the instrument driver (on the PAWS side) will be known by. This name will appear in the BusConfi file to assign a controller and logical address for the device, and it will also be used by the WCEM Wizard for the name of the C file the driver functions will be created in. So choose a name carefully, making sure that you don’t choose the same name as the plug&play driver uses, to avoid any conflicts.

In the resource static description for this device we will describe three separate functions; one for each noun/measured characteristic being implemented for this instrument. A simple static description would include:

Note several things about this static description. First, the resource name is DMM. The using defines that this resource can only be allocated to one ATLAS statement at a time, and it also identifies the instrument that this static description is being written for. The name could also have been E1412. You need to make sure that you don’t have any naming collisions. By naming this device DMM a ‘C’ interface file called ‘DMM.C’ will be created. If the device had been named ‘HPE1412’ a ‘C’ interface file called ‘HPE1412.C’ would have been created, which could have been a name conflict with the plug&play source files. You can decide on a naming convention that suits your project and style of programming.

Second, note that the FNC numbers are all assigned at the lowest functional level. There are no begin/end structures nested beneath them. This is important, as the WCEM Wizard will not find any FNC numbers that are not at the lowest functional level.

Once you complete the resource static description for the E1412A you can build the device file. After the device database has built with no errors you can execute the WCEM Wizard. This process will create the interface for the WCEM.DLL where you can add the calls to the plug&play driver.