NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to use 2 different LV-Runtimes at the same time?

Hello,

i have an old custom labview-OPUI that was built with Labview 8.2. It is used to execute teststand-sequences.

Now i updated to Labview 8.5.

When i set the labview-adapter in teststand to "Development-System" then i can execute the opui normally.

 

But when i set the labview-adapter to "Runtime 8.5" then the sequence in the opui halts at the first instrument-teststep.

 

Is this a problem because i use two different runtimes here? Runtime 8.2 for the OPUI and runtime 8.5 for the teststeps?

 

Thx

0 Kudos
Message 1 of 5
(2,036 Views)

Hi, I had the same problem. I investigated and made several trials but, bottom line, I had to convert all vi into the same LV version. In TestStand changing adapter you can select une LV RunTime version. Even if you select the highest LV runtime version, the VI compiled with with the other version does not work, they should be recompiled.

 

Bye  

0 Kudos
Message 2 of 5
(2,030 Views)

Check out this link:  See Post #8

 

http://digital.ni.com/public.nsf/allkb/D82FEAF0B4BA293A862575710053E252

 

If you have a sequence calling some VIs written in a later version of LabVIEW than the one which was used to build your operator interface and have the LabVIEW Adapter set to use that later LabVIEW Run-time Engine. In order to solve this problem, you have two options:

  1. If you have the LabVIEW Development System installed on the machine, you can configure the LabVIEW adapter to use the LabVIEW Development System. The LabVIEW Development system is able to compile VIs created in earlier versions of LabVIEW before running them. To change this setting:

    • In the sequence editor or operator interface select Configure»Adapters.
    • Select the LabVIEW adapter and click on the Configure button.
    • Select the Development System radio button in the window that appears and click OK to close the window.
  2. Mass-compile the LabVIEW operator interface and recreate the executable using the version of LabVIEW you are using. This way, you ensure that all VIs loaded in memory are in the same version as the LabVIEW run-time engine the LabVIEW adapter is configured to use

 

I ran into this problem when a developer attempted to update their LabVIEW VI version of the tests steps to LV 8.6 and the Operator Interface was built in LabVIEW 8.5.  They had to go back to LabVIEW 8.5 until the operator interface was rebuilt into a later version and verified.

 

Thanks,

PH

0 Kudos
Message 3 of 5
(2,023 Views)

Thanks for your answers.

The problem occurs at a customer-system.

I set up here a new PC with the same versions of LV/TS and the same OPUI which was compiled with an older version of LV. And: Here it is working!

 

Which means i have set the LV-Adapter to runtime to execute the teststeps in runtime-mode with the newest LV-runtime and at the same time the whole thing is executing in a labview-OPUI which was compiled with an older labview-version than the teststeps..

 

This means for me: If it is working on my debug-system then there must be a way to also make it running on the customer-system.

 

(If i set the labview-adapter to development, them the OPUI can also execute the steps. But i want it in runtime so that tha small labview-window does not appear)

 

0 Kudos
Message 4 of 5
(2,013 Views)

Hi Teds,

thanks for your link. I found now the difference between my dummy-system and the customer-system.

Your links point 8 says something withe Merge Errors.vi and this is exactly what i am using here.

After i renamed the vi to something else and use the new name in my teststeps it is working.

 

Question is only for me: Why is the compiled version of the OPUI using the MergeErrors.vi? I thought all Vis are compiled inside of the EXE-file?

 

Thx

0 Kudos
Message 5 of 5
(2,008 Views)