An ATEasy Driver is a plug-in, reusable module that can export any of its submodules to any other module (Programs, System, and other Drivers) in the project. The Driver is used to communicate with the "outside world" such as instruments or other devices. In a project, a driver resides under the System Drivers submodule.
When defining a driver, you select the interfaces (for example, GPIB
or VXI) the driver supports and their default configuration (such as time-out,
terminator and more). Once the driver inserted to the system, the system
creates a driver shortcut
. You then select the interface used and
set other configuration attributes such as address.
Unlike a program, the Driver variables retain their values during the life of the application even after a program has finished. For example, if a program invoked a Driver's virtual DMM panel, the virtual panel would still be available after the Program is finished.
Driver commands are high-level statements like the statements commonly found in Test Requirement Documents (TRDs). The Driver commands, typically the code used by programs tests, are independent of the actual instrument or the method used to communicate with the instrument (for example, GPIB). A major advantage of this architecture is that it allows ATEasy users to replace instruments and drivers without the need to modify any of the test program code. This holds true for any instrument or Driver if the Driver commands are designed in the same way for all instruments of the same type.
Like any module, the Driver also contains the Forms submodule. Forms may be used interactively to create virtual panels of the instruments, allowing you to control the instrument interactively without programming.
An ATEasy Driver is a reusable module. Any libraries or programming elements declared as public and used within the Driver are available to all other modules within the project by merely referencing them. The advantage is code duplication is avoided, and code reuse is encouraged.
ATEasy drivers can be created by filling in the driver sub modules (e.g. inserting an external library and creating driver commands) or by importing a function panel (.fp) driver file that is usually used when programming in LabWindows/CVi® environment.