Background

We were working with Stefan Lemmens to update the custom Delacor VI Analyzer Tests for his company. They have some projects that use LabVIEW versions that are earlier than LabVIEW 2018 and some projects that use LabVIEW 2018. They wanted to take advantage of the #via_ignore feature when using LabVIEW 2018 and we didn’t want to maintain two VIPM packages for the same tests. Stefan came up with an idea on how to do this and at Delacor we expanded on his original idea. We thought this was too good to keep to ourselves and we hope it helps others trying to solve the same issue.

Types of VI Analyzer Tests

There are two types of VI Analyzer tests:

  • RD tests (LabVIEW 2017 and earlier) – If the VI Analyzer tests LLB contains a <test name> RD.vi, then it is an RD test. RD stands for “Reconstruct Data”, and the RD VI tells the VI Analyzer Results Window how to interpret the “Ref Index” value returned by a test failure. For example, if your test returns failures for For Loops, then the RD VI will specify the class “ForLoop”, which tells the VI Analyzer Results Window to traverse the failure VI for For Loops, and the “Ref Index” value will specify which item in the traversed array of references is the specific failure object. All VI Analyzer tests written from LabVIEW 7.0 to LabVIEW 2017 are RD tests.
  • UID tests (LabVIEW 2018 and later) – If the VI Analyzer test LLB does not contain a <test name> RD.vi, then it is a UID test. This means that the “Ref Index” value returned by a test failure is simply the UID of the failure object:

All VI Analyzer tests created in LabVIEW 2018 or later are UID tests. You can also manually convert an RD test to a UID test by:

  1. Modifying the test’s scripting code to pass UIDs instead of traversal indices
  2. Deleting the RD VI from the test LLB.

VI Analyzer 2018 and later will load and run either type of test. Unfortunately, in order to utilize the #via_ignore functionality added in VI Analyzer 2018, a test must be a UID test. So if you have old RD tests you are still using, they will not support the ability to ignore individual test results.

Implementing Dual Version VI Analyzer Tests

There is a workaround for this situation. You can implement your VI Analyzer test as a Dual Version VI Analyzer test by following these steps:

  1. Add the following code snippet to the diagram of your VI Analyzer test:
Save png and drag into LabVIEW block diagram

Dual Version Test Snippet

This code will return a Boolean that specifies whether or not the test that is currently running is an RD test or a UID test. Note that the code in the case structure only runs the first time it is called. It will use the stored value on each subsequent call (during an analysis session). This results in a minimal performance hit.

2. In the scripting code of your VI Analyzer test, generate both the traversal index (for an RD test) and the UID (for a UID test), and conditionally pass the proper value, depending on the Boolean value returned by the code snippet above. Here is an example:

Dual Version Test Use Example

The RD VI for this test specifies “Wire” as the failure object. If the test is an RD test (based on the code snippet described above), return the loop index in the failure cluster. If the test is a UID test, return the UID of the Wire.

3. When installing the VI Analyzer test, conditionally delete the RD VI from the test LLB if the test is being installed to LabVIEW 2018 or later. If you are using VIPM to distribute your VI Analyzer tests, this can be easily accomplished with a Post Install Action VI that queries the LabVIEW install version and conditionally modifies the test LLBs post-install.

Using this approach allows you to single-source your VI Analyzer test development in the earliest LabVIEW version you wish to support, while also giving you the valuable #via_ignore functionality provided in LabVIEW 2018 and later.
Caveat: When using the dual version test technique, you will probably want to install your tests to the LabVIEW folder. Tests in the LabVIEW Data folder will be shared across LabVIEW versions, and for the next several years anyway, if you are in a company like Stefan’s, chances are you’ll be using these tests in a LabVIEW version prior to 2018.
At Delacor we have helped customers create and maintain their custom VI Analyzer tests to guide their team through LabVIEW Style guidelines compliance. Let us know if we can help you do the same.
Happy wiring,
The Delacor Team