.llb versus .lvlib

[marccj]

Hi,

I'm a new user of labview and I'm developing a Labview library to distribute to clients to make my product easier to use.

The question I'd like to ask is if it's better to use a .llb or a .lvlib. In my project I have subvi's that I don't want the final user to be able to call, they are subvi's that I've created to implement the vi's that I want the clients to use.

I've read some info about the .lvlib's and how with them you can classify vi's into public or private.

I've also read that the .llb files are better for distribution because you have everything into one file and that is more practical and safe.

I could really use some help to chose between these two options.

Thanks in advance!

PD: About the .llb I don't quite understand how to properly use the always included and excluded files of the source files page.

[Dennis_Knutson]

The llb was created back in the old days when file names were limited to the 8.3 format. They really don't serve much of a purpose anymore. They are not safer than an lvlib and I would like to know where you read that. A single corrupt VI in an llb will make the whole llb unreadable. Since you can zip up a lvlib, the single file arguement is not understandable either. An lvlib also integrates with source code control and this is something you had better be using.

[Ben]

... adding to Dennis' excellent reply...

lvlibs are a nice feture. They let you better organize your sub-VIs and let you establish access control to protect sub-VI's you don't want other developers to use directly. They alos give you an extra option in the Hiarchy screen to let you view the hierachy grouped by the lvlibs. You have to see that yourself to appreaciate what a plus that one is. The grouping also let you spot recursive (library) calls you may not notice otherwise.

They also provide "Name Mangling" so that the old requirement to "Prefix your sub-VI names with blha blha blah" is not longer required and is done automatically wiht the lvlibs.

I like them.

Ben

[10Things_Rob]

I would note to any new user that the "Name Mangling" is something that they should be aware of because it can make some file moving/renaming operations non-intuitive. You can burn a lot of time re-finding/relinking VIs...

In fact, while I am using them, many compatriots do not because they don't like this "feature". I'd love to see a place that describes "Best practices for using lvlibs" so that I can help avoid this issue.

I do like the other features of the lvlib. I recommend using them, but be careful about the effects of moving a file on disk or between lvlibs or trying to make "copies" of code in lvlibs.

[altenbach]

---

@marccj wrote:

I'm a new user of labview and I'm developing a Labview library to distribute to clients to make my product easier to use.

---

What kind of "products"? Are these to simple drivers or examples for your hardware?

Are you distributing a toolkit or addon for LabVIEW programmers?

Maybe you want to look into VIPM. See also the LabVIEW tools network.

[SteveChandler]

Kudos for the comment on source control. I just want to add that you should never "develop code within an llb". The code that makes up the llb goes in your project as normal. You "build" the llb after making changes to the code. The llb itself does not necessarily go into source control although it can. Never open code from within an llb, modify it, then save it back to the llb. They are for distribution. On the other hand lvlibs do go into source control as they are part of your code.

It is apples and oranges to compare llbs and lvlibs. One really is a library and the other is a really funky zipfile.

[SteveChandler]

One more thing. I am on my phone and cannot provide a link, but go to the idea exchange and look for "bundled project library" It is sort of a hybrid between the lvlib, llb and lvlibp (packed project library)

[marccj]

Hello,

first of all thanks for all your answers.

I've discarded the use of a .llb but now you've given me some more options that I don't quite understand.

What I'm looking for is the best way to distribute a set of vi's that implement some low level functionalities of my drive (as moving a motor to a certain position). I'd like to distribute and installator to my clients so this set of vi's is installed into a custom pallete in their labview program.

For what you've told me, my options are:

- .lvlib: scope protection (I have private vi's that I use to implement the vi's that I want to distribute and I don't want the clients to be able to see them), source control (I'm not using it right now but I will), "name mangling" (for now my library is small and I don't need it but I probably will), code protection (I don't want the clients to be able to see or modify the source code)

- Packed project library: a .lvlib in a single file, compiled for one target and one LV version (complicates things), you can generate a release build that will not include the block diagrams (improves security), their are precompiled so improve compilation time for the clients

- Bundled project library: I haven't found much information about them....

- VIMP: as I understand it's to distribute through Labview tools network and I don't think I need it right now.

I'll apreciate if you can give some more advice since I've just been using labview for a couple of months and I'm a little lost...

Thanks again!!!!

[SteveChandler]

VIPM really is the best way. There is no such thing as a bundled project library. It is an idea on the idea exchange. If you use an lvlib your clients will be able to see the private vis if they look for them. What marking them private does is make sure that only vis in the library can call them. You just get a broken arrow if you try to call the vi from a vi that is not a member of the library. Your clients will be able to change the setting to public. It is not a security method. If you want that you can remove the block diagram or set a password on the vi.