My Labview EXE (not computer) goes to sleep-mouse jiggle wakes up

[X-man]

System is WinXP pro (SP1), labview 7.1. Labview compiled exe controls NI-DAQ card, motor systems (2xPCI controllers), and has network connection for accessing subsystem on a nework through an active-x control. Everything works fine, no crashes. BUT, every few hours, the compiled exe code 'goes to sleep'. The computer does not go to sleep (other compiled labview exe's will continue running if loaded).

Inside the program there are 6 parallel loops (one for user button input, others for monitoring sus-system status etc). I have wired indicators to each of the loop counters and put them on the front panel. When the exe goes to sleep, ALL the counters stop. A mouse jiggle inside the front panel will wake the exe up and system continues as if nothing happened. It stays 'asleep' indefinitely otherwise.

A mouse movement outside the front panel does not wake it up. Changing exe window focus from within windows Task manager also wakes it up.

When awake, Task manager reports application running and CPU approx 50%. When asleep, task manager reports same status (ruuning, 50% CPU).

All vi priority settings are default. (Changing execution priority in task manager to 'higher' does not change the behaviour). When the program is working normally, it is communicating with network, checking hardware status and writing log data to disk at least once every 5 secs. All this activity stops when it goes to sleep, and resumes without a hitch when mouse is jiggled. (Note PC does not go to sleep - all power saving features I could find are off anyway).

Any ideas would be appreciated - dont know if this is windows, labview or me. Any ideas for utilities that might help diagnose what state the exe is in would also be appreciated. thanks.

[mikeporter]

When the counters "wake-up" do they just continue on from where they were, or they jump to a larger value and then continue incrementing?

How many hours have to pass before this happens?

Is there some smaller subset of the functionality that still exhibits the behavior? Or another way of putting it: Does taking anything out cause it to go away?

You mentioned an ActiveX control you are using; how about DLLs, CIN's, subpanels -- anything like that?

Mike...

[X-man]

The interval between 'sleeps' seems to be variable, I have found no pattern yet. Shortest time about 1 hour, typically many hours. Until I fix the problem I have to wake up every 3 hours during the night to make sure process has not stopped too long!

Loop counters update fairly rapidly when 'awake' so to the best of my observation powers I believe they count from where they stopped. But I understand what you are getting at, is it working inside but display is not updating. The log file being written every 5 secsa or so has time stamp every 5 secs or so and there is a gap in the times shown in the log corresponding to the sleep time. Also the hardware stops moving.

There are 4 main subsystems. One uses a 3rd party active-x control to access a fixed IP address to get a sting of data a few times a second. That susbsytem has been tested on it own and has been observed to not fall asleep when the main exe has fallen asleep. The other systems are an Aerotech translation system (PCI card, manufacturers CIN's DDL's and Labview Vi's), Newport rotary motion system (as per Aerotech) and an NI-DAQ multifunction PCI card which R/W's 2 digital I/O lines.

I am in the process of breaking out these subsystems. One bandaid I am working on (suggested by NI engineer) is to move cursor using software. I will try that in desperation but it has some potential complications unless done right.

No subpanels. System has never 'crashed' to the best of my knowledge.

Stan

.

[mikeporter]

When you talk about subsystems, are these separate process running independently of one another or are they just different loops on the same block diagram. If you can migrate the application to independent processes communicating with a GUI via queues or something, it might be helpful. (Or is that what you meant when you said you were working on breaking out the other subsystems?)

For example, you'd be able to run the different subsystems separately or in combination--and perhaps narrow down where the problem is coming from.

Mike...

[X-man]

I guess I am being a bit sloppy about terminology. By subsystems I meant the hardware for which there is a seperate PCI card (Aerotech PCI controller, Newport PCI controller, NI-DAQ multifunction digital I/O). In addition there is an active-x control for reading data from a local network (not under my control-data I need is transmitted via this network, I just read it).

The status of each 'sub-system' is monitored by calls in seperate loops, which run in parallel to each other and in parallel with the main user-gui loop. There is a bit of overlap in that some status vi's are read within the main gui loop. By breaking out the subsystems I basically mean turn the status loops into seperate vi's/exe's and run them. I actually did that during development and saw nothing untoward but I wnever imagined they might be going to sleep so I may have missed that. This testing may not have been thorough enough because the test exe's basically just monitored status and did not exercise the move functions much.

I can only run tests when production schedule permits so I have only tried a few ideas. I take your point in that if the individual sub-system tests do not reveal anything, I need to start running combinations.

Thanks for your interest

[chrisger]

hello there

i once got a similiar behaviour with a floating popup - subpanel. the subvi transferred data to excel. the loop sometimes stopped when the mouse left the window. when clicking the mouse inside the floating window the loop ran with expected speed. i changed the window appearance to modal and then all was fine.

are there any settings like floating window? what about the execution systems of your VIs?

best regards

chris

[Philippe_Goetz]

Hi X-Man,

did you have hyperthreading acivated?

Regards,
Phil

[X-man]

Phil

I will check but I dont think hyperthreading is activated but I dont think so unless its the default or a mistake on my part.

However I have some new information. Believe it or not I am still running tests. Each one takes weeks because the effect is 'random'. After lengthy discussions with an NI engineer, he suggested I set dll function calls (which are used for some hardware-non NI) to re-entrant instead of the default 'run in GUI mode'. At this time I have run for 1 week without it going into a come. I decided to stop saying it goes to sleep because that was not at all correct. Parallel loops can keep running.

I will let you know what the result is in a couple of weeks. The only explanation I have from NI is that there can be a problem initializing function calls in a dll but as I am the only one seeing this on the planet, it still sounds weird.

Stan

[X-man]

I believe I may have finally solved this one - maybe.

The computer finally died. A look inside indicated leaking capacitors. Some research

revealed that this was a problem that has plagued many motherboards. A call to Dell and a tech came

around the following day. He confirmed leaky caps and replaced the motherboard (the system was just still

within warranty).

The system was restarted and it ran, and ran, and ran. Unfortunately the test had to be stopped after 4

weeks (project was terminated). Previously 1 week was a long time between 'sleeps'.

Talking to a few IT guys, the general comment was everyone has seen weird things when power supply/mother

board has problems.

So it is a pity I could not get a positive definite conclusion from the test but no other explanation

came close to an answer. NI tech support had no records of any similar behavior in their database.

[ArchivedPointOnePa]

Three year later....2010

I'm debugging a Labview 7.1 application (Windows XP SP1), that has a similar problem to the one described in this thread.  The application goes to sleep and pauses or hangs after a long (9-35 hours) and random period of operation.  The movement of the mouse alleviates the problem and operation is restored.  I've dug through the source code and addressed several possible issues, old FTDI USB drivers, USB selective suspends and various power management configuration, Labview 7.1.1 patch, checked all communication time-outs, added log messages to try to trap occurrences.  None of these has solved the problem.  The problem appears to be with the labview 7.1.x runtime engine going to sleep while polling a 6K motion controller via an old iNet network connection (ocx activex).  I was wonder if anyone has ever experienced a similar problem.

I'm in the process of porting the application to Labview 2009 and I'm hoping that the problem is resolved by the port to a newer runtime engine.  I'm also going to try the comercial mouse jiggler from cyberguys to see if it addresses the problem...not great, but for $20 worth a try and if it fixes the problem, then fine.  At this point, I'm running out of ideas.