Creating and using library code

[Bandit]

As my LabVIEW experience grows I'm at the point I guess many developers reach. In the interest of efficiency I wish to reuse code from one project to the next. For common functions and features it would be useful to have tested reliable library code instead of copying code ad-hoc from one project to the next. I'm reading up on the possibilities, and would welcome the advice and experience of the community.  

So far I have determined that LabVIEW provides or can utilise the following types of library file;

• Library file (.llb)
• Project libraries (.lvlib)
• Packed project library (.lvlibp)
• Shared libraries (.dll)
• VI Package (.vip)

The usage remains within LabVIEW, and of code I have written myself, so .dll and .vip do not seem appropriate. 

.llb, .lvlib and .lvlibp all seem to have their pros and cons. From the searching and reading I have done so far I don't have a complete picture of how any of these are implemented. it does seem that there can be a degree of nesting. This post is useful, although may by now be out of date.

http://forums.ni.com/t5/LabVIEW/packed-library-distribution-and-the-user-lib-folder/m-p/1481996/high...

I develop code on two or three different machines, and not always with perminant network access, although temporary access can be arranged to transfer files or they can be moved via USB key. For the forseeable future it's just me, not a development team. Applications are compiled into executables for installation on target machines, and are generally data logging applications with some exhibiting some degree of process control (e.g. driving solenoids and valves). 

So, within the confines of LabVIEW (no budget for additional tools) how would you go about this? 

Alternatively, where have you encountered pitfalls? I'm all for learning from mistakes, but perhaps in this instance I can learn from yours.  🙂

I'm currently using LV 2011SP1 and 2013SP1, but have VLA and access to the latest releases.

Regards,

Bandit.

[crossrulz]

If we are talking pure resue, then VIPM is the best for distributing it.  It is best to have your reuse code in the user.lib folder under your LabVIEW installation and then have palletes that point to that library.  VIPM allows you to do all of that by creating a VI Package.  You then just install that package on whichever machines you want via VIPM.

[Bandit]

crossrulz,

Firstly, I'm sorry for the delay in my response.

Thanks for your reply. I'll take a look at VIPM and see what it can do for me. However as things stand I have no budget available for tools, so primarily I'm looking for the best solutions I can achieve within the LabVIEW environment. I only develop on a couple of machines before creating installers for the developed applications to install on specific target machines - there isn't a wide user base of either developers or end users for this so I'm able to control and install libraries manually once I know what to do. 

The big thing for me is to understand what those different library types can do for me and which (or which combination) provides the best solution.

Regards

Bandit.

[Sam_Sharp]

We used to have a subversion repository for re-use code, organised into individual folders - preferably with the VIs organised into .lvlibs. We would check out the repository into our user.lib folder and could. Change management with this monolithic repository became a nightmare - we had to have a different version of the repository for each LabVIEW version which meant changes from one version to another weren't maintained, we also had situations where code saved in a later version was saved to the older repository, causing a headache trying to open the VIs. We also had no idea which 'version' of the repository was in use at any time.

I put the business case together to move to VIPM Pro, it was an easy sell to my boss and we have never looked back. With VIPC files we know exactly which packages went into each build, we can easily distribute packages and we get notified on opening VIPM that a newer version of the package is available. It also deals with different versions of LabVIEW - just build the package in the earliest version you want to support and it will mass-compile for the version you are installing to. With the free version of VIPM, you can still build/create packages - you just can't create an internal repository or create the VIPC files (which tell you which packages are used in the project).

It also makes it a lot easier for other developers to open each others' projects - we just checkout the source, run the VIPC file and everything gets pulled in automatically. Far fewer broken run arrows! We've even taken 3rd party instrument drivers / toolkits and put them into packages ourselves.

As for a summary of the different types:

- LLBs: I think these are pretty much deprecated by lvlibs at this point, but they are a good way to share re-use code in a single file

- LVLIBs: The modern replacement for LLBs - they provide proper namespacing of VIs (e.g. a Run.vi in Driver1.lvlib can be loaded in memory alongside Run.vi in Driver2.lvlib) and are a good way of logically organising a group of related VIs. It's essentially a mini-project - references a collection of VIs.

- DLL: Useful when calling LabVIEW code from other languages, I think it allows you to run code built in an older version of LabVIEW at runtime (but obviously you need the appropriate run-time engine installed)

- LVLIBPs: Essentially the LabVIEW version of a DLL - it 'compiles' an LVLIB into a single file and draws in the dependencies. Can only be called by the version of LabVIEW it was built in. The block diagrams are removed so you can't edit the code - useful for distributing plugins (with many caveats) and/or libraries that you don't want people to be able to modify.

- VIPs: In my mind, the best way to distribute shared code between projects/developers

[Bandit]

Thank you for your reply Sam_Sharp.

Your summary of the libraries is useful intel. 

VIPM does look like a great tool, but lack of budget and restrictions on some areas of our network mean it's not currently an option for me, even the free version. Having LabVIEW in some network areas is currently a special case. Hopefully this will be addressed some time in the future, but for now I have to work within what's possible.

Regards

Bandit.