My company seems "stuck" on 2011... benefits to upgrading?

[Autodefenestrator]

Hi,

 

I work for a medium sized company with a small dev group (I'm one of 4 LV people at the moment, with maybe one new hire soon).

 

We're currently using LabVIEW 2011 for all of our development and deployment on new stations, mostly because we bought a bunch of licenses in 2011 and didn't upgrade them after that.

 

We have a few 2009 or older full licenses on older stations, 2 LV2012 licenses that I could find (one full, one developer), and one 2013 developer, and then for 2011 we have something like 3 developer licenses and probably 10 or more full licenses.

 

In the future we're going to try to stick more to compiling EXE files and deploying those instead of putting the full license on the station and running it like that for extended time frames.  So if we upgraded versions just for the developers and maybe a couple of other ones for testing before replacing with a compiled EXE, we could probably still be fine.

 

From time to time I will look around to see how to accomplish a task in LabVIEW, and find that it's either not easy or not possible in LV2011 but is in a future version of some kind.  I've also seen examples of code that seem to have improved block diagram commenting and some helpful programming methods added, but it's hard to quantify how much of that stuff would help and how much time/money it might save in the future.

 

I've yet to come across a task that is flat-out impossible in LV2011 though.

 

Can anyone share if they've dealt with something like this before, or have a better notion of what time savings might come (either to the developer or in reduced bugs on the end station) from moving to LV2013 or 2014?  Specific examples would be great if possible, though I will understand if some of it is company confidential code.

[hooovahh]

Running applications from source is a bad idea in almost all cases.  I highly suggest building EXEs.  That being said it is more work to make an EXE.  Especially if for some reason the builder craps out and you need to start over again.  Locking down an application is critical if you are taking any kind of measurement so you know a developer wasn't fudging the numbers, or adding filtering and averaging to make it pass.

 

I'm lucky enough that my company currently has a renewable license scheme, so I don't have to deal with your specific problem.  LabVIEW 2011 is the oldest I currently go back to, but all active programs are developed in 2013 SP1.  We generally wait until the SP1 release before using it on any programs.  We don't usually upgrade a project to a newer version of LabVIEW, unless we see a need for it.  It has added risk associated with upgrading, which is why we have some older programs running 2011.  Having all versions you need is important because saving as 2011 in 2014 means you can now only open it in 2014, which could be a problem if all of your developers don't have the appropriate versions.

 

2011 is basically the oldest I'd want to go back to.  2010 didn't have static VI references, and a bunch of the other application control functions used often today.  Here are some of the major benefits I see from going from 2011 to 2014.

 

• Conditional auto-indexing, and concatenating loop options.
• Icon Editor API for code generation.  In 2011 there was some kind of API but starting in 2012 it had more exposed.
• Code complexity metrix using VI server
• New scripting functions, some with events
• Bookmark Manager, for keeping track of todo's or other tags in source
• Improvements in QuickDrop.  Especially the auto-wire, which could be done in earlier versions.
• Clear specific error (OpenG has a function like this)
• More control over events with the events palette
• Event structure now has a trace window for debug
• Events can be lossy
• Much improved shipped examples
• Improved versions of the Actor Framework
• Mouse scroll event

 

And what might be a big selling point, is the fact that the Professional and Full LabVIEW 2014 now includes PID Fuzzy Logic Toolkit, and Professional also includes Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit.  

 

EDIT:  Oh and lots of FPGA and RT updates

[ShaunR]

You do know that your managers will probably read this, right?

 

I think consolidation is your key argument in this kind of environment. The premise is that it is cost effective to rationalise/consolodate the myriad of versions into one version for production benfits. As NI don't sell any other versions than the latest, that means upgrading to 2014 at time of writing. Shame eh? 

 

First step. Talk to the NI rep and find out how much it will cost to consolidate all the versions and how much discount he can apply (important for the bean counters later). Push him hard as he will want the sale as much as you want to upgrade so he is a great ally here and you can use some of his sales BS when you argue later internally. Get him to give you two quotes. One with the prices for upgrading individually (which is a single seat full licence per person-don't forget all your addons) and the other with his best offer. This is the accountancy "saving" you can show the bean counters later  Make sure an SSP is also included as an optional line item.

 

Then onto the convincing

 

Espouse the merits of a single platform and the advantages of having a single version in terms of maintenance, deployment and upgrading test facilities.

 

A powerful argument here for production is downtime. Center the argument around cost saving in terms of product not being produced (rather than programmer effort -you are cheap, product is not ). Point out that whilst upgrades are being tested; they have to be tested for each version (multiplying test station downtime by LV versions). The corollary is that a single platform only needs to be verified and signed off once and can be deployed to multiple stations (Replication of effort across multiple disciplines). Really emphasise the effective cost of sign-off too. That multiple disciplines must be involved so deployment resource is multiplied outside of just a puny software engineer and may involve expensive resources like quality engineers, production and maintenance engineers as well as the great god Project Manager.

 

Basically you argue that everyone  (production,  quality, management, maintenance, bottom line) will benefit if they upgrade and look what a fantastic offer NI have come up with for a one-time consolidation package (show the two quotes)

 

I think you get the gist.

 

Once you have argued those kinds of points with management and techie types, then you can woo the bean counters with all the free goodies you will get that they would have to buy anyway but you can get for free if they do this "one time consolidation"  like "Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit." (thanks for the list Hooovahh ) Show them the quotes as what they have to pay if they do it now or when they have to later.  Explain that if they get the SSP too, we will not have to worry about this again next year and we can roll it on ad-infinitum (this is a different budget ) . Any counter arguments, steer towards the SSP. This is your sacrificial "feature" which you may get if you are really smooth, but really not that bothered if you don't. Just make sure you steer all financial arguments towards buying or not buying that to deflect from consideration of the upgrade.

 

I hate politics.

Edited December 3, 2014 by ShaunR

[JoeQ]

Can anyone share if they've dealt with something like this before, or have a better notion of what time savings might come (either to the developer or in reduced bugs on the end station) from moving to LV2013 or 2014?

 

 

I must not be the average Labview user.  I would guess there are less than 10 features that I use that were added from 6.1i to 2014!    Believe me, I cringe every time we decide to upgrade because I know some library will be broke or they will have dropped support for some NI hardware I use.    Problems can be something as simple as the serial ports no longer work (and still don't because we all know how hard it is to use Windows to talk to a serial port) to something like the cPCI  bus no longer works (which after MANY hours on my part and narrowing it to a single file they were able to find the problem).    It takes me a fair amount of time to qualify a new version when it comes out.  I will say that at least moving from 2011 to 2014 did not imped my efforts other than the time to install it.   

 

That said or if you read my previous posts you may have the idea I can't see any value to using Labview.   This is certainly not the case at all.    It has saved me countless hours over the years.   It has also caused me to have a few more gray hairs.    

 

Add to the list, they include the Jitter Analysis Toolkit for free (and it works)!   

[Autodefenestrator]

 

 

First step. Talk to the NI rep and find out how much it will cost to consolidate all the versions and how much discount he can apply (important for the bean counters later). Push him hard as he will want the sale as much as you want to upgrade so he is a great ally here and you can use some of his sales BS when you argue later internally. Get him to give you two quotes. One with the prices for upgrading individually (which is a single seat full licence per person-don't forget all your addons) and the other with his best offer. This is the accountancy "saving" you can show the bean counters later    Make sure an SSP is also included as an optional line item.

 

Hmm...

 

I wonder if the NI rep can tell me how many licenses my company owns and at what revisions.  I've been having trouble tracking down exactly what versions and how many we own and what exact versions/privileges we have.

[hooovahh]

I must not be the average Labview user.  I would guess there are less than 10 features that I use that were added from 6.1i to 2014! 

I don't know where I fit in the spectrum of average LabVIEW users, but I would not be able to make the same application that I do today in 2013, in 6.1, without many extra weeks put into custom code for UI design, and work arounds and even then it wouldn't work as well.  

 

Drag and drop, events, property/invoke nodes that were added, VI server control, subpanels, user events, I mean have you ever tried to make a multicolumn listbox in 6.1 and have it be interactive?  Sorting based on column clicking?  Because I did once, and gave up when I was doing it with VB code and .Net to make tables.  Not every version delivers a home run in terms of features, but many good tools come in 3 years, let alone 12.

 

But I do understand the pain of upgrades, which is why I mentioned we don't upgrade unless we see a need.  That being said since 2009 NI has done much better at maintaining version compatibility and feature set.  I'd bet a large majority of 2009 projects could be opened in 2014 and work as is.  There are probably a few tools that have been deprecated but I don't know what they would be.

 

Also please don't think I'm attacking you.  I simply think 6.x is too far.  I'd say the majority of my code could be done in 2010 or 2009 without much trouble.

[JoeQ]

Actually I agree with you.  There is no way I could do in 6.1i that I can in 2014.  

 

I typically only use Labview to automate some sort of test, maybe collect and display some data.  In a few rare cases I have used it to replace writting a full on app.   It's been a great tool for engineering work.  I can get a lot done in short time.   I do not typically reuse my code.  Most of it is fairly simple and the tests are unique enough there is little to gain.   Any features they add that attempt to "help me" draw go to waste on me.   I know where I want things and how I want them wired.  If they want to help me in this area, make it fast and stable.   I would take 10 bug fixes of my choice over an autogrow feature!      

 

No one will say Labview has not improved over the years but some areas really lack luster for the time it has been on the market.  You mention the UI.   I was amazed when I found out that the simple edit commands that Windows supports were not supported in the tables, list boxes, or any other function I looked it.     For me, I just use the basics when it comes to the UI.  I'm sure you have seen some of my panels.  3D graphs are about as fancy as I get.  Any time I have tried to get too fancy all I do is waste a lot of time.   If I had one UI feature that I could add it would be solve the font problem once and for all!  I don't care how.  Make your own custom Labview fonts for all I care.  Just make it a standard.   

 

As impressed as I am with how advanced the majority of the libraries have become,  I am still amazed just how limited the Ethernet support is and how much I have to make direct calls to Winsock.   

 

If I were stuck with 2011 I would have been fine with it except for that free jitter tool kit is just so slick.  

[Mads]

I'm lucky to be the one that decides our upgrade strategy, and the philosophy is basically that we "Evolve or Die". This way we learn and adapt continously, making each step small and manageble (if we need a feature from 2015 it is likely that the transition is simple if we are already familiar with 2014).  

 

And perhaps most importantly it keeps the developers happy (who likes to be "stuck" in the old days). That is a major contributor when it comes to productivity, creativity and the quality of the work people do.

 

Sure, I would like to see more news between the different versions than we have done lately - yearly upgrades are a bit too frequent, but the frustrations we get from that have been outweighed by the positives.

[dannyt]

I very much agree with the comment below

 

 

Running applications from source is a bad idea in almost all cases.  I highly suggest building EXEs.  That being said it is more work to make an EXE.  Especially if for some reason the builder craps out and you need to start over again.  Locking down an application is critical if you are taking any kind of measurement so you know a developer wasn't fudging the numbers, or adding filtering and averaging to make it pass.

 

and think you really need to  look at going down the executable route for all your deployments. 

 

You say say you only have 4 developers so moving to a system of deploying executables you move yourself over to simple 4 LabVIEW 2014 licenses, maybe 5 if you want to get clever and have an automated build machine.

[Phillip Brooks]

You might also want to consider a license server. It seems that you have more licenses and stations than programmers. With a name based licensing setup, you could load LabVIEW on all potential test stations and program anywhere. If you have test equipment that you need to interface to, access to a locally installed LV instance is much easier than using a remote desktop to your dev machine and Remote VISA back to the machine you are working from.

 

The only limitation is that you can't be logged into multiple LabVIEW instances as the same user name simultaneously.

 

In an R&D or continuous manufacturing environment, you might need to make an update to a test in situ. That may be why you have local licenses installed. With network licensing, you could log into the network, load LabVIEW, open your source code from a network location (source control assumed), make the change, compile and build. Install the new build, test and leave the station running the newly updated EXE.

 

If your test stations are "off the network" then you've got other problems...

 

Just checked the NI site and it looks like LV2011 does not support Windows 8. Windows 7 for business will be supported for a while, but if your company upgrades to Windows 8.x or Windows 10, you might not be able to run your LV programs reliably....

Edited December 4, 2014 by Phillip Brooks

[Autodefenestrator]

 

 

Just checked the NI site and it looks like LV2011 does not support Windows 8. Windows 7 for business will be supported for a while, but if your company upgrades to Windows 8.x or Windows 10, you might not be able to run your LV programs reliably....

 

Ah, I didn't know that.  That's actually an argument that has the advantage of being both true and being understandable by someone who isn't a developer but has to approve our purchase reqs...

 

Given that preinstalled Windows 7 installs for all of the Home versions already have a set stop date by Microsoft, I think that could be a good argument to make.

 

The strategy of building executables is one we'd like to move to everywhere, but currently it only seems feasible with software revisions that haven't been changed in a year or so, as many of our processes need slight tweaks month-to-month as we have a lot of new products that keep adjusting their specs slightly.  We do have plenty of stations that we have executables for... just not enough to only need exactly 4 or 5 licenses.

[ShaunR]

Ah, I didn't know that.  That's actually an argument that has the advantage of being both true and being understandable by someone who isn't a developer but has to approve our purchase reqs...

 

Given that preinstalled Windows 7 installs for all of the Home versions already have a set stop date by Microsoft, I think that could be a good argument to make.

 

The strategy of building executables is one we'd like to move to everywhere, but currently it only seems feasible with software revisions that haven't been changed in a year or so, as many of our processes need slight tweaks month-to-month as we have a lot of new products that keep adjusting their specs slightly.  We do have plenty of stations that we have executables for... just not enough to only need exactly 4 or 5 licenses.

 

Be careful. The table is here. NI just say they haven't tested on those platforms. I know for a fact that even LV2009 works on 8.1 and it is difficult to see why any of them  wouldn't although addons, toolkits and DAQ may be sensitive. Even 2014 is only listed as "Partial" so just be aware of the specific claims.

[Autodefenestrator]

Be careful. The table is here. NI just say they haven't tested on those platforms. I know for a fact that even LV2009 works on 8.1 and it is difficult to see why any of them  wouldn't although addons, toolkits and DAQ may be sensitive. Even 2014 is only listed as "Partial" so just be aware of the specific claims.

 

I actually didn't see that table before, I was looking at a different page.

 

I think that the reason "mainstream support is ending" would probably be a good enough reason to push through getting some new versions in.  They may see that it's August 2015 that it ends officially and try to push it out a quarter or two but that could work.  The non-IT guys can understand that a lot better than developers wanting the newest version of something because it's "shiny".