![]() This installation requires one of the following Microsoft operating systems: Refer to the IVI Compliance Package Release Notes, Version 4.4, for general information about this product. Supports NI Update Service 2.0 (CAR 91206).Includes IVI Shared Components 2.2.1 (CAR 254400).Adds IVI-COM adapter support for the IviACPwr class (CAR 254370).This release includes the following new features and bug fixes: IVI Compliance Package (ICP) 4.4 is an update release of IVI Compliance Package 4.3. All rights reserved.IVI Compliance Package Readme NI IVI Compliance Package 4.4.0 Readme File a different driver-instrument combination).Ĭopyright 2013-16 Boonton. Swapping instruments in such a system involves merely associating the Logical Name in the Config Store with a different Driver Session (i.e. In either case, no instrument-specific details exist in the client program. Applications load IVI-C specific drivers by passing a Logical Name to the Initialize function on an IVI-C class driver. ![]() Applications create instances of IVI-COM drivers by using the COM Session Factory and specifying the Logical Name. The Logical Name is what client programs must use to build interchangeable systems. The Logical Name serves as this extra level of abstraction - a simple string identifier for a Driver Session. Since the Driver Session is tied to a particular driver and instrument, a level of indirection is needed to abstract these details in interchangeable client applications. The Logical Name allows users to associate an arbitrary name with a Driver Session. You may have multiple Driver Sessions for the same Software Module, if, for instance, the driver is being used to control several instances of the same instrument at different GPIB addresses. Users create a separate Driver Session for each unique combination of driver software, instrument hardware, and initialization settings. Virtual names are used by client programs to access repeated capabilities in an interchangeable fashion.įor a dicussion of repeated capabilities, physical names, and virtual names, see the Repeated Capabilities topic. The Driver Session also specifies such things as driver initialization values and mappings between physical repeated capability names and virtual repeated capability names. The Driver Session associates the Software Module with the Hardware Asset. The main purpose of the Hardware Asset is to house the I/O resource descriptor used to communicate with the device. The Hardware Asset identifies a specific piece of instrument hardware. The Software Module identifies the instrument driver DLL, as well as various pieces of important driver information, such as the physical repeated capability names used for the repeated capabilities, IVI compliance information, as well as a variety of other items. Consult the documentation for your Config Store editor for detailed instructions on modifying these items. The following sections provide descriptions of each of the Config Store entries mentioned here. To author test programs that allow for interchangeability, you must create three additional entries in the Config Store: End users should never modify the Software Module entry. This entry is removed by the driver uninstaller. The driver installer creates only one entry in the Config Store - the Software Module. Alternatively, the IVI Shared Components include a programmatic interface to the Config Store, known as the IVI Configuration Server. Instead, use one of the available third-party editors. The Config Store file is highly self-referential and easily corrupted if directly modified. Instrument vendors and other third parties provide graphical tools for conveniently editing the Config Store.Īlthough the IVI Configuration Store is a human readable XML file, the IVI Foundation strongly discourages you from directly editing this file. To use the driver in application programs that will be interchangeable, you must edit the Config Store and add a few specific entries. If you only wish to access the instrument specific functionality of the driver, then no other entries in the Config Store are required. No other entries in the Config Store are created by the driver. Specifically, the driver installer adds a Software Module entry to the Config Store to represent the driver DLL itself. The Boonton55xxx installer populates the IVI Configuration Store (Config Store) with the required entries for using the driver. Where, is typically C:\Program Files\IVI Foundation\IVI. Physically, the IVI Configuration Store is an XML file installed by the IVI Shared Component Installer in the following directory: The IVI Configuration Store serves as a central repository for driver registration information. The IVI Configuration Store is part of the IVI Shared Components distributed by the IVI Foundation.
0 Comments
Leave a Reply. |