Labview 2011, Is this the buggiest Version ever?

[Timmar]

Myself and 3 other collegues have just migrated to Labview 2011 SP1.

We all experience frequent crashes, I am averaging at least 10 per day,

Anyone else using it experiencing this sort of problem?

[TiTou]

I'm not. I've only been using LV2011 SP1 a few week and for one big project but I find it more stable than my LV2010 was (haven't used 2010 sp1 nor 2011).

It is rather surprising since NI insisted on the fact that they instroduce few new feature but focused on stability and performance for LV2011.

What OS are you using and are you using external code or specific LabVIEW toolkits?

[rolfk]

I definitely can't echo that. LabVIEW 2011 is one of the most stable versions for me so far (and 2010 was and is also great as I'm still working on projects that started in 2010), maybe with the exception of the legendary 7.1.1. But for anything but single application development the lack of a project window is rather painful.

I had recently some problems with 2010 and 2011 suddenly starting to pop up with all kinds of errors. At the point when I couldn't start it up anymore because of an error message that it couldn't find various files in its resource directory I did a complete disk scan and it found several thousend damaged files all over. After fixing that I had on two occasions that the restored files where actually damaged and still caused problems. Reinstalling the affected toolkits fixed that. Of course the hard disk got in the mean time replaced!

This showed me several things:

- A computer with severe disk damage can still appear to work fine for quite some time but cause random errors.

- LabVIEW in itself seems to be rather stable nowdays but if you somehow pull the floor under its feet, (hardware problems, device driver issues, etc) it will sooner or later go flat on its face

- I need to be more aware about potential issues by doing regular disk scans and other monitoring options

Besides of this issue the only time I regularly or even consistently crash LabVIEW is when I'm doing work on external code. But that is hardly the fault of LabVIEW but the faults the person in front of the keyboard has built into that external code. 

[Timmar]

Fresh Windows 7 x64 Install,

DS2012 (32 bit)t,

Use R/T quite a lot

Agin, this is happening on 4 different machines.

[TiTou]

---

@rolfk wrote:

[...] the legendary 7.1.1. But for anything but single application development the lack of a project window is rather painful.

---

Good lord this is so true!

[rolfk]

---

@Timmar wrote:

Fresh Windows 7 x64 Install,

DS2012 (32 bit)t,

Use R/T quite a lot

Agin, this is happening on 4 different machines.

---

Hmm, the only thing that makes me suspicious here is the W7 64 Bit together with RT. Most of my applications are not RT (and none in LV2011 so far) and I still use W7 32 bit on my main development machine. So it could very well be that the RT Module has some issues on W7 64Bit. I faintly remember other people reporting such problems.

[Timmar]

The bulk of my Code is OOP,

My Boss can crash it just by opening a project.

I just realised that I am usign source control software (Perforce), Easy to blame it, but well written code should be able to report and recover from any event caused by an external system.

Tim L..

[rolfk]

---

@Timmar wrote:

The bulk of my Code is OOP,

My Boss can crash it just by opening a project.

I just realised that I am usign source control software (Perforce), Easy to blame it, but well written code should be able to report and recover from any event caused by an external system.

Tim L..

---

GOOP is another thing I haven't bought into yet. For me the efforts to get acquinted with it, simply don't feel like wieghting up against some of the disadvanteges of not using it.

And that is despite having some OOP knowledge from C++ and Java. What I see in OOP often is that while it gets used, it is quite often not a clean and elegant architecture but rather a thrown together bunch of classes and hierarchies. To keep overview there seems almost impossible for me, and I have doubts that I can create a cleaner and eleganter class hierarchy that allows me to keep the overview. So why bother with it?

[Timmar]

Wow, That's a pretty big call,

I am Finding OOP is making My Code Far neater, more managable and maintainable.

View->Class Hierachy is a pretty good tool.

I got sick and tired of creating Cluster behemuths and then unbundle/bundle to manipulate the base data.

An object is just a cluster with some attached methods for manipulating the data.

A class hierachy is a neat way of managing the behemuths.

Another advantage, You can't create reference to a cluster, you can for an object. - Allows you to acess data from multiple places in multple ways without using Functional Global variables.

Wheter or not you should is a debate for a later day.

Tim L.

[Ben]

---

@rolfk wrote:

...

GOOP is another thing I haven't bought into yet. For me the efforts to get acquinted with it, simply don't feel like wieghting up against some of the disadvanteges of not using it.

And that is despite having some OOP knowledge from C++ and Java. What I see in OOP often is that while it gets used, it is quite often not a clean and elegant architecture but rather a thrown together bunch of classes and hierarchies. To keep overview there seems almost impossible for me, and I have doubts that I can create a cleaner and eleganter class hierarchy that allows me to keep the overview. So why bother with it?

---

My first LVOOP code started out looking that way as well. I did not come away from that project with a single function I wanted to or could re-use apart from the rest of the application.

I had not yet "got it" with the OOP theory.

After reading more and applying more OOP theory, my code started to get more "re-usable" and classes started dropping out as re-use fodder.

Eventually I got to the point where I had a LVOOP library developing and each new project contributed another piece to the set.

But since I "write for my audience" and my audience is often LV Basic I grads, I wrtie more code in non-LVOOP that LVOOP. But I have come to realize that my non-LVOOP stuff is a lot like my LVOOP code and the leasons I learned from the foraml OOP theory has made my code easier to read and develop.

So OOP has had a good influence on my code and style.

Re: stability of LV 2011

I have read too many bad posts about LV 2011. Aside from one very short project (1 week) to get a new customer started, I have not developed in LV 2011 and I may actually step over that version completely. I like mnay of you end up at the wrong end of the stick when our project run too long due to LV failures.

Just my 2 cents,

Ben