presentazione gpib- pxi- vxi -parte i

1Instrument Control The Future of GPIB, VXI, and PXI

Welcome to our seminar on instrument control, where we will discuss the state of instrument control technology and the future of some of the most common and popular buses for controlling instruments: GPIB, VXI, and PXI.

National Instruments Corporation Instrument Control The Future of GPIB, VXI and PXI

2Seminar Agenda

Evolution of instrument control GPIB bus

History Technical overview Software architecture

Other instrument control buses Stand-alone buses: Serial, Ethernet, USB, and IEEE 1394 Modular buses: PCI, VXI, and PXI

Application development environments

In the seminar we will present the following topics:1. A brief overview of the evolution of instrument control technology.2. The overview leads into a more detailed tutorial on the GPIB bus. In this section, we discuss

the history of GPIB, present a technical overview of the bus, and discuss the software architecture that makes it a robust and easy bus to use for instrument control.

3. We then discuss other instrument control buses. Fundamentally, this discussion splits into two groups of buses: Stand-alone buses similar to GPIB which include Serial (or RS-232), Ethernet, USB, and

IEEE 1394 (or FireWire) Modular buses which include the PCI bus, the VXI bus, and the PXI bus

4. Finally, we discuss application development environments (ADEs) offered by National Instruments that integrate seamlessly with our instrument control products and make your application development task even easier.

Instrument Control The Future of GPIB, VXI and PXI ni.com

3Evolution of Instrument Control Hardware

GPIB

PC DAQ

PXI

VXI

ENET/USB

1975

1988

1997

1987

1995

Prior to 1975, developing automated test systems required significant effort because of a lack of established standards for interfacing to stand-alone instrumentation.GPIB, or IEEE 488, provided a common software and hardware framework for connecting instruments to computers, and significantly decreased the development effort required to create an automated test system. More than 25 years later, GPIB is still the most popular way to automate stand-alone instruments.VXI, introduced in 1987, provided the first industry-standard modular hardware for the test industry. Because VXI targeted mainly high-cost applications, we introduced plug-in instrumentation in 1988 to address the large number of users that required a test system tightly integrated with a standard PC at a low cost.In the mid-1990s, the industry began considering standard computer buses such as Ethernet and USB as possible alternatives for instrument control. Although these buses offered some advantages, they have yet to gain widespread acceptance in the industry.Because of its high cost and lack of an integrated software and driver framework, VXI never achieved broad market acceptance. To overcome these challenges and to provide an ideal platform between PC-based plug-ins and VXI, PXI was introduced in 1997. PXI leveraged the driver model of PC systems to provide a high level of productivity to test system designers. Today, PXI is the fastest growing instrumentation platform since the introduction of GPIB.


4VisionPXI Distributed I/O PLCsGPIB/Serial and VXI

Modular Instrumentation

System Management SoftwareTest Management, Data Management

Data Acquisition and Signal

Conditioning

Measurement and Control Services

LabVIEW MeasurementStudioOther

Software

Motion

LabWindowsTM/CVITM

Integrated Software Framework

The challenges that system developers face today lead to the need for an integrated software framework. This framework must decrease the complexities of integrating multiple measurement devices into a single system by providing standard interfaces to all I/O devices. Additionally, the framework must also provide development tools to rapidly configure, build, deploy, maintain, and modify high-performance, low-cost measurement and control solutions. This integrated softwareframework must provide seamless connectivity to the ever-evolving enterprise management systems on which an organization standardizes. It is through this framework that an organization delivers products to market faster, achieves greater product quality, and lowers development and production costs.An integrated measurement and automation software framework delivers a modular, yet integrated structure for building high-performance, automated measurement and control systems. For maximum performance, ease of development, and system-level coordination, the components of the framework must remain independent, yet tightly integrated. This structure empowers developers to rapidly build measurement systems and easily modify them as the system requirements change. A key benefit of this integrated software framework is that organizations become more competitive because they can design and test higher quality products and deliver them to market faster and more cost effectively than ever before.


5User Test Application Program

Instrument Drivers

Measurement Hardware

Conf

igur

atio

n an

d De

bugg

ing

Tool

s

Driver Engines and APIs

Instrument Control Buses

Platform for Instrument Control

Although this integrated software platform provides a vehicle to incorporate devices ranging from instrument control, data acquisition, and motion control to image acquisition, distributed I/O and control of PLCs, in this seminar we focus on the platform for instrument control applications.The diagram above shows the interaction among the different layers in the architecture. The bottommost layer, the hardware layer, is composed of measurement hardware connected to a computer via an instrument control bus. This hardware is controlled from the PC directly through a device driver engine and application programming interface (API) or indirectly through an instrument driver. Both of these layers interact with configuration and debugging tools that help users develop their instrument control application. Finally, these software layers combine in the users test application program, which could be a simple application or a complex test management system.The remainder of this seminar examines the different pieces of this platform as they relate to instrument control. We will use the diagram above throughout the seminar to help you visualize those pieces.


6Instrument Control Buses

Measurement Hardware

Instrument Control Buses

We begin by discussing the hardware layer, specifically the instrument control buses.


7Types of Instrument Control Buses

Stand-Alone

GPIB

Serial

Ethernet

USB

IEEE 1394

Modular

PCI

VXI

PXI

We can separate instrument control buses into two fundamental groups: You can use stand-alone buses to communicate with rack and stack instruments. The most

common example of a stand-alone bus is GPIB. Other examples include Serial (RS-232), Ethernet, USB, and IEEE 1394.

Modular buses incorporate the interface bus into the instrument itself. Examples of modular buses are PCI, VXI and PXI.

We first discuss the GPIB bus and provide a historical background, technical overview, and software architecture overview.


8Origins of GPIB

Originally designed by Hewlett-Packard in 1965 Interface for HP controllers & instruments

National Instruments formed in 1976 Offered interfaces to industry standard computers

DEC, IBM, etc. Offered alternatives to HP Basic

LabVIEW, LabWindows

The General Purpose Interface Bus (GPIB) was originally developed by Hewlett-Packard (where it was called the HP-IB or Hewlett-Packard Interface Bus) in the late 1960s to connect and control their programmable instruments through their controllers. With the introduction of digital controllers and programmable test equipment, the need arose for a standard, high-speed interface for communication between instruments and controllers regardless of vendor. The GPIB soon became the clear choice.The first product from National Instruments was a GPIB interface. Throughout its history, NI has offered GPIB interfaces to industry standard computers such as DEC and IBM computers. In addition, NI also offered programming alternatives to HP Basic, the prevailing standard in the early years of GPIB. These programming alternatives included LabVIEW and LabWindows.


9GPIB Standardization History IEEE 488.1 1975

Standardized the physical, electrical, and mechanical features of GPIB IEEE 488.2 1987

Standardized software for controllers to interface with instruments Standard Commands for Programmable Instrumentation (SCPI) 1990 HS488 (Undergoing IEEE standardization)

High-speed GPIB (8 MB/s)

1965 1987 1990 19921975

HP de

signs

HP-IB

HP-IB

becom

es

IEEE 4

88 IEEE 4

88.2

Adop

ted, IE

EE 48

8

becom

es IEE

E 488.

1

SCPI

introd

uced

IEEE 4

88.2 r

evised

HS488

in app

roval

proces

s

2003

In 1975, the IEEE Standard Digital Interface for Programmable Instrumentation (ANSI/IEEE Standard 488-1975 ) was released. IEEE 488 contained the electrical, mechanical, and functional specifications of an interfacing system.Because the original IEEE 488 document did not contain guidelines for preferred syntax and format conventions, the supplemental standard IEEE 488.2, Codes, Formats, Protocols, and Common Commands was released for use with IEEE 488 (renamed IEEE 488.1). IEEE 488.2 builds on IEEE 488.1 by defining a minimum set of device interface capabilities, a common set of data codes and formats, a device message protocol, a generic set of commonly needed device commands, and a new status reporting model.In 1990, the IEEE 488.2 specification added the Standard Commands for Programmable Instrumentation (SCPI) document. SCPI defines specific commands that each instrument class must obey. Thus, SCPI attempts to guarantee complete system compatibility and configurability among these instruments. You no longer need to learn a different command set for each instrument in an SCPI-compliant system, and you can easily replace an instrument from one vendor with an instrument from another. The drawback is that not many instruments are SCPI compliant.National Instruments has proposed a high-speed extension of the IEEE 488.1 standard that defines a handshaking method that increases the bus performance by almost 10x. This standard is currently undergoing IEEE standardization.


10

GPIB Longevity

Extremely large install base: 510 million GPIB instruments An agreed upon standard that has survived 30 years Robust and reliable

Handshaking, shielded connectors, error handling, etc. Faster than other buses for most of its life

Relatively fast at 1.5 MB/s (IEEE 488.1) Very competitive at 8 MB/s (HS488)

Easy for users to use and for vendors to implement

The GPIB bus is still extremely popular today, almost 30 years after its creation. There are many reasons for this longevity, the most important of which may be the extremely large installed base of GPIB instruments (510 million instruments in use). It is an agreed upon industry standard that unifies the method for controlling instruments from multiple vendors.The GPIB bus is also robust and reliable. Its defined handshaking mechanism, shielded and rugged industrialized connectors, and error handling mechanisms all ensure data integrity. The GPIB bus has been faster than other buses for most of its life. It is still relatively fast at the 1.5 Mbytes/s transfer rate defined by IEEE 488.1 and is very competitive at the 8 Mbytes/s transfer rate proposed by HS488.Finally, the longevity of GPIB can be attributed to its simplicity. You can easily learn to use the bus, and vendors can easily implement instruments based on it.


11

GPIB Technical Overview

Hardware specifications Software specifications

Now that we have seen a GPIB instrument control application, lets look at a technical overview of the GPIB bus. We first discuss the bus hardware specifications and then we present the software architecture of a National Instruments GPIB system.


12

GPIB Electrical Specifications Defined by IEEE 488.1 24 Lines Cable specifications

Max cable length between devices = 4 m (2 m average)

Max total cable length = 20 m Max number of devices =

15 (min 2/3 powered on) Bus speed

1.5 MB/s with IEEE 488.1 8 MB/s with HS488

DIO5DIO6DIO7DIO8RENGND (TW PAR W/DAV)GND (TW PAIR W/NRFD)GND (TW PAIR W/NDAC)GND (TW PAIR W/IFC)GND (TW PAIR W/SRQ)GND (TW PAIR W/ATN)SIGNAL GROUND

DIO1DIO2DIO3DIO4EOI

DAVNRFDNDAC

IFCSRQATN

SHIELD

1

12

13

24

GPIB is a digital, 24-conductor parallel bus. It consists of eight data lines (DIO 1-8), five bus management lines (EOI, IFC, SRQ, ATN, REN), three handshake lines (DAV, NRFD, NDAC), and eight ground lines. The GPIB uses an eight-bit parallel, byte-serial, asynchronous data transfer scheme. This means that whole bytes are sequentially handshaked across the bus at a speed that the slowest participant in the transfer determines. Because the unit of data on the GPIB is a byte (eight bits), the messages transferred are frequently encoded as ASCII character strings.Additional electrical specifications allow data to be transferred across the GPIB at the maximum rate of 1.5 MB/sec because the GPIB is a transmission line system. These specifications are: A maximum separation of 4 m between any two devices and an average separation of

2 m over the entire bus A maximum cable length of 20 m A maximum of 15 devices connected to each bus, including the system controller with at least

two-thirds of the devices powered onIf you exceed any of these limits, you can use additional hardware to extend the bus cable lengths or expand the number of devices allowed.Note: For more information about GPIB, visit the National Instruments GPIB Web site at ni.com/gpib.


13

GPIB System Configurations

Linear ConfigurationStar Configuration

A GPIB hardware setup consists of two or more GPIB devices (instruments and/or interface boards) with a GPIB cable connecting them. The cable assembly that connects devices consists of a shielded 24-conductor cable with a plug and a receptacle (male/female) connector at each end. With this design, you can link devices in a linear configuration, a star configuration, or a combination of the two.In the star configuration, multiple devices are all connected from one device. The dual-sided connector makes this type of connection possible. In the linear configuration, the devices are daisy-chained with cables going from one device to the next. Neither of the two configurations offers inherent advantages over the other. Your specific needs determine how you connect your instruments.


14

Overcoming GPIB Specification Limits

Hybrid systems Use GPIB bridges: for example, GPIB-ENET/100 (GPIB to

Ethernet converter) for distributed instrument control Use instruments with other native bus connectivity options

GPIB bus devices GPIB bus expanders connect more than 14 instruments GPIB bus extenders extend GPIB system cable lengths

As mentioned earlier, you can overcome the GPIB system limitations and maintain the performance of your GPIB system. One way to overcome these limitations is to use GPIB bridges. These bridges offer a mechanism to translate between GPIB communication and Ethernet communication for example. Using this, you can distribute your measurement application over much longer distances.You also can use GPIB bus devices such as expanders and extenders. With expanders, you can connect up to double the number of instruments (28) to a GPIB system and using extenders you can overcome the cable length limitation. With fiber optic extenders, you can extend the total cable distance in your GPIB system to more than 1 km.


15

HS488 Technical Details IEEE 488.1

Uses DAV, NRFD, and NDAC command lines for handshaking

Extra delays introduced by talker and listener monitoring two extra lines

HS488 Uses only DAV line for handshaking Listener only monitors DAV line, talker

asserts it when data is available

The IEEE 488.1 standard originally defined a three-wire handshaking mechanism. This was done because many devices on the system could not communicate fast enough over the bus, and this was a method to ensure extra redundancy and that the data was received. The talker and the listener used the three handshaking lines: DAVData Valid NRFDNot Ready for Data NDACNot Data AcceptedEach device would monitor two lines and assert the third when it was ready to send or receive data.With the HS488 handshaking scheme, it is assumed that modern devices can parse and send data quickly enough so that both devices can monitor one line, the DAV or data valid line, and send and receive data based on the electrical state of that line. To ensure backward compatibility, HS488 devices use a standard initial communication pattern over this line to determine whether the other device is also an HS488 capable device. If it is not, they revert back to the standard IEEE 488.1 handshaking scheme.


16

GPIB Instrument Control Software

Instrument DriversCo

nfig

urat

ion

and

Debu

ggin

g To

ols

Driver Engines and APIs

GPIB (NI-488.2)Configuration and debugging toolsVISA and instrument drivers

We now discuss GPIB instrument control software. This discussion is broken down into three sections: The NI-488.2 driver software and API GPIB configuration and debugging tools Instrument drivers and the VISA I/O library


17

GPIB Communication

Similar to a well run classroom GPIB card (controller-in-charge)

Teacher Instruments (talker/listener)

Students Service Requests (SRQ)

Students raising hands Messages (communication)

Talking between student and teacher Talking between student and student (rare)

Before we discuss GPIB software, we first explore how GPIB communication occurs. You can think of GPIB communication as similar to a well run classroom. The GPIB card, also known as the controller-in-charge, is equivalent to the teacher. The GPIB card controls the bus communication and instructs devices on the bus when to send and receive messages.Instruments on the GPIB bus are the equivalent of the students in the classroom. They need the permission of the controller to send and receive messages. Instruments on the bus generally are referred to as talker/listeners. The instruments request service using the SRQ line on the GPIB bus, which is similar to students raising their hands.Finally, messages on the GPIB bus are how communication occurs on the bus. Messages are generally sent between the controller and instruments (students and teachers) and very rarely between the instruments themselves (student to student).


18

GPIB Communication

Message-Based System Easy to conceptualize Different boxes different languages

SCPI: attempt at industry standardization (

19

Multiplatform NI-488.2 Software Compatibility

Windows2000/NT/XP/Me/9x/3.1

DOS

SolarisDigital UNIX

HP-UXMac OS

Mac OS X

PCs

LabVIEW Real-Time

Embedded

MacintoshWorkstations

The cornerstone of the National Instruments GPIB strategy is to provide software compatibility unmatched in the industry today. We support multiple platforms and have maintained the same software API for more than a decade, protecting our customers software development investment.National Instruments continues to leverage new operating system technology to provide solutions when our customers expect them. We currently offer our NI-488.2 driver software solutions for all Windows operating systems, Mac OS, Sun Solaris, and embedded applications through the LabVIEW Real-Time environment.


20

VISA

Virtual Instrument Software Architecture (VISA) Standard for more than 10 years Created by VXIplug&play Systems Alliance Controls GPIB, VXI, PXI, serial, and Ethernet

instruments with the same API USB to be added to standard

In the early 1990s, different commercial implementations of I/O software existed not only for GPIB but also for VXI and serial interfaces. These I/O software products were neither standardized nor interoperable.As a step toward industry-wide software compatibility, the VXIplug&play Systems Alliance was founded in 1993, with one of its goals to define one specification for I/O software, Virtual Instrument Software Architecture (VISA).The VISA specification defines a next-generation I/O software standard that has been expanded for use with GPIB, VXI, PXI, serial, and Ethernet interfaces. For example, after identifying which type of instrumentation platform to use, the function VISA Write would work for either a GPIB, serial, Ethernet, PXI, or VXI device. In addition to these interfaces, VISA is currently being updated to support communication with USB interfaces.


21

Sample VISA Programs

viOpenDefaultRM (&rsrc);viOpen (rsrc, GPIB::1::INSTR, 0, 0, &io);viWrite (io, *IDN?\n, 6, &count);viRead (io, buf, 1024, &count);viClose (rsrc);

LabVIEW

LabWindows/CVI

There are two sample VISA programs shown above. Both examples use NI-VISA, the National Instruments implementation of the VISA standard. The first shows a graphical representation of a VISA communication in the National Instruments LabVIEW graphical development environment. LabVIEW will be discussed in more detail later in the seminar. The VISA Write block writes the data buffer specified to the instrument indicated by the VISA session or resource name. Then, the VISA Read function reads back 100 bytes from the instrument.The second example uses NI-VISA in National Instruments LabWindows/CVI, a development environment built on the ANSI C programming language. We will discuss LabWindows/CVI later. The program has the same functionality but includes session management functions handled automatically in LabVIEW such as VISA Open and VISA Close.Notice that both examples include a VISA session resource descriptor. This descriptor specifies the type of device that is being used for the communication. This example refers to a GPIB instrument at address 1 with the descriptor GPIB::1::INSTR. If the descriptor were changed to TCPIP::10.10.10.10::myinst::INSTR, the same programs could have been used with an instrument connected via an Ethernet interface.


22

Instrument Drivers

Set of software routines to control a programmable instrument

Simplify instrument control Reduce user development time

Eliminates need to learn new programming protocol

Common architecture and interface

Application Development

Environment (ADE)

Instrument

Instrument Commands(*idn?, meas?)

Bus Communication Protocol(configure, read, write, trigger)

InstrumentDriver

Although VISA simplifies instrument control programming significantly, it still requires low-level knowledge of instrument communication and of instrument command sets. As an improvement, instrument and software vendors began writing instrument drivers. Instrument drivers are a set of high-level software routines to control a programmable instrument. For example, instead of sending four commands to an oscilloscope to set it up to perform an acquisition, an instrument driver would have one function call that configures the scope.Instrument drivers simplify instrument control and significantly reduce the amount of time required to develop an instrument control application. Not only do instrument drivers eliminate the need for the user to learn new command sets for each instrument, but they also provide a common architecture and interface to the user.


23

Instrument Drivers

Intuitive high-level functions Instrument addressing Command string building Range checking Memory storage Data scaling Response string parsing

Easy to use

Instrument drivers generally contain high-level functions that not only perform configuration and measurement functionality, but also handle details such as instrument addressing, command string building, range checking, memory storage, data scaling, and response string parsing.Instrument drivers are very easy to use since they generally provide you with native functions for whichever development environment you are using. You use instrument drivers just like you would any other library in your programs.


24

Instrument Drivers: Benefits

Drivers simplify test development Replace instrument command programming High-level API isolates the instrument I/O Focus on ease-of-programming

Drivers decrease learning curve Different instruments, common structure

Instrument drivers simplify test development by replacing the need for low-level instrument command programming and providing a high-level API that isolates you from the I/O. This lets you concentrate on developing the rest of your application, thereby making your programming task easier.Because instrument drivers provide a common and consistent structure, they decrease the learning curve when going from one instrument to the next.


25

History and Evolution of Instrument Drivers IEEE 488.2

Defines commands for identification, self test, and so on

No standard commands beyond these

SCPI Groups instrument functionality in

attribute groups Defines language for setting and

retrieving attributes Focused on message-based

instruments

1987

IEEE 4

88.2

1990

SCPI

LV & CVI Plug&Play Instrument Drivers

Standards for instrument drivers have evolved over the years, with each standard building on the previous one. While all of these standards have evolved, National Instruments LabVIEW and LabWindows/CVI plug & play drivers have provided consistent instrument control for more than 15 years.IEEE 488.2Created in 1987, this standard defines a set of commands for instruments to perform such common tasks as identification, self test and so on. The standard also defines the method for communication across the bus but does not define any commands for performing measurement tasks.SCPICreated in 1990, the Standard Commands for Programmable Instrumentation or SCPI was the first standard to group instruments into different classes and group instrument functionality into attribute groups. The standard defines the language for setting and retrieving instrument attributes and the commands for performing common instrument tasks. SCPI is focused on message-based instrument communication.


26

History and Evolution of Instrument Drivers VXIplug&play

Focused on vendor interoperability A few standard functions Source code Users requested interchangeability

Driver standard was needed to: Build on VXIplug&play driver model Incorporate advanced features like

interchangeability, simulation, and state-caching

Provide high quality drivers

1987 1990 1993

IEEE 4

88.2

SCPI

VXIplu

g&play

System

s

Allianc

e

1998

IVI Fou

ndation

LV & CVI Plug&Play Instrument Drivers

VXIplug&playDefined to focus on multi-vendor interoperability and defines a set of common and standard functions that all instruments had to support. It also specifies that drivers be provided in source code so that users could modify them.A driver standard was still needed, though, that provided for instrument interchangeability and other advanced functionality such as simulation and state-caching. The IVI Foundation defines such a standard.


27

IVI: Interchangeable Virtual Instruments

IVI Foundation is an open consortium of Users: Boeing, Northrop Grumman Integrators: BAE Systems Vendors: National Instruments, Agilent, Tektronix

Founded in August 1998, incorporated in March 2001 27 member companies Recently absorbed SCPI Consortium and

VXIplug&play Systems Alliance

Such a standard was defined by the Interchangeable Virtual Instruments (IVI) Foundation. The IVI Foundation is comprised of user companies such as Boeing and Northrop Grumman, integrators such as BAE Systems, and instrument and software vendors such as National Instruments, Agilent Technologies, and Tektronix.The IVI Foundation was founded in 1998 and incorporated in March of 2001 as a Delaware non-profit organization. It has an active membership of 27 companies, and it recently absorbed the SCPI Consortium and the VXIplug&play Systems Alliance unifying all standards for instrument control software under one roof.


28

IVI Foundation: Goals

Hardware interchangeability Maximize software reuse Preserve test software investment

Deliver consistent driver quality Software interoperability

Architecture to integrate software from multiple vendors Standard access to driver capabilities

The goals of the IVI Foundation are as follows:Hardware interchangeabilityAllow users to exchange instruments in their system with little or no software modifications, thereby maximizing software reuse and decreasing cost by preserving your investment in test software.Driver qualityDefine specifications for drivers that provide more consistent quality and robustness and provide the user with familiarity with the instrument driver standard.Software interoperabilityDefine an architecture to easily integrate software from multiple vendors and provide a consistent and standard method for access to driver capabilities.


29

IVI Architecture

IVI Instrument Specific Layer and DriversIVI Instrument Specific Layer and Drivers

IVI Generic Class Layer and DriversIVI Generic Class Layer and Drivers

User Test Application Program

Conf

igur

atio

n an

d De

bugg

ing

Tool

sDriver Engines and APIs

The IVI architecture splits into two layers: an instrument specific layer, which provides driver quality and consistency, and a class layer, which achieves instrument interchangeability.


30

Instrument Driver Network

ni.com/idnet LabVIEW plug & play,

LabWindows/CVI plug & play, and IVI

More than 2,200 instrument models from 150 vendors for LabVIEW, LabWindows/CVI and Measurement Studio

The instrument driver network (IDNet) at ni.com/idnet is your source for the most comprehensive collection of instrument drivers available anywhere. IDNet has LabVIEW and LabWindows/CVI plug & play drivers, as well as IVI drivers, to use with both of those environments as well as Measurement Studio for Visual Basic, Visual C++ and Visual Studio .NET.The instrument driver network offers instrument drivers for more than 2,200 instrument models from upwards of 150 vendors.


presentazione gpib- pxi- vxi -parte i

Documents