LabVIEW 2013 Favorite features and improvements

[hooovahh]

The new Events features is my favorite. I did a presentation on this topic at NIWeek. I started a new thread to spur discussion (i don't want to derail the current thread). I'd like to get the community's input on the new event features. New Events Features in LabVIEW 2013

This is by far my favorite too. I missed your presentation because it was the same time as another and a tough decision was made. While web services are slick but I don't know if I will use them any time soon. And what about MyRIO? I know this is a new features of LabVIEW thread but why is a FPGA and dual core arm running linux real-time, with built in WiFi, and USB host for $500 not getting lots of attention (price was mentioned by NI but not confirmed yet)

[Christina Rogers]

Would you mind going into detail a little about what is done for the improvement?  Mostly just curious and if your answer is "It's complicated" then that's fine with me.  

 

We were just guessing at the Lava BBQ and we assumed that it was doing behind the scenes, what we were doing as work arounds.  Things like only updating cells you can see in the control, and only loading data for the cells you can see (so a table only has 10 rows show so it loads those 10 rows at a time with a fake scrollbar)

 

Most of what I changed for listboxes in 2013 was related to calculating cell boundaries. From profiling the code, I discovered that a) when all rows were the same height, the algorithm for calculating a cell's bounds was slower than it needed to be and b) we were calculating cell bounds more often than we needed to. Since it's fairly common for all rows to be the same height, it was worth putting in an optimization for that case.

[hooovahh]

Most of what I changed for listboxes in 2013 was related to calculating cell boundaries. From profiling the code, I discovered that a) when all rows were the same height, the algorithm for calculating a cell's bounds was slower than it needed to be and b) we were calculating cell bounds more often than we needed to. Since it's fairly common for all rows to be the same height, it was worth putting in an optimization for that case.

That's very interesting.  So I would guess (haven't tested yet) that any coding around we have done in past applications to improve performance, will continue to improve performance in 2013, but we may find that these improvements are no longer needed.  Thanks.

[Rolf Kalbermatter]

That's very interesting.  So I would guess (haven't tested yet) that any coding around we have done in past applications to improve performance, will continue to improve performance in 2013, but we may find that these improvements are no longer needed.  Thanks.

 

Or it might be that the cell boundary calculation was unnecessarily done in all updates for each cell. I doubt NI would not have some clipping optimization when updating for instance the cell background of many cells that they would even attempt to draw anything on the screen that will not be visible. They do have to go into the right cell and update its attributes accordingly of course so the cell can display correctly when scrolled into the visible viewport.

So your optimizations in the past mainly may have reduced the number of times cell boundaries were recalculated . Now with them gotten out of the way your optimizations might not harm but likely won't improve the speed much anymore.

And beware of changing the cell height accidentally for one row. That might disable the nice optimization from Christina altogether and get you back to the old situation.

[hooovahh]

And beware of changing the cell height accidentally for one row. That might disable the nice optimization from Christina altogether and get you back to the old situation.

Yeah when Christina mentioned the cell height of each cell needs to be the same, I thought when have I ever wanted the cell height to be different for a single row, and I guess there is a case for this but I have never needed it.

[mje]

Yeah when Christina mentioned the cell height of each cell needs to be the same, I thought when have I ever wanted the cell height to be different for a single row, and I guess there is a case for this but I have never needed it.

 

Often my header rows are different heights, though there are obviously other cases. Regardless, it is good to know of this optimization, as by knowing it I can use other tricks to show things like units and what not which would cause the abnormal sizes for a single row.

[hooovahh]

Often my header rows are different heights, though there are obviously other cases. Regardless, it is good to know of this optimization, as by knowing it I can use other tricks to show things like units and what not which would cause the abnormal sizes for a single row.

I forgot about this.  But usually to highlight this I will color the background a different color, or bold the font.  I don't think either of these change the cell height.

[John Lokanis]

I am really liking the new labels with arrows but I think I may have found a bug.  It seems that it is able to point to the diagram element correctly with primitives but if you have an object with a long label showing, it calculates the center of the item using the label and resulting in an arrow pointing in midair.

Not sure if this applies to other diagram items as I have only tried it with a few.

[JeffP]

I am really liking the new labels with arrows but I think I may have found a bug.  It seems that it is able to point to the diagram element correctly with primitives but if you have an object with a long label showing, it calculates the center of the item using the label and resulting in an arrow pointing in midair.

label arrows.png

Not sure if this applies to other diagram items as I have only tried it with a few.

Hi John,

 

I was only able to reproduce this with objects, but I filed CAR 422905 on it.

 

Thanks

[jcarmody]

Been using it for a week now, and have to say my favourite feature so far is the stability. Not a single crash, hooray!

 

LabVIEW stopped crashing for me when I upgraded to 2012.  2011 was HORRIBLE...

[Rolf Kalbermatter]

LabVIEW stopped crashing for me when I upgraded to 2012.  2011 was HORRIBLE...

 

Well, on that note I have all versions of LabVIEW installed on my system since about 5.0. A few months back LabVIEW 8.2.1 started to crash on startup but I didn't have any urgent need for that to work so left it at that. I did regularly check if it still crashed to because there was a potential project that might need a minor maintenance work in the near feature.

 

Just before installing LabVIEW 2012 I tested again and it still crashed. After installing LabVIEW 2012 SP1 and the according device driver DVD I tried again and it now worked. And no, I prevented the DADmx driver from removing any support from the LabVIEW 8.2 directory by hiding it (and the other versions, the DAQmx intaller wants to rob of all DAQmx VIs) during the install! So while 2012 may be more stable, the underlaying device drivers can make a much bigger difference.

[ShaunR]

Well, on that note I have all versions of LabVIEW installed on my system since about 5.0. A few months back LabVIEW 8.2.1 started to crash on startup but I didn't have any urgent need for that to work so left it at that. I did regularly check if it still crashed to because there was a potential project that might need a minor maintenance work in the near feature.

 

Just before installing LabVIEW 2012 I tested again and it still crashed. After installing LabVIEW 2012 SP1 and the according device driver DVD I tried again and it now worked. And no, I prevented the DADmx driver from removing any support from the LabVIEW 8.2 directory by hiding it (and the other versions, the DAQmx intaller wants to rob of all DAQmx VIs) during the install! So while 2012 may be more stable, the underlaying device drivers can make a much bigger difference.

 

Have you tried updating from the 2013 device driver DVD? A nasty little gotcha!

[Michael Aivaliotis]

LabVIEW 2013 has crashed twice on me so far. Sorry...

[Val Brown]

LabVIEW 2013 has crashed twice on me so far. Sorry...

 

 

Hmmm not on me so far...

[hooovahh]

LabVIEW 2013 has crashed twice on me so far. Sorry...

I have a problem where basically all versions of LabVIEW will crash on exit occasionally.  2013 is no different.  I suspect it is a system setup rather then a stability/instability of LabVIEW.

 

Traditionally NI (intentional or not) skips a version when it comes to stability in my opinion.  There are exceptions to the rule.  This list is just my experience and you're welcome to disagree.

 

7.0 - Not Stable

7.1 - Stable 

8.0 - Not Stable

8.2 - Stable

8.5 - Not Stable

8.6 - Not Stable

2009 - Stable

2010 - Not Stable

2011 - Stable

2012 - Stable

2013 - TBD

 

Is there a rule about software releases where every other version is good?  I feel like Windows follows this same rule.

[Darin]

I find that all LV versions can be stabilized. Any feature which leads to crashes is basically dead to me. Then it becomes a question of how useful a version is. 8.2 and 9 were both very good to me.

These days I consider the time between August and January to be the beta period and the release of SP1 to be time to dive in, especiallly when it comes to new features. There seems to be a relatively long time without an f1 patch, could be a good sign for 13.

Favorite feature is not a new one per se, but rather that the conditional tunnels no longer suck.

[crossrulz]

I have a problem where basically all versions of LabVIEW will crash on exit occasionally.  2013 is no different.  I suspect it is a system setup rather then a stability/instability of LabVIEW.

 

Traditionally NI (intentional or not) skips a version when it comes to stability in my opinion.  There are exceptions to the rule.  This list is just my experience and you're welcome to disagree.

 

7.0 - Not Stable

7.1 - Stable 

8.0 - Not Stable

8.2 - Stable

8.5 - Not Stable

8.6 - Not Stable

2009 - Stable

2010 - Not Stable

2011 - Stable

2012 - Stable

2013 - TBD

 

Is there a rule about software releases where every other version is good?  I feel like Windows follows this same rule.

I had nothing but problems with 2009.  Rarely ever ran into issues with 8.6.1 (which I have by far used the most).  I skipped 2010, so I can't comment on that.

But NI does keep making the point about how much time they have been spending on either fixing stability issues or adding code to help track down the issue in the last few years.  They are making progress.

[shoneill]

I have a problem where basically all versions of LabVIEW will crash on exit occasionally.  2013 is no different.  I suspect it is a system setup rather then a stability/instability of LabVIEW.

 

Traditionally NI (intentional or not) skips a version when it comes to stability in my opinion.  There are exceptions to the rule.  This list is just my experience and you're welcome to disagree.

 

7.0 - Not Stable

7.1 - Stable 

8.0 - Not Stable

8.2 - Stable

8.5 - Not Stable

8.6 - Not Stable

2009 - Stable

2010 - Not Stable

2011 - Stable

2012 - Stable

2013 - TBD

 

Is there a rule about software releases where every other version is good?  I feel like Windows follows this same rule.

Wait.  8.2 stable?  Maybe if you don't use LVOOP, otherwise is sucked hard.

 

2012 has been a real mixed bag for me.  Having a lot of crashes and other problems with drivers (FPGA etc.)

 

6.1 was stable.  I used it for years.

[hooovahh]

Wait.  8.2 stable?  Maybe if you don't use LVOOP, otherwise is sucked hard.

 

2012 has been a real mixed bag for me.  Having a lot of crashes and other problems with drivers (FPGA etc.)

 

6.1 was stable.  I used it for years.

Yeah I didn't know how far back to go.  I didn't use 5.x, and 6.x much but from what I remember it followed my semi-pattern.

 

5.0 - Stable

6.0 - Not Stable

6.1 - Stable

 

Don't ask me to go back farther.

My current installation of 2012 crashes regularly when exiting LV, but only with one project that has a bunch of CAN comms in it. So it could be driver related.

You know my projects have alot of CAN/XNet stuff it could be the driver I guess.

[Aristos Queue]

7.0 - Not Stable

I know mileage may vary, but I question your judgement as a result of this evaluation. 7.0 was the "extra year with nothing but bug fixes". It was rock solid -- 7.1, which you credit as stable, was a release where essentially nothing changed in the core, only in the RT/FPGA modules. Any stability of 7.1 was due entirely to 7.0.

 

And if you're going to classify 8.2 as stable, you have to classify 8.5 as stable if for no other reason than the vast majority of the code changes between those two were stabilization fixes (still cleaning up the disaster that was 8.0). I don't care if you change 8.2 to unstable or if you change 8.5 to stable, but there's a deep and obvious trend in the bug reports from that era.

[John Lokanis]

I have created projects that would crash or warn on exit in multiple versions of LabVIEW.  The most recent one turned out to be a corrupt 3rd party class file with bad mutation history.  There is now a CAR to address it.  So, be careful labeling version A or version B stable or unstable.  It might be bad data in your source files.

 

I have been able to build and release applications with every version going back to when the application builder was first introduced that have been stable.  It all depends on what features you choose to use and what extras you bring in.  I have always found the core functionality of LabVIEW to be stable.

You may still run into some issues at the fringe, but NI has always been good about tracking and fixing issues in a timely manner, in my opinion.  Much better that the majority of other software tool vendors.

[Aristos Queue]

My own rankings, based on both my own perceptions as I work in these versions, on the CARs I was fixing for each version, and the amount of complaints I heard from customers on the forums. Note that these do not really reflect the stability of the modules, just of LabVIEW itself. I realize that for many of you, RT and FPGA are LabVIEW, but for me, they're add-on libraries that are separate products to be evaluated separately. I don't have enough data to evaluate the FPGA module. For RT, I've included comments where I feel it differs from the rating for LabVIEW Core. In general, RT cannot be better than Core simply because the crashes are cumulative. If Core is unstable, RT can't help but be unstable.

 

6.1 - Average (RT Below Average)

7.0 - Far Above Average (RT Above Average)

7.1 - Far Above Average <<< almost identical to 7.0 except for work in the modules

8.0 - Far Below Average

8.2 - Below Average (RT Far Below Average) <<< RT impacted by lingering 8.0 project issues

8.5 - Below Average but better than 8.2

8.6 - Average

2009 - Average

2010 - Below Average but better than 8.2

2011 - Above Average <<< Many people called this the new 7.0 and it had extremely fast adoption rate

2012 - Above Average

2013 - Above Average (keep in mind that I've been actively developing in 2013 for months longer, in alpha and beta, than most of you, so I feel I have enough time under my belt to evaluate this one)

 

 

Some folks are likely to chime in that the SP1 (or previously the x.x.1) releases are more stable than any of these and so they never upgrade the software when it first comes out. It's an ok position, but, honestly, the particular set of bugs may shift, but none of the recent versions since 2010 has had any retrograde in overall quality. There's enough code quality checking in the modern era that I don't think users should be generally concerned about upgrading when the new version comes out other than the churn it creates in their own business processes.

[ShaunR]

Well. My list doesn't just include stability. It also includes performance (both exe and IDE).

 

There have been only 2 that have been exemplary (too long ago to remember exactly before 7.0, but started at around 2.x and have no bad impressions). Only labview before 8.x was bullet proof IMHO and even as far back as 2.x it was rare to get an Insane Object (the equivalent of a GPF in the more modern versions) which I experienced 2 or 3 times a year..

 

So. Outstanding editions:

7.x

2009

 

There have been some real dogs too

 

8.x (yes all of them!)

2010

 

That leaves high project risk but maybe worth it for the features or if specific fixes address business critical problems you have experienced (they didn't for me)..

 

2011 ("Performance and stability release" was a joke, and I said so at the time)

2012

 

So on to 2013.

My experience so far is that it is excellent and, if it didn't have the JSON issue or it had a a few more new events, I would have upgraded from 2009 when SP1 comes out. The issue for me is that when installing  the latest DAQ it states that it will bork 2009 DAQ functions and I'm not prepared to do that. So whilst I might have upgraded to LV2013, I am now and will be forever stuck at the current version of DAQ until I abandon 2009..

Edited August 21, 2013 by ShaunR

[Darin]

I would clarify that old features do not seem to regress in the new versions, but most new features need at least the first SP to get polished. Usually this means fixing bugs found too late in the beta cycle. 7 was a good version in retrospect. At the time it gave us Express VIs and worked hard to shove them down our throats. Having repressed those memories does seem to improve my outlook on it. I just reinstalled a copy this morning. Another cool feature in LV13 is the scaling of the event structure dialog. I do miss the old getting started window, I think I will have to hack that. Harder now with those darned PPLs.

[Val Brown]

Hmmmm, well everyone has opinions don't they.  FWIW I think 2013 is very stable and, again FWIW, I don't have to deal with DAQ so I can't really say much about ShaunR's perspective, except to sympathize.  So my experience: I've migrated a very large and complex app to 2013 (having nursed it all the way through 5x) and this was the easiest migration ever.