method to build exe with dynamically callable sub-vis

[LV_Pro]

I am having a "senior moment" here. I am trying to build an exe that can call arbitrary sub-vis placed in a separate directory, not necessarily at build time. They will be specified at runtime with a path in an ini file. The sub-vis are moderately complex (the make DAQmx calls, etc.) so they are just a high level vi using the built in "atomic" LabVIEW functions. This works fine, until I try and put it on a laptop that doesn't have the dev system, at which point I am getting a message that the target sub-vi is broken.

Just getting over a bought of the "Ithaca Crud" a nasty cold strain acquired in Ithaca, NY at my son's wedding, brain not firing on all cylinders!

[JÞB]

Let me help warm up that grey matter a bit.

The RunTime environment needs compiled objects.  So, put your dynamic vi's in a Packed Project Library and deploy the *.lvlibp ( a single file with the compiled objects you want to dynamically call)  Then call them by name (variable in the ini file) from the *.exe

Tim will probably show up and comment on the mechanics and best practices.

[LV_Pro]

Warm up is right, currently perched at a small table next to the door to an environmental chamber (engineering offices undergoing a complete makeover) and there has been an inordinate amount of traffic through in/out of chamber as another test system is being troubleshot.

Will give this a try.

Thanks!

[crossrulz]

---

Jeff·Þ·Bohrer wrote:

Tim will probably show up and comment on the mechanics and best practices.

---

Sure, now I have to make a reply...

I am actually new to the PPL mess myself.  I just rehashed a bunch of drivers to use PPLs so that I can have a plugin architecture and a HAL.  So I am sure others will come up with a bunch more lessons learned that I have not ran into yet.  If objects are involved (or common VIs), it gets even more interesting.

At this point, it is probably easier to just link to an article: Plug-in Architecture using Packed Project Libraries (lvlibp)

Also, be sure to use the Get Exported File Path (File IO->Advanced File Functions->Packed Library).  Since relative paths are used inside the PPL, things can move all over the place on you when you just add another subVI call that is in the middle of nowhere.  This allows for finding the VI you want inside of the PPL.

[JÞB]

---

@crossrulz wrote:

---

Jeff·Þ·Bohrer wrote:

Tim will probably show up and comment on the mechanics and best practices.

---

Sure, now I have to make a reply...

---

Well. of course we lowly CLD's expect to receive better advice from our lofty CLA's.

[crossrulz]

---

@JÞB wrote:

Well. of course we lowly CLD's expect to receive better advice from our lofty CLA's.

---

At least you finally realized your place in the world...

[550nm]

Hi LV_Pro,

I have no experience with the "packed-project library", however, I've deployed many LabVIEW applications (EXE's) that call VIs which are stored in LLBs.  The only "trick" is to be sure that all VI-dependencies are stored in the LLB with the VI. I use the use the app-builder "Source Distribution" to create the LLBs.  With DAQmx you'll need to uncheck "Exclude VIs from VI lib" (Properties\Additional Exclusions) in order to include the DAQmx dependencies.

If you were to place all the "high-level" VIs you want to call on a single diagram of a "container VI", then "compile" that container VI into an LLB, you could then call those "high-level" VIs at runtime.

When opening the VI, the name of the LLB appears in the VI path as if it were a directory name!

[LV_Pro]

Ok, built a packed library that has the two plug-in subVIs I want to use. Made my code extract/build the path to the lvlibp and it seems to work on my dev machine. Built an exe, selecting the ppl as a must include and sending it to the "data" folder in the exe level folder. Using calls to MSoft's DebugVIEW I can see that the paths to the desired VI in the PPL are called the same on either (I make the path relative to the app directory, both point at the ppl in either environment).  When I try and run it on the target machine, without a dev system, I am getting a composite error message: "Error 15 Resource not found"   "Error 55 Could not load packed library" I notice that the PPL icon on the target machine doesn't look the same as that on the dev machine, but it is identified as Type "LabVIEW Packed Library" on the target machine.

Give me some good news!I Woke up at 4:00AM to half my hotel room floor wet, including where my computer bag was sitting. Computer high enough in sleeve to be ok, some paperwork didn't fair as well. This week's trip is starting to feel, as a friend once described "like being nibbled to death by ducks!"

[LV_Pro]

After numerous attempts to rectify this, still no joy. Tried separating the individual acquisition vis into their own PPL and call those, but still getting the

"Error 15 occurred at Open VI reference in blah.vi

Possible Reason(s)

LabVIEW: Resource not found.

An Error occurred loading VI'NI_Tac.lvlibp:NI TAC Collection Ver 2.0.0.vi

LabVIEW Load Error code 55: Could not load packed library.

VI Path: C:\App|data|NI_Tac.lvlibp\Plugins\NI TAC Collection Ver 2.0.0.vi"

The program runs on the dev machine, using the same relative paths, but no go on the target (without the dev system installed). 

I got side tracked earlier fixing one of my associate's exe problem, where it wasn't happy with the 2017 LVRT installed, discovered the exe had been built by another of my associates in 2017, but 64bit. Argh! It took a bit to realize that, no one is working in 64bit (for all of the reasons) and I am still doing most of my dev in 2015, as that is the LVRT installed on most of our lab's 10 Toughbooks.

[550nm]

re: "The program runs on the dev machine, using the same relative paths, but no go on the target (without the dev system installed)."

Did you remember to install DAQmx Runtime on the target?