LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Intaris

LTS (Long-term support) vewrsion of LabVIEW

Status: Declined
Thank you all for providing feedback on this idea. After carefully researching our options and talking to many customers about the possibilities, we have decided not to pursue a separate version of LabVIEW at this time. Instead, we have dedicated more resources to improving the stability and performance of our standard LabVIEW releases. The latest release, LabVIEW 2011, is an example of this emphasis, see here (http://zone.ni.com/devzone/cda/tut/p/id/12890) for more details. We plan to continue this type of emphasis for future releases.

I want to be able to work on STABLE versions of LV.

 

The last great stable version I remember was 6.1 (I never had 7.1).

 

2009 and 8.5.1 were not bad but please give us a feature-fixed long-term support version of LabVIEW.

 

For anyone unfamiliar with the idea, many Linux distributions offer the same:  Here's a link to the Ubuntu webpage outlining THEIR LTS strategy.

 

Shane.

21 Comments
CharlieRodway
Active Participant

Just to let the forum know, Gerardo G called me this week to get a handle on our requirements as a company.

 

It's great to see National Instruments following the forums, picking up on customer ideas and running with them.

 

BTW, today's Dilbert made me chuckle, I hope GerardoG's boss isn't like Dilberts!

 

Regards, Charlie

 

untitled.gif

Charlie Rodway | Principal Software Engineer | Certified TestStand Architect (CTA)

Computer Controlled Solutions Ltd | NI Silver Alliance Partner | GDevCon#1 Sponsor

hecmar.arreola
Active Participant

Although I have had very few issues with the last few "big" versions of LabVIEW, I remember having lots of fits with version 8.6.  I'd like to see a LTS version of LabVIEW that was included with SSPs.  People who want single licenses can decide if they want the LTS or latest version at the time of purchase.  It would also be helpful if NI just made some general rules for their definitive version (i.e., a new version will be chosen as the new LTS every 3 years or every 5 years).  Not sure how this would play a role in profitability... not my department ;).

LuI
Active Participant
Active Participant

To Gerardo:

> When you install a service pack, does it force you to revalidate your code? 

 

Well, this is not really related to LabVIEW, but, YES!

I am working at a producer of medical devices and SW. We have an approval test for our end-user SW that is run for all actually supported versions whenever a new bugfix of the SW that is supposed to run with our SW (especially WinXP, Vista & Win7) comes out. The test runs in virtual machines and/or images and is partly automated and partly manually performed. One of my colleagues uses allmost 1/3rd to a half of his work time for that purpose.

 

I create Test Systems (TS) for those medical devices and have to approve both a Test Stand (including HW and Win Patch status), the version of LabVIEW and any version of the TS-SW build from that. BTW, my codebase is still at LV7.1.1 as it does what I need and is approved and stable. Nevertheless I have an SSP and have newer versions installed on my work-PC.

 

And to make it clear: Validation of SOUP (SW Of Unknown Provenance) does not mean to test all of its features and properties, but testing what is expected to be critical for the required functionality and safety. So _my_ approval test for LV (7.1.1) in its current version is to load a smaller test project, run it, build an app from it and run that as well. If it meeds the specified criteria than the validation is given.

 

Greetings from Germany!

--

Uwe

GerardoG
Member


Hello all,

 

Thank you all for providing feedback on this idea. After carefully researching our options and talking to many customers about the possibilities, we have decided not to pursue a separate version of LabVIEW at this time. Instead, we have dedicated more resources to improving the stability and performance of our standard LabVIEW releases. The latest release, LabVIEW 2011, is an example of this emphasis, see here for more details. We plan to continue this type of emphasis for future releases.

 

We encourage you to continue providing feedback on LabVIEW.

 

Gerardo Garcia

National Instruments

G-Money
NI Employee (retired)
Status changed to: Declined
Thank you all for providing feedback on this idea. After carefully researching our options and talking to many customers about the possibilities, we have decided not to pursue a separate version of LabVIEW at this time. Instead, we have dedicated more resources to improving the stability and performance of our standard LabVIEW releases. The latest release, LabVIEW 2011, is an example of this emphasis, see here (http://zone.ni.com/devzone/cda/tut/p/id/12890) for more details. We plan to continue this type of emphasis for future releases.
Mads
Active Participant

I think the core of this idea is the need for long term support, not that there should be a separate version of LabVIEW for it.

 

I too am worried about how we are going to support products we deliver now that have fieldpoint controllers running LabVIEW RT. If we need to troubleshoot or upgrade one of thise devices in ten years time it's not like we can open the source code in LV 2020 and start debugging. We might not even be able to open the code. We will have to upgrade the OS and LabVIEW version on the controller, and most likely that will not even be possible as the hardware will no longer be supported. So we basically have to store machines with all kinds of versions of LabVIEW on them for years to come, and hope that those machines will still run and be able to connect to our future Volume License Server to get a license to run(!) whenever they become needed.

 

Another case is the lack of backwards compatibility with code compiled in previous versions of LabVIEW. We have a wide range og plug-ins for our products, and every time we upgrade the main applications we have to recompile all the plugins as well because otherwise they will not be callable by the new main application. With the backwards compatibility going 0 versions (!) back we have to do this *every* time we upgrade to a new LabVIEW version, which now, thanks to the new versioning strategy of NI, happens to be every year. Sure, we could stick to an old version for years, but that's not a good strategy either as we do want our products to live on and adopt new technology and fixes as they become available.

ErnieH
Active Participant

If NI won't create a long term stable version, then the users will create their own rules for updates. We are going to a 3 to 5 year update cycle. Any bugs we encounter on the current version will at least be known and documented. We simply don't have the manpower to update twice a year (with service packs) and constantly update our systems on the manufacturing floor and the field. Currently we support 2009 and 2011 SP1. 8.5 for an older real time fieldpoint realtime system since that is the latest version that is supported for that product. A few older ones will be updated to 2011 when their PC's fail. See ya for LabVIEW 2016.

Intaris
Proven Zealot

I just want to say that shifting focus to more stable environment should be a reason to support this idea and not as a reason against.

 

The problem behind this idea is not going to go away and I truly belive it's going to be an inevitable step for NI eventually.

Intaris
Proven Zealot

I'm sorry, but I have to re-activate this idea.  I categorically refuse to accept the reason for declining this idea.  If you can come up with a better reson, fine but the one given is completely insufficient.

 

It's nice and all that you're focussing on stability but I STILL have a lot of bugs in LV 2011 which will no longer be fixed due to LV 2012 being out.  There are lots of LV developers who are tied into a certain version of LV and can't simply change versions to get things working.

 

I find it absolutely inacceptable and extremely worrying that NI doesn't seem to put any kind of weight on this topic.  Yeah, producing more stable code is cool but there's only so much you can fix (and only so many bugs that can get found) within the 1-year update cycle being used.

 

There's a big problem with this looming in the not-too-distant future and if NI doesn't do something to properly alleviate it I believe it will eventually bite NI in the A$$.

 

PS There are a Thousand CARs being filed every MONTH.  Extrapolate that and you'll get a feel for how many bugs are going to be left unfixed in any given versions.

Ray.R
Knight of NI

I gatta support Shane on this one..  Wish I could still give Kudos..