My application freezes, but when the mouse is moved it resumes

[hoagey]

The LabVIEW application is a life test fixture that is implemented using an MXI

link to a PXI chassis. The PXI chassis contains three DAQ cards that are

being used to collect data and do some basic control. The data is logged in an excel

spreadsheet using the report generation toolkit. The application is

implemented in two loops (threads) so that the access time for logging data

to the file does not cause the control/acquisition loop to stall.

Periodically (after days), the application can freeze, but when the mouse

is moved on the computer it resumes as if nothing has happened. A mouse

button does not need to be actuated, just the mouse moved and everything comes

back. 

All of the screen saver and power saving modes on the PC are disabled; even

though the PC is acting as if it is going into power save mode. The

screen remains lit and active even though labview GUI (and execution) is

frozen until the mouse is moved.

This issue appears to be caused by the report generation toolkit as we

experienced the same (or very similar symptoms) previously when the excel

file size became large.  As a work around we copied the excel files and

restarted the application every 3-4 days to keep the file sizes small.

This seemed to work until now.   

[muks]

Check whether your program is waiting for your mouse event? (Are you using an event structure?)

Message Edited by muks on 12-17-2009 04:36 PM

[hoagey]

The application does contain an event structure, but it is implemented as a timed event to execute every 50msec.

[muks]

Can you post your code?

[hoagey]

See attached code for details

[RavensFan]

Why do you have an event structure whose only event is the timeout case?  Why not just make it a regular while loop with a 200 msec timer inside of it and no event structure.

How fast is your state machine loop running?  (I can't run because I don't have your hardware.)  Unless something is embedded in some of the subVI's, I don't see anything that might prevent the state machine loop from running at top speed.

[hoagey]

The idea behind using an event structure with a timeout case is to guarantee that the loop (and the ADC averaging)

occurs every 50msec.   Since the rest of the loop can execute with a period of any where from 5  to 25 msec, this

construct ensures that ADC averaging is performed on a consistent basis.   There are other ways to accomplish this

functionality, but this mechanism seems to work as intended. 

[Ben]

Does the log file indicate the app was hung or we just talking about what the FP looks like after sitting for days of logging?

If it looks like it is just the GUI, then first check what your memory useage is at the time it is stalled. If you file has grown so large that you no longer have enough physical memory to run in you'll switch over to virtual memory. Once running in virtual, blocks are swapped out to disk and stay there until they have to be accessed. if the GUI was idle for a long time, then the "frozen" state may just be an artifact of waiting for the code to be paged into memory. If this indeed the case then the work-around invloves keeping the file small by renamine it regularly (like youhave done!) so... You may have already fixed teh problem.

Just trying to help,

Ben

[hoagey]

Ben, your suggestions are in-line with my previous thinking, but honestly the available memory on the PC doesn't drop significantly over

time.   The file size does grow with time, but we start getting problems before the file is 1M, which is pretty small as excel files go.   As

I mentioned our work around seemed to function fine for several weeks, but now we have experienced our first "freeze" with a file

size of only 500k.   I remain convinced that the issue lies in our use of the report generation toolkit with this excel file.   As you might

have noticed we're writing to 31 separate worksheets within the file, each of these writes comes at the expense of reading the sheet

to find the last line.  Typically, this file write operation takes about 2 seconds.   I've performed standalone unit tests of this file update

VI and found that as the file gets extremely large the file write times can climb to over 20 seconds.   During this test, I logged some

random writes to the file that spiked far beyond the linear upward trend that we measured.   With one of these periodic (relatively rare)

spikes in write time, it to the file took over 2 minutes to update the file.   It was when the file reached a size of 19M that the standard

write time to the file took about 20 seconds.   

[SAS]

Hi,

Very Interesting issue - have you found any solution to this. Please do share any information you have which will really help us.

We are also having similar problem and the application freezes without any memory built up. The test runs for days and it hangs very randomly and we couldnt narrow down to any specific code.

After the hanging issue, the application comes back normal. The code hangs for 4 hrs or more!

Thanks

Sasi