LabVIEW Development Best Practices Documents
6/6/11 Update
Version 1.1.2 released with a bugfix for reading files that were generated by a big-endian processor.
Overview
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.
This Library's Design
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.
How to Use This Library
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:
- You can open one or more files for writing using the Add File VI, and you can close them using the Remove File VI.
- You can create and gain access to data records using the Checkout Record VI, and you can relinquish access using the Checkin Record VI. Records are written to a file using Store Records, and they can be removed from the session using Delete Records.
- To provide simultaneous access to the API session from multiple processes, the Obtain Session and Release Session VIs are provided in the palette.
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.
Requirements
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.
References
Thanks, Chris. I didn't even think of that. 
Have you thought about using the TDMS format? There are primative built in to LabVIEW for reading/writing as well as a TDMS file viewer (which is open, so if it doesn't fit your needs you can use it as a template). Also, it's well suited to waveform data, and DAQmx now has stream-to-disk in TDMS format functionality built in.
cheers,
Chris
Hi David
i´m working on STDF-Output and use also GDR records.
Inside the GDR record i use :
1) 1 Byte
2) 4 Byte Float
3) String
4) String
Between 1) and 2) there is a 0x00 when looking into the output *.std!
Do you know where it comes from?
My System
Win7 (64)
Labview 2010 SP1
Country:Germany
Martin,
This library doesn't control the file mark offest. If you select "open" for Operation input to the Add File VI, the file marker will be at the default location (the beginning of the file in this case). It looks like the Write Cached Records VI of the Deferred Write class needs to be modified to call the Set File Position Funtion VI to set the file marker to the end of the file before writing the records.
I've confirmed this works and will see that the fix gets into the next update.
--Michael
I try to save an example code(stdfex_Create Initial Sequence.vi) as another VI without changing anything.
Then I copy this VI to another computer, run this VI and LabVIEW CRASH!
Does anyone have the same problem?
Test Environment:
Windows 7 & LabVIEW 2011
VIPM 2011.0.1 (build 1693)
ESF 1.1.0.5
NI STDF IO Library 1.1.2.14
-Adam
Michael,
My initial thought is the same as yours. My all computers have the identical test environment as described. This issue can be reproduced on three different computers.
I am using Professional version Windows 7 with SP1 and 32-bit LabVIEW 2011.
-Adam
Thanks pgans! Can you and Adam confirm you are using LabVIEW 2011 SP1 with the f1 patch. Go to Help >> About LabVIEW... and see if it says Version 11.0.1f1. My suspicion is that this has to do with something that changed in the f1 patch that recently rolled out.
