Create application with multiple LLBs

[TLamb64]

I have an LLB with several VIs. The start VI is defined. The start vi calls several VIs from different LLBs. How do I add those LLBs to the build specifications in the build project?

~~~Tracy

[altenbach]

If these VIs are dependencies of the toplevel VI, they will be included automatically. How do you "call" these VIs?

[Kyle97330]

I would note that for a number of reasons, it's advised to no longer use LLBs in your normal usage.  If you don't have a strong reason to use them (and "I got them from someone else" is not a strong reason) then I would advise you to convert them to standard files and folders.

The only case I can think of to use an LLB in the current era is if you have created an open-source library and want to make it easier to distribute and use.

[Andrey_Dmitriev]

---

@TLamb64 wrote:

I have an LLB with several VIs. The start VI is defined. The start vi calls several VIs from different LLBs. How do I add those LLBs to the build specifications in the build project?

~~~Tracy

---

It is better to convert LLBs to individual VIs (Tools → LLB Manager...) and then create *.lvlib libraries from these. And yes, the dependencies of the top-level VI are usually included automatically, regardless of whether they are in LLBs or LVLIBs.

[Andrey_Dmitriev]

---

@Kyle97330 wrote:

I would note that for a number of reasons, it's advised to no longer use LLBs in your normal usage.  If you don't have a strong reason to use them (and "I got them from someone else" is not a strong reason) then I would advise you to convert them to standard files and folders.

The only case I can think of to use an LLB in the current era is if you have created an open-source library and want to make it easier to distribute and use.

---

I am still using LLBs for application distribution. I "borrowed" this architectural idea from Vision Builder for Automated Inspection (the same approach used in Vision Assistant) and have been pretty happy with it. There are two reasons why I haven't migrated to packed libraries.

  The first reason is simply legacy-I have a project with around 10,000 SubVIs in 350 PlugIns, deployed on hundreds machines and migrating would require a significant investment of time, with no added value for customers.

  The second reason is technical: I can control exactly what is included in LLBs and what is not. If you look at the build specification, you’ll see an "Always Excluded" list in source distributions, which is missing in packed libraries. In packed libraries, you only have an "Always Included" list, but no exclusion list. I use this exclusion feature to keep core VIs out of the distribution.

  But that’s a completely different topic. I should probably prepare and share a small example of plugin architecture with LLBs, and discuss with the community how to elegantly migrate to other solutions.

[TLamb64]

I've attached several files...

Project Dependencies.bmp, shows the build dependencies.

Project Build Specs.bmp shows the build specifications, source file settings

CalScript Runner Block Diagram.bmp, shows the block diagram.

CalScript Runner1.bmp, shows what the application should look like with the pink toolbar at the top. This works correctly when I run the top-level vi from the development environment. 

CalScript Runner2.bmp, shows what the application actually looks like after the .exe is built. The pink toolbar does not show up. 

The VIs that control the pink toolbar are in BT3500.llb.  The individual VIs are listed in the project dependencies, but BT3500.llb (the library with the toolbar VIs) is not in the dependencies list. All of the other VIs used in the top-level VI are listed in the dependencies, and are also in different LLBs (instrument drivers).

~~~Tracy

[Andrey_Dmitriev]

---

@TLamb64 wrote:

...after the .exe is built. The pink toolbar does not show up.

---

It looks like a typical issue caused by differences between the development environment and the built application. To get started, you can read Developing and Distributing an Application.

This may be applicable

Verify that the paths used in the development environment still behave correctly on destination computers. If the project loads VIs dynamically, use relative paths, instead of absolute paths, to specify the location of the VI. Because file hierarchies can vary on different computers, relative paths ensure that paths function correctly in both the development environment and the destination computers on which the application runs.

and this as well

Explicitly include dynamically loaded VIs in the build specification.
If a VI loads other VIs dynamically using the VI Server or calls a dynamically loaded VI through a Call By Reference or Start Asynchronous Call node, you must add those VIs to the Always Included listbox on the Source Files page of the Properties dialog box for your application.

[altenbach]

---

@TLamb64 wrote:

The VIs that control the pink toolbar are in BT3500.llb.  The individual VIs are listed in the project dependencies, but BT3500.llb (the library with the toolbar VIs) is not in the dependencies list. All of the other VIs used in the top-level VI are listed in the dependencies, and are also in different LLBs (instrument drivers).

---

Everything that is in the project, but not in the dependency list because it is called via a reference just needs to go into the "always include" collection. It does not matter if it is in an llb or not.

Nobody here likes to stare at truncated bmp files, but the code contains some questionable constructs. For example your error wire formed a loop and a feedback node got inserted automatically. I strongly suggest to clean that up.

In this particular case you have a subVI that creates a reference to be inserted, but that subVI depends on the error from the insertion node. Without the feedback node, the subVI cannot start until the insertion is complete, but the insertion cannot start until the subVI is complete.

A bad feature is that LabVIEW (by default) automatically inserts a feedback node if such a circular dependency is detected, meaning that the error propagation does not do what you think it does. For details, read this idea and the older ideas in the links.

[TLamb64]

I got rid of the feedback node by running the toolbar first, then inserting the VI using an invoke node.

The same problem persists... it works fine in the development environment, but when I build then run the executable the pink toolbar does not display. The fact that the toolbar does not display makes me wonder if any of the other SubVI's compiled into the executable. The executable file size is 762K ... seems kind of small if all the other VIs are included.  All of the subVIs are in other llbs, and they are all listed on the dependencies list. How do I add these to the "always include" list in the build specifications?

The customer has LabView Runtime, but not the same file structure as my development machine.  

~~~Tracy

[altenbach]

---

@TLamb64 wrote:

I got rid of the feedback node by running the toolbar first, then inserting the VI using an invoke node.

---

This will only clean up the code, but does not fix your other underlying issues. You did not say if you did a correct "always include" in the build specifications. did you?