LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to find & repair the missing Subvis in EXE ?

Sorry, forgot the pic in tension... Smiley Sad
- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 21 of 29
(2,019 Views)
I just went an looked at the actual run-time version and it is 7.1.1 but MAX lists it as 7.1 as well. As I mentioned, the 7.1 run-time is on your LabVIEW 7.1 CD (not the device driver CD). It's in Components\lvruntimeeng. There's an lvruntimeeng.msi there. I'm pretty sure you will have to uninstall the 7.1.1 run-time before the old version can be installed.
Message 22 of 29
(2,009 Views)

Dennis, Problem solved, Sir ! Smiley Very Happy

I followed the procedure you told me & it was seamless re-installation thereafter. I ll elaborate what I ve done so far...

I uninstalled LV 7.1.1 RTE thro' Control Panel Add/Remove Programs. It also uninstalled the Dependant components, viz, LV & LV App Builder also.

Then, I first installed LV 7.1 RTE alone from the LV 7.1 PDS CD. Then I installed LV 7.1 PDS from the same CD.

Now I verified the version of the lvrt.dll in the National Instruments\Shared\LabVIEW Run-Time folder & it was 7.1 intact. I skipped installing the Device Drivers CDs.

I built the EXE of my project & it started to run smoothly, without any error pop-ups. Smiley Happy

I restarted my PC once & this time I straightaway installed the Device Drivers CDs of Nov 2006, keep opening my National Instruments\Shared\LabVIEW Run-Time folder to see what happens...

It deleted the lvrt.dll of LV 7.1 & then replaced it afresh with lvrt.dll of LV 7.1.1.

Now, I again built one EXE & it also started to run smoothly. Smiley Happy

So, what I could infer was, either the original Device Drivers that came with the LV CD need to be installed first & then replaced by the later dated ones or LV & LV RTE alone are to be installed first skipping the Device Drivers & installing them seperately thereafter.

This allows the installer to write all the versions of the LV RTEs that are installed in the system to be written somewhere in the Windows Registry seperately. If the later dated Device Drivers are installed alongwith LV on the first instance itself, it overrides the original RTE installed by the LV CD & is overwritten with the one that comes in the Device Driver CD without seperate Registry settings.

I may be wrong in my analysis, but the problem got solved anyhow. Smiley Wink

IMO, NI has to come up with some correct procedure for the installation of LV & LV RTE along with it. It should not keep the RTE in various CDs. It ll be good to keep the RTE only in the Device Drivers CDs because anyhow people installing the FDS cannot build the EXE using the App Builder, only those who have got the PDS version alone can build the EXE, I think...

Please correct me if I m wrong.

So, the RTE that is to be used only by the EXE or the installer, needs to be kept only in the Device Drivers CDs. This will perform a trouble-less installation because somehow they can check the current PDS version of LV installed in a PC & then install the corresponding version of the RTE. If more than one PDS version is found to be installed, they can prromot the user to choose the various versions of the RTE.

Expecting experts' opinions regarding this...

- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 23 of 29
(1,989 Views)
Still 2 more screenshots for today.
- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 24 of 29
(1,987 Views)

Pratha,

I’m glad to see you found a solution to your problem. Your understanding of the problem seems to be correct (it works right). Many customers of LabVIEW run into similar problems when installing/using multiple versions. It is always best to install and use the latest version of LabVIEW while not deleting an older version. Additionally, the latest version of LabVIEW, 8.5, has had significant improvements in .llb usage and building applications.

Charlie M.

 

Charlie M. CLD
0 Kudos
Message 25 of 29
(1,966 Views)

Charlie wrote "It is always best to install and use the latest version of LabVIEW... " Smiley Surprised

I must strongly disagree. Using the latest and greatest version is only practical if there is only one application being supported.

Please see this thread where Kennon indicates that this is a problem that should be fixed!

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 26 of 29
(1,958 Views)
Good link, Ben. Thanks for that.
- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 27 of 29
(1,944 Views)

I have encountered the same probelm when using the lvanlys.dll in a pgm.  What I found is it does get included as one of the dependancies and put into the correct sub folder.  However if yuo read how LV handles DLL's it says that it only includes the top level DLL and if that DLL calls other DLL's you will have to include those manually.  I tried to read the lvanlys.dll in notepad to see if it calls other DLL's and there are several other DLL filenames in there.  I included all of the DLL's that I could find but there were still some that I couldn't find and it still doesn't work.  The bottom line is I don't think the lvanlys.dll will work in an exe until we know all of the sub DLL's it calls and are able to manually include them in the build

0 Kudos
Message 28 of 29
(1,696 Views)

Wafer Map wrote:

..... The bottom line is I don't think the lvanlys.dll will work in an exe until we know all of the sub DLL's it calls and are able to manually include them in the build


That is simply not true. There is no need to manually include anything. Go to your installer properties and post what files are part of the data folder. When you run the installer, are all of those files there on the pc? Exactly what happens when you run the exe?

0 Kudos
Message 29 of 29
(1,689 Views)