LabVIEW 2013 Favorite features and improvements

[John Lokanis]

Just ported my project to LV2013 (livin on the bleeding edge!)

I am sure to find many cool new features and improvements but I thought I would share one with you the jumped right out at me:

 

The Tree Control is 10x faster!     

(At least, when I am setting cell colors on multiple rows while updates are deferred.)

 

In my example, it was taking 4-5 seconds to do the update for a few 100 rows in LV2012.  In LV2013 it takes less than a second.

This will be a big improvement for my GUIs.  So, thanks to the engineer(s) who worked on this!  

 

I wonder if this is specific to the tree control or if other UI processing is also improved?

 

I will report back with more finds but please add your own to the thread.

 

-John

[hooovahh]

This almost worries me.  You see for years the Tree control, multicolumn listbox, and table have been dog slow at doing individual cell updates when there are many.  So to get around this I have several coding techniques that will improve performance.  Things like only updating the cells visible, only showing a subset of the data then load the other data when you scroll, and defer front panel updates.  

 

So my worry is that my performance from older applications will actually be slower then the native implementation, and now I'm going to end up removing all that hard work I did to get around LabVIEW's issues.

[John Lokanis]

I too have jumped through many similar hoops over the years.  But you need to embrace change!

Think of it this way: the code that drew the colors when scrolling will just run 10x fast now!

[hooovahh]

Don't get me wrong, I can't wait to try it out and see what other features 2013 is going to have.

 

So generally LabVIEW releases are hit and miss.  They will have a stability build, then a feature build, where the feature build will be great but usually rough around the edges.  Since having a service pack mid-way through the year this seems to make sure all released versions are solid.  For this reason I have no fear about using a SP1 version of LabVIEW.  But I am still apprehensive about switching to a new version before this SP1.  

 

This could probably be made into a new topic, but do you believe you will switch to 2013 as soon as possible?  Or are you going to wait a bit and test the waters before diving in?  The idea of using new awesome stuff both frightens and excites me.  My colleges usually wait until SP1 because it lines up with the Veristand release so if I did go 2013 I would be the one finding all the issues first.

[ShaunR]

Don't get me wrong, I can't wait to try it out and see what other features 2013 is going to have.

 

So generally LabVIEW releases are hit and miss.  They will have a stability build, then a feature build, where the feature build will be great but usually rough around the edges.  Since having a service pack mid-way through the year this seems to make sure all released versions are solid.  For this reason I have no fear about using a SP1 version of LabVIEW.  But I am still apprehensive about switching to a new version before this SP1.  

 

This could probably be made into a new topic, but do you believe you will switch to 2013 as soon as possible?  Or are you going to wait a bit and test the waters before diving in?  The idea of using new awesome stuff both frightens and excites me.  My colleges usually wait until SP1 because it lines up with the Veristand release so if I did go 2013 I would be the one finding all the issues first.

 

Let John find all the issues  then switch when you start a new project (if it is after SP1). By all means "play" but as far as real projects are concerned; you are spot on with your current regime IMHO

 

It's all very well "embracing change" but changing/upgrading tool chains is a huge project risk and there have to be specific, justifiable benefits. Unfortunately, I have not seen any practical benefits of note after LV 2009 for my projects. Lets see if that changes with LV 2013.

[John Lokanis]

Oh, I would not be switching to LV2013 yet either if my project was near completion.  But in this case, I do not expect to be ready to release until well after SP1 comes out.

For me, there are many compelling features in 2013 that I want for this project.  Including the new web service features and the improvements to .net calls.

Getting this tree control speedup is just a bonus.

In the past I have always waited for SP1 before updating my projects.  It is actually kinda fun to be able to jump in the pool early this time.

As for upgrading my tool chains, that took all of 20 minutes to install packages from VIPM, copy reuse code, recompile and save everything.  The only 'bug' I ran into is the new rule that a shared clone cannot statically link to an Application level event.  Not sure why this is but the workaround was fairly painless to implement.

[Phillip Brooks]

Did the download include a new features list?

 

If so, could you share it here?

[John Lokanis]

Did the download include a new features list?

 

If so, could you share it here?

Try this:

http://www.ni.com/pdf/manuals/371780j.pdf

[ShaunR]

ooooh.Gonna have to check these out.

 

• Flatten To JSON
• Unflatten From JSON

[Christian_L]

Did the download include a new features list?

 

If so, could you share it here?

 

Check out http://www.ni.com/labview/whatsnew/

[todd]

Aha! jlo got (at least) one in. Is it above or below the attribution?

http://zone.ni.com/reference/en-XX/help/371361K-01/lvupgrade/labview_features/

 

Application Builder Enhancements Automatically Selecting NI Software for Installers

  When you build an installer in LabVIEW 2013, LabVIEW automatically selects installers for the drivers and other software components required by the built application. Use this feature to reduce the possibility of building an installer without the right components. To disable this feature, remove the checkmark from the Automatically select recommended installers checkbox on the Additional Installers page of the Installer Properties dialog box for the installer.

[idea submitted by NI Discussion Forums member jlokanis]

Creating Directory Versions in Build Specifications

In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box.

[John Lokanis]

I have been immortalized in the LV2013 release notes!  

 

I am so glad they added this.  Although I think it is more because I kept calling support and asking them what each installer did what and when it was needed.  I was amazed that the top-tier test support guys didn't have any more clue than I did.  I'm betting this feature alone reduces the number of calls they get in the future.

[hooovahh]

I have been immortalized in the LV2013 release notes!  

 

I am so glad they added this.  Although I think it is more because I kept calling support and asking them what each installer did what and when it was needed.  I was amazed that the top-tier test support guys didn't have any more clue than I did.  I'm betting this feature alone reduces the number of calls they get in the future.

I had this issue just yesterday.  I built an EXE and and installer and put it on a new PC which complained about missing a DLL.  Lots of searching later I found it was an XNet DLL, so I searched for all XNet functions until I found one place where it was never being called.  I have yet to call support for this issue but I have spent alot of my own time trying to figure it out.

 

EDIT: A few that caught my eye.

 

Scripting the event structure.

More control over events like queues (flush priority and size)

Email with security

Tasks/Todo lists built in (I was just about to make a tool for that)

Better build errors (hopefully we won't see a blank details again)

Control value by index seems neat but I think there are other ways to do the same thing

Edited August 2, 2013 by hooovahh

[JamesMc86]

Not had a chance to use in anger yet but the new experience for web services looks like a massive improvement. Adding static pages previously was a but cludgy but this looks to be a huge improvement.

[gregstoll]

Control value by index seems neat but I think there are other ways to do the same thing

As I worked on this, I feel obliged to chime in :-)

 

There are definitely other ways to do the same thing, and they're pretty much all easier than using Set/Get Control Value by Index.  The reason you would want to use Set/Get Control Value by Index is that it's very fast - just barely slower than wiring directly to an indicator.  So it's useful if updating control/indicator values is something you're doing many times a second - otherwise there's no reason to switch to it.

[JamesMc86]

 very fast - just barely slower than wiring directly to an indicator.  

 

I'm guessing this means no switch to the UI thread, presumably similar performance to a local variable?

[Cat]

Don't get me wrong, I can't wait to try it out and see what other features 2013 is going to have.

 

So generally LabVIEW releases are hit and miss.  They will have a stability build, then a feature build, where the feature build will be great but usually rough around the edges.  Since having a service pack mid-way through the year this seems to make sure all released versions are solid.  For this reason I have no fear about using a SP1 version of LabVIEW.  But I am still apprehensive about switching to a new version before this SP1.  

I had the same reaction regarding trees, multicol listboxes, etc. and all I've had to do to program around issues in the past.

 

Also, I was severely bitten in multiple ways by 2011 -- the last "stability release", IIRC.  I installed 2012 the  moment it came out and got rid of several big problems. I'll be waiting for all of you to test out 2013 for me before I upgrade.

[gregstoll]

I'm guessing this means no switch to the UI thread, presumably similar performance to a local variable?

Yup!

[shoneill]

Favourite LV2013 addition?

 

Fixing waveform chart bug which should be also fixed in LV 2012 but probably won't be........

 

Aside from that, the ability to limit the depth of any given event queue is really huge.  If you've ever thought of combining events with a notifier to get around some messy "Mouse move" events, this is the answer to your prayers.

 

Shane

[Wire Warrior]

Downloading now!  I can't be at NIWeek but I can download LV2013!!

[hooovahh]

As I worked on this, I feel obliged to chime in :-) There are definitely other ways to do the same thing, and they're pretty much all easier than using Set/Get Control Value by Index.  The reason you would want to use Set/Get Control Value by Index is that it's very fast - just barely slower than wiring directly to an indicator.  So it's useful if updating control/indicator values is something you're doing many times a second - otherwise there's no reason to switch to it.

That is really neat and I will want to do some tests to compare results with OpenG, and MGI options too. My original thout was replacing the save to panel and load but that will happen seldomly and a better use case is as you said, constantly updating a UI.

[Christina Rogers]

The Tree Control is 10x faster!     

(At least, when I am setting cell colors on multiple rows while updates are deferred.)

 

In my example, it was taking 4-5 seconds to do the update for a few 100 rows in LV2012.  In LV2013 it takes less than a second.

This will be a big improvement for my GUIs.  So, thanks to the engineer(s) who worked on this!  

 

I wonder if this is specific to the tree control or if other UI processing is also improved?

 

You're welcome.

 

(And sorry it took so long for us to find a way to address this).

 

The changes that improved this performance were specific to the listbox, multicolumn listbox, table and tree controls. I don't expect that they will conflict with any "programming around the problem" tricks that you've used in the past.

 

[hooovahh]

You're welcome.

 

(And sorry it took so long for us to find a way to address this).

 

The changes that improved this performance were specific to the listbox, multicolumn listbox, table and tree controls. I don't expect that they will conflict with any "programming around the problem" tricks that you've used in the past.

Thank you so very much.  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)

[Michael Aivaliotis]

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

[JackDunaway]

Favorite feature: LabVIEW Web Services in 2013 -- the R&D Team nailed it with the all-new LVOOP API