A Case Study in LabVIEW Upgrades: Part 2 - Semiconductor Fabrication

Overview

Throughout the years, National Instruments R&D has developed a process for upgrading NI LabVIEW applications internally. To help programmers upgrade their LabVIEW applications, NI is publicizing this upgrade process, along with several examples of NI R&D assisting large customers in upgrading their LabVIEW applications. This tutorial is Part 2 of a two-part series of case studies documenting these R&D-assisted upgrades. Each case study walks through the upgrade process for a specific code set, examines issues that arose, and offers information on the techniques used to solve each issue.

For more information on the upgrade process used throughout these case studies, click here.

Visit ni.com/labview/upgrade for more information on upgrading your LabVIEW applications.

Code Description

This large semiconductor fabrication company, known as Company X for the purposes of this case study, has been developing a LabVIEW application containing more than 14,000 VIs to test its products. This code, organized by functionality, can be classified into several categories. The Instrument Drivers VIs are a separate set of VIs that perform driver calls to various instruments. The Measurement Module VIs are designed to accomplish a specific task such as retrieving data from an instrument and graphing that data. The company then logged the results of the test application in a database using another set of VIs. With LabVIEW, the development team also built tools to execute certain repetitive tasks such as performing calibration, mining data, and building Express VIs. This case study covers the upgrade of this depot of VIs from LabVIEW 8.2.1 to a beta release of LabVIEW 8.6, using a dedicated test machine.

Size of application: 14,000 VIs

The Upgrade

SemiFab followed the recommended upgrade process provided by NI.  A test machine was set up, mass compile procedures were followed, and a test plan was followed to evaluate the success of the upgrade and identify any large issues.

Occurrences of the types of problems more commonly reported during an upgrade were low.  There were very few behavior change upgrade issues or broken VIs as a result of this upgrade, and the other issues encountered, relating to difficulties mass compiling, were also easily mitigated.

Mass Compile Issues

To update the code depot to the newest version, the company performed a mass compile on the entire code set in both LabVIEW 8.2.1 and LabVIEW 8.6.  The mass compile of their code repository in 8.2.1 ran without incident, but when SemiFab ran the mass compile in the beta LabVIEW 8.6 version, it repeatedly crashed and hung on specific VIs.

Identifying the source of the crash proved to be more difficult than anticipated as the log file associated with the mass compile was empty. As a result, the LabVIEW log file generated due to the crash was used instead. The failure log indicated a few VIs that could potentially have problems in them. The indicated VIs could be opened and closed without a problem. Mass compiling the directory containing these VIs did not produce a crash; however, mass compiling the parent directory did crash the process. This, however, still did not indicate which particular file was causing the crash. The solution was to use an undocumented ini key to send debug messages to a temporary file. Because the earlier identified directory need not be the only source for the crash, engineers at SemiFab broke down the code into several parts and compiled each section at a time as the parent. They wrote a LabVIEW application to programmatically restart the mass compile after a crash. The building of the application took about two man hours.  After this program finished, and the upgrade issues that were discovered were fixed, mass compile successfully completed in normal operation.

Ultimately, the specific issue that caused the crash was not identified; however, mass compile crashes are not uncommon in prereleased software (even during internal testing at NI). However, as the product develops and stabilizes, the frequency of mass compile crashes diminishes. Because beta LabVIEW users must also use beta drivers (which often have their own issues), it becomes difficult to determine if an issue is caused by the driver or by LabVIEW.

In addition to crashing, the mass compile consistently hung at certain VIs. Engineers at SemiFab checked the mass compile progress box to learn which files were causing the hang. They proceeded to terminate the mass compile process and open the suspected files. They discovered that the VIs made calls into an Adobe/PDF API. When these VIs loaded, the Adobe Updater detected an update. The Updater pulled up a pop-up message that the user had to acknowledge to proceed. This resulted in the VIs not being loaded until the API was loaded. SemiFab was using a default image on the test machine that is not updated regularly. Updating the Adobe component fixed the issue.   It is important to note that this issue would have been encountered even if the customer was not upgrading their application; this occurs when transferring VIs from one machine to another with out of date Adobe software.

Upgrade Issues Encountered

As discussed in the Upgrade to the Latest Version of LabVIEW document, when upgrading, code can be affected both by migration upgrade issues and behavior change upgrade issues.  SemiFab did not encounter any migration upgrade issues, but did encounter a few behavior change upgrade issues.

The first issue encountered was a corrupt driver VI.  When SemiFab’s engineers reviewed the mass compile logs, a bad VI was reported in the beta version of a driver that prevented its caller VIs from running.  This issue had previously been reported to NI, and was fixed well before the public release of 8.6.  Resolving the issue was trivial; a corrupt control was replaced with a non-corrupt version.  It is possible that the mass compile crashed due to this bug in the unreleased beta version of NI-DAQmx, but it would be premature to conclusively attribute the crashing solely to this NI-DAQmx VI corruption.

In addition to VI breakages due to the DAQ corruption, the log file also indicated there were other broken VIs in the customer’s application.  These broken VIs were opened and it was identified that they were calling low-level vi.lib VIs.  These low-level vi.lib VIs do not appear on any LabVIEW palette, and were changed in LabVIEW 8.6 without migration, mutation, or notice to users.  NI does not recommend using VIs that ship with LabVIEW that are not on our palettes partially for this reason.  Fixing these breakages was also trivial; the low-level vi.lib VIs were replaced by higher-level VIs that appear on the LabVIEW palettes.

The final upgrade issue that was encountered was a breakage in a third party toolkit, called LuaVIEW, used by SemiFab.  LuaVIEW is used to create and run scripts in LabVIEW. In versions prior to LabVIEW 8.5, LuaVIEW depended on the ability to wire a strictly typed VI reference to a type cast function. However, in LabVIEW 8.5 and 8.6, the code making this call was broken due to a very specific, and unrelated, change in behavior in how data types are converted at Case Structure tunnels.  A change in the way LabVIEW converts data resulted in a wire being broken in one of the toolkit VIs.  The manufacturer of LuaVIEW had provided a patch for this issue for users of LabVIEW 8.5 and newer which resolved this issue.  This issue had not been previously reported to NI, and was filed to R&D as issue number 120556.

Additional Issues That Are Widely Applicable

As there was a dedicated R&D engineer at NI working with an engineer at SemiFab, NI was able to provide suggestions during upgrade process.

Mass Compile Process

When mass compile crashes it does not automatically restart; instead, it must be manually restarted.  Furthermore, because the mass compile is performed on an entire directory of code, it restarts at the beginning of the directory. Mass compiling does not currently report which VI is currently being loaded or compiled, so it is difficult to locate at which VI the mass compile crashed.  This makes the entire process frustrating when crashes are encountered.

Normally, a log file is created with mass compile to indicate VIs that contain problems. The log also contains information about files that been moved. This is expected unless the directory of the test system structure is identical to the development system. A second mass compile does not have this information because the linkages between the VIs are reestablished from the first run. The associated log file indicates VIs of more interest. Reviewing these issues pinpoints problems in your VIs due to the upgrade.

Plan to Test Existing Code

NI R&D recommended having a test plan for code to ensure that any changes or upgrades made are not adversely affecting performance. The recommendation included that the tests be stored in a central database and check for a particular feature or application. For testing VIs that involve measurements, it is important to check for expected and unexpected input ranges. An example of an unexpected input range is unusually small or large negative values. The user interface for the tests generally should not have any inputs. A Boolean control indicates if the test has failed, and the test should be set to fail if any test within it fails.

Test plans are also important for comparison.  When an issue is encountered in the new version of the software, it is important that the issue be identified as a pre-existing issue or one that is new to the software.  It is not uncommon for an issue to be discovered in the new version of the software that also exists in the previous version of the software.  This is often a result of increased and changing testing efforts at the time of the upgrade.  It is good to have a way to ensure the previous software was functioning as expected in addition to determining if issues encountered are new issues.

Summary

SemiFab’s upgrade experience is an example of a case when there are minimal issues during upgrades due to robust code, modular coding practice, and expert LabVIEW programmers. To locate which VIs have not been upgraded correctly or have become broken, use the mass compile logs.

If you want to read more about LabVIEW upgrade case scenarios, view the following.

A Case Study in Upgrading LabVIEW: Part 1 – Telecom Test Executive

For more information on upgrading LabVIEW applications, visit ni.com/labview86/upgrade.

0 ratings | 0.00 out of 5

Print

Reader Comments | Submit a comment »

It's August 7th now
So where's the remainder if it was supposed to be available August 6th ?
- Aug 7, 2008