LabVIEW Library (.lvlib) Tutorials and General Basics

[rusky]

Hello all,

I am really struggling with the use of libraries in LabVIEW (2017).

I've read the native help pages, but they never scratch the surface of the whys and hows of libraries.

I'm familiar with LabVIEW but have always floated outside of needing or seeing the point of libraries.

Having done LV Cores 1 to 3, which has a great coverage of many project items (with tutorials and examples), I'm surprised by the apparent black hole of info regarding .lvlib

I can see users in the forum giving advanced advice on .lvlib specifics, the question is - where have they learnt this from? I've been banging my head against LabVIEW libraries for the better part of the day and can't get my head around the fundamental concepts.

If anyone can point me in the direction of a comprehensive knowledge base (including fundamentals) for LabVIEW libraries (.lvlib) I'd be extremely grateful.

Many Thanks,

Rusky

---

Some quick fire questions:

- How do I 'get at/use' a VI stored within a library for use within another VI in the same project?

- Do Libraries need to be created at project conception or can they be created retrospectively?

- I've got a main.vi that uses a bunch of VIs that I want in a Library. Can I group them into a library without having to edit main,vi?

- Can a group of indepedant projects all make use of a shared library?

- Can a creation of a project library be used to resolve project conflicts?

[crossrulz]

---

@rusky wrote:

Some quick fire questions:

- How do I 'get at/use' a VI stored within a library for use within another VI in the same project?

- Do Libraries need to be created at project conception or can they be created retrospectively?

- I've got a main.vi that uses a bunch of VIs that I want in a Library. Can I group them into a library without having to edit main,vi?

- Can a group of indepedant projects all make use of a shared library?

- Can a creation of a project library be used to resolve project conflicts?

---

The main point of a project library is for name spacing, which can resolve VI name conflicts in a project.  The other feature I use a lot is being able to set access scope.  With that, I can set VIs to private scope, making it so only VIs inside of that library can call it (useful for protecting Action Engines or other VIs other libraries and external VIs should not use directly). Otherwise, a library just groups a bunch of VIs together.  Everything else is just normal LabVIEW (you can create them as you develop, different projects can use the same library, you can just call VIs in the library just like any other VI call).  Just play around with them in a project and you should have all of your answers within an hour.

[natasftw]

---

@rusky wrote:

Having done LV Cores 1 to 3,

If anyone can point me in the direction of a comprehensive knowledge base (including fundamentals) for LabVIEW libraries (.lvlib) I'd be extremely grateful.

---

Some quick fire questions:

- 1) How do I 'get at/use' a VI stored within a library for use within another VI in the same project?

- 2) Do Libraries need to be created at project conception or can they be created retrospectively?

- 3) I've got a main.vi that uses a bunch of VIs that I want in a Library. Can I group them into a library without having to edit main,vi?

- 4) Can a group of indepedant projects all make use of a shared library?

- 5) Can a creation of a project library be used to resolve project conflicts?

---

Given the first portion of your quote, it's a tad concerning you have these questions.  It may be worth taking a look at those courses again now that you've got some practical time in LV.  The questions posed here are all either answered through general ideas in Core 1-2 or in the Library section of Core 3.

1) The best practice is to include the library in the project and drag the VI directly from the library to the caller VI.  Keep in mind, project files are just links to where things exist on your PC.  Adding the library only adds a few lines of text rather than adding the entire size of the library. 

2) It's easier to create the library in advance. But, you can create a library at any time.

3) Not exactly.  When you add the VIs to a library, you change their effective name.  They were MyVI.vi.  Now, they're MyLibrary.lvlib:MyVI.vi.  You'll need to do some relinking.  This is why it's helpful to create the libraries in advance.

4) Yes.  Just as a group of independent projects can all make use of the same subVI.  Because a project only links to where things exist, it doesn't matter if you link to the library in each.  (Just be aware that moving either the project or the library to a new location on the PC is likely to cause linking issues as the relative path change is no longer the same)

5) Yes and no.  Are the project conflicts related to multiple VIs with the same name?  Then yes.  It depends on what the conflict is.  For context, this exact question is posed in Core 3 before introducing Libraries and explaining how they help.  This is one of the reasons I recommend reviewing the Core 1-3 material.

[Yamaeda]

A library works like a file folder in the same way that it's mainly a way to organize files. Since the library is a namespace it allows you to have the same file name in several functions (in the same way a folder does), you can have lib1.init() and lib2.init(), whereas if you used standard files you can only have one init() in a LV program.

Two big differences between folders and lvlibs are:

1. Both file and lib knows of their ownership, a normal file doesn't

2. A lvlib can have member files from any file location, though it's recommended to gather them in a folder

How to use them? In a LV project the library is a virtual folder, in the block diagram it's basically invisible, you'll see it as a VI just like any else.

[natasftw]

While point 2 is technically true, "recommended" isn't quite strong enough.

If you're making a library, create a separate folder just for the library and its members.  Keep them all there.  Do not punish yourself by using VIs from different locations within this library.

The management required to keep the relative paths correct if you move anything is an unfun experience.  If you move one, you'll have to move both or re-link. 

While this statement isn't true, the alternative is frustrating enough that it's worth treating it as true:  A lvlib and its member VIs need to be isolated to their own separate folder.

[billko]

---

@natasftw wrote:

While point 2 is technically true, "recommended" isn't quite strong enough.

If you're making a library, create a separate folder just for the library and its members.  Keep them all there.  Do not punish yourself by using VIs from different locations within this library.

The management required to keep the relative paths correct if you move anything is an unfun experience.  If you move one, you'll have to move both or re-link. 

While this statement isn't true, the alternative is frustrating enough that it's worth treating it as true:  A lvlib and its member VIs need to be isolated to their own separate folder.

---

I wholeheartedly agree with your last point.  That's what virtual folders are for.  I do have (real) sub-folders under my main library folder named "VIs" and "Controls" but that's about it.  Let virtual folders take care of the organizing.  Moving something from one virtual folder to another only involves a change to the lvlib file itself.  No code recompiles or anything like that.  Very useful when dealing with versioning software.

[crossrulz]

---

@billko wrote:

I do have (real) sub-folders under my main library folder named "VIs" and "Controls" but that's about it.  Let virtual folders take care of the organizing.

---

I don't even go that far.  I just put everything for a library in the same folder.  Any sub-libraries or classes that are in the library will have a sub-folder.  Otherwise, yes, Virtual Folders are used to organize inside of the library.

However, NXG will not have virtual folders.  So all of these "rules" are thrown out the window.

[billko]

---

@crossrulz wrote:

---

@billko wrote:

I do have (real) sub-folders under my main library folder named "VIs" and "Controls" but that's about it.  Let virtual folders take care of the organizing.

---

I don't even go that far.  I just put everything for a library in the same folder.  Any sub-libraries or classes that are in the library will have a sub-folder.  Otherwise, yes, Virtual Folders are used to organize inside of the library.

However, NXG will not have virtual folders.  So all of these "rules" are thrown out the window.

---

Ugh, I know.  I had to grin and bear it when working with NXG.  I think the thing that finally made me decide to stop trying to like it was that wires no longer carry properties.  That negated a huge chunk of my self-documentation scheme, and it eliminated over half of the OpenG library.