My front panel stops updating after running for a few hours - Can I substitute a "wait for front panel activity" instead of normal wait to conserve resources?

[Daddy-O]

My VI continues to run, at least the queues keep cycling through (on the front panel).  I am losing updates to an array of indicators, and they go to inactive, and grayed out. I am afraid that my timing may have something to do with this and I am thinking of using a "wait for front panel activity" in place of a "wait" in my GUI loop. My GUI Loop doesn't need to do anything until is is called, because my DAQ Loop has already gotten it's queues. I don't know if that makes much sense. I have included a picture of my block diagram and circled the timer I want to replace. What are the pro's and con's of this potential substitution please?

[altenbach]

Im am pretty sure that you timing is not the problem.

You have an event structure, so "wait for front panel activity" is not needed and would be completely useless. What is happening in the timeout case? I suspect you have either a race condition or some other problem with e.g. one of the references. Are any data structures growing without bounds?

Even the 100ms wait is useless, because the event ony run if needed or every 200ms.

Can you attach the code?

[smercurio_fc]

One thing to keep in mind is that you should not perform any "can take a while" operations in your event structure. In the event case that you're displaying you are calling two VIs. What are they doing, and how long does it take for them to execute? The event loop should capture the event, and push a message onto your queue so your other loop can handle the operation. This allows the event structure to respond to the next event.

Also, you have the "zoom" control wired to the event case edge, but I don't see anything being done with it.

I would have the handling of the response to pressing the "End" button in the event structure, rather than in the consumer loop.

[Daddy-O]

I hope this code is sent properly so you can open it.

The only reason the Zoom is wired there is to get rid of the warning that tells me it was wired to nothing. I don't like seeing the little warning symbol on any of my VI's. (Anal I guess...)

[Daddy-O]

I am not sure I know how to determine if I have data structures growing uncontrollably. I have been monitoring "memory" usage, via WIndows Task Manager, and it doesn't seem to get over 75 Mb. It also doesn't seem to correlate with when I lose the array of indicators. I also set LabVIEW as "Real Time" priority in Task Manager. Is there a way in LabVIEW to detect growing data structures? I know race conditions can be kind of hard to find. Thank for y'all's help.

Chris

[altenbach]

One problem is the fact that you call two interactive subVIs inside an event structure, and one of those even contains its own event structure. This means your main event structure can easily lock up if one of those dialogs gets covered by other windows and forgotten. Maybe you should make them dialogs so they stay on top of things.

In any case, I definitely would not stack events like that. You have events within events!

Message Edited by altenbach on 09-28-2007 08:24 AM

[Daddy-O]

Altenbach!!

I removed the wait completely from my event structure's while loop... AND GUESS WHAT???

It ran all night without crashing. I may still have a job Monday. THANKS FOR YOUR HELP!!!!

Chris