TestStand API LabVIEW VIs should be automatically mass compiled when copied into <LabVIEW>\vi.lib\AddOns

[adambro]

When TestStand launches, it determines the active LabVIEW version and copies the TestStand API VIs into <LabVIEW>\vi.lib\AddOns if not already present. (SOURCE)

I suggest there should be an additional step here and TestStand should call that LabVIEW version to mass compile these VIs.

Currently, the VI version remains unchanged which means when you open a LabVIEW code module which uses these, you'll sometimes find you have a 'dirty dot' due to unsaved changes because of the recompilation. It also means that you wouldn't be able to run a sequence using the LabVIEW Run-Time Engine until you've switched to Development and converted the VIs.

This is a minor annoyance but it would be nice if TestStand could cut out the additional version conversion step.

I do wonder whether the transfer of the TestStand API VIs into the vi.lib could actually occur when LabVIEW is installed if a TestStand installation is detected. Perhaps this might be relevant for other addons which existing LabVIEW installations have.

[kewal]

I fully agree with automatically mass compiling the VIs to the version of LabVIEW that the TestStand API VIs are transferred to.

However I think the right instance for installing the TestStand API VIs and mass compiling them should be during the Installation of  TestStand when it detects different versions of LabVIEW are present.

[crossrulz]

This is where the NI Package Manger could provide the capability (install software, link to LabVIEW, mass compile).  Hopefully NI considers this as they continue to develop that framework.

[kewal]

The following idea would help when installing a new LabVIEW version where TestStand has been previously installed:

Option to migrate VIs installed in a previous version LabVIEW

[aswinmci]

I'm wondering if this idea is the solution for my issues at the moment.

I'm using the TestStand Deployment Utility to make an installation package for a deployment machine.

This includes:

- TestStand Base Deployment

- LabVIEW Run-Time Engine

- Support drivers like NI-DAQmx, NI-XNET etc.

- And of course our machine software made in LabVIEW.

This was going fine, but at the moment we run in issues that the TestStand engine reports an error -17600 that the LabVIEW project has conflicts that needs to resolve in LabVIEW.

To test the things that you stated, I installed a trail version of the LabVIEW development software on this deployment machine.

After opening the LvProj file that is compiled and installed by the TestStand Deployment Utility, there is a dirty dot shown in the project explorer.

At that point I just close the LabVIEW project, agree on save all the changed files. (No modifications are made by a user)

After this quick recompile the TestStand engine just runs fine, as intended in the LabVIEW Run-Time engine.

Do you guys also deploy your software on a deployment machine with only TestStand base and LabVIEW RTE?

And if you do, do you also have the same issues?