LabVIEW VI causes TestStand Deployment to fail

[Mike_Millhaem]

Hello,

I have a problem with the attached VI.  Any time I include it in a deployment, I get an Error that says "Internal Error Code 1 processing VIs... Installer not created due to an Error"

The VI and a simple sequence file are attached.

[Joe_H]

I used to get this error when using Active x and OO in LV with teststand so I would say that it is not any different in using .NET. The way that I found around the error was to build an installer in LV and then build one in TS but do not include the VI that you built an installer with in LV. Then in teststand set up the installer to run the LV installer when it finishes. Sucks to have to do it this way but it worked for me.

[Manooch_H]

Hi Mike,

I was able to reproduce the error with your VIs. I have reported this to R&D (# 181041) to be fixed in a future version of TestStand. Thank you for bringing this to our attention!

[Simon_Holman]

Hi Manooch,

Do you know if this issue has been addressed in TestStand 4.2 ?

It looks like I have to download the whole TestStand to see the Readme for TestStand4.2 which has the list of Bug Fixes! (http://zone.ni.com/reference/en-XX/help/370052H-01/tshelp/infotopics/42bugfixes/ )

This issue doesn't appear in the Known Bugs list (https://www.ni.com/en/support/documentation/bugs/09/archived--teststand-4-2-x-known-issues.html)

Thanks

[RayFarmer]

Simon,

The following (below) is the Deployment improvements for TestStand 4.2.  I haven't been able to look at the VI of the original post so I dont know of the actual problem but there are still issues with the deployment tool in TS4.2

Regards

Ray Farmer

TestStand Deployment Utility Improvements

The TestStand Deployment Utility now uses improved internal caching to accelerate analysis and build times. Additionally, the LabVIEW VI Options dialog box includes the following new options so you can choose between faster performance and improved error handling:

• Check for Broken VIs During Analysis—When enabled, the TestStand Deployment Utility checks for broken VIs during analysis. This option is disabled by default to improve performance. Enable this option when you want to debug VI errors.
• Check for Broken VIs After Build—When enabled, the TestStand Deployment Utility checks for broken VIs in the image directory when building an image. This option is enabled by default to ensure that distributed files do not contain broken VIs. Disable this option for better performance if you are rebuilding and have not made changes to VIs.
• Remove Unused SubVIs—Removes unused polymorphic subVIs and disconnects type definitions when building. This option is disabled by default for backward compatibility. Enable this option for better performance and to deliver a smaller number of subVIs.

Note  Enabling the Remove Unused SubVIs option disables certain editing and debugging options on the deployed system, such as wiring a new type to a polymorphic VI or making type changes across several VIs by editing a type definition.

The Deployment Utility also better integrates with LabVIEW 8.6.1 or later for improved build speeds and deployment of advanced LabVIEW features, such as VIs that include LabVIEW object-oriented programming.

The Installer Properties section of the Distributed Files tab of the TestStand Deployment Utility also includes a new Force File to Install option. Enable this option to force the installers the deployment utility builds to always overwrite existing files.

Refer to Chapter 14, Deploying TestStand Systems, of the NI TestStand Reference Manual and to TestStand Deployment Utility for more information about the TestStand Deployment Utility.

[Mike_Millhaem]

The feedback I recevied from NI on this issue is that it corrected if you use LabVIEW 8.6 and TestStand 4.2

Mike

[Manooch_H]

This problem does not exist when using TestStand 4.2 and LabVIEW 8.6.1

[RayFarmer]

Hi Mike,

I was able to reproduce the error with your VIs. I have reported this to R&D (# 181041) to be fixed in a future version of TestStand. Thank you for bringing this to our attention!

When you said that you were able to reproduce the error, what versions of software were you using?

Regards

Ray Farmer

[Mike_Millhaem]

Hello Ray,

Input from Manooch says this is fixed in the latest releases of LabVIEW and TestStand.

I was using LabVIEW 8.5.1 and TestStand 4.1.1

Mike