llb

[Roger Montague]

Hi Gang,

I'[ve developed in LabVIEW for years, but have never used LLBs.  My questions are so fundamental that I can't find anything in the LV help or in Developer Zone.  In the application I'm designing, management wants a large number of test steps to be housed in a single file.

1. How do you call VIs in a LLB?

2.  Can LLBs be opened/closed programmatically?

All help is appreciated,

Roger

[smercurio_fc]

---

@Roger Montague wrote:

Hi Gang,

I'[ve developed in LabVIEW for years, but have never used LLBs. 

---

Good. Don't start now. You should not use LLBs unless you absolutely have to, and even then you shouldn't. LLBs are old technology. They have more disadvantages than advantages, and some "advantages" are actually disadvantages. One thing you can do with LLBs is to give your VIs names with illegal characters (as far as regular filenames). This creates a problem when you try to build the application and find that it won't work because of the illegal character. A HUGE disadvantage: if just ONE VI gets corrupted, then the WHOLE LLB is toast. Yeah, that's real useful, right? Also, LLBs do not lend themselves to source code control of individual VIs.

Instead, you should use project libraries (.lvlib). They are far superior, and they provide namespacing to prevent name collisions. You can read more about project libraries in the LabVIEW Help.

[LV_Pro]

As the previous post says, one corrupted file and all are caput. That being said, a lot of instrument drivers are still in the llb mode. What version of LabVIEW are you using? After about 7.1 I think, clicking on an llb opened it as a folder, allowing you to select vi's just as they would have been if in a folder. They were originally created when LabVIEW was ported to the Windows world. In those early (Windows 3.x) days, filenames were limited to the 8.3 format, severly limiting the useful naming of them. Since there wasn't that restriction in the Mac world were LabVIEW was created they came up with a method to create "virtual folders" with a much less restrictive naming scheme. But, LabVIEW in those days, at least on the PC, crashed very frequently, sometimes trashing the vi you had open, which in turn could trash an llb's worth of vi's. Argh. I had more and darker hair before those days. If you are in the 8.2 and above versions and don't have to use vi's in existing llb's avoid them as was previously suggested. If you have to use them LabVIEW can open them as though they were folders. Ironically in previous versions (7.x) the exe that LabVIEW created was essentially a modified llb!

[Roger Montague]

Hi Again, Gang,

Thanks for the replies!  We're planning to do this app in LV 8.6.  I'll look up .lvlib in the help.  I didn't know about them.  I was also thinking about compiling LV code to a DLL, But that seems like a pain, and not very mainstream.

Again, thanks for the help!

Roger

[LV_Pro]

Why do you want to compile it to a dll, be callable from another app?

[johnsold]

In the original post it was specified that "management" wanted everything in one file.  Maybe you just need to create an executable.

Lynn

[Roger Montague]

Basically what I want to do is reinvent a test executive in LV.  I originally wanted to use TS, but it was shot down because of the high number of RT licenses needed.  What I'm looking for is a way to attach resources to the app to support the product families to be tested on that station, and to inform the executive about the hardware resources on that station.  This also could be easily done using .net, But nobody else here can support that.

Another idea is to use .zip files.  extract the vis when the app starts and delete them after.  But that still seems...

Roger

[smercurio_fc]

I've done something similar here. The exec shell is an application, and each project (related to a product being designed and tested) is a library (.lvlib). The .lvlib is then put into its own LabVIEW project file (.lvproj). The project file contains two build targets: a source distribution and an installer. The source distribution puts all of the project-specific code into an .LLB, but (and this is important) only for distribution as an installation, and with all of the block diagrams removed. The installer copies the .LLB to disk. The exec shell has a configuration file that informs it of what projects are installed so the user can select which project is being tested.

[Roger Montague · Accepted solution]

Again, thanks to all for the responses.

What I'm going to do is use Zip files disguised with a different extension.  The application will extract the VIs when it starts and erase them when it ends.  I did a little utility that does that nicely. That's keep the distribution of new products and updates clean.

Thanks Ag

ain,

Roger