Dynamic Loading and Unloading of Libs?

[danielsan]

Hi,

somehow I´m stuck.

Short description of the problem:

I am designing and implementing a new LV-application for our test stands. The old system was written in Agilent VEE. Basically the software consists of one main application and some libs which are placed on a network folder. Every test stand has one PC and up to two Test Modules each connected to one or two DAQ Cards. Each test stand is running the same main application. The test modules are recognized by hardware code and the libs are loaded according to the result. This gives us the flexibility to easily change parts and whole pcs or to combine different test modules without a lot of configuration effort. The drawback is that a lot of libs are shared by different test stands and it is very dangerous to change something. In a running test system only on module is active at a time.

In the new LV-Software I implemented a framework to initialize the modules and load the corresponding libs by loading child classes of the modules and test devices (I implemented everything in lvoop, even if some classes are only abstracts). I also introduced a source code control system using tortoise and svn. I´d like to use my libs (like string, database, etc...) as externals and bind them to one specific revision nr for module software in a stable status because further changes should not affect my running systems.

But what can I do, if I have a combination of two test modules, each requiring a different revision of one lib?

My Ideas so far:

1: Add the libs to each Module Lib and load them as module1:lib, module2:lib. This is not possible because a vi or lvlib can only belong to one lvlib.

2: Dynamically load and unload libs with different revision nr. according to the module active. Since it is not possible to have several instances of one vi in memory is it possible to dynamically unload and load the needed libs according to the module that is active?

3: Always use the newest lib available and be very careful about changes. This is what we do now and it´s not really comfortable.

Any suggestions?

Greetings,

Dan

[Daklu]

But what can I do, if I have a combination of two test modules, each requiring a different revision of one lib?

Poor namespacing strategy (by NI) stikes again! This sounds like an SVN question, which I don't use, but I can appreciate the problem and have developed a workflow that works regardless of your source control system. It may or may not apply to your situation.

I'll make the following assumptions:

• You don't code against your reuse code's source. What I mean by this is when you create a reusable code module you build and install it to the expected file system location (even on your dev computer) and all code you write links to that instance, not the instance in your development directory.
• You use some sort of version numbering scheme with your code modules. Most people follow the major.minor.bugfix.build convention; however, differentiating between a major and minor revision tends to be open to interpretation.

First, my versioning rules state that I increment the major version number if and only if backwards compatibility is broken. I could end up with unusual version numbers like 1.98.3 or 36.0.1. Doesn't matter. The whole point of the major version number is to differentiate between incompatible module releases.
Second, when I build the source I append the major version number to any public top level libraries. If I have four classes in my module then the build process renames them MyClass1__v1, MyClass2__v2, etc. If the four classes are wrapped in a lvlib then I can get by with only renaming the library MyLabviewLibrary__v1. (I use OpenG Builder to build code.)
Third, I deploy each module as a package to a directory that includes the major version number as part of name. (C:\reuse\MyLabviewLibrary v1\MyLabviewLibrary__v1.lvlib) I strongly recommend VIPM for managing your reusable code packages. If budget constraints are getting in the way you can get by with OpenG Package Builder and VIPM Community Edition, both of which are free. If you have the money you'll likely save time and frustration by purchasing VIPM Professional.
Following this strategy gives me the following benefits:

• When I release compatible updates to a code module it is deployed to the same directory and all dependent code automatically uses the updated module.
• When I release an incompatible update, the previous version of the module is not overwritten and dependent code can continue to use the old code.
• Upgrading an application to use a new major release requires some level of manually replacing the VIs from the old module. Some may not think of this as a benefit, but I do. It forces me to be more rigorous when changing the application code to account for the incompatibilities.

I recently gave a LUG presentation on managing reuse code. You can find it here.

Edited August 12, 2009 by Daklu

[danielsan]

Thank you for the input. I will think about that.

But I dont`t think that I am really comfortable with using different names for several versions of the same file. Somehow I like the svn idea more (especially the advantages of branches and tags).

greeting,

dan