Change currently active LV version in batch script

[TobiasT]

Hello,

I use two different applications on my computer and one of them should run in LV 2011, the other one in LV 2012. Both versions are installed and it works fine as long as I start the correct LV version manually before starting the application (by starting and closing the required LV version from C:\Program Files (x86)\National Instruments\... before starting my application).

I want to do this automatically in a command script, so basically I want to do the following:

* Check which LV version is currently active (which LV version was started last)

* If the currently active LV version is NOT the required one: change to the required LV version (by starting LV and closing it, or preferably doing it differently if someone could tell me how)

* If the currently active LV version is the required one: Do nothing

There are two problems I could not solve so far:

* How do I get the currently active LV version (I checked windows registry, but I only see my installed LV versions, and not which one is currently active)

* How can I close LV with a batch script (or how can I change the currently active LV version w/o opening and closing it)

Thanks in advance,

  Tobias

PS: I did the same for different TestStand versions, by reading out the TestStand system environment variable and if requuired changing the TestStand version via the command line of the TS Version Selector. This works fine, but there is no system environement variable that tells the currently active LV version.

[Norbert_B]

Tobias,

the "current active LV version" is simply the last development environment version you started. So instead of trying to get information on the active version, i would rather always start the correct version of LV ADE.

Another idea:

If the applications you start are "finished", why dont you create executables out of them? An EXE always loads the correct LV RTE version (if installed, if not, the EXE will not run displaying an error dialog).

Norbert

[TobiasT]

Hi Norbert,

in my applications I start an executable that starts the TestStand Engine and the TS sequences use LV VIs to perform steps. So I cannot start always the correct LV version, since LV is started out of the TS Engine and in TS I can only configure to use the currently active LV development version, but I cannot tell TS to use a different LV version (starting the requried LV Run-Time version can be configured, but as I said this is not possible for the LV development environment).

This might sound a bit complicated, but we use this environment for all our test tools in our site due to other advantages. To put the whole environment in an executable would be pretty complex and might be a far term solution but this is currently out of sight.

  Tobias

[Norbert_B]

Tobias,

which version of TS are you using?

And you know that for a TS deployment, you should make sure that the LV adapter is configured to be "Runtime Engine" rather than "Development Environment"?

Moving the TS module VIs into an executable is nothing i would do. I would rather leave them "as is" or create a packed project library (PPL, *.lvlibp) out of them.

Norbert

[TobiasT]

We are using different versions of TS, depending on when the specific project was started. So the current projects run TS 2012 SP1.

Now and then we add a new project on an existing station in our production. And then we have the problem I try to solve that the new project should run the new TS and LV version, but since we don't want to change the exisiting project the old project should continue to run the old TS and LV versions. As I said I solved this for TS, but not for LV so far.

Also for our new projects we do configure the LV Adapter to Runtime Engine, but we only recently got so far. So our old projects still run with the LV Development Environment. Hence I have the described problem.

[Norbert_B]

Hm, a very unpleasant situation, indeed....

Those different versions of LV:

1. Do they have different toolkits installed?
2. Are you sure that the current drivers are compatibel to all used LV versions?
3. Do all VIs still have their block diagrams included (so they can be recompiled)?

If the answer to 1 is NO and to 3 YES, the simplest trick would be to open all modules with the newest LV version always. In my experience, upconversion is not an issue if the versions are not too far from each other. Huge steps can introduce issue though, esp. including question 2.

Did you try searching the Windows Registry for a key showing the last started LV version?

Norbert

[TobiasT]

They might have different toolkits installed. Block diagrams on our old projects are included, but on our new projects we plan to not include them anymore. Driver compatibilty is a problem that we check each time we have this situation with different versions to make sure that it is working as expected. On one project I did not install the new driver, but kept the old one to make sure there are no changes to the old project.

It is a problem when we execute old code with a newer LV version than the version was used during the validation of the same code. We probably would have to do some revalidation with the newer LV version and this is what I try to avoid (working in the medical device industry means a lot of validation).

I could not find the current LV version in the Windows registry. But it must be located somewhere, since TestStand gives the Active LV Version in the LV Adapter configuration and when I open a VI in Windows Explorer the last used LV version is started.

So my question is where does TestStand and Win Explorer read this out, since then I could read the same thing out in my batch script.

[Norbert_B]

If you work in regulated environments (where  you require validation), there is imho only one valid answer to your dilemma:

Virtual machines.

This circumvents all questions you arose in the first place, but is quite an effort to keep up and running correctly.

Norbert

[TobiasT]

I fully agree that a virtual machine is the best solution for my problem. The VM must support full HW control of NI cards in PXI racks and of HW from other vendors and several years ago we could not get it running. This might be possible now, but we currently don't have the resources to spend the effort that you mentioned.

So I would be grateful if someone could tell me how to read out the currently active LV version.

[Norbert_B · Accepted solution]

OK, this is a very inofficial tip:

In the registry (regedit), you will find the key "HKEY_CLASSES_ROOT\LabVIEW.Application\CLSID". This Default key should contain some weird ID information.

If you search for this key, you find an entry for the key in the "HKEY_CLASSES_ROOT\CLSID" section.

If you have several versions of LV installed, there should be a key in the entry giving you the path to the active version of LV. Remember: This is the version you opened up the latest successfully!

Please note that the keys can change from system to system. Also different LV versions might use different keys as "routing information" to the path of the actual LabVIEW.exe.

hope this helps,

Norbert