Labview 7.1.1 crashes daily?

[Kevin_R]

We are running a multi-chamber process system using LabVIEW 7.1.1 and the matching 7.1.0 DSC module. Each process chamber is controlled by software on an individual workstation, which share status information with a master control workstation via the DSC. There is also a gateway workstation that lets the chamber workstations communicate via OPC to an array of instruments in the system, and a database stored on another workstation where all process steps are logged.

That part is all working.

The problem is that one (and only one) of the process workstation programs crashes once a day (usually in early hours of the morning). There are no Labview error dialogs generated; we simply arrive in the morning to find the dreaded Windows 'LabVIEW.exe has encountered a problem and needs to close' message on the screen with the option to send the error report to Microsoft.

Any hints? Since it's a windows exit rather than a labview crash I'm not getting any useful error messages.

Related question: We've been sticking with LV 7.1.1 for now because we're trying to actually *use* our process system, and I wasn't sure how much rewriting I'd have to do to get everything working in 8.x . I do have the 8.5 install disks; would upgrading be likely to help, and how transparent will the upgrade process be, given that I'm dealing with 8-9 interconnected machines and the DSC?

[smercurio_fc]

If the crash is being caused by code which is "tickling" that specific instance of Windows in the wrong way, then it's unlikely that upgrading will fix the problem since you will be running the same code (albeit in a new version of LabVIEW). With crashes like this you first need to do some homework to determine what's causing the crash rather than blindly doing something, hoping it will fix it, with no real evidence that it will (or won't). For instance, you have no way of knowing if another machine isn't going to start doing the same thing.

Given that, you should monitor the memory usage on the computer to see if you have a memory leak. Do you have any logging for the process? If not, add some in so you can see at what point it's crashing. You may find, for example, that you're opening references, but not closing them, eventually running out of reference numbers. Or, you may find that you're ignoring certain error conditions, or you're trying to perform an action with an invalid value.

[Kevin_R]

We did get one clue last night indicating it is related to an out-of-memory condition.

First, we hoped we'd found the problem when we discovered a temperature monitor program that had no upper bound on the number of points in its chart, and added an auto-clear function to keep it under 200 points at all times. Unfortunately, that proved not to be the problem; the Windows program closure dialog was up again this morning, and the Labview program appeared to have been halted at 3:35 am, as that was when all the temperature logs stopped updating.

However, LV had been running a deposition process earlier that evening and that piece of the code reported an "out of memory" condition (error 2) at about 11:30pm.   (The deposition process code dynamically loads and unloads the process step vis as it runs, because keeping all possible process procedures in memory would overload the system. The error 2 was reported by the load/unload VI). Note that the other monitor vis ran successfully for another 4 hours before Windows shut the whole shebang down.

I'm going to try recompiling all the process step libraries (via mass compile) in case there are some process steps with changed subvis that are consuming excess resources by being recompiled when dynamically loaded.

Are there any resource monitor tools we can use to watch and log LV's memory/resource consumption over time while the system is unattended?

[smercurio_fc]

Windows has the Performance Monitory that you can use. Here is a page describing how to set up a customized version:
http://articles.techrepublic.com.com/5100-22_11-5263541.html