Using Libraries (not LLBs) To Group Your VIs

In previous posts, I looked at how to wrap OS calls in LabVIEW. Now I will look at packaging them up. While I will be referring to how to package up the calls into the OS, it is also a general topic.

The easiest way to create a library is to first create a project (File -> New Project). Control-Click (Right-Click) on My Computer and select New -> Library. Now select File -> Save All, and save the project and library to disk (create a new folder in the file dialog).

The next question is "What do I name my library?" I would suggest using your reverse DNS name. For instance, If I was making a library for Carbon, I may use "com.Apple.Carbon" as the name. Now preferrably Apple would make this, but if you don't think they would, you can use their name. In the higher level code that uses the Carbon APIs, I may name that library "com.ni.Carbon".

Now inside of Libraries, you can have a library. For instance, say you wanted to have a CoreFoundation library inside of Carbon. So you would control-click (right-click) on com.Apple.Carbon, and select New -> Library. Then save that library as CoreFoundation (or CF). You may want to make a new directory in the com.Apple.Carbon directory to save the library. And then within the CoreFoundation library, you could have a String library (for CFStringRef functions).

What creating levels of libraries like this does is enable you to have VIs named the same (in different libraries) and still be able to work in LabVIEW together. For instance, say you had a VI called GetTypeID that wrapped CFStringGetTypeID (). The full name of that VI would be com.Apple.Carbon:CoreFoundation:String:GetTypeID, so it could peacefully coexist with com.Apple.Carbon:CoreFoundation:Array:GetTypeID. You could have them both on the same diagram and there would be no problems.

I would suggest having a namespace for each library you call into. That library would then be just thin wrappers around the calls to the entry points in the library (like com.Apple.Carbon). Then have a separate library that are convert the calls into more useful LabVIEW calls (like com.NI.Carbon). Inside each library, add a library for each group of calls (in Carbon it would be a library for each manager). If the manager is divided into different objects it works with, then create another library level for each of the different objects. If you use any clusters, save them as typedefs in that library. If you have helper functions you can make them private in that library (or public if their usefulness extends beyond the library).

Anyway, just some basic ideas on how to make a well packaged wrapper around a Shared Library.