LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamically loaded VI using a subVI included in the .exe

Solved!
Go to solution

Dear community,

I'm trying to figure out how I could make custom libraries that my exe would load dynamically, and those external libraries could use as subVIs some VIs that are "included" in Main.exe

 

I made this simple diagram to show how I see it, perhaps someone already faced that issue and found some workaround technique to make it possible.

 

The idea is to keep Main.exe as standard as possible, without having to make a new build each time we make slight new features in custom.vi

 

Cheers!

 

Untitled.png

0 Kudos
Message 1 of 15
(2,687 Views)

You can simply call the sub.vi in your custom.vi and load the custom.vi dynamically. I don't understand what is the issue here. Are you facing any problem calling the dynamic VI (custom.vi)?

-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 15
(2,684 Views)

Yep, when you load the VI I think it will first look in memory for any dependencies, then look in the paths stored in the file (ie ../blah.vi for a VI in the same folder) and then finally look at the LabVIEW search paths (vi.lib in the dev environment, I don't think there are any extra search paths in the runtime env). Just use VI server to load it and everything should be OK.

 

If you are concerned about making this deployable, you can build the "custom" vis into an LLB (source distribution) and exclude the VIs you expect to load in your main VI. You can also build your custom stuff into a packed project library (basically a dll), but you can run into dependency issues pretty easily there (source).

 

And of course if you want to take it a step further, you can implement your exe using an interface class and load up an instance of "custom.vi" as a class using something like the factory pattern: https://decibel.ni.com/content/docs/DOC-13724

0 Kudos
Message 3 of 15
(2,663 Views)

Hi P@Anand,

my concern is only about the sub.vi that is no longer on the hard drive which results into a broken custom.vi

 

Main.exe contains sub.vi but also calls dynamically the actual custom.vi from a separated library on the hard-drive. custom.vi still looks for sub.vi but I'm just trying to figure how to reference it to main.exe available VIs in run-time.

0 Kudos
Message 4 of 15
(2,618 Views)

Sorry seems I'm getting mixed up these days!

 

Can you build an installer?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 15
(2,610 Views)

This is not all that difficult, just your requirements aren't perfectly clear.

 

For this to work well you'll want your Main.VI to open a reference to the custom.vi by using the path to the VI on disk.  When I do this type of thing I try to use a recursive file list, and use the paths to the file, knowing that it exsits.  Obviously if you try to open a reference to the VI not there it will generate an error.

 

Then using that reference you can use the Call By Reference node, calling the VI dynamically with normal inputs and outputs.  For this to work you'll need the connector pane of the dynamcially loaded custom.vi to be known.  Again if the connector pane of the custom.vi doesn't match the connector pane of the Call By Reference node an error will be generated.

0 Kudos
Message 6 of 15
(2,603 Views)

Hi Hooovahh!

thanks for your answer, my problem is not to dynamically load a VI.

 

The thing I need to know is: custom.vi uses sub.vi which is inside Main.exe, how can we get it work?

0 Kudos
Message 7 of 15
(2,594 Views)

AHHH, okay well you can go in the reverse, where custom.vi also loads the subVI dynamically but it does so using the VI Name not the path.  The Open VI Reference accepts the full VI name not just the path.  So if you provide the name of a VI to use, and that VI is already in memory (which it will be because it is loaded from the main.vi) then it uses that.  

 

That's one option.  You can also get the path to the subVI in the EXE like C:\my application\program.exe\subVI I want.vi but the location of the VI in the EXE isn't flat starting in 2009 by default so the path in the EXE may not be known.

0 Kudos
Message 8 of 15
(2,589 Views)
Solution
Accepted by topic author JimChretz

You don't need to worry about it.  As was already stated, the version of the subVI that is currently in memory will be used.  If you don't believe me, give this a try.

 

I have a VI that calls subVI and another VI that is called dynamically that also calls the subVI.  The subVI just keeps track of how many times it was called.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 15
(2,566 Views)

That's cool if the VI is referenced somewhere in main.vi but if I modify your example by removing the direct call of sub.vi, it's not working anymore, even if I put it in "always included" list.

0 Kudos
Message 10 of 15
(2,513 Views)