New ZTEC Instrument Driver Architecture Increases Hardware and Software Platform Independence

Total Page:16

File Type:pdf, Size:1020Kb

New ZTEC Instrument Driver Architecture Increases Hardware and Software Platform Independence

New ZTEC Instrument Driver Architecture Increases Hardware and Software Platform Independence

Unlock the power of your modular instrument using ZTEC instrument drivers

Integration unlocks the power of modular instruments. Therefore, ZTEC is dedicated to provide the tools you need to make this integration a success. Tools such as manuals, getting started tutorials, and phone based technical support provide a good first step. However, the most fundamental tool needed by integrators is a high quality instrument driver.

Instrument drivers allow you to programmatically control your modular instrument. For example, the software routines found in an instrument driver provide programmatic control of configuration settings, the reading and writing raw data, and other general operations of an instrument. Instrument drivers come in many forms, each addressing a different need. ZTEC has standardized on LabWindows/CVI plug-and-play (PNP) instrument drivers. We chose PNP drivers because they are the most universal and industry standard architecture available today.

Figure 1 – ZTEC PNP drier architecture for Windows (PXI and PCI)

PNP instrument drivers provide a number of benefits, for both the manufacturer and end user. For starters, they can easily be integrated with the most commonly used instrumentation programming environments, such as National Instruments LabVIEW and LabWindows/CVI, Geotest ATEasy, and Agilent VEE. At the same time, PNP drivers are not limited to these programming environments. PNP drivers also provide hooks to be used by other common text based computing languages, such as Microsoft Visual Studio and Visual Basic. In addition, the C source code of a PNP driver can be used for compilation into many other environments. PNP drivers also provide a standard style interface that is intuitive and well documented for end users.

One limitation of typical PNP instrument driver is its dependence on the Virtual Instrumentation Software Architecture (VISA). Most PNP driver development tools automatically include the use of VISA data types, functions, and error codes. When using a Windows or National Instruments environment, VISA is well supported and this

http://www.ztecinstruments.com is not an issue. However, once you get away form Windows or National Instruments and move to a Linux or embedded system, problems can arise as the C based source code will not port to these other systems without VISA.

To help our customers overcome this portability challenge, ZTEC has implemented a hardware I/O abstraction layer within our PNP instrument drivers (Figure 1). This hardware abstraction layer makes it very easy for end users to utilize the core PNP driver components supplied by ZTEC with their own custom I/O layer (Figure 2).

Figure 2 – ZTEC PNP driver modifications for use with

Custom System (such as Linux) (PXI and PCI) (changes in RED)

For a PXI instrument, the core routines of a ZTEC PNP driver are found in the “zt_n_.c” file, where “_n_” is the instrument family number (002, 430, 450, 500, or 530). Within the “zt_n_.c” file, there is no VISA specific information. Instead, ZTEC specific I/O functions are used. These ZTEC specific functions, found in “zt_pxi.h” and “zt_pxi.c,” are then mapped to the appropriate VISA function at compile time using information in the “zt_common.h” file. The “zt_common.h” file can easily be modified to map these functions to other I/O routines, eliminating the need for VISA.

For example, a typical VISA function and type are “viOpen()” and “VI_STATUS” respectively. In the “zt_n_pxi.c” file, ZTEC specific functions and types are used, such as “ztOpen()” and “ZT_STATUS. Then, within the “zt_common.h” file, the ZTEC types are mapped to the corresponding VISA type:

#define ztOpen() viOpen()

#define ZT_STATUS VI_STATUS

Likewise, if you have your own I/O library, you can use the “zt_common.h” to map the ZTEC types to match:

#define ztOpen() myOpen()

#define ZT_STATUS MY_STATUS

Once the mapping is complete, you simply need to re-compile the instrument driver for inclusion into your project.

By providing this type of hardware abstraction layer, a ZTEC PNP driver overcomes the lack of portability associated with typical PNP drives that use VISA. At the same time,

http://www.ztecinstruments.com the ZTEC PNP drives are able to utilize the benefits of VISA when used in conjunction with a VISA supported platform. This “best of both worlds” approach provides customers with the ability to choose a software solution that is flexible, powerful, and best meets their needs.

Another challenge with PNP drivers is that they tend to be hardware specific, making it difficult to migrate from one hardware platform to the next (moving from a VXI to a PXI instrument for example). To overcome this challenge, ZTEC has also implemented a hardware abstraction layer within their PNP drivers. By changing the abstraction layer, the end user is able to migrate between VXI and PXI instruments with relative ease (Figure 3).

Figure 3 – ZTEC PNP driver modifications for use with VXI (changes in RED)

In summary, the new ZTEC instrument driver architecture provides a number of benefits to our users. First, by leveraging PNP drivers, ZTEC is able to provide a standard programmatic interface to our instruments that will satisfy the majority of our users. However, for users that have custom software or hardware cross platform compatibility requirements, our new driver architecture provides the flexibility needed for their applications.

All ZTEC instrument drivers with source code can be easily downloaded from the ZTEC Support Center. If you have any comments or questions on this article, we encourage your feedback.

http://www.ztecinstruments.com

Recommended publications