LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to have a lvlibp in the project but do not have it in tghe memory?

I'm currently working on a rather big project , that should finish as a single lvlibp with an installer, that copies all the dependencies, a TestStand sequence etc.

 

In my project I have an lvlib with all my code inside. Moreover in the project I have included the lvlibp (of course outside thge lvlib), a build tool etc. Now, when I want to build (pack) the library I get a following error:

 

 

The following packed library is in use or loaded in memory: Control_R2.lvlibp. LabVIEW cannot build packed libraries that are in memory.

 

How to unload it from memory? I can't remove it from the project, because the next step is to make an installer using this lvlibp.

 

Nikodem

0 Kudos
Message 1 of 5
(3,203 Views)

If I'm following you correctly, you are creating a conflict in your project. It appears you have a structure similar to this:

  • Top Level Project
    • Source Code for Packed Library
    • Packed Library
    • Build Specs
      • Top Level Application Build Specs
      • Packed Library Build Spec

When LabVIEW loads a project into memory, it loads all items of the project as well as all dependencies. This means that the only way to "unload" it from memory is to remove it from your project and not call anything in the packed library (which defeats the purpose).

With a setup like the above, you would want it to be like this:

  • Top Level Project
    • Packed Library
    • Build Specs
      • Top Level Application Build Spec
  • Packed Library Project
    • Packed Library Source Code
    • Build Specs
      • Packed Library Build Spec

Part of the idea behind using a packed library is that when you compile the source code into a packed library, it is considered a binary release (just like an executable). In this scenario, your top level application would always use released binary code rather than using source code. If you follow the second structure, your build process would first require building the packed library in it's project and then building the Top Level Application with the most recent packed library build.

Message 2 of 5
(3,178 Views)

As you said, your packed library file is included into project. Also I guess some VIs linked to the packed library, not to the lvlib.

Remove lvlibp from project. You will add it into installer from build specifications, not as a file from project folder.

If you are using lvlib(p) in different project, make sure it does not include original lvlib (in dependencies also).

0 Kudos
Message 3 of 5
(3,162 Views)

Yes iZACHdx, this is exactly the structure of my project (the firts one). I wanted to have everything in one project in order to be able to just run Build All to trigger the build of the executable (lvlibp) and the installer afterwards (an because of that I have to have the packed lubrary in the project). I hoped that if I will move it outside the library source there will be no problems.

 

Is there any other way to do that, so that I would have a single project with single Build All?

0 Kudos
Message 4 of 5
(3,152 Views)

The depdency hierarchy that you have created prevents you from doing what you are asking and without knowing more about the setup of your application and ultimate end-goal, it is hard to provide an alternate recommendation. I can, however, point you to a good discussion of the issues that you may run into when using packed libraries here: http://labviewjournal.com/2011/10/packed-project-libraries-part-2/

 

There is an external tool that can help control your build process from a single location and get you closer to your desired functionality: https://www.mooregoodideas.com/mgi-solution-explorer-2/

0 Kudos
Message 5 of 5
(3,144 Views)