Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: LabVIEW Life Lessons #6 - Versions

swatts
Active Participant

Hello and welcome to my latest L³ Ramble

If you use source code control (SCC) then Kudos to you, this then will lead neatly onto version numbering

 

I've seen a fair few ways that you can version your source-code and this is what we've settled on. Guess what! it's not very complicated.

 

For every unique deliverable item we require a version number.

 

So......

MainVIVersion.png

For our main VI we have a version number and this is linked clearly (via the comments) to our versions in SCC. Clicking on the indicator will pop-up the details

Version info can be found in SCC comments and we also stick them in VI Documentation too. If they get too wordy we can link to another file or write a specific container.

VIProps.png

On the block diagram we just use a version constant vi.

VersionConstant.png

We use embedded exes and micro-services for some our programs and these will need versioning too.

EmbeddedExe.png

Here we see that the bugreporting dialog is an exe called by the main VI and this one is on Beta Version 1:14.

 

For exes it's very useful to be able to query the version from the command line. Here's the code.

GetVersionCmdLine.png

Using this we can send the command line bugreporting.exe --Version and it will respond on the std_out it's version number. It won't actually load itself as this is a dynamic calling VI not the actual bugreporting screen. We use this for auto-updating.

 

For Realtime systems we use similar tactics, but as well as something visible on the front panel, we also need to be able to query it remotely.

RTServer.png

Here we query the rack info for a connected server and our version constant is front and centre.

RTQueryVersion.png

In fact this applies to all embedded targets, for example we have PIC controllers that respond in a similar fashion.

 

Finally for FPGA targets we just embed a couple of controls on the front panel and these are then passed up to the host.

FPGA.png

These are updated each time they are released to the outside world and not for every commit to SCC.

 

Here's some practices we've observed and DON'T do ..... you may have a use case that these apply to.

 

I've seen CLA level work that individually version numbers each VI, I guess this is instead of a pukka version control system. Seems very counter-intuitive to me!

I don't use the individual revision history options as part of LabVIEW, to my mind it drowns you in information you don't need.

 

In short I want to know what version of software is being used/ reported against and then be able to trace this back to a SCC release.

 

So far this has worked very well for us.

Lots of Love

Steve

 

10-July-2017 Here's an addendum based on a project I've been called in to support.

 

New rule: The version of the source-code needs to be traceable from source code control to the version of the built exe. I came across a project last week where I had no clue as to what version of the source code was used to build the version of the exe.

 

This option was used on the application builder.

VersionAppBuilder.png

The build version was then taken from this and displayed in the title bar. This is fine for the customer, but for someone supporting the code is was essentially useless. I could replace the source-code with an entirely new set of code and all it would do is increment to the next build. 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
James_McN
Active Participant

No more than it needs to be, perfect!

My convention is that I have the constant which should display either in the about box or the start of the log for an RT system. Similarly these are updated on releases to customers.

I don't make any changes back to the individual VIs though, I tag the version in source code control so I can see the commits between versions which reference back to my changes. Not quite as good as yours but so far it has served its purpose.

I also ensure installer versions match on release.

Have you automated any of this at all? I have a checklist of places to check but am keen at somepoint to have one place to set it that will update everything else

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
swatts
Active Participant

I have automated it, but never really used it in practice as I quite like to do it manually.

One of the reasons for using the Constant VI was so that I could link the build, svn comment and version number (via scripting) for an exe release. The pre-build action collected the comment, the post-build did the SVN command line stuff. Worked nice, but we don't do many mass releases, so never really got much value from it.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

James@Work
Member

Very good points!

I place Comments and Labels in SCC to mark releases of Windows Apps and RT Image versions.

I used constants for RT versions years ago, but switched to Image versions.  The Image version is visible in MAX and can be retrieved from a property node in either the Windows or Real-Time application.  And, it's much safer to deploy images to ensure all RT deployments match.  I also made UI that uses customized RAD VIs for use in Windows apps for selecting/deploying images

Tech Advisor - Automation
LabVIEW 5.0 - 2020
swatts
Active Participant

That's a very interesting technique, one of our projects is going to be moving to a stage where this will become very useful.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile