LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

method to build exe with dynamically callable sub-vis

Solved!
Go to solution

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!

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 1 of 21
(5,181 Views)

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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 21
(5,178 Views)

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!

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 3 of 21
(5,167 Views)

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.


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 4 of 21
(5,159 Views)

@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.Smiley Happy


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 21
(5,155 Views)

@JÞB wrote:

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


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


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
0 Kudos
Message 6 of 21
(5,137 Views)

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!

 

0 Kudos
Message 7 of 21
(5,112 Views)

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!"

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 8 of 21
(5,077 Views)

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.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 9 of 21
(5,044 Views)

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?

0 Kudos
Message 10 of 21
(5,025 Views)