Avoid that TS Version Selector changes vi.lib

[TobiasT]

I want to run 2 different sequence files on the same computer using two different TS version. Hence I use the TS Version Selector between running those files.

Every time I switch the TS Version some files in the vi.lib change. I discoverd it for files in the follwoing folders:

- C:\Program Files (x86)\National Instruments\LabVIEW 2009\vi.lib\addons\TestStand

- C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\addons\TestStand\

A TS Version Switch changes the vi.lib of both all installed LV Versions.

 After a switch to TS 2012 the vi.lib files are compiled in LV 8.2 or something similar old and hence my sequence that runs TS 2012 returns an error. After a mass compile in LV 2012 with folder C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\addons\TestStand\ the sequence runs fine w/o error. But after each TS Switch my masscompiled files are overwritten and I need to do the mass compile again.

I saw the post Version Selector mass compile VI's from paulmw, which outomates the masscomile, but this is no solution for a system running in production. I don't understand why a TestStand Version switch changes files in the LabView vi.lib.

Why is this change of vi.lib done?

Is there a way to avoid this?

[dug9000]

I'm not a LabVIEW expert, so hopefully someone who knows more can explain if this is correct or not, but I think the typical work flow with using the LabVIEW runtime engine is that one packages their VIs using the deployment utility which makes a private copy of the files in vi.lib so TestStand updating the files under LabVIEW's directory does not typically affect such VIs. And further, on deployed systems, it's not even required that the LabVIEW development environment be installed at all.

That said, the files come from this directory:

C:\Program Files (x86)\National Instruments\TestStand 2012\API\LabVIEW

So you can avoid the problem (as long as you are only using one version of LabVIEW) by putting the version of the files already mass compiled for the version of LabVIEW you are using in the above directory.

TestStand updates these files when you version switch to ensure that the TestStand palette VIs are those of the current version of TestStand you are using. Normally it's not a problem that they are compiled with LabVIEW 8.2 because they are used in the development environment which just recompiles them as needed.

-Doug

[TobiasT]

Thanks for the path.

I only use one file of the TestStand addons in the vi.lib, the LabVIEW Test - Sequence Context.ctl and hence my solution was to copy this file to a new location and change all usages to this new path. This worked fine, but replacing the files in the path you gave is probably a better solution. I'll try that later today.

It is not as easy as it sounds to deploy a complete system and we are not that far yet. We develop our codes and at release time we switch to using the LV runtime environment, however LV is still installed. Also your approach only works if the private copy files of the deployment utility are mass compiled in the LV version that the RT runs in (I aggree that this is recommended) .

After your post I now understand why the problem only occurs with the sequence that uses LV 2012 RT and not with the sequence that uses LV 2009 (since LV 2009 runs in development environment and the files get recompiled).

However I still think it is a bad idea that a TS Version switch changes the vi.lib files. When using the development environment TS always uses the currently active LV version (which is the latest started LV version) and one cannot change this in TS. There is a vi.lib for every installed LV version and hence every LV version should have the vi.lib compiled in its version. TS should just use the files out of the vi.lib of the LV version that is used. To ensure that the TestStand palette VIs are those of the current version of TestStand you are using I had expected some kind of automatism that ensures that the files are compiled in the used LV. For example that the TS Versoin Selector first checks whether the files are available and if so does nothing. If not it could put the files there and then perform an automated mass compile in the LV version of the vi.lib that changing.

Finally to your last point: Every recompilation takes time and hence the recompilation might not be a problem but it is not as expected.

  TT

[dug9000]

---

@TobiasT wrote:

Thanks for the path.

I only use one file of the TestStand addons in the vi.lib, the LabVIEW Test - Sequence Context.ctl and hence my solution was to copy this file to a new location and change all usages to this new path. This worked fine, but replacing the files in the path you gave is probably a better solution. I'll try that later today.

It is not as easy as it sounds to deploy a complete system and we are not that far yet. We develop our codes and at release time we switch to using the LV runtime environment, however LV is still installed. Also your approach only works if the private copy files of the deployment utility are mass compiled in the LV version that the RT runs in (I aggree that this is recommended) .

After your post I now understand why the problem only occurs with the sequence that uses LV 2012 RT and not with the sequence that uses LV 2009 (since LV 2009 runs in development environment and the files get recompiled).

However I still think it is a bad idea that a TS Version switch changes the vi.lib files. When using the development environment TS always uses the currently active LV version (which is the latest started LV version) and one cannot change this in TS. There is a vi.lib for every installed LV version and hence every LV version should have the vi.lib compiled in its version. TS should just use the files out of the vi.lib of the LV version that is used. To ensure that the TestStand palette VIs are those of the current version of TestStand you are using I had expected some kind of automatism that ensures that the files are compiled in the used LV. For example that the TS Versoin Selector first checks whether the files are available and if so does nothing. If not it could put the files there and then perform an automated mass compile in the LV version of the vi.lib that changing.

Finally to your last point: Every recompilation takes time and hence the recompilation might not be a problem but it is not as expected.

  TT

---

In general I agree that version switcher could handle this better, perhaps by mass compiling after replacing the files, but I think you are misunderstanding some of the issues.

1) "When using the development environment TS always uses the currently active LV version (which is the latest started LV version) and one cannot change this in TS." - Yes, but the currently active version of LabVIEW can change simply by the user launching a different version of LabVIEW and there is no guarantee they will run version switcher again after doing so, thus all versions of LabVIEW on the machine need to be updated.

2) In the use case where the LabVIEW Development environment is used at development time and then deployed to a machine without labview installed using the deployment utility, then no issues should be encountered with the current behavior. Though I agree it would be nice to also support your use case.

I've added this issue to our tracking database for future consideration (id #421499). No guarantee on when or if it will be addressed though.

-Doug

[TobiasT]

Here are some more findings on my side, fyi.

1) I tried the suggestion from above: The llb's in C:\Program Files (x86)\National Instruments\TestStand 2012\API\LabVIEW\ are Read only so I had to change that before I could perform a mass compile. After that it worked fine and as expected my problem is gone.

2) I took the time to check another computer with TS 2010, TS 2010 SP1, TS 2012 and LV 2011, LV 2012 installed. The TS Version Switch changed the llb files in both vi.lib's to the files of the TS version to that I switched. All files in the llb's of TS 2010 and TS 2010 SP1 are compiled in LV 8, the ones in TS 2012 are compiled in LV 8.2, so all older than my installed LV versions. However I can still run my sequence after using the Version switcher in LV 2012 RT. After the explanations above this should not work, since LV 2012 RT does not recompile the LV 8 or LV 8.2 files. I won't go into that deeper since it is working.

3) I was also surprised that there is the file ...\vi.lib\addons\TestStand\lvpalettesupport.dll and on the other hand there is the file TestStand 2012\API\LabVIEW\LVPaletteSupport.dll. Both are binary equal, but the upper-or lower case letters are used. I don't see a problem there, but it shows that the TS Version switch does not perform a direct copy.

4) I could not find the "tracking database for future considerations" in a quick search. Is it accesible externally from NI and can I give Kudos or sth similar to the ID that you created?

[dug9000]

4) The database is not externally accessible. You'd have to ask for support to check on the status of that issue.

-Doug

[JonP]

This problem also occurs switching between TS 2012 and TS 2013. In my case I am using some of the TestStand "Simple OI" VIs. Thanks for the workaround, it will help!