Version 1.1.2 released with a bugfix for reading files that were generated by a big-endian processor.
Standard Test Data Format (STDF) is a file format developed by Teradyne to be used for logging data on automated test systems. It provides a common format for storage and transmission of all types of data in almost every system design. It is an active standard that has been widely accepted by ATE manufacturers in many industries. The attached library provides a means for both writing and reading STDF files that is conformant with version 4 of the specification.
The STDF format is designed for minimal size on disk. To achieve this, the file is structured as a linked list of binary records. A minimal configuration is required for the file to be valid, but beyond this "initial sequence", almost any number or order of records can be present. Additionally, each record has lists of required and optional fields; the optional fields may be omitted from any record under certain circumstances.
This arrangement lends itself very nicely to an Object-Oriented design. The three basic elements of the library are the Record class, the STDF Writer class, and the STDF Reader class. The Writer and Reader classes each manage a file and a list of records. When creating an STDF file, records are created, populated with pertinent test data, and stored in a writer. Similarly, when reading a file, the reader scans records from the file on disk and returns them to you.
The STDF Writer, STDF Reader, and Record classes are the basis of the STDF IO library.
To accommodate the 26 different kinds of records defined in the STDF specification, the design is extended using LVOOP Dynamic Dispatching: each type of Record class is defined as a child class. This allows the library's programming interface to dynamically change the data members of a record based on its subtype, without the client (you) having to change the set of VIs and functions being used.
The Class Property Node (a LV 2010 feature) dynamically adapts to the record type it is given.
These design elements are sufficient for use in a single, linear test sequence writing to a single STDF file on disk. However, many test applications operate in parallel or need to manage multiple data files at once. In response to this need, a wrapper API class called the Test Data Manager was created. The Test Data Manager encapsulates the STDF Writer and Record classes, instantiating and juggling them as necessary to provide a simple multi-access, multi-element management interface.
The Test Data Manager class provides multi-file management and a multi-access client interface.
The Test Data Manager class is an ESF session, which provides global access via the Obtain method and by-reference handling via the Data Value Reference (DVR) handle that is passed between its method VIs. Now Records can be accessed and modified by multiple parallel processes, and they can be written to one or more files as appropriate.
As a client developer, you don't really need to understand any of the underlying design decisions in order to use the STDF library. The end result is a palette of functions that behaves like many file I/O APIs, except that it is designed to manage multiple files and provide access to multiple clients:
The STDF palette provides the VIs and node needed for most test applications.
The File I/O subpalette provides VIs used for lower-level write access and read access. These palettes lack the VIs needed for multiple-access designs (Checkin/Checkout and Obtain/Release). The Records subpalette provides VIs needed to create and manipulate records. The Examples palette provides simple code snippets that demonstrate the use of the various palette functions.
The File I/O and Records palettes provide low-level APIs for managing STDF files.
As NI TestStand is a critical component in most automated test systems, consideration was given to the STDF library's use in that environment, as well. A beneficial artifact of deriving the Test Data Manager class from ESF is that it provides an interface that can be accessed directly from TestStand, if needed. The DVR handle passed between the class's methods is recognized as a simple U32 integer type. When designing a TestStand sequence, the developer has the flexibility of creating a Test Data Manager object and passing its handle to code modules or allowing code modules to access the object using the Obtain and Release VIs.
The session's DVR handle is seen as a U32 in TestStand, making it easy to pass between code modules as a parameter.
An essential usability feature of this library is its reliance on the Class Property Node to dynamically populate itself with the appropriate data members for each record type. Without this, a palette of over 500 accessor VIs would have to be made accessible to the user! A showstopper bug affecting the Class Property Node was fixed in LabVIEW 2010 SP1; as such, this library requires LV 2010 SP1 (LV 10.0.1) to function.
This library is dependent on the Extensible Session Framework. The ESF package can be downloaded from its NI Community document here.