LabVIEW 6.1 Freeze / Hang – Related to User Interaction / Potentially File I/O

[Linuxx]

Hi Everyone

As you can see by the title, we are using an archaic version of LabVIEW. This will not change, as the system has been running since 6.1 was new, and it is our philosophy not to touch a running system.

The thing is that it isn’t a running system anymore. Or should I say it’s never been perfect, only that we didn’t notice. Anyhow… Here comes what this is about:

We use LV in a jet engine test environment. Now, a normal engine test would take something like an hour or maybe a maximum of two, depending on the applicable test procedures. This time frame used to cover the majority of tests and we had no problems whatsoever. Recently though, we had an accumulation of engines that caused problems and therefore the tests started taking longer and longer, up to four or even five hours. And that is when the problems started…

LabVIEW would run just like it should, until after a long time it would suddenly freeze / hang upon user interaction. It looks like this could be related to some file i/o, like writing test results to an excel file or alike (“Save”), but I cannot rule out 100% that this impression is wrong. The data, however, will never be saved to the file in cases of a freeze / hang.

To test it and see what happens, we had let the application run over night and write some data and a time stamp to a text file, so we could see if and when it would hang. Nothing happened, obviously because there was no user interaction.

It may be handy to know that we are running LV on a Windows XP SP3, 32Bit system. The O/S doesn’t hang / freeze and everything else carries on working just like it should, it’s only the LabVIEW application as such that hangs (all of it, not individual *.vi’s or loops). Normally, after several minutes the application is back, but TCP and *.xls ActiveX references (refnum, in a global variable) are closed, and need to be re-established manually.

I know this information is very vague and you may need more input to be able to help. Yet it is a starting point.

Thanks for feedback!

Linuxx

[LV_Pro]

Really hard to even begin to diagnose the problem with this data. You mentioned that your wrote to a text file with a time stamp, so I'm assuming from this that the program can be modified (just not upgraded to a newer version)? If so there is a diagnostice utility in the Windows kernel32.dll that might help, if used properly it shows "stuff" going on in your code and in the Windows environment. What we do here is create a little sub-vi that will write a string to the Windows debug "file", and salt these throughout our code, showing when commands are issued, threads are shut-down, etc. Using a free download utility from MicroSoft called dbgVIEW we open a monitoring window behind our code and watch what is happening. It is particularly useful if you are running your application as a exe as it can give you a view into the inner workings without the overhead of writing to a file, etc.