Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW crashes in timed loops

Hi,

I'm running LabVIEW 8 on a Pentium D, 2 GB RAM, Windows XP sp2 with an ETS target Pentium 4, 256 MB RAM. I have two timed loops in a sequence, so they do not execute at the same time. A similar sequence is on the target allowing me to make a state machine between both computers.

The loops on the host simply update the GUI for the user have a large period of 45-ms. This makes the CPU usage virtually zero. Also, task manager tells me that LabVIEW on the host only uses 200 MB of memory, so I know that the computer is not running out of memory.

When I run the multiple VIs, the host will randomly crash. It works about 9 times out of 10 with no crashes. Windows will tell me that it (is sorry and) has to close LabVIEW on the host. The target side continues to run like nothing happened. When I click on the link requesting details, I get this information from Dr. Watson:

AppName: labview.exe
AppVer: 8.0.0.4005
ModName: lvalarms.dll
ModVer:8.0.0.6
Offset: 00001df4


I have narrowed it down and I know that it will only crash in the two GUI loops. Does anyone have any ideas about how to approach this problem?
.
-J

Message 1 of 7
(4,666 Views)

Hi J,

We've seen this type of error with timed loops occasionally in the past, and the first thing to try is replacing the timed loops with standard while loops (if you use the Wait Until Next Ms Multiple VI it will have nearly the identical behavior as the Timed Loop).  Since the error occurrs on the host side, the ms resolution of this VI will be identical to the period resolution of the Timed Loop. 

Regarding the behavior of your system after the crash, does everything still operate correctly while the Windows dialog box is active (i.e., does your application seem to behave any differently, either on the host or target end)?

Cheers,

Matt Pollock
National Instruments
Message 2 of 7
(4,646 Views)
Matt,

Thanks for the reply. I'll change everything to a normal while loop with the wait. I was hoping to use the timed loops because of the ability to pass errors through to each iteration in the loop structure itself, but shift registers will do the same thing (hopefully with not too much more in resource usage). When the error occurs, the host side completely freezes and I can't make any changes to the controls and the indicators don't change their values. The target continues to operate successfully, following the program. I know this because it's on a CAN network and the CAN bus monitor running on another computer still reads an increasing number of messages on the bus.

I never noticed this problem occurring when I was first developing the application, even though the timed loops have been part of it from the beginning. I didn't change the timed loops at all. Is there a reason that lvalarms would suddenly have a problem?

-J

Message Edited by jms221 on 05-22-2006 01:20 PM

0 Kudos
Message 3 of 7
(4,640 Views)

Hi J,

There could be any number of reasons why we'd experience a Windows crash on the host side, but my guess would be that the issue started occurring after adding a XY Graph or other graph indicator to the host VI.  Do you remember approximately when you first saw the issue?  Also, what method are you using to transfer data between target and host?  (Shared variable, datasocket, etc)

Having the standard while loop with a shift register for the error should give virtually identical performance - we built the timed loop out of several other primitive types in LabVIEW, so on a Windows machine, you can emulate the behavior very easily by combining these primitives yourself.

Cheers,

Matt Pollock
National Instruments
Message 4 of 7
(4,631 Views)
Matt,

I remember first seeing the error when I moved 2 xy-plots and a 3d plot into the true part of a case statement, which was inside the loop. These indicators were already in the VI beforehand and I don't remember having any problems until I realized that I didn't want them to plot except in specific conditions.

I'm using shared variables to transfer data between the host and target. None of the graph processing is done by the target however. A cluster of information is passed from the target and the host decodes and plots the data.

Thanks
Jason

0 Kudos
Message 5 of 7
(4,623 Views)
Hi J,
 
I'm curious to know if switching to the normal while loops did the trick for you.
 
We've seen some odd behavior with XY Graphs and Timed Loops interacting strangely, though the issues we're aware of were addressed by the 8.0.1 maintenance release.  If switching to the normal while loop doesn't solve the issue (though I believe it will), you may want to consider updating LabVIEW and its modules to the 8.0.1 release.
Cheers,

Matt Pollock
National Instruments
Message 6 of 7
(4,607 Views)
Matt,

Your comment to switch the loops appears to have solved the problem completely. I ran the program consecutively over 50 times for multiple days and was not able to get it to crash. This leads me to believe that it was some interaction with the timed loops, as per your thoughts.

Thanks for the help on this.
Jason

0 Kudos
Message 7 of 7
(4,577 Views)