LabVIEW 2013 - a step backwards?

[cowen]

Hi Guys,

 

I am just wondering what the impression of developers is regarding the LabVIEW 2013 release?

 

We have been developing a large application and have found it to be very unreliable and buggy. All of our developers have several crashes per week (sometimes per day). In addition, as the project has grown we have found that opening or closing a VI in our project results in a 1-2 second delay. Strangely though if we switch from project view to file view, the delay does not occur.

 

I am in communication with NI regarding the delay, but a response of ""since this delay is not that long, I do not think there is something that can make the delay shorter" is very disappointing. Imagine working on your project and hitting this 1-2 second delay every time you open or close a VI. This delay also occurs if you add a project subVI to the VI under development. :-(

 

OK, I am just interested if our perception of LV2013 matches that of others.

 

Cheers

[todd]

I've only done two medium-size projects in 2013 (<2,000 VIs). Classes, Actors (now that I've got the lvlibs partitioned properly), ACBR. So far, so good.

[LogMAN]

LabVIEW 2013 is quite new and to me it is relatively normal for a new version to present annoying problems until the first SP release and .f# bug fixes. I had to switch to LV2013 from LV2011 for a single project with about 2k VIs, since the project did crash on the old version due to some architectural issues that could not be solved in time. However on LV2013 it worked quite well and even better when it comes to classes and property nodes as well as large cluster hierarchies (still some lag, but much less than before). So far I have found only one critical bug which has been solved recently: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/

 

Whether or not the new version is better or worse for you depends on your project size, architecture, used addons, etc...

 

Anyways I wish NI would spend more time on fixing bugs and increasing performance of the IDE rather than implementing more and more possibly unstable features. Whenever a new version is released, the methods we do to validate the stability and usability of that version is very time consuming and more and more often leads to the choice to not update to the newer version (used 8.6.1 till 2011, and 2011 since than - 2013 is an exception after hours and hours of discussion). The main reasons to not update are bugs which cause our VIs to stop working or systems to crash after several hours.

 

My experience is, that in almost every case the IDE is unstable because the sources are not very well designed (see discussions regarding code complexity & dependency trees). So I think as NI should work on stability and performance, we have to work on our own sources to solve bugs and decrease code complexity. Due to new features in the IDE, the code complexity will increase, sometimes without us wanting to, because we do not always understand the behaviour and/or purpose of some components.

[Antoine Chalons]

Here's one person's opinion that I think is to be taken into account : http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/?p=105003

[Val Brown]

I agree with AQ on this: ie I have found 2013 to be very stable.

[mje]

2013 is the first version of LabVIEW in a long time I have not had any major problems with.

[jzoller]

Not sure here, it won't install on my work machine.  It appears to be interacting poorly with something from my IT group.

 

I'll try again when I really need it.

[ShaunR]

Hi Guys,

 

I am just wondering what the impression of developers is regarding the LabVIEW 2013 release?

 

We have been developing a large application and have found it to be very unreliable and buggy. All of our developers have several crashes per week (sometimes per day). In addition, as the project has grown we have found that opening or closing a VI in our project results in a 1-2 second delay. Strangely though if we switch from project view to file view, the delay does not occur.

 

I am in communication with NI regarding the delay, but a response of ""since this delay is not that long, I do not think there is something that can make the delay shorter" is very disappointing. Imagine working on your project and hitting this 1-2 second delay every time you open or close a VI. This delay also occurs if you add a project subVI to the VI under development. :-(

 

OK, I am just interested if our perception of LV2013 matches that of others.

 

Cheers

 

Well. My 2p. It's the best since 2009, but there have been some real dogs (yes 2010, I'm looking at you).

[todd]

My experience is, that in almost every case the IDE is unstable because the sources are not very well designed (see discussions regarding code complexity & dependency trees). So I think as NI should work on stability and performance, we have to work on our own sources to solve bugs and decrease code complexity.

Yes, the IDE is stable until a user does something less than ideal, So instead of a user having to learn what will work, perhaps the IDE can teach us what won't work. Perhaps show the user what's taking so long.

[hooovahh]

I have not used it on a real project yet, but what work I have done with it appears to show it as being stable.  I also agree that we probably won't be using it on large projects until the SP1 release.  We also have some Veristand guys and we try to all upgrade at once.  Veristand 2013 came out a few weeks ago so hopefully we can all just wait until the SP1 release of LabVIEW and upgrade together.

[cowen]

Thanks for all your opinions guys.

 

We have a project that began in LV2012 and is now under development in LV2013. We have the problems I orginally described (slow VI open and close, LV crashing).

Given that your feedback is so positive, I have to wonder what is wrong in our case. I will create a new project file and see what effect this has. Of course a mass compile was done when we moved to LV2013.

 

 

As a general rule we do not upgrade to the latest LV versions each time they are release. LV8.2.1 was used for several years and only last year did we switch to LV2011. With us developing a new project, we decided to develop with the latest LV version. Once the first EXE is released, the LV version will be fixed for several years (unless there is a good reason to upgrade).

[cowen]

A small update to this. Our project contains 2000+ VI's. With trial and error I have tracked down that it is one specific VI that has been causing our delay in the project. The VI in question uses Hash functionality as shown here:

http://lavag.org/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=2583

 

Deleting this code from the VI fixes all problems in my project. I have passed this information to NI. Interestingly, commenting out the code is not enough, it really does have to be deleted.

[LogMAN]

A small update to this. Our project contains 2000+ VI's. With trial and error I have tracked down that it is one specific VI that has been causing our delay in the project. The VI in question uses Hash functionality as shown here:

http://lavag.org/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=2583

 

Deleting this code from the VI fixes all problems in my project. I have passed this information to NI. Interestingly, commenting out the code is not enough, it really does have to be deleted.

 

Let me share my experience based on your example:

 

As soon as I load the constructor, my system shows heavy disk operations. So I close LV (eventually killed the process)... Restart the system in order to try again... Wait for 15min, until no process does anything anymore, take a look into the resources monitor -> everything is fine. Now again starting LV -> create new VI -> insert the constructor, wait approx. 5s... System overflowing with disk activity (100%).

 

The load is caused by MsMpEng.exe which is part of Microsoft Security Essentials. For some reason it will start scanning the entire computer!? (The highest load is given to the MFT). Of course LabVIEW is now very slow as many other programs that rely on disk activity.

 

All caused just by putting the SHA256Managed constructor in a blank VI!

Tested in LabVIEW 2013 (32bit) on Windows 7 (64bit)

 

Maybe somebody else can confirm this behavior?

Hint: The constructor is located at: mscorlib->System.Security.Cryptography->SHA256Managed

[LogMAN]

Update: My computer finally decided to take a rest, so I decided to restart LabVIEW and try that a third time. The environment does run just fine without any disturbing disk activity. Am I seeing stuff ? ?  -> Restart again, as third fourth time's the charm, now waiting for 30min... New VI as before, constructor and... nothing!

 

So obviously the MsMpEng.exe did not relate to the issue at hand and was randomly scanning my computer twice just as I placed the constructor. Thanks Bill!

[BramJ]

Just tried it on my work machine running LV 2013 64-bit, don't notice anything slowing down. Also adding it to a project caused no problems

[Neil Pate]

 Perhaps show the user what's taking so long.

Would love to have this.

 

I have a medium size project (approx 1000 VIs) that I have to maintain, and edit operations are very slow. Drop VI, wait, make a wire change wait etc etc. I have a similar version of the code base where I managed to fix this by re-organise the hierachy a bit (literally just moved one VI from a library into another, or made it a global variable or something like that), but I cannot seem to make it go away this time around, and do not have time to investigate.

 

The delay is almost certainly due to some type propagation checks or something similar, but I have no idea what the offending code is. If the LabVIEW IDE could just give me some way of letting me know what it is doing when it brielfy locks up I would be very grateful. 

[jcarmody]

Build specifications for a project that I wrote before LV2013 now take forever to build (application and executable), while LV2012 took only minutes.

[Val Brown]

Have you tried the "copy the project to a new name" trick?

[Pavanb]

Have you tried the "copy the project to a new name" trick?

How do I do this?