Best way to keep track of custom SubVIs?

[hecmar.arreola]

Hi!

I have a number of SubVIs that follow me around.  I have not come up with a "good" way to keep track of these things and have resorted to the sloppy habit of copy-pasting them from directory to directory as I need them.

I have 2 LabVIEW Developer's suite installs, my work laptop and my home computer.  I rarely use my home computer install, unless I need to catch up over the weekend.  I like having all the SubVIs that I use for a specific project with its project directory.  I also include the SubVI in the Project file and they also have a (SubVI) prefix.

Problems that come up:

1. Not having the most up-to-date version of one of my SubVIs when I open an older project.  Sometimes I like this because the project is still in the state I left it in and no new bugs will crop up because I tinkered with one of its functions in another project.  Most of the time I want the most recent.

2. When I try to open multiple project files, I often get into conflicts.  Sometimes LabVIEW tries to resolve these conflicts such that the file pointers within the Project get screwed up.

Should I put my custom VI's into a tools palette?  A Library?  Or what?  I need some organization advice.  Thanks!

-Nic

[Norbert_B]

Nic,

well, there is no "perfect" solution available i think, but this is something many developers encounter.

I suggest as a first step: Use Source Code Control. This will deliver a good versioning tool enabling you to get back to older versions easily.

Nevertheless, it does not by its own solve your conflicts. Crossreferencing can even occur with SCC if the sources are not handled properly.

To resolve those crossreferences, a lot of work is needed and if not done properly will popup any time again.....

I suggest you to take care about folders and projects content. A module must never show up twice in different versions. The conflict resolve mechanism in LV was improved over the last versions and now you get many useful information on why there is a conflict. Often, conflicts remain because a VI loads a SubVI statically from one place where another VI tries to load this SubVI from another place. The only way to resolve the conflict is to select the correct SubVI and save the changed calling VI. This is important because a static VI call includes the (at least relative) path to this VI. If the VI was loaded from a different path, the static call has to be updated!

If you use a library (lvlib)....its more or less up to you. The advantage of lvlibs is clearly: Namespacing (if necessary) and access control of the items. The backside of lvlibs is: You always need the lvlib and moving the VI on disk may break the VI/lvlib.

hope this helps,

Norbert 

[Mark_Yedinak]

I would also recommend that you take a look at JKI's Package Manager.

[rex1030]

Have you ever used VI Package Manager (VPM)? Its widely used by LabView developers and it allows you to not only download all the cool OpenG packages and install them right to your right click drop menu, but also allows you to make your own packages and install them into LabView. You could have a package with your custom subVIs right in your menu if you use VPM to install them. VPM keeps track of versions of the package and even keeps track of which version of Labview the package was made for. You should check it out because it sounds like it is what you are looking for.

http://www.jkisoft.com/vipm/

Edit: Upon further review it looks like the version that allows you to create packages isn't free.

Message Edited by rex1030 on 10-27-2009 12:57 PM

[TCPlomp]

Yes VIPM is a good solution, yo use the openg package to create packages of your VI.

the source should be placed under source code control and the target under user.lib.

Ton

[hecmar.arreola]

Yeah, $999 is a pretty steep price to maintain a palette of function across 2 LabVIEW installs ><.

[hecmar.arreola]

Uhg... I really dislike the fact that user SubVIs for the palette need to exist in C:\Program Files\National Instruments\LabVIEW 2009\user.lib\

Why not be stored in the user's folder somewhere like every-other windows application?