The WATS LabVIEW tool-kit is a powerful link between existing test solutions and WATS report generation. This article discusses how to create a simple LabVIEW program to add data from a simple ASCII test result file to the WATS database.
- Download and install the WATS client (Not a customer yet? Sign up for a free trial at www.skywats.com).
- Install the WATS LabVIEW add-on from the WATS Client Configuration panel.
- Download and unzip the attached file WATSReportGenerator.zip (at the end of this article).
- Open the project in NI LabVIEW. The project is created using LabVIEW 2009.
When opening the Main.vi file you may experience that LabVIEW is searching for the WATS TDM Interface dll. This can happen when the dll currently on the PC is of a different version than the one used when the application was created. Simply click cancel and ignore the load warning thrown by LabVIEW.
Should you receive an error regarding the ctrl_SubmitTypes.ctl please contact us for the latest version of the LabVIEW tool-kit.
This example will read a simple ASCII (.txt) file and use the WATS LabVIEW add-on VIs to feed the information to the WATS server
The main VI simply calls a purpose-built file reader VI that filters header data from raw test data, loops through the returned raw data and sorts it into the correct test types, and finally submits the created UUT report.
The Data File Reader VI simply reads out the ASCII data, splits it into two parts (Header data and Result data), and transforms the data into LabVIEW clusters which are the returned to the main VI.
The Header data sorting is a trivial matter handled directly in the Data File Reader VI, whereas a series of sub VIs handles the processing of Result data, one for each type of test. This example code includes VIs for processing each type of test step data handled by WATS, except for graph data, as these would bloat the data file.
Though built alike each of the Data Organisation sub VIs are customised to handle the data specific to that test step type. The Test data is bundled in a cluster and passed on as a variant. This construction makes it possible for the program to handle the differences in the clusters passed by each different Data Organiser. E.g. Numeric Limit Test data contains an upper and a lower limit, whereas Pass Fail Test Data simply contains a Boolean stating whether the test passed or failed.
Test steps can be organised in different step groups. The first case structure within the main loop handles this organisation. For this example only one level of step groups are handled, hence whenever a new group name appears the program will jump back to the root sequence and create a new group. However, the API does allow for multiple layers of groups.
The second case structure in the main loop takes care of adding the test steps to the test report. As the test data is passed on as variants, each case includes a function to regenerate the data in the original format and passing it on to the corresponding WATS step VI.
Finally, with all data added to the report, the report is submitted to the WATS server. As this example only takes care of UUT data, the Submit UUT and Close type is set. This assures correct closing of the UUT LabVIEW references before closing the connection to the WATS server. For this example it doesn’t make much of a difference whether the closing of references happens in the Submit VI or in the Close Connection VI. However, with an additional loop layer for handling of multiple UUTs the program would either have to open and close the connection for each UUT, leading to heavily increase in time consumption, or suffer from memory leaks due to unclosed LabVIEW references.
With the report submitted to the WATS server it is, of course, readily available through the browser interface.