LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV 7.1.1 vs 7.1 Run-Time conflicts

Is it just me or is the upgrade to 7.1.1 a bit quirky?

NI has chosen to keep the same run-time engine folder (7.1), but has changed the run-time.

First of all the 7.1 run-time did not get removed properly so the first time I build an application it gave an error during startup, saying that the resource file had the wrong version. I had to uninstall the run-time, delete the files that refused to be uninstalled, and then install the 7.1.1 version...fine enough. That part might very well be a local phenomenon(?).

However, if I run an application built in 7.1, the application launches with the 7.1.1 run-time, but it seems to have a problem with some dynamically loaded external VIs (7.1 as well), and upon exit I get a VI initialization window. I assume this is due to the external VIs being 7.1 not 7.1.1, a bit too soon to tell though.

If the 7.1.1 Run-Time has changes that might not make it 100% compatible with 7.1 version applications it would have been better if the new run-time installed itself in a separate directory.
Message 1 of 3
(2,879 Views)
i want to put forward one point regarding dynamically loaded VIs.

if you are dynamically loading the VI then the path in executable is interpreted differently. when you add dynamically loaded VI(suppose LoadMe.VI) in application its path becomes c:\app.exe\LoadMe.VI where c:\app.exe is the path of your application

Tushar Jambhekar
tushar@jambhekar.com

Jambhekar Automation Solutions
LabVIEW Consultancy, LabVIEW Training
Rent a LabVIEW Developer, My Blog

0 Kudos
Message 2 of 3
(2,849 Views)
Yes, I am aware of that (If you work with .llbs just strip the path twice and it will still work in built apps, or even better - use the "Current VI's parent directory function" in OpenG Toolkit).

This is for applications that have been programmed properly and work fine with the LV 7.1 RTE.
0 Kudos
Message 3 of 3
(2,839 Views)