Delivering Interchangeability and More AUTOTESTCON 2012 Anaheim, CA September 10-13, 2012 Agenda IVI Basics and Background IVI Architecture IVI Shared Components Why IVI? IVI-COM, IVI.NET and IVI-C www.ivifoundation.org IVI Background Open consortium End-users System integrators Instrument and software vendors Founded in August 1998, incorporated in March 2001 26 member companies Consolidated home for many SW standards IVI Instrument Drivers VISA VXIplug&play SCPI LXI Synchronization www.ivifoundation.org What is IVI? The primary purpose of the Consortium is to • Promote the development and adoption of standard specifications for programming test instrument • Focus on the needs of the people that use and develop test systems who must take off-the-shelf instrument drivers and build and maintain highperformance test systems • Build on existing industry standards to deliver specifications that simplify interchanging instruments and provide for better performing and more easily maintainable programs From IVI Foundation By-laws www.ivifoundation.org IVI’s Fit with Other Specs IVI 4.x(Classes) Scope DMM FGen DCPwr ACPwr Swtch PwrMe SpecAn RFSigGn Counter DownCnv UpConv Digitiz Instrument Capabilities Programming Interfaces for C/C++/C#/VB LabVIEW, etc IVI 3.x (Arch) SCPI C COM VXI plug&play .NET VISA message register IO Interfaces & SW Protocols IVI 6.3 PXI plug-in HiSLIP PXI-2 and PXI-6: Software AXIe 2.0 VXI-11 GPIB LXI USB TMC GPIB Ethernet USB VXI VME PXI AXIe 1.0 PCI, PCIe & Compact PCI AXIe 3.1 T&M Specific Needs Physical Connection IVI’s Fit with Other Specs IVI 4.x(Classes) Scope DMM FGen DCPwr ACPwr Swtch PwrMe SpecAn RFSigGn Counter DownCnv UpConv Digitiz Instrument Capabilities Programming Interfaces for C/C++/C#/VB LabVIEW, etc IVI 3.x (Arch) SCPI C COM VXI plug&play .NET VISA message register IO Interfaces & SW Protocols IVI 6.3 PXI plug-in HiSLIP PXI-2 and PXI-6: Software AXIe 2.0 VXI-11 GPIB LXI USB TMC GPIB Ethernet USB VXI VME PXI AXIe 1.0 PCI, PCIe & Compact PCI AXIe 3.1 T&M Specific Needs Physical Connection What is IVI – Really?? 4.15Digitizer 4.14 UpConv 4.13DownCnv 4.12 Counter 4.10RFSigGn 4.8 SpecAn 4.7 PwrMe 4.6 Swtch 4.5 ACPwr 4.4 DCPwr 4.1 Scope 4.3 FGen Architecture specifications Instrument class specifications A library of shared software components 4.2 DMM Architecture Specifications 3.1,3.2,3.3,3.4,3.5,3.6,3.9,.3.10,3.12,3.17,3.18 www.ivifoundation.org 13 specs @ ~220 pages ~1140 pages of specs Goals of the IVI Foundation Hardware Interchangeability Simplify replacing an instrument from a system with a similar one Preserve test software when instruments become obsolete Simplify test code reuse from design validation to production test Quality Improve driver quality Establish guidelines for driver testing and verification Software Interchangeability Provide an architectural framework that allows users to easily integrate software from multiple vendors Provide standard access to driver capabilities such as simulation, state caching, range checking and coercion Provide consistent instrument control in popular programming environments www.ivifoundation.org IVI Membership Benefits Influence the development of standards Participate in and access future standards Share ideas with developers, users, system integrators and vendors Access source code for shared components Participate in interoperability sessions Network with test and measurement industry leaders www.ivifoundation.org Approved Instrument Classes DC power supply AC power supply DMM Function generator Oscilloscope Power meter RF signal generator Spectrum analyzer Switch Upconverter Downconverter Digitizer Counter/timer www.ivifoundation.org Driver Architecture Spec’s IVI-3.1: Driver Architecture Specification IVI-3.2: Inherent Capabilities Specification IVI-3.3: Standard Cross-Class Capabilities Specification IVI-3.4: API Style Guide IVI-3.5: IVI Configuration Server Specification IVI-3.6: COM Session Factory Specification IVI-3.9: C Shared Components IVI-3.12: Floating Point Services Specification IVI-3.14: Primary Interop Assembly Specification IVI-3.15: IviLxiSync Specification IVI-3.17: Installer Requirements Specification IVI-3.18: IVI.NET Utility Classes and Interfaces Specification www.ivifoundation.org IVI Driver Features Simulation State caching Range checking Coercion Required of all IVI drivers Very useful for testing in new ADEs Helpful when instruments are difficult to procure Coercion recording All extended features enabled and accessed in a standard fashion www.ivifoundation.org IVI Shared Components C Shared Components Floating Point Services IVI-COM Session Factory Configuration Server COM Type Libraries .NET PIAs IVI.NET Shared Components www.ivifoundation.org IVI Conformance Basic conformance Follows all architecture specs Implements inherent capabilities defined in IVI-3.2. Not one of the classic instrument types No class-compliant functionality (none of the IVI-4.X specs apply) Can be advertised as fully IVI compliant Instrument-class conformance Basic conformance + one or more instrument class APIs (IVI-4.X specs) www.ivifoundation.org What is IVI Compliant -Really?? Standard install location and process Support for IVI Features Common API for common tasks ~40 common functions Simulation, Caching, Open, Close, Initialize, SW Trigger, Status check, Version check ….. Consistent API Common types, Name generation, Organization www.ivifoundation.org What is IVI Class Compliant Really?? Adds Class Compliant API Instrument API same as other instruments Custom API still available Especially for capabilities beyond the class Simplifies swapping instruments IVIFoundation.org ww.ivifoundation.org Why IVI – One Driver to Rule them All Much more than interchangeability Arguably the biggest benefit is the ability to provide one driver and give users a first class experience in nearly all ADEs Visual Basic 6 Visual C++ Visual C# and Visual Basic.NET VBA (Excel, Word, PowerPoint) MATLAB LabVIEW LabWindows/CVI Agilent VEE www.ivifoundation.org Why IVI? – Uniform Way of Doing Common Tasks Avoids frustrations of arbitrary differences Instantiation, initialization, shutdown Controlling driver features – state caching, error query, simulation, etc. Configuration and installation Standard mechanism for handling multi-channel devices aka repeated capabilities in IVI parlance Standard error reporting No need to dig thru header files, registry settings, help or readme One place to reliably set the I/O address is a big benefit No need to deal with the numerous possible error schemes Versioning standards www.ivifoundation.org Why IVI – Tools, Tools, Tools Far easier to develop an IVI driver with a tool than it is to develop a customer driver without a tool Common requirements enable tools Leads to better, cheaper drivers Driver is much more than a DLL w/ function exports Help files Installer IVI 3-17 dedicated to IVI installers and is 53 pages Regression test apps / Unit test apps Special components for .NET XML IntelliSense file interop assembly version policy files www.ivifoundation.org Why IVI – Tracking the Standards Vendors relieved from onerous task of keeping pace with multiple moving targets Windows OSs, Windows help, Windows installer, Windows API, security, .NET platform Six versions of Visual Studio since IVI Vista and UAC was a major challenge for IVI 64-bit OS support took two years within IVI IVI member companies bring experts to meetings to ensure IVI solutions work with their hardware Users of IVI directly leverage R&D efforts of NI, Agilent, R&S, etc. www.ivifoundation.org API Standards in IVI IVI specifications layout three APIs IVI .NET IVI-COM IVI-C Many considerations for both driver developers and end users when choosing which technology to use Driver developer environment Custom environment Others…(more on this later) IVI specs also define how to build driver wrappers Allows one code base while supporting IVI-C, IVI-COM and IVI .NET APIs IVI-COM on top of IVI-C (not common) IVI-C on top of IVI-COM (very common in today’s IVI drivers) www.ivifoundation.org Simple IVI-COM Driver Usage in Visual Basic Dim driver as New Agilent54600 Dim scope as IIviScope Set scope = driver scope.Initialize “GPIB::10”, False, False, “” scope.Trigger.Level = 3.4 scope.Trigger.Type = IviScopeTriggerEdge ‘setting a numeric property ‘setting an enum property scope.Measurements.Initiate ‘calling a method scope.Close www.ivifoundation.org Simple IVI-C Driver Usage // NOTE: Error checking not shown #include “ag54600.h” int _tmain(int argc, _TCHAR* argv[]) { ViSession vi; ViStatus viStatus = ag54600_init(“GPIB::10”, VI_FALSE, VI_FALSE, &vi); viStatus = ag54600_SetAttributeViReal64(vi, “”, AG54600_ATTR_TRIGGER_LEVEL, 3.2); viStatus = ag54600_SetAttributeViInt32(vi, “”, AG54600_ATTR_TRIGGER_TYPE, AG54600_VAL_EDGE_TRIGGER); viStatus = ag54600_InitiateAcquisition(); viStatus = ag54600_close(); } www.ivifoundation.org Motivations for IVI.NET Present an API more suited to .NET developers Simplify source code Allow end users to understand instrument behavior by examining driver source Allow end users to fix bugs on their own Allow end users to add features to drivers on their own Richer, more expressive APIs More flexibility with API data types Clean handling of asynchronous notifications (aka “events”) Side-by-side deployment of drivers Only one version of an IVI-COM or IVI-C driver can be installed at a time IVI.NET allows multiple versions of a driver to be installed www.ivifoundation.org Richer Type System in IVI.NET Both IVI-COM and IVI-C drivers suffer from a limited set of data types Integers, floats, Booleans, strings Arrays of the above, but extra parameters are required in IVI-C IVI-C cannot expose an array of strings IVI-C cannot expose structs Can be done in IVI-COM, but it’s tedious to implement IviScope_FetchWaveform(ViSession vi, ViConstString channel, ViInt32 waveformSize, // # of elements on input ViReal64 waveform[], // actual data buffer ViInt32 *actualPoints, // # of elements on output ViReal64 *initialX, ViReal64 *xIncrement); www.ivifoundation.org Simplifying APIs with .NET Types IVI-C signature IviDigitizer_FetchWaveformReal64(ViSession Vi, ViConstString ChannelName, ViInt64 WaveformArraySize, ViReal64 WaveformArray[], ViInt64* ActualPoints, ViInt64* FirstValidPoint, ViReal64* InitialXOffset, ViReal64* InitialXTimeSeconds, ViReal64* InitialXTimeFraction, ViReal64* XIncrement); IVI.NET signature Channels[].Measurement.FetchWaveform(IWaveform<Double> waveform) www.ivifoundation.org Simplified Usage Syntax Simplified access to very commonly used features Enums Repeated capabilities (e.g. “channels”) C# client using IVI-COM driver through interop digitizer.Arm.Sources.get_Item("LAN3").Detection = IviLxiSyncArmSourceDectionEnum.IviLxiSyncArmSourceDetectionHigh; C# client using IVI.NET driver digitizer.Arm.Sources["LAN3“].Detection = ArmSourceDetection.High; www.ivifoundation.org Shared IVI.NET Data Types IVI Foundation felt it would be useful to offer commonly used data types as part of the IVI.NET Shared Components Increase consistency amongst IVI.NET drivers Facilitate data interchange between drivers Standardized IWaveform and ISpectrum interfaces Digitizers and scopes and RF spectrum analyzers all read waveforms Function generators and RF signal generators source waveforms Without a common definition of a “waveform”, client applications would need to write the tedious code to translate between each class’s notion of a waveform Time-based parameters can use PrecisionDateTime and PrecisionTimeSpan No confusion about ms vs sec, absolute vs relative time, UTC time, etc Precision adequate for IEEE 1588 devices Common trigger source data type Useful in “stitching” together devices in triggered source-measure operations www.ivifoundation.org Additional Information For more information or to join, go to our webpage at: www.ivifoundation.org Additional Resources: IVI Getting Started Guide on our Home page or Resources page Either in in short pdf files for the ADE that you prefer Or, single pdf file that includes eight different ADEs Tutorial Videos Coming Soon: IVI Getting Started Guide tutorial videos in the ADE you prefer. www.ivifoundation.org