about using LLB, subvi and project

[dragondriver]

Hi all,

  I have bunch of subroutines will be needed for all projects developing in the same computer. For long time, I wrap each of those subroutines as a separate subvi and call the subvi when needed. But I just saw someone will build a LLB to contains all those subvi. Will it be the same to build the LLB or separate subvi? So what's the advantage to use LLB? I saw the builtin functions are all wrapped into a LLB. So if I create my LLB, where should I put that LLB so it will be appear on the main palette?

The second question I have is what's a Project is for in labview 2013? I have been using labview 7 for long time and I create my project in a folder. But in LV2013, I can creae a project and bind everything in there. So what's the advantage of using a project?

Thanks.

[Dennis_Knutson · Accepted solution]

There really is no use for an llb anymore. It was primarily used to store VIs with long names - names that were not acceptable in the early days from the transition from DOS. Storing working files in an llb is a bit dicey since a single corrupt VI will render the whole llb unreadable. An llb is not suitable for source code control. The source code control is only able to track the llb and not the individual files. The only time an llb should be used is to distribute released code. Better and what is being used now is the lvlib or the packed library. One of the biggest hassles of older versions of LabVIEW was the inability to load different VIs with the same name. Placed into separate vilibs, you can now do that.

The advantage of the project is what you said - binding everything together irrespective of the actual file locations. The project can contain files other than VIs - word and excel files for example. A project is also required to create an exe. The project will contain the build specs for the exe and installer. A project can also contain DAQmx tasks. Even if you don't intend to create an exe, a project is still a handy organizational tool.

[JÞB]

And let me add to that.

The LLB- is the equivallent of a LabVIEW screw-hammer.  A useful tool if you have nothing better in your toolbelt- you now do.

The Lvproj- Provides an application namespace to organize a library of vis with a common use scope (Think "<name> ON This Application/target")  that is where the project provides namespaceing "On Proj/Target".  The lvproj knows who its members are and where to find them.

The Lvlib- Provides a way to group related vis.  Like an Instrument driver or an Error Logger  Its namespacing is "MyLblib:<Name>" on xyz.  so its what functional group in your project.  Of course, the same LvLib can belong to multiple projects they are great for reusable code.  The lvlib knows all its members and where they are just like the lvproj however, the lvlib members ALSO know they are part of the library so we can set some protection on the member access (Private/ public /friendly scope items)  This prevents someone from accidentally reusing code where it shouldn't be used.

The plvlib (Or ppl) is a collection of compiled objects.  its a single file on disk and makes a nice way to distribute packages of functions. BUT is not editable.  The equivallent of a DLL that can only be called from LabVIEW. (That's a gross oversimplification but, you get the point)  Since its a single file, the whole plvlib must load to load any part of the plvlib so try to keep the functionallity closely coupled.

[dragondriver]

---

@JÞB wrote:

And let me add to that.

The LLB- is the equivallent of a LabVIEW screw-hammer.  A useful tool if you have nothing better in your toolbelt- you now do.

The Lvproj- Provides an application namespace to organize a library of vis with a common use scope (Think "<name> ON This Application/target")  that is where the project provides namespaceing "On Proj/Target".  The lvproj knows who its members are and where to find them.

The Lvlib- Provides a way to group related vis.  Like an Instrument driver or an Error Logger  Its namespacing is "MyLblib:<Name>" on xyz.  so its what functional group in your project.  Of course, the same LvLib can belong to multiple projects they are great for reusable code.  The lvlib knows all its members and where they are just like the lvproj however, the lvlib members ALSO know they are part of the library so we can set some protection on the member access (Private/ public /friendly scope items)  This prevents someone from accidentally reusing code where it shouldn't be used.

The plvlib (Or ppl) is a collection of compiled objects.  its a single file on disk and makes a nice way to distribute packages of functions. BUT is not editable.  The equivallent of a DLL that can only be called from LabVIEW. (That's a gross oversimplification but, you get the point)  Since its a single file, the whole plvlib must load to load any part of the plvlib so try to keep the functionallity closely coupled.

---

Thanks. I am reading your comment. I am trying to develop some common code to control the DAQ output (for example, to set the timing, set the high/low time for the counter, etc.). Those vi are shared to all code developed in the computer and they are not supposed to changed in future. So my understanding to your comments is lvlib should be a good way to achieve that. My question is I don't know how to set the access scope. I think I should only open the calling for functions defined in lvlibs but don't expect anyone to modify the code.

[JÞB]

Create a DAQ Project with a DAQ functions LVLIB.  the lvlib member scope is set from the project exploere in the owning project by right-clicking the members and selecting "Access scope"

Other projects that depend on those functions cannot call them if they are private.  Other libraries in the owning project can call them if they are "Community" and anyone can call a puclic scopes file.  The help would be a good read.

[dacad]

---

Jeff·Þ·Bohrer wrote:

The Lvlib- Provides a way to group related vis.  Like an Instrument driver or an Error Logger  Its namespacing is "MyLblib:<Name>" on xyz.  so its what functional group in your project.  Of course, the same LvLib can belong to multiple projects they are great for reusable code.  The lvlib knows all its members and where they are just like the lvproj however, the lvlib members ALSO know they are part of the library so we can set some protection on the member access (Private/ public /friendly scope items)  This prevents someone from accidentally reusing code where it shouldn't be used.

The plvlib (Or ppl) is a collection of compiled objects.  its a single file on disk and makes a nice way to distribute packages of functions. BUT is not editable.  The equivallent of a DLL that can only be called from LabVIEW. (That's a gross oversimplification but, you get the point)  Since its a single file, the whole plvlib must load to load any part of the plvlib so try to keep the functionallity closely coupled.

---

I had previously been told that the Lvlib is also a single file on disk and that it will also be loaded in it's entirety when there is any call to a component located in it.

Is that a true statement ?

[JÞB]

---

@dacad wrote:

---

Jeff·Þ·Bohrer wrote:

The Lvlib- Provides a way to group related vis.  Like an Instrument driver or an Error Logger  Its namespacing is "MyLblib:<Name>" on xyz.  so its what functional group in your project.  Of course, the same LvLib can belong to multiple projects they are great for reusable code.  The lvlib knows all its members and where they are just like the lvproj however, the lvlib members ALSO know they are part of the library so we can set some protection on the member access (Private/ public /friendly scope items)  This prevents someone from accidentally reusing code where it shouldn't be used.

The plvlib (Or ppl) is a collection of compiled objects.  its a single file on disk and makes a nice way to distribute packages of functions. BUT is not editable.  The equivallent of a DLL that can only be called from LabVIEW. (That's a gross oversimplification but, you get the point)  Since its a single file, the whole plvlib must load to load any part of the plvlib so try to keep the functionallity closely coupled.

---

I had previously been told that the Lvlib is also a single file on disk and that it will also be loaded in it's entirety when there is any call to a component located in it.

Is that a true statement ?

---

in 1000 words- No:

[dacad]

OK,  it's late on a friday afternoon and I am running a bit slow.

So it's not a single file.

And

Only the individual compnents load as called.

Correct ?

[JÞB]

Silly firewall, I've got a nice capture of "All vis in memory with Close.vi (Agilient 34401A.lvlib:Close.vi)" but I'm not getting it uploaded- I HATE it when some JAVA weenie messes with my LabVIEW mojo

It would show that only "Untitled, Close.vi and Close.vis dependancies are in memory

 

[Edit: Finally!}

[dragondriver]

---

@JÞB wrote:

Create a DAQ Project with a DAQ functions LVLIB.  the lvlib member scope is set from the project exploere in the owning project by right-clicking the members and selecting "Access scope"

Other projects that depend on those functions cannot call them if they are private.  Other libraries in the owning project can call them if they are "Community" and anyone can call a puclic scopes file.  The help would be a good read.

---

Hi Jeff, 

  That's really cool. I think this is absolutely what I am looking for. I created my library and have some sort of access controls to all other callers. Amazing. Thanks.