Built executable won't include dynamically called subVIs (LabVIEW 2014 SP1)

[fede_c]

Hello,

I am using LabVIEW 2014 SP1 32-bit on Windows 7 and I am trying to build an application executable.

At some point, the application makes a dynamic call to a subVI; this one is dynamically called using the Open VI Reference function, which requires a VI path to be wired to its input. In this particular case, the VI path is not known at build time, but at runtime; in fact, the path of the VI is stored in a configuration file that is read by the application at runtime and then passed to the Open VI Reference function (see the attached diagram).

I am having a problem building my application, because it seems that the dynamically called subVI won't be included in the build process, even if it is added to Always Included source files list. Indeed, once the application is built, if I delete the subVI.vi file and run the application executable, this one won't be able to find it, as if it wasn't already part of the executable.

I have developed an almost similar application with LabVIEW 7.1 on Windows XP, but I don't experience the same problem with that application.

Am I missing something? Is there a workaround to the problem?

Thank you.

[MarcDub]

First, a picture of a block diagram is generally pretty bad to try to help but a generic drawing, it does not help at all. So, if you want to increase the likelihood to get help, include real code, no picture. If you cannot share the code as is, try to reduce the code to the simplest expression that still generates the problem; you might actually solve the problem by yourself.

Second, your problem can be easily solved using the Factory pattern but that involves using Object Oriented Programming. It can be done without OOP but I could not easily find the reference.

Not knowing what you have done so far, I would invite you to look at the various examples provided with LabVIEW. Search for "Open VI reference" and look at Asynchronous calls. You don't have to call asynchronously, you can also just use the function "Call by reference".

[zou]

After built exe, path changed.

What path you use for the sub vi in exe?

As for workaround, make the sub vi a direct call in any of your vi, and put it in a case which never get used.

[billko]

---

@zou wrote:

After built exe, path changed.

What path you use for the sub vi in exe?

As for workaround, make the sub vi a direct call in any of your vi, and put it in a case which never get used.

---

Curious: The compiler won't optimize it out?

[zou]

---

@billko wrote:

---

---

Curious: The compiler won't optimize it out?

---

It probably will if you wire a constant to the case.

But if you create an additional case to your message loop, then I doubt the compiler will be able to remove it.

[fede_c]

---

@zou  ha scritto:

After built exe, path changed.

What path you use for the sub vi in exe?

As for workaround, make the sub vi a direct call in any of your vi, and put it in a case which never get used.

---

I use an absolute path.

I solved with a workaround, that is (IMHO) rather raw.

In the VI that makes the dynamic call to subVI I put a case structure whose selector gets the subVI name string; each case contains a Static VI Reference linked to a particular subVI. The builder, still configured with the Always Included list filled with the subVIs, generates an executable which runs as expected: doesn't care of referenced subVIs because their code has been included in its binary.

[wiebe@CARYA · Accepted solution]

---

@fede_c wrote:

---

@zou  ha scritto:

After built exe, path changed.

What path you use for the sub vi in exe?

As for workaround, make the sub vi a direct call in any of your vi, and put it in a case which never get used.

---

I use an absolute path.

I solved with a workaround, that is (IMHO) rather raw.

In the VI that makes the dynamic call to subVI I put a case structure whose selector gets the subVI name string; each case contains a Static VI Reference linked to a particular subVI. The builder, still configured with the Always Included list filled with the subVIs, generates an executable which runs as expected: doesn't care of referenced subVIs because their code has been included in its binary.

---

Unless you need a clone of the dynamic VI, you can simply use the static VI reference...

Of course, this is all starting to look like DIY dynamic dispatch... 

[zou]

---

@fede_c wrote:

---

I use an absolute path.

---

I don't know if you familiar with the path name change issue.

Use absolute path doesn't immune from the path change problem.

After built, your path should include the exe name as a folder name.

[fede_c]

---

@zou  ha scritto:

---

@fede_c wrote:

---

I use an absolute path.

---

I don't know if you familiar with the path name change issue.

Use absolute path doesn't immune from the path change problem.

After built, your path should include the exe name as a folder name.

---

I created a project from scratch. In this Dynamic subVI Call.lvproj new project (located at C:\Dynamic subVI Call Project\), the Main.vi calls the Launcher.vi, which in turn makes a dynamic call – through Open VI Reference function – to a subVI called Pinger.vi. In detail, Launcher.vi uses Read from Text File function on C:\Dynamic subVI Call Project\Init.txt text file, that contains the single text line C:\Dynamic subVI Call Project\Paths.txt; after this string has been read, Launcher.vi uses it to locate the 'pointed' text file and uses Read from Text File function again on Paths.txt text file. This one contains the string C:\Dynamic subVI Call Project\Pinger.vi that Launcher.vi converts to path type (String to Path function) and then passes to Open VI Reference function. Then I create the build specification choosing Main.vi as startup VI and adding Pinger.vi to Always Included list. Once the Main.exe executable is built, I run it and, as I expected, the application runs flawlessly, even if I delete Pinger.vi.

That is the behaviour I would expect from the original project.

[tst]

---

@fede_c wrote:

---

Once the Main.exe executable is built, I run it and, as I expected, the application runs flawlessly, even if I delete Pinger.vi.

I don't see how, as this seems to be a complete mishmash. My guess would be that the VI is actually contained inside the EXE (which would happen by default when you include it in the build) and is already loaded in the EXE, in which case opening a reference by path to another VI will load the original VI (I think. See point 3 below).

In general, there are a number of things which changes between LV 7.1 and LV 2014 which could affect your scenario, such as:

1. In LV 7, VIs inside the EXE were saved at a single level. In later versions, they are saved using their original hierarchy by default.
2. In LV 2014, VIs can have their source code separated and unless you account for that, loading VIs from EXE can be more complicated.
3. At some point (I think LV 8.0), opening a reference by path to VI A, where VI A was already loaded from a different path, changed either to return an error or to stop returning an error and just use the loaded VI, but I don't remember which way.

I would suggest that you explain what your actual use case is, as I agree with Wiebe that it's likely there are other solutions, such as static VI references or dynamic dispatching. Loading VIs directly from an EXE is not a scenario I think I ever actually needed, even with plugins.