Why Use LLB?

[Sara_J]

This might be kind of a dumb question; I hope you'll all forgive me.

My boss wants me to look into using VI Library Management. As far as I can find out, this involves grouping VIs together in .LLB library files. None of the information I can find (in LabVIEW's help files or here on the Web site) points to this being anything other than a tool to organize VIs, though. Is there some benefit to it beyond that? Or is it really purely an organizational tool?

Thanks!

Sara J.

[Dennis_Knutson]

It is an organizational tool but one I don't recomend you use. You can see the recent posting about one of the dangers of using an llb for development. Also, an llb doesn't work well with sourc...

[tbob]

I see it as an organizational tool. I might have a bunch of vi's that perform functions on a particular instrument. I would like to have those vi's grouped together in one file for ease of transport and storage. Look in your instr.lib folder and you'll see that every instrument driver has their vi's grouped into an llb. Also, I might have a collection of vi's that constitute an entire test for a certain product. Again, grouping them into an llb makes sense for storage, backup, and transportation to several test sets on a shop floor, or for distribution to remote sites. As an alternative, you could just put all these vi's in one common folder, and create folders for each project, which has the disadvantage of having to use/view several files instead of just one like with the llb. Or you could zip them up into a zip file, which has the disadvantage of having to unzip to run the vi's. Look at the llb like zipped vi's that don't have to be unzipped to use.

[Dennis_Knutson]

Screwed up the link. Here's what I meant to do:

It is an organizational tool but one I don't recomend you use. You can see the recent posting here about one of the dangers of using an llb for development. Also, an llb doesn't work well with source code control systems(which should be used by everyone). You can check an llb into and out of source code control, but when you have multiple VIs in the llb, you have no way of knowing which VI in the llb was changed. It kind of defeats the purpose of scc. An llb is very handy for distributing an application from one place to another, but that's about it.

[Enrique]

I try to keep my VIs separate during development. To distribute, I put them in a tidy llb. That's about it.

[Sara_J]

Thanks, guys! (Especially Dennis, for pointing out that danger--eek. Backups are Good Things.) That pretty much answered my question. I appreciate the help!

[tbob]

Same here, I would not use llb's during development. But I use them all the time for storage and transport. And I've stored llb's in vss lots of times without any problems whatsoever. So does everyone else at my company, and that is a lot of llb's in vss. No one has ever had a problem here and they've been doing this for many years. But it is always safe to keep a backup somewhere else just in case.

[Ben]

There is one benefit that can be obtained by using llb's.

Illegal file names

I f understand correctly, this is why they were created in the first place, to get past the DOS naming conventions.

They are a great way to put "all of your eggs in one basket" (insert sarcastic smiley face here).

Ben

[altenbach]

I think back in the old 16 bit days (Windows 3.1), LLBs had clear advantages because they allowed e.g. long file names, while the OS did not. This meant you were able to use VIs developed on a MAC without having to truncate the names. This advantage got lost with the introduction of Windows 95. Only in recent version, NI made another effort with the explorer interface for LLBs. It's nice because you directly see all the custom icons.

The only other advantage of an LLB over individual files is the fact that you can designate a toplevel VI. (It would be nice if this was available for regular VIs too and they would then show up with a different icon in explorer. Sometimes, I look at a folder of an old project with 50 VIs and it takes me a few minutes to figure out what the toplevel VIs were. :(. Similarly, here in the developers exchange, somebody might need help and attach a zip containing 10 VIs. It would be clearly useful if the toplevel VIs would stick out in some way.).

As others have mentioned, I would personally never use llbs for development work, but it's probably OK to package a finished product if you have other backups. There is no real advantage such as compression.

[chrisger]

Hi there

i like llbs!

because: if a vi is like a function, then a llb is like a dll. i always bundle vis by their function, e.g. a llb for handling my binary datafiles, a llb for handling the hardware and so on, just like one would create dlls for special purposes when programming in c++. the llb then contains everything i need to use the functionality of the bundle, e.g. all typedefs and all sub-vis, and thats the point:

the question is not how to pass some vis to another person, the question is how to pass a functionality. and that includes the right version of typedefs and sub-vis. so i put them all togehter in one single file (the llb), and thats the file i check in and check out and pass to other persons! by doing so one can be sure that the other person has all vis with the right version. another plus: if you decide to remove or rename a sub-vi, no one recognizes that at all if your code is encapsulated in a llb. if your vis are not in llbs, you have dead vis out there. to come back to my comparison with a dll: no one is checking in/out a single function or typedef from a .c file! you check in the whole .c-file with ALL functions and all typedefs, i.e. the functionality.

and thats why i like llbs!

best regards
chris