LabVIEW in high reliability applications

[Charles_CLA]

At the last LabVIEW advanced user group meeting I brought up the subject of using LabVIEW in high reliability applications. I wanted to post here and see if I can get some ideas on how others handle these situations.

First let me define "high reliability application". I define this as any application in which the LabVIEW application must keep running or something catastrophic happens (fire/flood/etc...). Second let me share my constraints:

1. I am stuck with LabVIEW 8.5.1
2. I am stuck using LabVIEW in the development environment, no real time, run time, nothing only the dev environment
3. I am stuck with an architecture that uses a Test Stand Custom Sequence Builder that calls the LabVIEW development environment to execute each step of my test. This means that my LabVIEW is not always running so using messaging between different applications is difficult
4. Probably lots of others but that's all I can think of at the moment

My issue is that occasionally for reasons unknown LabVIEW crashes to the desktop and displays the "LabVIEW has encountered and error and needs to close" window. This happens in the middle of tests which involve the use of a temperature actuator which if left at hot temperatures for extended period of times could potentially start a fire or if left at cold for extended periods of time causes ice buildup on the PCB which can lead to short circuits. My thought was to use Microsoft .Net C (or C++ or C#) express to create an app that runs in the background to check to see if the LabVIEW process is still running, if the process is missing and the temp actuator is still running, then the app should take over and shut everything down. Somebody at the meeting suggested building a LabVIEW executable to do the same thing but I'm hesitant as this whole problem is caused by LabVIEW's instabilities in the first place. What are your thoughts?

Charles

[JLSx]

Hey Charles,

One quick thought would be to throw in some logging code if possible.  This wouldn't be a solution to the problem (hilarious if somehow it was...) but over time it might help you determine where in your code the crash happens.  If you're lucky, it's happening in the same place or same piece of code most/all of the time.

As an addon to that, you might consider logging (in addition to a sort of standard timestamp) memory usage on each log line.  If you log frequently enough, you might be able to see evidence of a leak over time.  Popping open Task Manager while it's running might also help you observe this.  However, it's possible that this may only manefest itself after longer periods of time.  A medium-speed growth scenario along with array size doubling for auto-allocation when using, for example, the build array function comes to mind as potential "it might take a bit to see this, and is perhaps not immediately obvious in Task Manager" sort of scenario.

You may start/try just before and/or after heavy array operations, calls to external code (relative to LabVIEW), and definitely calls to external code involving arrays or clusters.

In theory, having a fallback/restart application is great, but I'd sleep better addressing the primary cause of the crash vs just fixing it up with an automated restart.  Doing both would be the dream aye

Hope this helps!