Labview 2011, Is this the buggiest Version ever?

[Timmar]

Been there, seen that,

Most of my code is LVOOP whilst it can be compiled in 8.6 format splits the objects out into libraries.

We tend to upgrade our code remotely by overwriting the .RTEXE.

I "fixed" one set by adding an in place structure - I figured I would give the compiler a helping hand.  LV spun off and started (re-)compiling it's own libraries, .. Very odd, I would hope that they don't change.

Second set appears to be related to NPSV's, Still working on it. The sand in my hourglass continues to slip by.

[Eric416]

I have been having shutdown and fpga compile crashes, first started getting a few on shutdown with 2011, now I am starting to get more in 2011 sp1

I am a Win7 64, 32-bit LabVIEW, RT, FPGA.user as well.

If I load up my RT/fpga project and do a FPGA compile it works fine, do a second compile (after some changes)and it will crash.

Strangley enough when reloading the project it immediatly shows up that there are unsaved changes(*) even though the constant crashing has got me into the habit of saving everything before I do a FPGA compile.

I do the save because after a while I find the "recover" option will complete trash my entire project...bizarre errors to the point even editing becomes risky.

(no longer use the recover option, just revert to last saved files)

The only recovery has been to recreate the project and copy and paste from the old VI's, copying the VI's can seem to bring across somthing that causes crashes.

At this point I am working in an "expendable" project which can get trashed when I go "one crash to far".

When the bit is done I copy and paste it into the main project, it seems every compile just builds up some cruft that eventually corrupts the project to the point of unsuabilty.

PS I haver a vague feeling some of my inital crashes seemed to occurr after adding conditional complile symbols, but once they start its like a snowball.

[Spectre_Dave]

I find LV2011 to be very stable- I can't remember when it last crashed on me.

I converted about 10,000 VIs including a dozen FPGA projects and everything is running fine.

Very structured Queded Message Handler code and I do NOT use LVOOP, Locals, Globals, Sequences. Parent VIs are comprised of upwards of 3000 subVIs.

I adhered to Peter Blume's LabVIEW Style Book esecially the Modularity index = (# User VIs / total # of Nodes) x 100.  Keep to >3.0.

[Timmar]

Dave,

Thanks for the info,

Sounds like you write solid "Old School" code and it works well for you.

I like to think that my LVOOP code is written in a similar way.

 I also believe that OOP makes my code even simpler and more efficient.

I am a heavy User of LVOOP,  Maybe there is a lesson here, Perhaps the LV compiler isn't mature enough to be using OOP yet.

[Goldfish_Crackers]

I'm experiencing crashing issues with LabVIEW 2011 + SP1 as well. As a matter of fact, it's non-stop.  Sometimes I can't even open a project without it crashing constantly, and sometimes I'll be editing code and the screen will disappear and crash.  This software is terrible.  I love when I call NI support and they blame other vendor tools for their problems and tell me to call them instead (i.e. Xilinx for LabVIEW FPGA bugs - like bad simulation libraries).

[altenbach]

---

@Goldfish_Crackers wrote:

I love when I call NI support and they blame other vendor tools for their problems and tell me to call them instead (i.e. Xilinx for LabVIEW FPGA bugs - like bad simulation libraries).

---

You seem to imply hard evidence that the problem is with LabVIEW and not with the external libraries. Did you share this evidence with NI?

Have you excluded disk corruption and hardware problems?

What is your definition of "screen will disappear and crash". What is a "screen"? Are you talking about the LabVIEW application crashing or is the entire computer crashing?

[Timmar]

I don't use FPGA/Xilinx (to my knowlege anyway) and still see the same behavior.

Opening a project is a classic.

Source control: Open == Crash

Labview: File, Open Open existing project == Crash

Labview: Open recent Project == O.K.

Windows Explorer: Open == O.K.

I am working around Primal functionalty on a daily basis.

I am seeing on my 2 PC's and on 3 of my collegues.

Projects frequently get corrupted (project survives on average 2 weeks before corruption) producing phantom errors during run and builds which can be corrected by transferring files to a new project.

The Screen Freeze (identified bug, yet not fixed in SP1) seems to occur when you highlight more than about a dozen items (wires or vi's in a project).

Onboard/Low end graphics cards seem to have a much harder time of it.

# Begin Rant

If the class support for LV10 wasn't so apalling, I would have rolled back months ago.

Altenbach, Whilst you have been my guru since I began my labview quest and will always have my ultimate respect, these are real and I suffer them daily.

I am surprised that the Labview Masters of NI universe aren't sitting at my desk watching me program right now scratching their heads saying "oooh, we really need to fix this, it is terrible".

The two companies that I have worked for in the last 4 years both independantly developed the policy of not migrating to the next version until the first servce pack comes out. 

Is LV2012 actualy "LV2011 SP2" or the start of a new bug cycle? I feel I need to jettison 2011 to escape the hourly crashes and days of head scratching hunting for Labview Ghosts and other bugs of my own creation obscured by unhelpful error messages.

#End Rant

[User002]

---

@Timmar wrote:

I don't use FPGA/Xilinx (to my knowlege anyway) and still see the same behavior.

Opening a project is a classic.

Source control: Open == Crash

Labview: File, Open Open existing project == Crash

Labview: Open recent Project == O.K.

Windows Explorer: Open == O.K.

I am working around Primal functionalty on a daily basis.

I am seeing on my 2 PC's and on 3 of my collegues.

Projects frequently get corrupted (project survives on average 2 weeks before corruption) producing phantom errors during run and builds which can be corrected by transferring files to a new project.

The Screen Freeze (identified bug, yet not fixed in SP1) seems to occur when you highlight more than about a dozen items (wires or vi's in a project).

Onboard/Low end graphics cards seem to have a much harder time of it.

# Begin Rant

If the class support for LV10 wasn't so apalling, I would have rolled back months ago.

Altenbach, Whilst you have been my guru since I began my labview quest and will always have my ultimate respect, these are real and I suffer them daily.

I am surprised that the Labview Masters of NI universe aren't sitting at my desk watching me program right now scratching their heads saying "oooh, we really need to fix this, it is terrible".

The two companies that I have worked for in the last 4 years both independantly developed the policy of not migrating to the next version until the first servce pack comes out. 

Is LV2012 actualy "LV2011 SP2" or the start of a new bug cycle? I feel I need to jettison 2011 to escape the hourly crashes and days of head scratching hunting for Labview Ghosts and other bugs of my own creation obscured by unhelpful error messages.

#End Rant

---

Have you tried other version control such as GIT or Mercurial (another word for glorified filesystems)? I'm using exclusively LVOOP in my projects. (Look at the attached image for the dependency tree.)

Also try to separate source code from binaries in your LV2011 projects. If something goes awry, you can clean the compiled object cache and start recompile from scratch.

@The only time LV2011 annoys me is when I change some base classes and clear the cache, then, recompile takes forever. Hello multithreaded/multicore compiler?? Anyone @ NI listening? Perhaps no? 😉

Don't go for LV2012 since the performance guy at NI have gone AFK since LV2011 and dont seem to be on its way back coding anytime soon.

Br,

/Roger

[Timmar]

Roger,

I tried seperating the compiled code from the block diagram and found that my RTExe's either woulg offdn't compile or wouldn't run.

I Love the concept, but only if it works, and in my case it didn't, driving home the point of this post even further.

I use a lot of polymorphism in my code, how about you?  Maybe this is the cause.

As far as source control is concerned, I use perforce,

I have 5 guys all working from the same codebase.

I nedd a package that has devenr integrration and branch/merge tools, unfortunately subversion and other low end (open source) sools don't cut it.

As some constructive feedback, may I suggest that you use more glyphs or even text in your objects, It makes it much easier to identify it or it's family.

I have also invested time to make a wiring srandard,  Data objects, Running threads, Link, core(trunk), DAq, each have different wire types,

[User002]

---

@Timmar wrote:

Roger,

I tried seperating the compiled code from the block diagram and found that my RTExe's either woulg offdn't compile or wouldn't run.

I Love the concept, but only if it works, and in my case it didn't, driving home the point of this post even further.

I use a lot of polymorphism in my code, how about you?  Maybe this is the cause.

As far as source control is concerned, I use perforce,

I have 5 guys all working from the same codebase.

I nedd a package that has devenr integrration and branch/merge tools, unfortunately subversion and other low end (open source) sools don't cut it.

As some constructive feedback, may I suggest that you use more glyphs or even text in your objects, It makes it much easier to identify it or it's family.

I have also invested time to make a wiring srandard,  Data objects, Running threads, Link, core(trunk), DAq, each have different wire types,

---

In my previous "life" I have been working as an integrator (merging customer code/modules with the vanilla baselines and shipping to customers such as Motorola and Sony Ericsson) using Perforce, mostly on Symbian C++ code. Well, after using GIT for the last 3 years, I don't miss centralized systems for a second. 🙂

Regarding your problems:

One idea would be to create a delivery/build branch where you always do "theirs"-merges, subst a drive, modify your wiew, and in LV2011 re-enable the compilation flag of the entire project and try build from there? Perhaps there are some issues are from merging binaries, since perforce can merge in a content-based way?

Yeah, I have different wire for classes and named methods without glyphs.

Too lazy creating class glyphs. though. 

I use polymorphism in my base classes and inside those static methods, there are overridden methods. For example my heavily used InputStream/OutputStream classes.

Br,

/Roger