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”
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!