EXE's, Dynamic Loading of VITs, and seperation of source and compiled code

[JonJay]

I have recently been tasked to determine why an executable has stopped working for Labview 2011 when it worked fine for 2009.

The program is an in-house test executive which is based on a plug-in architecture using VITs. As far as I can understand the executable is simply a program that dynamically calls the main test executive vi. From this main test executive multiple services, applications, and editors are loaded in through use of static file path names from INI files and then dynamically opened. 90% of these are VITs.

I know that in Labview 2011 the runtime engine has issues opening vis like this due to the separation of source and compiled code. However after looking through the 1000+ vis all of them do not have the check box for the separation checked.

When I currently try to run the exe I get back a dialog stating that every single vi within the main test executive is missing.

So where do I even start? I’ve searched the forums and user groups for information and as far as I can tell the architecture and way the test executive runs the plug-ins is the worst possible way to operate. However there are over a hundred applications built upon this executive so it’s not possible to rewrite it.

If anyone can point me in the direction of progress I’d be greatly appreciative.

[tst]

---

@DukeGriffin wrote:

When I currently try to run the exe I get back a dialog stating that every single vi within the main test executive is missing.

---

Well, if the error says the VIs are missing it probably means that it can't find them where it expects to find them, so that would be the first thing to look at.

Is the MTE called dynamically as well?

What happens if you call it statically?

Does it run from inside LV?

Are the missing VIs user VIs or VIs from vi.lib?

Are the paths really correct?

If the problem is with the dynamic VIs, have they been resaved in 2011?

[FraggerFox]

*If you have the main project from which the build was made:

Did you try doing a mass-compile of the project, view the compile report, and fix the BAD VIs (probably due to paths) it reports? Once you mass compile, and resolve all the missing issues/dependencies, make a build and see if the problem still exists. Post back here if this doesn't solve the issue.

*If you do not have the main project from which the build was made:

follow tst's instructions

It would be a better option to manually search the missing VIs and then put those VIs in the path it searches (possibility of file/folder moved after installation)

[Ben]

Is ther a sperate build for the plug-ins?

I would at lest put some indicators on the FP on the main to show where it is looking for the dynamics.

THere was also a change in the way VI's were saved (can't recall which version) but look for the option to save files using the ... 8.6(?) format.

Ben

[JonJay]

I do have access to all of the files and have run Mass Compile on all of them and remove/fixed all the Bad/Broken VIs. This didn't help.

I dont think its a linking issue, the files were upconverted from 2009 straight to 2011 and it just stopped working. I wrote a quick "side" Main vi that is dynamically called and after looking at the paths it appears to point to the location correctly, it just doesnt open up properly afterwards.

If I run the "launch main" (the one that calls the actual Main VI dynamically) as a VI in the development system it runs perfectly fine with no issues or erros. As soon as I build the "launch main" vi into an exe and run it dynamically loads the Main VI and throws an error that every subvi is missing.

[JonJay]

• Is the MTE called dynamically as well?

Yes, a mini launch vi dynamically loads the main vi based on a path recieved from an INI file.

• What happens if you call it statically?

This would defeat the purpose that they origionally wanted, which is to be able to modify almost any VI that is part of the system and just run the mini EXE to allow all of it to run in the runtime engine. if I added it statically it would require a lot of code to be incorporated into the EXE and thus make it un-editable

• Does it run from inside LV?

Yes, if I run the launch vi within LV it dynamically loads the Main VI correctly and no issues are found.

• Are the missing VIs user VIs or VIs from vi.lib?

Any subvi is found missing, both ones we built in user.lib and many from vi.lib

• Are the paths really correct?

I checked with a test Main VI to check if the paths were working correctly and they appear to be. I even created a very very basic Main VI to be called dynamically with a single self written subvi in it and it states that that subvi is missing.

• If the problem is with the dynamic VIs, have they been resaved in 2011?

Yes, when they updated to 2011 they mass compiled everything and made sure everything was upconverted.

[tst]

---

@DukeGriffin wrote:

• Are the missing VIs user VIs or VIs from vi.lib?

Any subvi is found missing, both ones we built in user.lib and many from vi.lib

---

If I had to bet on something, it would be that - when you build an EXE, the default behavior is for vi.lib and user.lib (which are both logical folders) to be inside the EXE. I'm guessing the EXE is trying to look for those VIs in there.

That said, I don't know why this should be different between 2009 and 2011. This would be my guess, but I don't know why that should affect it.

If this is the case, the executable might work if you place it in the LabVIEW folder (this should at least confirm that's the problem). Another thing you can try is the 8.x flag Ben mentioned, which can be found in the Advanced page in the app builder, although that might also break your relative paths.

I'm not sure what else can be done about it. I don't know of any INI key which will tell the EXE where the logical folders should be. You do have the search paths INI key, which probably will work, but that means the VIs will have to search for their dependencies every single time you load them.

---

DukeGriffin wrote:

• What happens if you call it statically?

This would defeat the purpose that they origionally wanted, which is to be able to modify almost any VI that is part of the system and just run the mini EXE to allow all of it to run in the runtime engine. if I added it statically it would require a lot of code to be incorporated into the EXE and thus make it un-editable

---

Actually, it wouldn't make the code uneditable - it would just mean you need to rebuild the EXE for it to have the new code. This is actually the usual recommended practice - it is generally considered a bad idea to use the source code directly in the working system - normally you would have some sort of build step to make the code runnable in the working system (even if it's a plugin which is kept as a set of VIs).

[飞雨天]

you should print the subvi's path out in some way, for example: in txt file, front panel, etc.  the labview 2011 uses a different excutable layout for all subvis.

[JonJay]

I'll look deeper into the paths and the possible location change. I'll also try running the EXE from the Labview folder to see if this helps at all.

---

DukeGriffin wrote:

• What happens if you call it statically?

This would defeat the purpose that they origionally wanted, which is to be able to modify almost any VI that is part of the system and just run the mini EXE to allow all of it to run in the runtime engine. if I added it statically it would require a lot of code to be incorporated into the EXE and thus make it un-editable

---

Actually, it wouldn't make the code uneditable - it would just mean you need to rebuild the EXE for it to have the new code. This is actually the usual recommended practice - it is generally considered a bad idea to use the source code directly in the working system - normally you would have some sort of build step to make the code runnable in the working system (even if it's a plugin which is kept as a set of VIs).

---

Sadly I'm a contract that came into this bad practice. Everything built and programmed here is based on this idea of having almost everything editable at runtime. I would love to change this paradigm but that would require lots of recertifcation and lots of testing. Sadly I have to work within my restrictions.

[Ben]

look again on the build option to use the 8.X file format.

THe new builds pack the sub-VI differently resulting in new file paths. Using the advanced option lets you use the old file format.

Ben