I'm not being critical but... (Re-use) Part 1

[swatts]

Hello my friends.

Hope you are full of LabVIEW loveliness

One of my pet hates is people who say "I'm not being difficult|rude|critical but....." and then proceed to be just that!. Well I'm not being critical but I think the standard model of LabVIEW re-use sucks.

I hate myself!

One of the on-line groups I am a member of is devoted to collecting best practices with regards to  software development using LabVlEW. A subject came up recently with regards to upgrading old code and it became apparent that my company (SSDC) had been working around an issue within LabVlEW practices and we've been doing this for over a decade. The trouble is that when the work-around becomes in-grained it becomes habit and then just something you do. Well my eyes have been opened and I would like to discuss the standard LabVlEW re-use model and how it doesn't fit into our use case.

First I'll describe the standard re-use model as I see it (feel free to chip in and expand this).

In the LabVIEW Environment we have several places to put libraries of re-usable code and these appear in our palettes

\lnstr.lib — Download a hardware driver and it will likely as not appear here

\vi.lib — We park code in the Addons Sub-directory, also toolkits go here

\User.lib — This is the main directory for re-use code

Using the excellent VIPM makes this easier to manage.

So in the ideal world for this model our final piece of software will consist of VIs and Controls pulled from these libraries. Our projects then become an assembly of our own code and this re-useable code. This is part of System Configuration Management and a white paper (especially section 5) discusses this.

Let's call this re-use in the environment.

This is how it has been for as long as I've been using LabVlEW and for as long as I've been using LabVIEW I've been fighting against it.

So what's the issue?

Let me describe some common worries

Upgrading, moving machines, deploying source-code

• PC goes phut!
• IT Rollout a new operating system
• LabVlEW gets upgraded
• We want to set up a new development system.

Now it's a bit annoying to reload all the dependencies (by dependencies I mean drivers, re-use libraries etc etc), but manageable enough.

Linking to dependencies, lost links, version cock-ups

More seriously for me is the quiet/silent changes.

So we change a system VI and this changes things in other programs, this has happened to me and is incredibly annoying, in de-bugging it's all too easy to open a VI that isn't doing quite what you want it to, but if you change it it will cause issues in other projects that share it.

Don't get me started on multiple versions of LabVIEW on 1 PC and the save-all disaster (I'm sure I'm not the only one!)

Version control, traceability and validation

Here's the thing...I've got my project under version control, version number on the front panel for all to see. TortoiseSVN shows all ticks. I open the General Error Handler.vi and change it, save it. Nothing visibly changes in the project, worse nothing visibly changes in all my other projects. I have no way to detect changes in my project caused by changes in shared library code.

“This might be the last of the Ten Commandments but it’s a really, really important one. When an app has external dependencies which are required for it to successfully build and run, get them into source control”

http://www.troyhunt.com/2011/05/10-commandments-of-good-source-control.html

Now on the assumption that storage space is essentially free now I propose a slightly different model.

Keep re-useable code in the system libs as a local cache, but when they are moved onto the block diagram offer the choice to create an Ivlib in the project. This should protect the name-space, any other tools from the same lib could be added to this Ivlib. This Ivlib should be stored in a sub-directory called Dependencies below the calling VI, give it an auto-generated name like instrlib- Agilent 34401.1vlib and the Project can then contain all of the shared VIs. This will then make a package of standard LabVIEW that can be versioned and stored away. So take NIScope, a fairly large set of VIs even if we're not selective we are only adding 2Mb to our project size. A complex project might add 50Mb.

Let's call this re-use in the project.

For 100% confidence in your build I suggest you would need 100% traceability of the code elements - there is an argument to include all dependencies in this, I'm talking dlls here! I middle ground suggestion maybe to include a dependency manifest as part of the project files that lists all dependency dlls, versions, date changes etc. This would be updated when the project is opened.

I think this may be an interesting discussion (and not one I've heard discussed much), part 2 will look a bit futher forward and be a bit more radical.

Many thanks to Jack Dunaway, Adrian Brixton and Jon Conway for helping to turn my vague grumblings into a coherent article.

Looking forward to Geneva CLA Summit, not looking forward to re-certifying, maybe this will be my last one!

Lots of Love

Steve

"The only other advice I can relay is that you should write code as if it were mistaken, and you wil..." Tef

[CharlesB64]

Which I think is something you can easily do with LV scripting and the VIPM API...

Sure, but this would work only if loading the project from a hand-made VI, right? The said VI would load project, check the vipc, and apply its configuration. But that's not what I'd call an IDE integration: open the project the normal way, and the check doesn't happen.

Unless you can, in your project, tell LabVIEW to run a VI at project load?

[Thoric]

Greg: I suspect for individuals this isn't an option, but I'm no lawyer so check perhaps with your local NI sales rep?

Charles: check out the Project Provider Interface http://www.ni.com/white-paper/13921/en/

[Olly85]

I know I'm late to the party but great article Steve! Lots of good insight on this subject.

I've spent the last year working with an expanding team of developers on multiple projects all sharing the same set of re-usable (common) code.

Unfortunately, even though source code control has been used, we have struggled being able to replicate older versions of executables (amongst other issues).

VIPM was a great solution to our problem. It is a little bit clunky and has a small learning curve for the team. Unfortunately, our biggest issue with VIPM has been getting it through the company IT department. The preferred solution would be something native to LabVIEW. I'm hoping NI Packet Manager for LabVIEW NXG will be the future solution. It's a shame it was never implemented for the traditional version of LabVIEW.

[swatts]

Thanks for your kind words Olly,

This subject is far from solved!

I loved the collaborative aspect of this article, the whole certainly surpassed the original post. The things to look out for is how standard and configurable a solution is. I like when they talk about it in term of OPKG and other industry standard terms. But I'm suspicious of tools and toolkits. A lot of people get a great deal of value from VIPM, it really is a great addition to the eco-system, (kudos to JKI and Michael Aivaliotis). Fab does a lot with version controlling VIPM packages and it would be well worth your while talking to her.

I like removing dependencies rather than managing them and am having some success with this, another post is pending....