Keysight Technologies Understanding the Programming Interfaces of PXI Instruments

Transcription

1 Keysight Technologies Understanding the Programming Interfaces of PXI Instruments Making PXI-based ATS Integration Easier Application Note

2 Introduction PXI-based automatic test systems (ATSs) are gaining the interest of test engineers, however the architecture and programming methods for these test systems are quite different than box-based ATSs. This application note explains the differences in system architectures and programming interfaces to help you understand and select the most appropriate programming interface (either SCPI or a direct access driver), for your application, and make your system integration job easier. PXI Automatic Test Systems Challenging Tradition Though rack-and-stack test systems based on box instruments are the majority of what is used in the market, more and more test engineers are transitioning to automatic test systems (ATSs) based on PXI or PXIe modular instruments. The increasing availability of RF and microwave PXI modules in recent years is helping to accelerate this transition. A few key factors are contributing to the rapid growth of PXI-based ATSs. One is the faster measurement speed of PXI instruments, which leverage the latest PC technologies such as PCI/PCIe buses and increasingly powerful central processing units (CPUs). The second reason for the growth of PXI-based ATSs is their compact size, complete with an industry-standard architecture and interface. These ATSs provide benefits like flexibility and scalability, which are desirable for testing multi-port devices such as phones and base stations that are adopting MIMO and beam forming. Their compact size also provides the smaller footprint desired in production, and the mobility desired by the military for on-site maintenance and trouble shooting. When migrating from a box instruments-based ATS to a PXI-based ATS, one challenge you may face is programming the modular instruments. Traditionally, SCPI has been the dominating programming interface for box instruments. It is relatively simple and familiar to all engineers working on test systems. In the modular world, there are multiple programming interface choices. While this provides more flexibility, it adds complexity. The intent of this paper is to describe the majority of these programming interfaces to help you to understand their differences, strengths, and weaknesses.

3 03 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note What Changes When Moving from a Rack-and-Stack System to a PXI-based ATS If you intend to migrate your ATS from a box-based rack-and-stack system to a PXI-based ATS, or build a new PXI-based ATS, understanding the following differences will be quite helpful. Figure 1 illustrates the hardware and software layers of a traditional box-based ATS, and how these layers are distributed inside PC and instruments. It should be noted that while an actual test system is likely to include multiple instruments, for simplification, Figure 1 shows only one instrument. Hardware and software layers - rack-and-stack Automatic test program I/O software Computer I/O hardware I/O cable (GPIB/LAN/USB) Measurement software Measurement hardware Box instrument Figure 1. Hardware and software layers in a box, or benchtop instrument-based rack-and-stack automatic test system.

4 04 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note What Changes When Moving from a Rack-and-Stack System to a PXI-based ATS (Continued) In Figure 1, the instrument and the PC are two separate items interconnected through either a GPIB, USB, or LAN cable, or possibly through a LAN or WAN network if they are geographically separated. For any box instrument, you can simply think about it as a two-layered product. The bottom layer is measurement hardware, which physically connects to the device under test (DUT) to either capture a signal from the DUT, or send a signal and stimulate the DUT. The upper layer is measurement software, dealing with hardware control, data processing, analysis, and the presentation of measurement results. It also provides the graphical user interface (GUI) and remote user interface (RUI). For simple instruments, like digital multi-meters and power meters, the measurement software layer can be very thin. It runs in a very simple embedded computing environment, like single chip microcomputer. The measurement software layer can also be very thick in more sophisticated instruments, like RF or microwave signal analyzers. These types of instruments need to deal with very complicated hardware control, calibration, data processing, measurement algorithms, and sophisticated GUIs and RUIs. To deal with this complexity, a complete and modern computer is typically inside the instrument, often running a powerful operating system such as Microsoft Windows. A separate PC is used for remote control of instruments and test automation. The PC runs the automatic test program (ATP), which sends a series of commands to the instrument and reads the results from instrument. Computer I/O hardware is needed to enable the physical connection to the instrument. This can be a GPIB card, LAN port, or USB port, which is chosen to match the I/O hardware type provided by the instrument. I/O software is a bridge layer between the ATP layer and the I/O hardware, which provides libraries like VISA to ensure commands and data can be properly transported between the ATP and instruments over I/O hardware and cables. According to the I/O type and instrument address, the I/O software packages commands and data into the proper format. For instance, IP packages and routes commands and data to the LAN port with the proper IP address. There are some well-known I/O software on market, includes Keysight Technologies, Inc. s IO libraries and National Instrument s Measurement and Automation Explorer (MAX).

5 05 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note What Changes When Moving from a Rack-and-Stack System to a PXI-based ATS (Continued) Figure 2 illustrates the layered structure of a PXI-based ATS. You will notice differences when comparing it to box instrument ATSs. Hardware and software layers - PXI-based Automatic test program I/O software Measurement software Software in controller I/O software Instrument PXI or PXIe bus Measurement hardware Module Controller Chassis Module Figure 2. A PXI-based ATS

6 06 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note What Changes When Moving from a Rack-and-Stack System to a PXI-based ATS (Continued) In a modular world, the two instrument layers, measurement hardware, and measurement software are allocated into two physical items: the module and the controller. The measurement hardware is in the form of a single module or multiple modules, while measurement software is installed in the controller, which can be either an embedded PC inside a PXI chassis, or a commercial PC connected to the chassis via an interface adaptor card. The module and controller are interconnected via a PXI or PXIe bus on the backplanes which evolved from the PCI or PCIe bus and has a unique trigger and CLK bus designed specifically for instruments. For PXI, the module is primarily measurement hardware. In most cases, the measurement software is moved into the controller, particularly in sophisticated devices such as an RF signal analyzer with a very thick measurement software layer. There also is a trend of moving the measurement algorithm into field programmable gate array (FPGA) to improve speed. You may notice that the controller is a computer shared by the ATP and the measurement software for all modules; unlike a box-based ATS that has separate computing devices: one for the ATP and one for each instrument. Measurement software and hardware, which are in single in box instruments, now are separated into two physical places for PXI. Measurement software is in the controller. Hardware is in the module. As a result, the module is unable to perform as a fully-functional instrument unless combined with the measurement software resident in the controller. Since in most cases, the ATP and measurement software are running on the same controller, I/O hardware is no longer necessary. However I/O software is still needed. It is sandwiched either between the ATP and measurement software, or between the measurement software and measurement hardware, or both, depending on the vendor s software architecture. The I/O software enables communication between ATP, measurement software, and measurement hardware in order for them to work properly, and ensures all PXI resources are well managed. This change in connection between the ATP and instrument is the major difference between the programming interfaces of box and modular instruments, which will be discussed later in this application note.

7 07 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Application Development Environment and Programming Interface Types This section explains how the ATP, measurement hardware, and software operate together through a variety of programming interfaces. No matter how many programming interface types you might use, there are only two fundamental programming interface types for any programmable instrument: message-based SCPI or a direct-access driver. Message-based programming communicates through high-level, English-like commands sent by the computer to the instrument in a serial fashion. The most widely deployed command language is SCPI, which uses plain text for sending commands to instruments to set parameters or query results. Programming via a direct-access driver is completely different. The instrument is viewed as a set of registers in the controller s shared memory space. Reading from and writing to these memory addresses causes the instrument to execute desired functions. These are often complex operations that are composed of many memory reads and writes, and that often use bit-mapped registers and binary data. Due to this complexity, register-based instruments typically are delivered with a software driver that executes the instrument function. In addition to the direct register access to the instrument s hardware parameter settings, drivers may also directly access/call some software components for measurement features implemented purely by software, or the driver may be a piece of software code written for a specific measurement feature. Even if an instrument uses message-based SCPI as programming interface, it eventually needs to directly access the memory of hardware inside the instrument after the text commands are parsed. This happens inside the tester and is invisible to test engineers. As illustrated by Table 1, message-based SCPI and a direct access driver have their own strengths and weaknesses, and are suitable for different application scenarios. Table 1. Comparison of SCPI and a direct access driver Strength Weakness Message-based SCPI Most versatile. Works between any OS and programming environment Controller PC can be the same as Slower speed Text-based syntaxes are errorprone during ATP coding or different to computing device of instrument Being widely used and familiar by all ATP programmers Direct access driver Much faster in executing speed Sophisticate parameters coupling rule needs to be handled by a system developer Only works where the ATP and measurement software are in same PC Dependent on OS and programming environment

8 08 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Application Development Environment and Programming Interface Types (Continued) With few exceptions, box instruments use message-based SCPI as the primary programming interface, which allows an independent PC to control them easily. SCPI has been widely adopted by the test and measurement industry and is managed by the IVI Foundation. Direct access drivers are being used for most PXI instruments that are relatively simple, while SCPI is also used in PXI instruments, particularly sophisticated modular instruments like RF signal analyzers. SCPI also allows easier reuse of existing measurement science and code compatibility with box-based ATS. For example, the Keysight. M9290A CXA-m X-Series PXIe signal analyzer, is purely SCPI-based, and it can be programmed either with SCPI commands or drivers wrapped from SCPI commands. The Keysight M939xA vector signal analyzer uses a mix of SCPIs and direct access drivers. Though there are only two fundamental programming interface types provided by instruments, from an application development environment (ADE) point of view, there are many varieties of programming interfaces. These varieties are developed for each kind of ADE. For example, LabVIEW drivers for LabVIEW, IVI-COM and IVI-C drivers are defined and developed by IVI Foundation for better inter-exchangeability. Ultimately, they are wraps of SCPI or direct access driver programming interfaces previously mentioned. Each ADE has its natively-supported programming interface, which provides the best usability in that ADE. For compatibility consideration, many ADEs, for instance Visual Studio and LabVIEW, support multiple programming interfaces. Programming interfaces like SCPI, IVI-COM, and IVI-C drivers are supported by multiple ADEs. Table 2 shows the support matrix between ADEs and APIs. Table 2. Support matrix between ADEs and programming interfaces Programming interfaces O: Native support V : Support Application development environments Visual studio Lab Windows LabVIEW VEE MATLAB... SCPI O O V V V IVI-COM driver O V V V V IVI-C driver V O V V LabVIEW driver O VEE panel driver O MATLAB driver O...

9 09 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Application Development Environment and Programming Interface Types (Continued) The term driver is so widely used that when you talk about drivers, it may not necessarily be in reference to a registered-access driver. Driver can also refer to wraps of SCPIs. Some of the most popular programming interfaces can be transferred between each other. For example, SCPI can be wrapped into an IVI-COM driver or LabVIEW driver, and IVI-COM or IVI-C can be wrapped into a LabVIEW driver. Figure 3 shows an example of how SCPI and a register-access driver are wrapped into an IVI-COM, IVI-C, and LabVIEW drivers. All of the drivers work under LabVIEW though there are differences in usability. In addition to the widely-used programming interfaces mentioned above, new programming approaches are emerging in the test and measurement industry that have yet to be standardized. Since the measurement software and ATP reside in same computer, it is technically possible for the measurement software and ATP software to interact with each other through ways commonly used in the software programming industry; like calling DLLs of COM components, or.net API, or controls. However, such approaches still rely on specific vendors, and there is no common method for programming between two types of measurement software that is defined by the test and measurement industry. On the other hand, SCPI or IVI drivers are defined by VISA Foundation and these standards for drivers are used by all test and measurement vendors. This application note only covers the programming approaches defined by test and measurement industry; not the alternative programming approaches adopted in software industry, though they might be more flexible and efficient. LabVIEW ADE LabVIEW driver LabVIEW driver IVI-COM driver IVI-C driver Programming interfaces SCPI Register Message based commands access Measurement hardware and software Register access Modular instruments Figure 3. An example of how a programming interface is supported by LabVIEW and how the interface can be converted to different types of interfaces

10 10 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Tips for Building PXIe-based ATSs With an understanding of the structural difference between box-based, rack-and-stack ATSs and PXI-based ATSs, and the variety programming interfaces, the question is, Which programming interface shall I select? The following are tips and questions to think about before you start integrating your system. 1. Which should you choose: SCPI or a direct access driver? To help you decide, the most important question to consider is, Are you mainly pursuing measurement features or highest throughput? You may desire both of them, but which one is more critical? If you are pursuing extremely high throughput, a direct-access driver is your ideal solution. While if ready-to-use features is more critical than speed, you may be better served by an SCPI-based approach due to it long-established rich and mature measurement science. In some cases, you may want to adopt them in mix. 2. Do you just want to build the ATS, with ready-to-use features from instrument vendors, or do you need to develop some proprietary measurement algorithms? SCPI-based instruments are more closed than direct-access-based modular instruments when dealing with proprietary algorithms. That typically makes direct-access-based modules a better choice. If proprietary algorithms are not need, you may find an SCPI-based module is easier to use. 3. Is code compatibility to box instruments desired? Code compatibility is a key benefit for test system programmers if they are building an ATS evolved from old test systems. This is typically the case for production ATSs or military device test systems. 4. Which ADEs should be used? Each ADE has its own strength and weakness. Familiarity with one ADE may make it your preferred choice, but matching the ADE s strength and weakness to your own applications and modular instrument s interfaces is more important. A wise procedure is to address the above three questions first, then use that information to select the best-suited ADE. Choosing the ADE first will likely cause difficulties when selecting instruments and require greater effort when developing custom algorithms. In a real world, you might be forced to use a mixed-box instrument and modular instruments to build an ATS, and/or use mixed programming approaches. For example, you may use IVI drivers based on direct register access for fastest speed, and use SCPI or SCPI-based drivers for existing measurement features provided by vendor. In some cases, which you should try best to avoid, you may be forced to build your own drivers or proprietary measurement algorithm to handle desired measurement capabilities which are not provided by vendors.

11 11 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Conclusion Keysight provides both box instruments and PXI instruments. Decades of experience, accumulated insights in test and measurement, rich measurement science and features, and practical programming interfaces, are shared among these two form factors. As a result, working with Keysight can help you minimize the challenges and difficulties of migrate ATS from box based to PXI-based.

12 12 Keysight Understanding the Programming Interfaces of PXI Instruments - Application Note Evolving Since 1939 Our unique combination of hardware, software, services, and people can help you reach your next breakthrough. We are unlocking the future of technology. From Hewlett-Packard to Agilent to Keysight. For more information on Keysight Technologies products, applications or services, please contact your local Keysight office. The complete list is available at: Americas Canada (877) Brazil Mexico United States (800) mykeysight A personalized view into the information most relevant to you. Register your products to get up-to-date product information and find warranty information. Keysight Services Keysight Services can help from acquisition to renewal across your instrument s lifecycle. Our comprehensive service offerings onestop calibration, repair, asset management, technology refresh, consulting, training and more helps you improve product quality and lower costs. Keysight Assurance Plans Up to ten years of protection and no budgetary surprises to ensure your instruments are operating to specification, so you can rely on accurate measurements. Keysight Channel Partners Get the best of both worlds: Keysight s measurement expertise and product breadth, combined with channel partner convenience. Asia Pacific Australia China Hong Kong India Japan 0120 (421) 345 Korea Malaysia Singapore Taiwan Other AP Countries (65) Europe & Middle East Austria Belgium Finland France Germany Ireland Israel Italy Luxembourg Netherlands Russia Spain Sweden Switzerland Opt. 1 (DE) Opt. 2 (FR) Opt. 3 (IT) United Kingdom For other unlisted countries: (BP ) DEKRA Certified ISO9001 Quality Management System Keysight Technologies, Inc. DEKRA Certified ISO 9001:2015 Quality Management System This information is subject to change without notice. Keysight Technologies, 2017 Published in USA, December 1, EN