Random Ramblings on LabVIEW Design

It's about time LabVIEW caught up with all things internet so here's a preview of the next great thing happening to our favorite language..

Introducing CatVIEW.....

Notice the box like structure indicative of a while loop. No cat icon will be able to resist it.

Wire up your hilarious cat icons with the wool tool.

With CATView you'll be feline great every day!

Lots of Love

Steve

The last couple of years I've tried to give credit when credit is due, this is peculiar behaviour for an English man and doesn't come naturally at all.....

My last but one article was critical and Karma insists I correct the balance of the universe by kissing some butt.

So I'd like to heap praise on some people I've come into contact with from NI in the hope of making them uncomfortable,  first from over the pond.....

Mr S Mercer, Mr A Smith, Mr E Kerry, Mr D Nattinger, Ms C Rogers ................... All for having the guts to show us their code and ideas (this is a very hard thing to do), encouraging the open sourcing of tool kits, improving the examples, being so open in the community, spending so much time responding to me.

Mr B Powell, Ms N Hollenback ...................... For CLA summit efforts, buying me dinner in Paris

Ms K Hunka, Mr G Heimbach ....... for tireless Champion support

Ms M Martin ....... being constantly good humoured in the face of me grumbling about re-cert.

Mr R Des Rosier .... for inviting me to beer club and giving me excellent tequila. I'm sure he's owed technical thanks too

In the UK

Our past and present sales engineers especially Mr T Gibbs and Mr A Simms .....

Mr M Bailey, Mr S Emery, Mr N Williamson, Mr J McNally .... so smart and always eager to help.

Mr J Woodford .... for patience in the face of my unusual attitude to business.

All the guys and girls who help with CSLUG (including the 2 interns who showed stunning myRIO projects this time round, makes me very hopeful)

Everyone involved with the CLA summit in Geneva and the guys at CERN, a fantastic and inspiring event.

Anyone else I owe thanks to and forgotten to, because I'm an idiot!

Obvious thanks to the bosses.

So what's prompted this hippy behaviour? Well several things

1. CLA re-cert in 4 years!!!!
2. GOOP Dev Suite is open source!!!
3. Geneva CLA Summit was just incredibly good
4. Spring is in the air

I'm also liking the move towards more open APIs, listening to the community, engaging with the community that's been happening for the last few years.

I know this seems a bit strange but what the hell, we're quick to grizzle and moan and much slower to say nice things. Especially to large corporations.

Lots of random hippy peace and love (oh and anyone calls me a hippy I'll punch them!)

Steve

Here's a little quiz question for the weekend

How did I do this??

All are the same control and I can set new colours for new ranges if required. I quite liked the solution (little things please little minds)

I'll buy a beer for the first correct answer.

For all who are travelling to Geneva for the Euro-CLA Summit, travel safe and I'll see you there.

Lots of Love

Steve

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