Upgrading to the Latest Version of LabVIEW

Migrating an application to the latest version of LabVIEW can be a simple, error-free process if the correct procedures and practices are followed. National Instruments recignizes that switching to a different version of the development environment may require additional time and the re-validation of an application. This article provides a step-by-step process for upgrading in order to mitigate these risks and the other challenges associated with the process.

Upgrade Process

NI has consistently focused on long-term compatibility and continuity. LabVIEW is now on an annual release schedule to help ensure a smoother path from one release to the next. The expectation is not that all LabVIEW users upgrade annually; however, the goal is to make your upgrade process as smooth and easy as possible – whether you are upgrading from the previous version or from four versions back. 

Many of the add-on modules and tool kits that National Instruments provides are G-based.  Because of this, NI R&D must upgrade each of these products with each release of LabVIEW, much like a LabVIEW developer would upgrade an application that they developed.  This document will introduce the process that is used internally at NI, and walk you through the necessary steps to approaching the upgrade of your LabVIEW application with an easy-to-follow process.

Approaching LabVIEW upgrades with a defined process is crucial. Establishing a pattern of behavior that you can use to attack upgrades simplifies the process by eliminating variables that are otherwise introduced.  As such, the figure below displays the process that will be followed throughout this document.

[+] Enlarge Image

This process offers a systematic approach to conquering the upgrade.

Although this process had worked over the years internally at NI, there was no guarantee that this process would be widely applicable to the common LabVIEW application.  As such, NI R&D worked with several large international companies to apply this upgrade process to their applications.  Feedback throughout these upgrades was used to fine-tune this process.  

General Recommendations

Before examining the details of the upgrade process that NI recommends, consider these general recommendations:

You should use a test machine to upgrade LabVIEW code whenever possible.  This will help to keep problems in the upgraded code isolated from the code used on either a development or production system.  In many cases the cost for a test machine is outweighed by the cost for time spent troubleshooting.  To ensure that the development code is not affected, isolate the code by using a completely independent version or copy of the code. Using source code control (SCC) to manage and keep a record of file versions can simplify this process. Another benefit of using an upgrade system is that it simplifies the documentation of problems encountered during the upgrade. Recording these issues is important when the upgrade is applied to the development and/or production code base. 

Additionally, taking backup images prior to upgrading allows for an easy transition to the original code, if necessary. There are reimaging tools available to help restore systems back to a specific state:

•         Real-Time system replication tools
•         Altiris Deployment Solution
•         Norton Ghost
•         Acronis True Image

Your Upgrade Resources

Knowing what changes have been to the LabVIEW environment that you are upgrading to in advance can be extremely helpful in preparing you for the upgrade process.  There are many resources available both with the product and on ni.com that can be used to find this information.

LabVIEW Platform DVDs

Understanding which versions of LabVIEW modules, toolkits, and NI drivers are compatible with the latest LabVIEW release is a crucial step prior to beginning an upgrade. The new LabVIEW platform DVDs simplify this process by providing a single installation for NI LabVIEW modules, toolkits, and drivers. Each product on the DVDs is mass compiled for LabVIEW 8.6 and you can install the toolkits without affecting previous installations.  This simplifies the process of maintaining multiple versions of LabVIEW on the same computer. You no longer have to copy toolkit files to the new LabVIEW directory, manually edit the Windows registry, or mass compile LabVIEW toolkit code.  

LabVIEW Upgrade Notes

The LabVIEW Upgrade Notes are an underused upgrade resource.  Updated with each version of LabVIEW, the Upgrade Notes are included with every LabVIEW upgrade purchase or Standard Service Program (SSP) shipment. They feature a special section, titled “Upgrade and Compatibility Information”, that provides information on changes that might impact an upgrade, including new features, deprecated VIs, and behavioral changes made to LabVIEW going back many releases. For example, the LabVIEW 8.6 Upgrade Notes document that the Create Semaphore VI no longer exists and recommends the new Obtain Semaphore Reference VI, with an overview of the functional differences between the two.  Furthermore, there is an “Upgrading From” section that offers the information you need to upgrade across multiple versions of LabVIEW. To find the LabVIEW Upgrade Notes, click here.

One thing to consider is that changes to the lower-level VIs that install with LabVIEW or other NI products, those VIs which don't show up on the LabVIEW palettes and are often times in llbs in the vi.lib folder, are not documented in the Upgrade Notes. These low-level VIs are generally intended only for NI use in NI software; however, some of these VIs may be useful in your application and may be included in your application. Because changes to these VIs are not documented, it is recommended if you choose to use these VIs, you document their use and location so that when you upgrade you can test these VIs independently to ensure that no changes have affected your application. If you have not used any low-level NI VIs in your application, no extra testing should be necessary for this situation.

LabVIEW Upgrade Analyzer Tests

A new service included with LabVIEW 8.6 is the Upgrade Analyzer now available in NI Labs (ni.com/labs). This suite of upgrade tests is designed to test your existing code for known issues within the product. Although not every known issue can be detected through an automated inspection of your code, this suite tests for many known issues and offers additional information and workarounds.  For example, these tests are designed to identify sections of code, or specific configurations of code that could potentially cause a change in behavior when migrating.  This may be the result of deprecated functionality or updates to older VIs. They will not identify or detect any issues that are a product of the environment settings or are a result of the development environment itself.  NI will update this test suite periodically as known issues are reported.

LabVIEW Bug Fixes

All software products have unexpected behavior introduced with new versions, otherwise known as “maintenance issues” or “bugs.”  LabVIEW is no exception. However, while LabVIEW does have bugs, there is a process in place for developing products to ensure the delivery of high-quality software.  The NI process is certified as ISO 9001-complaint for software quality standards. Further mitigating the presence of bugs is that LabVIEW is a flexible programming language, which means most bugs have simple workarounds. On top of this, NI maintains annual maintenance releases, which are typically available six months after a major release.

In the event a critical bug is discovered without an easy workaround, NI technical support engineers can work with NI R&D to create a patch, or a fix, for a specific customer. You can find information on the bugs that have been fixed in the LabVIEW 8.6 Readme file. Changes in LabVIEW as a result of a bug fix could inadvertently change the behavior of your LabVIEW program after you upgrade, so review the list of fixed issues to determine if your application may be affected. However, in practice bug fixes rarely adversely affect a LabVIEW program.

Preparing Your Environment

Now that you are aware of all of the changes that can potentially affect your code, the next step in the process is to prepare the Upgrade environment.  

Source Code Control

Using Source Code Control (SCC) for upgrading is very beneficial. You can use it to share files among multiple developers, improve security and quality, and track changes to shared projects. Specifically for an upgrade, the version control of large applications is especially important.  With this version control, you can easily roll back your code if something critically detrimental occurs. Recommended for any large LabVIEW application development, SCC can prove especially useful in upgrading. In house, the LabVIEW development team uses Perforce to manage SCC requirements. However, there are many other SCC providers that integrate well within LabVIEW. Click here for more information on using SCC.

Test Computer

Properly preparing the upgrade environment can greatly simplify the upgrade process. The upgrade machine should not be linked to either the development or production environments, but it should be as close in configuration to a tested production system as possible. The first priority is ensuring that upgrading the application to the new version does not change the behavior of the VIs. Changes in your environment can introduce changes in the timing and execution order of your program, which can expose problems in the code that may have existed before the upgrade. It can prove difficult to differentiate these from behavioral changes introduced as a result of upgrading the application. The upgrade environment, when properly prepared, eases this difficulty by isolating the upgraded code base. Once the application is properly upgrading on the test environment, proceeding to upgrade the development and/or production environment is as simple as reproducing the changes made in the upgrade environment.

Independent testing of peripheral software should also be a priority. Many upgrade issues can be traced to VIs, drivers, and other peripheral software changing during the upgrade of your LabVIEW environment. Often times, upgrading to the LabVIEW  environment requires a concurrent upgrade of the peripheral software and drivers to support the new LabVIEW version. This can potentially introduce issues when there are behavioral changes in the peripheral software. When these upgrade issues occur, it is often difficult to determine if the issue is due to changes made in LabVIEW or changes made in the peripheral software. When your LabVIEW upgrade will require you to upgrade peripheral software, we recommend that you upgrade to the newest version available that supports your hardware. Additionally, you can take steps before upgrading your LabVIEW development system to test the required upgrades in peripheral software. This is not always possible, but if you are able to upgrade your peripheral software to the version you will be using in the new version of LabVIEW on the system currently running the previous LabVIEW version, you can upgrade the peripheral software on the previous LabVIEW system and perform testing before upgrading LabVIEW. For example, the NI-DAQmx drivers that release with new versions of LabVIEW are typically compatible with a few previous versions of LabVIEW. Before upgrading LabVIEW and the drivers to the latest version, you can upgrade just the NI-DAQmx drivers on the system with the previous LabVIEW version, perform testing to identify any upgrade issues in the DAQmx driver, then upgrade LabVIEW to the new version with the previously tested new DAQmx version.

Mass Compiling

Once the upgrade system is properly prepared, the table is set to “do the upgrade.” Performing an upgrade requires the application to be mass compiled to the newest version. Prior to mass compiling in the new version, you should first mass compile in the existing version.  You can perform a mass compile by choosing Tools > Advanced > Mass Compile from the LabVIEW menu bar. The mass compiler gives you the option to cache VIs in memory so that they don't need to be loaded every time a top-level VI is compiled. This can significantly decrease the time spent during a mass compile. Depending on your machine's available memory, the number of VIs you should cache will change, but a good range to try is between 50 and 80 VIs. The mass compiler also gives you the option to save a log of the process. This log is important for the upgrade process since it will tell you in which VIs problems existed. Once you have mass compiled the code in both the original and target versions, review the logs of the mass compiles and look for the load path warnings

“the VI expected to be at __ was loaded from __”

This warning notifies you of a new linkage in the test environment. Review these warnings to ensure that all new linkages are appropriate. Another warning looks like the following:

            “Could not load __ because __ in memory”

These are true cross linking errors in which LabVIEW may have chose the wrong subVI to link to because there was more than one VI on disk with the same name. Click here for more information regarding cross-linking problems. 

These load path warnings are typically the vast majority of the entries in the log file, which will happen unless the directory structure of the upgrade machine is identical to that of the development machine.  Once these messages regarding moved files has been reviewed, mass compiling a second time will remove these and only reveal problems with VIs that are of greater concern.  This is because the linkages were updated during the first mass compile. You should look for the following string in the mass compile reports to identify insane objects that exist in your application.

“Insane Object”

The log also indicates if these insane objects were fixed by the mass-compile routine. Also look for these characters to find bad VIs.

“###”

Although rare, the mass compile might crash when working with unstable VIs.  This happens internally frequently during early development of a new version of LabVIEW; however, mass compile crashes are rare and taken seriously as LabVIEW begins to stabilize.  It is unlikely that you will experience a mass-compile crash unless a particular VI is in a bad state that would also crash LabVIEW when loaded and saved.  If the mass compile crashes, the log file will indicate which file caused the crash.  Locate and open these files to ensure they are not corrupted, then mass compile again.  In rare cases, it may be necessary to remove this file from the folder if the mass compile will not successfully complete a directory due to the bad file.

Fixing Broken VIs

At the successful conclusion of the mass compile steps, the next step in the process is to identify broken VIs. If the upgraded code contains broken VIs, do not be intimidated by the number of broken VIs. There might be only a few VIs that are broken, but they are used widely in the application. Use the error list window to locate the broken subVIs and fix those first. As you fix the broken subVIs, the errors that propagated up the calling chain are also fixed. The broken subVIs can occur for a variety of reasons. If VIs or dependencies change location or are missing on the upgrade machine, then the calling VIs contain a broken run arrow. This can happen if everything isn’t properly copied over from the production machine. Additionally, peripheral drivers or software that is not installed on the upgrade machine cause the calling VIs to contain a broken run arrow.  A less common reason is that the upgraded code uses a feature in LabVIEW that is not supported in the new version but was supported in a previous version. These issues are typically resolved automatically through mutation code and compatibility VIs, but you can identify them using the Upgrade Analyzer tests.

Resolving broken VIs in an application is easier to do in the LabVIEW development environment.  The simplest resolution is to create a new VI in the new version and begin adding the top level VIs of your application into this VI. This includes framework VIs, VI libraries, and dynamic VIs. Add the top-level VIs one by one to the diagram and as broken VIs appear, use the broken run arrow and error list window to track down the root cause.  Remember to start from the bottom-up, which mitigates the errors caused by the calling chain. If you can’t determine the cause of the broken VI, load the VIs in the previous version to confirm that the problem is a result of an upgrade, and not an existing issue. For additional help, contact NI Technical Support and speak with an applications engineer.

Issues Affecting Upgraded Code

Upgraded applications can also be affected by two types of issues that do not result in a broken run arrow. The first is a bug in the new version of LabVIEW that was not present in the old version. Although rare, this bug can affect the behavior or performance of your application in the new version. Report this bug to NI through NI Technical Support, and work with an applications engineer to identify a workaround. The second type of issue that might affect the application is a problem with the migration itself. That is, NI includes mutation code in LabVIEW that automatically updates code for compatibility when specific behavior is altered in the native LabVIEW VIs and functions. If this mutation code contains a bug, that issue affects the upgraded code.

Testing

Testing, one of the most important upgrade steps, is often overlooked.  Remember that having an upgraded application that runs does not mean that the application behaves as expected. Proper and thorough testing ensures that the upgrade was successful. A large amount of testing on the upgrade system before integrating changes made to the application into the development systems is crucial. Furthermore, testing your development systems before integrating those changes to the production systems is also important. Syncing the development and production systems together both eases and speeds up the process of implementing changes on the production system.

Conclusion

Every upgrade case is unique and requires some decision-making on your part. This decision-making revolves around the critical components of your application, trade-offs that you are willing to make, and an understanding of the end goal of your code. NI knows that you face real challenges with an upgrade, and is taking steps to simplify the process and make pertinent information easier to find. For example, SSP customers have access to software and upgrade applications engineering specialists, a special group of technical support engineers with training specific to LabVIEW upgrades. The goal is to make your upgrade process as smooth and easy as possible, whether you are upgrading from the previous version or from four versions back. With the LabVIEW 8.6 release, NI has developed new technical content, tools, and services to help you through the upgrade process.

Related Links

On Demand Training: Best Practices for Upgrading LabVIEW Applications (SSP Required)

 

Reader Comments | Submit a comment »