The WATS LabVIEW Toolkit supports functions for UUT (Unit Under Test) and UUR (Unit Under Repair) reporting. This article delves into the possibilities of the UUR suite of functions, specifically the UUR Wizard example supplied with the WATS LabVIEW Toolkit.
- Download and install the WATS client
- Install the WATS LabVIEW add-on from the WATS Client Configuration panel
- Open the project in NI LabVIEW. The project is created using LabVIEW 2009
- Open the Example UUR Wizard.vi file
This example is fully functional; it will create a simulated UUR report using dummy data entered through the Front Panel on the program. If a WATS or skyWATS account has been set up, the report will be uploaded to the WATS server.
On the surface
The Front Panel of the UUR Wizard example is split into two tab-sheets. Identify UUR (Fig. 1) contains a cluster of header data in order to identify the UUR and an status indicator for the WATS server connection, and Failures (Fig. 3) is used to select and enter data for the Repair Report.
Fig. 1: Front Panel showing start data entries
Once the program is started, a window pops up to allow selection of the overall Repair Operation. The overall operation could e.g. be electronics, mechanical, or audio.
Fig. 2 Selection of overall repair operation
With Repair Operation selected repair sub-categories can be entered using the Failures tab on the Front Panel. Repair steps are added by pressing the “New” button, selecting appropriate Repair Category and Repair Code, entering a reference for the failed component and a comment if applicable. Pressing the “Add” button adds the data to the Failures List. The entire content of the Failures List is added to the Repair Report when the “OK” button is finally pressed.
Fig. 3: Example of filled out Repair Report fields
Under the hood
The example code consists of three sequences: An initialisation of the Front Panel elements, not discussed further in this article, a setup of the UUR report, and a handling of the UUR report data.
Fig. 4: Setup of New Repair Report
The Setup New Repair Report sequence incorporates four WATS LabVIEW toolkit VIs
- WATS_TDM_CreateTDMObject.vi creates a new WATS TDM object, handles the connection to the WATS server, and passes on needed references.
- WATS_TDM_GetRepairFailCodes.vi retrieves available Repair Failure Codes from the server and returns them in two arrays; one containing the failure types in clear text and one containing references to said failure types. The two arrays are mapped identically, i.e. when searching for a failure type in clear text the server reference will have an identical index.
- WATS_TDM_SelectRepairOperation.vi allows the user to select the overall Repair Operation
- WATS_TDM_CreateNewUUR.vi creates a new UUR report based on the Repair Operation selected.
The sequence opens the connection to the WATS server, retrieves the pre-stored Repair Fail Codes – Repair Fail Codes can are created and edited online using the skyWATS website – allows the user to select the overall Repair Operation, and using this data selects and passes on the filtered failure data on to the third sequence.
Fig. 5: Populate and Submit Repair Report
The Populate and Submit Repair Report sequence is based on an event handler reacting on inputs from the Front Panel. The NewFailure and SelectRepairCategory Value Change events simply handles the population and selection of failure codes. The AddFailure Value Change event, see Fig. 5, adds failures to the Repair Report using the WATS LabVIEW toolkit VI WATS_TDM_AddFailure.vi. The WATS_TDM_AddFailure VI adds repair steps to the final Repair Report one-by-one, i.e. in order to add multiple repair steps to the report the VI needs to be called multiple times.
Fig. 6: OK Button Value Change event
When selection of repair steps are done and the OK button is pressed, the program fills out the final header data of the UUR Report from the Front Panel control, submits the UUR Report to WATS, using the WATS_TDM_SubmitReport.vi with the Submit UUR type set, and finishes off the event handler. Outside the loop all open LabVIEW references are closed – This is best practice in LabVIEW, as references otherwise are kept in memory until LabVIEW is shut down completely – and the connection to the WATS server is shut down.