LabVIEW 2009 crash a lot

[RMThebert]

I have been using LabVIEW since LabVIEW2.5, now it is LabVIEW2009.  My experience is of several crashes per day when doing these things:

..

I have a medium size application converted from LabVIEW8.6.1 to LabVIEW2009.  The conversion went perfectly.

..

When calling LabVIEW2009 from TestStand4.2 sometimes TestStand errors saying lost LabVIEW ActiveX server.  Checking on this I find LabVIEW unloaded itself completely.  When this happens I already have the LabVIEW project which contains all of the needed code open.  I am debugging and may have opened some VI from either the TestStand Edit button or by clicking in the LabVIEW project.  The TestStand is loaded as a *.tsw.  I have noticed that in order to view the LabVIEW panels TestStand is calling I must open them from the TestStand Edit button, VI that are opened other ways do not update their front panels while TestStand runs calling them or what must be clones of them.

..

LabVIEW2009 crashes without the help of TestStand also.  Usually when opening a pallet during a fairly intense development session (rapid code writing).  The symptom is that the pallet gets stuck open, other LabVIEW windows fail to update - turn and stay white if moved.  The Task Manager says LabVIEW is idle and not growing memory.  I tried to open another VI while in this condition and another copy of LabVIEW2009 opened and recovered the stuck files even while the stuck VI panels were still on the screen.  This happens several times a day reminding me of Windows3.1 era when manually saving every couple minutes was very wise.  I usually force the stuck LabVIEW to close then open it again, it does a recovery and I have only lost a few minutes of work.  This is annoying enough that I expected to see a bunch of discussion on it.  It is not a function of the PC.  One of the PCs this happens on is a P4 dual core and the other is a Core2Quad.  The TestStand LabVIEW loss of ActiveX only happened on the P4 since I only used the TestStand there.

..

The LabVIEW2009 crashing is bad enough that I will probably not migrate other programs to it.  I will continue to post my crash symptoms to help with this.

..

A small gripe while I am at it:  The new icon editor loses the quick copy and paste of the entire icon from one VI to another - the default control attention is on the text instead - text gets first attention in a drawing tool! After selecting an area, the keyboard arrow buttons don't move the area around requiring tedius single pixel precision mousing instead - this makes it difficult to adjust text and graphics carefully to be readable.  The new icon editor facilitates chosing from a list of pictures nicely but the loss of my favorite productivity features and the slow loading of the icon editor are a high price to pay.

..

Thank You

Robert Thebert

Certified LabVIEW Architect

[Andrey_Dmitriev]

Hi, Robert,

My experience said that we've got "interlaced" stable and unstable releases...

I have been using LabVIEW since 5.1 and see the following (the only version which was used by me are listed below):

v. 5.1 - stable

v. 6.0 - unstable (like nightmare - crashes and bugs)

v. 6.1 - stable

v. 7.0 - unstable

v. 7.1 - stable (one of the best)

v. 8.0 - unstable

v. 8.6 - stable

v. 2009 - ????

So, we have to wait next version or major update ;)))

Andrey.

[SynergyMike]

There's an old adage that says not to buy original releases (e.g., ".0") versions of any software, presumably because no beta testing can match true wide usage in terms of finding bugs.  Perhaps that applies to LV (using 7.1 here and I still have occasional freezes, although more like once/twice a week rather than per day).  But then I think the only truely stable OS I ever used was DOS 3.3, and then there were still problems created by multiple programs trying to use the same memory in the name of speeding up execution...

I think it comes down to what level of hang-ups/slow-downs becomes unacceptable, and tolerance is user-dependent.  🙂

Michael Tracy

Synergy Microwave

[Neil.Pate]

---

Andrey Dmitriev wrote:

Hi, Robert,

My experience said that we've got "interlaced" stable and unstable releases...

I have been using LabVIEW since 5.1 and see the following (the only version which was used by me are listed below):

v. 5.1 - stable

v. 6.0 - unstable (like nightmare - crashes and bugs)

v. 6.1 - stable

v. 7.0 - unstable

v. 7.1 - stable (one of the best)

v. 8.0 - unstable

v. 8.6 - stable

v. 2009 - ????

So, we have to wait next version or major update ;)))

Andrey.

---

As you said yourself, you are only commenting on the version you have used, but you have left out 8.20 and 8.5 which (regardless of their "stability") will break your nice interlaced order as there are two versions between 8 and 8.6!

At least these days when LV crashes it tends not to corrupt the lvproj anymore (8.5 *cough*).

[Bgsmallwood]

I have found LabVIEW 2009 to be extremely unstable.  I have the f3 patch installed and it still crashed multiple times a day, even by simply opening or saving a vi.  Using VISA resources also seems to occasionally crash the system.

LabVIEW 8.6 was significantly more stable.  Lets hope the next update or release fix resolves these issues

[altenbach]

LabVIEW 2009 SP1 was just released. See if anything you are experiencing is mentioned:

 LabVIEW 2009 Service Pack 1 Bug Fixes  

(see also) 

[RMThebert]

I have not had the crash a lot happen very much after using LabVIEW 9 a while.  We are writing all new programs in LabVIEW 9 and migrating older ones that need attention to LabVIEW 9.

..

It could have been the interactions between the previous versions of LabVIEW and TestStand code being opened from within TestStand4.2 using LabVIEW 9, this would require a lot of background version conversion.  The pallet opening might have been compiling the pallets for the first use in some cases.

..

I don't have time to research the bug fix because I did not followup to create my own detailed bugs to be fixed list so I will go with the SP1 and hope for the best.

..

Thank you for your input.

[NIExpert]

I have SP1 installed and find LV 2009 crashes multiple times a day - typically when I try to open or save a vi.   The most common errror is "FDCO.cpp" line 652, but I have seen others.

I have also experienced issues with remote debugging.  Execution highlighting traces parts of diagrams that are not executing (ie wrong sections of the diagram are highlighted), probes and breakpoints do not always work.

[james brunner]

I just wanted to add my $0.02. 

Our migration from LV8.6.1 to LV2009SP1 is not going as smoothly as it could either.  There are several symptoms that show up that have been making this painful:

• I notice that the labview.exe begins gobbling up a huge amount of memory, and when paging kicks in, things really slow down.  I had thought I pinned this down to the built-in web server, but alas, even when it's turned off, the memory grows quite large.  I try to avoid loading our entire project hierarchies as they can be quite large, and that helps, but sometimes it cannot be easily avoided.

• One of our applications is based around the old G-web server.  We really want to move to the web services paradigm, but there is a problem that must be solved related to sharing memory (globals, DLL's, etc.) between the application instance and the web service instances.  I had an open message regarding this (see http://forums.ni.com/ni/board/message?board.id=170&message.id=480610#M480610), and was able to solve the first issue by using the "localhost" on the machine name input to the open application reference function. I turned the LabVIEW vi server on, an initially things seemed to work using this method.

My solution to wrap the global reads, etc., inside of VI server calls, is failing miserably, however, once the entire application gets running.  It seems like this solution causes LabVIEW to crash randomly, and it falls from memory with no warning whatsoever.  This makes it frustrating to pin down the cause, but based on my "gut" feeling and LOTS of searching in the forums, I think it may be related to this knowledge base article:  http://digital.ni.com/public.nsf/allkb/08B1BE0B500D667E8625733D005882B2.

I have since reverted my attempts back to global reads, etc., but I found it quite surprising that such problems would simply drop LabVIEW from memory!  I guess migrating to web services will have to wait, or we'll have to develop a means to share application/web services memory without using VI server.

Cheers,

James

[RMThebert]

I started this thread.  My experience with LabVIEW2009 over time is that there are less crashes.  I have not loaded SPI yet.  The crashes I have been having are maybe once a week and of the type where LabVIEW simply dissapears from running mode to not loaded instantly.  Each time when restarting LabVIEW there is a recover dialog and it works.  I save very often so this has not been a big problem.

..

When I started using LabVIEW 2009 I was doing a lot of converting from previous versions code of all types including FPGA.  Now I am just working in LabVIEW 2009 mostly state machines.  I don't use globals or locals, instead I use property nodes and notify or queue tools that provide better control of when things actually happen. 

..

I contruct my parallel tasks by building a separate assynchronous VI and a launcher JKI state machine for that assynchronous VI which works by instant one shot calls (load, populate controls, run, is it loaed yet, read, write, shutdown command, is it shut yet, abort if needed) suitable to reside inside a JKI state machine.  The launcher VI makes the assynchronous VI work like object oriented code so it is easy to maintain and reuse.  This model reduces LabVIEW problems by properly keeping control os background tasks.

..

I have a fast computer with the Nahalem chipset and 3 banks of 2GB of memory which is not all used because it has Windows XP which limits it to 4GB.  The processor has four cores and each is hyperthreaded so the Task manager window shows 8 processors.  Even with this computer my larger VIs (1.3MB / VI) with 100 or so states of JKI state machine take several seconds to compile.  The autosave is a bother when LabVIEW halts and does this several second compile.  I wish the autosave and compile would work on multiple threads to take advantage of the fast computer.