LabVIEW new version Every year - Why?

[DianeS]

Thanks Guenter!  It's good to know that other folks feel the same way and run across the same problems.  I've been tempted on a few occasions to start this thread -- specifically when one of my machines has crashed or I'm having hardware driver compatibility issues -- so thanks to the OP for doing so!  It is certainly a topic which can use a good airing. 

[JordanG]

Thanks for all the feedback. I've passed this information and a link to this specific thread on to our LabVIEW team. Your honest feedback and suggestions are valued and without it, LabVIEW wouldn't be where it is today! 

Thanks again and keep it up,

Jordan

[Mark_Yedinak]

---

@Jordan G wrote:

Thanks for all the feedback. I've passed this information and a link to this specific thread on to our LabVIEW team. Your honest feedback and suggestions are valued and without it, LabVIEW wouldn't be where it is today! 

Thanks again and keep it up,

Jordan

---

While I don't necessarily want to wait too long for a service pack it would be nice if major releases were released every two years. The problem with every year is that while you can open older code in the new version the reverse is not possible. This is one downside of a graphical language. Code from text based languages can generally be compiled in multiple versions of the compiler. LabVIEW (G) is limited because older versions cannot open code from newer versions. At least try to give us some level of compatibility besides "Save for previous version".

[JÞB]

Mark,

I hadn't ever considered that drawback of LabVIEW.  Seriously! since LabVIEW 6.i was introduced this last 2 months is the first time I have only had 1 IDE installed on my primarry development machine (and its Latest and Greatest.- so not compatability issues)  Oh, I admit having a half ton of media lying around sometimes got confusing (untill I learned to write on my DS DVDs with a sharpie to document LabVIEW and TestStand Vers)  But since my reuse code was allways archieved and in source control by LabVIEW Rev I never found the version backward compatability to be an issue.

[johnsold]

Mark,

I think you are on the right track there.  Suppose that we could open, edit, re-compile, and run a VI first created in LV 2011 in LV 9 without back saving from 11?  If a feature, VI, or component was added in VL 2010 or LV 2011 that  was not available in LV 9, then of course the VI would open broken with a list of errors and warnings.  As you pointed out many compilers for other languages are both forward and backward compatible.

I doubt the file format changes much from version to version.  I opened a vi.lib VI from LV 7.1 and the VI with the same name from LV 2011 as text files. The first 18 bytes are identical and much of what appears to be a header has a similar format.  Similar in the sense of patterns of 00 bytes separating non-zero bytes (which differ between versions).  All recent versions of LV know the compiler variations for several previous versions.

NI, are you doing something in there which is important enough to the newer versions that the old version could not recompile?

Lynn

[JÞB]

---

@johnsold wrote:

Mark,

I think you are on the right track there.  Suppose that we could open, edit, re-compile, and run a VI first created in LV 2011 in LV 9  ....

NI, are you doing something in there which is important enough to the newer versions that the old version could not recompile?

Lynn

---

Yes, NI is selling SSP and providing you with the latest IDE.

It is unfortunate that versions do not get continual patches to fix bugs (or 3 year support at least) This has a side effect that I tend to be an early adopter of the new versions.  Since I keep my SSP up to date I don't NEED to open a 2011 VI with 2009. (although, Save for previous could be tweaked some to avoid toolkit incompatabilities)

Ideally, when opening a LabVIEW 2011 vi with LabVIEW 2009 a little birdie would peek into the vi (like the one that tells me the version is too new!) and prompt a save for previous TO the target version from the installed 2011 compiler.  (Lightweight launch Do we really need to launch ALL of LabVIEW to compile 1 vi?)  Definately encourages me to keep my SSP active and actually Install the new IDE.

[Mark_Yedinak]

---

@Jeff Bohrer wrote:

---

@johnsold wrote:

Mark,

I think you are on the right track there.  Suppose that we could open, edit, re-compile, and run a VI first created in LV 2011 in LV 9  ....

NI, are you doing something in there which is important enough to the newer versions that the old version could not recompile?

Lynn

---

Yes, NI is selling SSP and providing you with the latest IDE.

It is unfortunate that versions do not get continual patches to fix bugs (or 3 year support at least) This has a side effect that I tend to be an early adopter of the new versions.  Since I keep my SSP up to date I don't NEED to open a 2011 VI with 2009. (although, Save for previous could be tweaked some to avoid toolkit incompatabilities)

---

While I keep my SSP up to date and can get the latest and greatest this is not reason enough to prevent people from sharing raw source code without requiring the additional steps to downgrade. Consider a new library developed by someone for public use. The only version they have is 2011. If this code is pretty generic and not using some of the latest and greatest features it would be nice to be able to share this with other users without requiring the developer to save as previous for the distribution. And as mentioned if some new feature was used that code would come up broken. Most of the core programming elements have been pretty stable for several releases.

[RobCole]

A problem that I ran into was that the SSP I had ran from time of purchase, not for a LabVIEW version.

Let me clarify that. My SSP covered an upgrade to LabVIEW 2010, but ran out before the service pack was released. I got a new customer that had the service pack, so I installed it at home (the customer's code was running it) and the NI License Manager would not accept my serial number for the service pack. I had to uninstall it and re-install the first version. Unfortunately, I found VIs saved at my customer's that would not open in the original version. So, I contend that the version is updated twice a year. Not once. And I think once is too much. Or, at least, make the SP available to everyone who has a valid copy of the version.

The problem is now moot since I took a full-time position with an Alliance member that maintains their SSP. Less contracting and more programming.

    Rob

[Coq_Rouge]

From a reliable inside source in NI. I was informed that the main reason for this is most of all economic. As long as the customer do not update. Ni will "loose" income on that software license. It was a problem for NI that customers stayed on a Labview version for a long time without upgrading. So the new version every year. Is a way of motivating/forcing us customers into a more frequent update. In order to generate more income. NI like all all other companies. Need some profit to keep the wheels going. So I do not think it is fair to criticize them for that new business plan. A more than fair share of the profit in NI. Goes back to NI and are used for development and R&D. More than in many other comparable companies

[smercurio_fc]

---

@COq Rouge wrote:

So I do not think it is fair to criticize them for that new business plan.

---

Actually, it is. Especially if, as explained in previous posts, it creates extra work and headaches for, oh, say, NI's customers. In fact, it's these kinds of decisions that lead many to either no longer recommend LabVIEW, or to abandon it because the "upkeep" for it is simply too expensive.