Presentazione GPIB - PXI - VXI - Parte I

1
Instrument 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 andpopular buses for controlling
instruments: GPIB, VXI, and PXI.
National Instruments Corporation Instrument Control The Future of GPIB, VXI and PXI
2
Seminar 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
3
Evolution 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 sincethe introduction of GPIB.
4
Vision PXI Distributed I/O PLCs
GPIB/Serial
and VXI
Modular
Instrumentation
System Management Software
Test Management, Data Management
Data Acquisition
and Signal
Conditioning
Measurement and Control Services
LabVIEW
Measurement
Studio
Other
Software
Motion
LabWindows
TM
/CVI
TM
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 toall 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 software
framework 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.
5
User Test Application Program
Instrument Drivers
Measurement Hardware
C
o
n
f
i
g
u
r
a
t
i
o
n

a
n
d

D
e
b
u
g
g
i
n
g

T
o
o
l
s
Driver Engines and APIs
Instrument Control Buses
Platformfor Instrument Control
Although this integrated software platform provides a vehicle toincorporate 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 theseminar to help you visualize
those pieces.
6
Measurement Hardware
We begin by discussing the hardware layer, specifically the instrument control buses.
7
Types 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.
8
Origins 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 regardlessof 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.
9
GPIB 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 1992 1975
H
P

d
e
s
i
g
n
s

H
P
-
I
B
H
P
-
I
B

b
e
c
o
m
e
s

I
E
E
E

4
8
8
I
E
E
E

4
8
8
.
2

A
d
o
p
t
e
d
,

I
E
E
E

4
8
8

b
e
c
o
m
e
s

I
E
E
E

4
8
8
.
1
S
C
P
I

i
n
t
r
o
d
u
c
e
d
I
E
E
E

4
8
8
.
2

r
e
v
i
s
e
d
H
S
4
8
8

i
n

a
p
p
r
o
v
a
l
p
r
o
c
e
s
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
DIO5
DIO6
DIO7
DIO8
REN
GND (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
DIO1
DIO2
DIO3
DIO4
EOI
DAV
NRFD
NDAC
IFC
SRQ
ATN
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 asASCII 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 on
If 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 InstrumentsGPIB Web site at
ni . com/ gpi b.
13
GPIB SystemConfigurations
LinearConfiguration StarConfiguration
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 Accepted
Each 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 Drivers
C
o
n
f
i
g
u
r
a
t
i
o
n

a
n
d

D
e
b
u
g
g
i
n
g

T
o
o
l
s
GPIB (NI-488.2)
Configuration and debugging tools
VISA and instrument drivers
We now discuss GPIB instrument control software. This discussionis 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 thebus
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 serviceusing 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 (<25% of instruments)
Message parsing slows system throughput
GPIB Polling
Allows instruments to request service
Adds efficiency to GPIB programming
GPIB communication is a message-based system that is easy to conceptualize. However, because
different instruments can and do speak different languages, instrument control programming using
this method is cumbersome. Standard Commands for Programmable Instrumentation (SCPI),
which will be further discussed later, was an attempt at standardizing the commands that
instruments of the same class respond to. SCPI is somewhat successful. About half of all new
GPIB instruments are SCPI compliant. However, because of the huge installed base of GPIB
instruments, less than a quarter of all instruments are SCPI compliant.
GPIB instruments use polling to add efficiency to GPIB programming. When an instrument
requests service by asserting the SRQ line the controller has noway of knowing which of the
instruments on the bus needs the service. In the classroom example discussed earlier, this is
equivalent to the teacher being blindfolded and having to find out which student raised his hand.
In serial polling, the controller asks each instrument for its status byte and checks the sixth bit to
determine if the instrument has requested service. The rules of IEEE 488.1 require the instrument
that requested service to have the sixth bit of their status byte be equal to one.
19
MultiplatformNI-488.2 Software Compatibility
Windows
2000/NT/XP/Me/9x/3.1
DOS
Solaris
Digital UNIX
HP-UX
Mac OS
Mac OS X
PCs
LabVIEWReal-Time
Embedded
Macintosh Workstations
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 embeddedapplications through the
LabVIEWReal-Time environment.
20
VISA
Virtual Instrument Software Architecture (VISA)
Standard for more than 10 years
Created by VXIplug&playSystems 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 VI SA Wr i t e 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
vi OpenDef aul t RM ( &r sr c) ;
vi Open ( r sr c, GPI B: : 1: : I NSTR, 0, 0, &i o) ;
vi Wr i t e ( i o, *I DN?\ n, 6, &count ) ;
vi Read ( i o, buf , 1024, &count ) ;
vi Cl ose ( r sr c) ;
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 showsa graphical representation of a
VISA communication in the National Instruments LabVIEWgraphical development environment.
LabVIEWwill be discussed in more detail later in the seminar. The VI SA Wr i t e block writes the
data buffer specified to the instrument indicated by the VISA session or resource name. Then, the
VI SA 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 discussLabWindows/CVI
later. The program has the same functionality but includes session management functions handled
automatically in LabVIEWsuch as VI SA Open and VI SA Cl ose.
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 GPI B: : 1: : I NSTR. If the descriptor were changed to
TCPI P: : 10. 10. 10. 10: : myi nst : : I NSTR, 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)
Instrument
Driver
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 significantlyreduce 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
I
E
E
E

4
8
8
.
2
1990
S
C
P
I
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 LabVIEWand
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&playdriver model
Incorporate advanced features like
interchangeability, simulation, and
state-caching
Provide high quality drivers
1987 1990 1993
I
E
E
E

4
8
8
.
2
S
C
P
I
V
X
I
p
l
u
g
&
p
l
a
y

S
y
s
t
e
m
s
A
l
l
i
a
n
c
e
1998
I
V
I

F
o
u
n
d
a
t
i
o
n
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&playSystems Alliance
Such a standard was defined by the Interchangeable Virtual Instruments (IVI) Foundation. The
IVI Foundation is comprised of user companies such as Boeing andNorthrop 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 Marchof 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 Drivers IVI Instrument Specific Layer and Drivers
IVI Generic Class Layer and Drivers IVI Generic Class Layer and Drivers
User Test Application Program
C
o
n
f
i
g
u
r
a
t
i
o
n

a
n
d

D
e
b
u
g
g
i
n
g

T
o
o
l
s
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/ i dnet is your source for the most
comprehensive collection of instrument drivers available anywhere. IDNet has LabVIEWand
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 morethan 2,200 instrument models
from upwards of 150 vendors.

Presentazione GPIB - PXI - VXI - Parte I

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Presentazione GPIB - PXI - VXI - Parte I

Uploaded by

Copyright:

Available Formats

1

You might also like