Shared LabVIEW routines

[blane12001]

This is a general question. How does everyone share the common routine that are internal to you development group/company? do you place the routines in a common directory with maybe placing thm into a more descriptive sub directory. Or do you place the routines in a library like LLB and place that library in a common location? or Do you use something like the VIPM to control the distrubuition and updating of the common routines in directories in the users computers?

I am in the processes of setting up a system for the accessing of common routine VI's and Controls and was wondering what the most common approach is?

Thanks for the input.

Bill Lane

[AELmx]

I am really interested in this topic.

For example i have VIs in common folders, and those VIs are called from others labview projects and teststand sequences.

But i dont have the way to track where is being called those VIs.
I would like to do something like when in a project, search all calls of a VI in that project.

I remember i did a question about this topic in a private labview group,  "Alex_Torres_GDL" told me to:
Create a new labview project

Go to the root folder where the code is located

Add the folder to the labview project (drag and drop).

I did a test some minutes ago and i can see i have repeated VIs, i will try to add locations with teststand sequences to see if can be added.

[TroyK]

This tutorial here might be useful : Sharing Code with the LabVIEW Project Library

Are you using a version management system?

IBM Rational ClearCase is what we use for sharing common code libraries but any decent version management system like SVN or Mercurial will do. GIT is another rising version control system that is popular with open source projects online but it may take a bit more fiddling around if you want to set up a private GIT server. Either way your version control system need to reside on a server somewhere.

Using your version control system means you can manage how updates affect different users.

I personally do not use LLBs, VIPM, lvlib or packed project libraries for internal libraries. My libraries are in categorized directories and follow a standardized naming convention to avoid naming collisions.  Related groups of VIs are linked to a LabVIEW project library. This helps to manage them without hiding them in a LLB or locking them to a lvlib.

As projects grow you need some way to avoid naming collisions. (You can't have two VIs in the same project called Initialize.vi for example.) Some of the methods mentioned above provide namespacing to help avoid filename conflics.

Doing it this way means changes to individual VIs can be more easily traced and controlled. It all depends on your needs and possibly internal processes.

Message was edited by: TroyK

[KevinM5055]

Am using packed project libraries in LabVIEW 2014 to share common framework type libraries.  The installer places the lvlibp in a common directory outside of the project, although I've started to experiment with putting an LLB in user.lib so the VIs are available in the palette.

Inside of the lvlibp, am using other child lvlibs to group similar functionality together, provide similar icons across the library, and narrow access scope.  Inside the lvlib there are virtual directories to group SubVIs by common functionality.

We're using packed project libraries because of the production environment that we're in.  In order to certify the product is made in accordance to released drawings, we need to show evidence that the right version is used.  A packed project library is a way to share code and see the block diagram in development without having the ability to change it except by releasing a new version.

For version control, I'd recommend using Subversion.  Subversion is better suited to version control of binary files (VIs), while git is a distributed version control system that works best on multiple branches with the ability to merge text files between branches.  

In either case, try not to store the installers in the repository.  The installers can be huge (over 1 GB), and down the road it can take too much time and drive space to do a full checkout.  Instead, use a file server or the file release area on a web server (like TeamForge) to store the installers.

[oskretc]

For low change ratio code. (libraries) we use VIPM's. VIPM's source code is under SVN, we use bamboo to build and pusblish them to our private VIPM repository.

For high change ratio code we use SVN.

[James@Work]

Bill,

I agree with oskretc about using VIPM for sharing code.

I have multiple VI packages that are shared using VIPM.  All of this code is in source code control where I add labels to correspond with each package release version.  The use of VIPM makes the distribution of updates seemles (and optional) for end users.  Using VIPM also provides for creating package configuration files that are saved within each project.  The configuration files are invaluable when returining to an old project to fix a bug or add a feature.

If you decide to use VIPM, I recommend separating your packages into groups where possible to keep the packages smaller (<250 VIs).  My largest package has grown to over 1000 VIs and 250+ custom controls which is pushing the limits of the VIPM software.  The builds have gotten slow and the VIPM application does not release memory (1G+) when complete, requiring a restart.

But, I do not think there is currently any better option for sharing code within an organization.

Good Luck,

James

PS.  And, creating the palettes is so much easier with VIPM than it was when distributing shared toolsets 15 years ago.

[GuessWho]

UNRESTRICTED / ILLIMITÉE

Folks

A somewhat related theme; apologies if this is considered 'hijacking' by some, but there is a common thread.

Recent IT Security-mandated changes to user admin privileges in our company have left us scrambling to support a wide variety of small tool applications which change intermittently, as our past practice of generating executables and installing them remotely by login are no longer viable; we must now have our IT services folk do all executable installs (across 25 or more target machines for just one of a multitude of applications). One approach we are considering is the generation of an executable "launcher" which would not change from release to release. The launcher would then load and run a vi hierarchy. That vi hierarchy would reside either on a server (sort of a super-class of "shared LabVIEW routines"), or locally in the user directory we still have r/w access to. Certainly, any personalization of the application that makes it unique (COM port numbers, data archival directory pointers, etc.) would reside in an ini or other text file or MAX configuration file, depending on the application. This is a very, very messy retrograde solution in my mind, but the present situation is intolerable.

Is this workable? Can anyone see other alternatives or suggestions?

Thanks

Blair Smith

[TroyK]

Blair,

This really does sound like it should be a separate topic.

Do you still have remote access to the machines? Is it just the admin rights you don't have anymore?

Why not install your launcher app as normal and put your real executable in a demilitarized zone where it can be run from and you can freely replace it?

We have a similar situation here where I work. Things in the Program Files directory can't be changed because you need admin rights.

Have you tried adding your exe to C:\Users\%username%\AppData\Local

[GuessWho]

UNRESTRICTED / ILLIMITÉE

On reflection, I agree it should be a separate topic, but we're here now.

Yes, we have network access to servers and other shared space. The issue is, as usual, security concerns about staff downloading and installing code that hasn't been vetted. Quite understandable, but very intrusive for our work.

I think the launcher approach is dirty, in that we now have a code to manage that is separate from the particular laboratory routines. However, I can see that with a little design work, it could be made quite universal, by giving it the ability to go out and determine what apps it has available and allowing the user to select from them, for example. So I think we'll explore this. Our IT team is aware of "executables", and the risk of us putting them in inventive places so I expect they will snoop for them. A package of Vis will be invisible, so we won't be generating executables unless we find that the approach of launching subvis is unworkable. The upside is, without our launcher, no one can run the Vis without LabVIEW, so security concerns should be manageable.

Thanks, Troy, for the reply.