1 / 29

Delivering Interchangeability and More AUTOTESTCON 2012 Anaheim, CA September 10-13, 2012

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. IVI Background. Open consortium End-users System integrators

philana-candice
Télécharger la présentation

Delivering Interchangeability and More AUTOTESTCON 2012 Anaheim, CA September 10-13, 2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Delivering Interchangeability and More AUTOTESTCON 2012 Anaheim, CA September 10-13, 2012

  2. Agenda IVI Basics and Background IVI Architecture IVI Shared Components Why IVI? IVI-COM, IVI.NET and IVI-C www.ivifoundation.org

  3. 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

  4. 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 high-performance test systems • Build on existing industry standards to deliver specifications that simplify interchanging instruments and provide for better performing and more easily maintainable programs www.ivifoundation.org From IVI Foundation By-laws

  5. IVI’s Fit with Other Specs IVI 4.x(Classes) SCPI Instrument Capabilities IVI 3.x (Arch) Scope DMM FGen DCPwr ACPwr Swtch PwrMe SpecAn RFSigGn Counter DownCnv UpConv Digitiz VISA C COM .NET Programming Interfaces for C/C++/C#/VB LabVIEW, etc message register VXI plug&play IO Interfaces & SW Protocols IVI 6.3 PXI plug-in PXI-2 and PXI-6: Software HiSLIP VXI-11 AXIe 2.0 AXIe 3.1 GPIB LXI USB TMC VXI PXI AXIe 1.0 T&M Specific Needs GPIB Ethernet USB VME PCI, PCIe & Compact PCI Physical Connection

  6. IVI’s Fit with Other Specs IVI 4.x(Classes) SCPI Instrument Capabilities IVI 3.x (Arch) Scope DMM FGen DCPwr ACPwr Swtch PwrMe SpecAn RFSigGn Counter DownCnv UpConv Digitiz VISA C COM .NET Programming Interfaces for C/C++/C#/VB LabVIEW, etc message register VXI plug&play IO Interfaces & SW Protocols IVI 6.3 PXI plug-in PXI-2 and PXI-6: Software HiSLIP VXI-11 AXIe 2.0 AXIe 3.1 GPIB LXI USB TMC VXI PXI AXIe 1.0 T&M Specific Needs GPIB Ethernet USB VME PCI, PCIe & Compact PCI Physical Connection

  7. What is IVI – Really?? 4.1 Scope 4.2 DMM 4.3 FGen 4.4 DCPwr 4.5 ACPwr 4.6 Swtch 4.7 PwrMe 4.8 SpecAn 4.10RFSigGn 4.12 Counter 4.13DownCnv 4.14 UpConv 4.15Digitizer 13 specs @ ~220 pages Architecture Specifications 3.1,3.2,3.3,3.4,3.5,3.6,3.9,.3.10,3.12,3.17,3.18 ~1140 pages of specs www.ivifoundation.org Architecture specifications Instrument class specifications A library of shared software components

  8. Goals of the IVI Foundation www.ivifoundation.org • 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

  9. 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

  10. 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

  11. 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

  12. IVI Driver Features • Simulation • Required of all IVI drivers • Very useful for testing in new ADEs • Helpful when instruments are difficult to procure • State caching • Range checking • Coercion • Coercion recording • All extended features enabled and accessed in a standard fashion www.ivifoundation.org

  13. 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

  14. 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

  15. 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

  16. 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 ww.ivifoundation.org

  17. 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

  18. 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 • 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 • Standard mechanism for handling multi-channel devices • aka repeated capabilities in IVI parlance • Standard error reporting • No need to deal with the numerous possible error schemes • Versioning standards www.ivifoundation.org

  19. 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

  20. 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

  21. 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

  22. 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 ‘setting a numeric property scope.Trigger.Type = IviScopeTriggerEdge ‘setting an enum property scope.Measurements.Initiate ‘calling a method scope.Close www.ivifoundation.org

  23. 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

  24. 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

  25. Richer Type System in IVI.NET 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); • 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 www.ivifoundation.org

  26. 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

  27. 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

  28. 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 msvs 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

  29. 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

More Related