LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Windows occasionally stop redrawing

We have a LabVIEW exe that consists of multiple windows, each with a bunch of numeric indicators that regularly (typically ~1Hz) update. The application is typically run for 8+ hours at a time. Occasionally (and seemingly randomly) we see one or more of the windows just stop updating. The problem is almost certainly not a coding thing, as each window is basically just a while loop with a timeout and some values going to the indicators. And there is no evidence of any blocking calls or thread contention. Further, the problem is resolved simply by minimizing and restoring the window.

 

We run on Windows 7 Enterprise. My first thought was that the problem might be related to the Aero effects and Desktop Windows Manger (DWM). I actually tried disabling the DWM Session Manager service on all the workstations, but we have still seen the problem (although it *might* have reduced frequency somewhat...the jury is still out on that one, as the change was implemented pretty recently).

 

Because the minimize/restore trick seems to work, I am inclined to believe the issue is at the OS or video card level. Like, the OS is trying to reduce redraw overhead by skipping some windows that it thinks aren't being viewed.

 

So, my questions are:

  • Has anyone else seen this problem before?
  • Does anyone have any ideas of what the root cause might be, and/or what other steps we might take to mitigate the problem?
0 Kudos
Message 1 of 34
(4,036 Views)

Hello Turbophil,

 

When you say that each window is a while loop with a timeout do you mean that it is a while loop with a wait function inside? How long is your wait contant for each loop? Why do you have each window open, is there a constant user interface that is being displayed. When the window itself stalls does the program keep executing? What version of LabVIEW are you using and are you interacting with any hardware? 

 

Thanks,

 

-Travis E

National Instruments
Product Marketer
0 Kudos
Message 2 of 34
(4,002 Views)

Running LV2010SP1. Most of the subwindows have a 1000ms wait. No hardware interaction. Program continues normally; after a minimize/restore, it's like nothing ever happened. I assume it is actually running normally even when it appears frozen--I think that is just an issue with the OS/video card not drawing the updates to the numeric indicators.

0 Kudos
Message 3 of 34
(3,995 Views)

This is a known issue with applications running with Windows Aero. A work around that may be useful would be to disable windows Aero. Here is a link that goes through the disable process: http://www.howtogeek.com/howto/windows-vista/disable-aero-on-windows-vista/. Here is the CAR number so you can track this issue: 369142. I apologize for any inconvenience this may cause.

 

-Travis E

National Instruments
Product Marketer
Message 4 of 34
(3,970 Views)

I work with Turbo, this is a major problem.  It's undermining our ability to champion LV to other groups.  The spacecraft goes up and some of our best operators don't know if they're seeing live telemetry.  Not cool.

0 Kudos
Message 5 of 34
(3,948 Views)

We use LV for all of our GUI's, btw.  We're kinda crazy about it, but we would like for this to be solved.  LV is amazing, and none of the proposed solutions would be much better IMO (C++ and QT, nah).  This, however, is cutting us off at the knees.  This really is a huge problem, we have GUI's that are essentially lying to the operator.  They have a number showing Live/green, when it is not.  

 

Our only solution during mission is to make sure the Mission Director knows about it, and tells people that their GUI might not be correct.

0 Kudos
Message 6 of 34
(3,934 Views)
Is my Dragon detector working right? it is chiming fairly loud. How can we help? NI I might suggest getting this fixed and opening the challenge to the community. If my dragon detector is in cal.

"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 34
(3,915 Views)

Correct 🙂

Message 8 of 34
(3,905 Views)

@Travis-E wrote:

This is a known issue with applications running with Windows Aero. A work around that may be useful would be to disable windows Aero. Here is a link that goes through the disable process: http://www.howtogeek.com/howto/windows-vista/disable-aero-on-windows-vista/. Here is the CAR number so you can track this issue: 369142. I apologize for any inconvenience this may cause.

 

-Travis E


I like this post.  It's like saying "This is a known issue with cars that have radial tires.  A workaround that may be useful is to put bias ply tires on your car."  😉

 

LOL I figure that NI is making this a top priority, but since it's very difficult to convey urgency in text, it sounds like NI is completely disaffected.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 34
(3,884 Views)

Hey Everyone,

This is an issue we have been actively looking at as a high priority issue.  Is disabling Windows Aero an option for your applications? This has been shown to resolve the issue in every case. If it does not resolve the issue for your case we will want to characterize the issue separately.

 

I would expect disabling Windows Aero to be a reasonable solution for all controls applications but please post back here if that is not the case.

Kevin Fort
Principal Software Engineer
NI
0 Kudos
Message 10 of 34
(3,829 Views)