LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Test Loader Loading Plugins PPL calling another PPL

Solved!
Go to solution

Hello All,

 

Got myself into some dependency path problems with a compiled EXE when dealing with a PPL calling another PPL and hope y'all can help out.

 

My basic setup:

  • A Main.vi that is a test loader. This Main.vi scans a "Test_Items" folder for lvlibp extensions and display them for users to select
    • I choose this simple plugin style so tests added and debugged
  • Inside the "Test_Items" folder are tests compiled into PPLs
    • Each test PPL is built from just a library containing 1 file, the test vi. For example, my battery charge test, "Battery_Charge_Time" library contains just a VI of the same name, compiled into a PPL of the same name.Mikejj_0-1638888864313.png

       

  • Here comes the part that is messing up my Main EXE: Each test VI is then in turn calling another PPL, my LVOOP based HAL abstract parent class. The HAL is in external libraries directory separate from where the Main.vi project resides. From here I have 2 options, both present its own problem:
    • I compile my test PPLs using "Exclude dependent packed libraries" unchecked and I get all the HAL duplicated in the build folder of the test PPLs
      • I then compile my Main.vi and always include my test PPLs
      • I now have a Test_Items folder full of a mix of test PPLs and HAL PPLs and dirties my selection list in the Main.vi
      • I can still pick out the test from the list and load them, but again, the list is full of HAL components I don't want populated
    • I compile my test PPLs using "Exclude dependent packed libraries" checked and I get no HAL duplicated
      • I then compile my Main.vi and always include my test PPLs
      • I now have a Test_Items folder of only test PPLs
      • I pick out the test I want and load it and it actually works, BUT this is a trick. I know it is working because the test PPLs still have an internal link to the HAL's path in my external libraries folder. This means when distributed on a computer where the libraries folder doesn't exist will cause it to break. Sure enough I tested this by:
        • Temp. renaming the HAL folder and reloading the test PPL and the file search dialog shows up briefly...can't find the HAL PPLs and loads a broken test VI

Can anyone help me out and enlighten me on a way to get working test PPLs without dirtying the Main.vi loader list?

 

Thanks,

Mike

 

 

0 Kudos
Message 1 of 5
(1,859 Views)
Solution
Accepted by topic author Mikejj

You need to create some "known folder" for where your library PPLs will live. This can be something like a folder in the ProgramData folder or the Public Application Data folder. For installation purposes don't keep your development PPLs there but in a separate folder that is the same relative path distance from the distribution folder. Also, the final location of your installed application must maintain that same relative path to the distribution PPL folder. Sounds complicated but it works. Take a look at my NI Week presentation regarding PPLs. Mine is the first one listed.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 2 of 5
(1,821 Views)

Additionally, you might want to consider using a package distribution to make sure all of the libraries go to the right location.


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 3 of 5
(1,813 Views)

Hi Mark,

 

Thanks, your presentation really helped clarify things for me in regards to PPL. The keys to fixing the issue for me was: separating the installer and PPL build specs into two separate projects

and

define where the dependencies are going in the build spec "Destinations".

 

Thanks again Mark!

 

-Mike

0 Kudos
Message 4 of 5
(1,736 Views)

@Mikejj wrote:

Thanks, your presentation really helped clarify things for me in regards to PPL. The keys to fixing the issue for me was: separating the installer and PPL build specs into two separate projects

and

define where the dependencies are going in the build spec "Destinations".


Another thing that might help you out is the LabVIEW Solution Builder.  It is a build tool to building dependent PPLs in the same project.


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 5 of 5
(1,728 Views)