LabVIEW freezes momentarily

[rickford66]

Hi all,

I have been using LabVIEW 7.0 for quite a while now, and there is something that I see from time to time that is puzzling.  I'm wondering if anyone else sees this behavior.  Typically, when I do a vi with a visible front panel, I will use a state machine in the code, running inside a while loop.  At issue is, sometimes, various vi's will seem to temporarily freeze up when a button is clicked.  Not only do they freeze up LV, but they freeze up the entire computer.  After somewhere between 1 and 30 seconds, it becomes responsive again.  This does not happen all the time, just sometimes.  I've found that often times, it helps to put a 10 ms wait in the loop.  This is ok for vi's that take user input, but those doing data acquisition, it is not an option.  Sometimes, the vi does very little, such as an "about" vi that just displays a few values and waits for the user to click the ok button.  Has anyone else seen this?  Any clues as to what is happening?  BTW, I don't understand why it would freeze the computer.  I thought the OS was supposed to divy up the time slices, not LV.

Thanks.

Rick

[Ben]

I think this Tag set should have a link that addresses that problem.

You should check the Windows Task Manager while the "hang" is active to decide if it CPU or memory that is being abused. If neither of those two seem to be lacking, then you may be dealing with resource contention but now I am getting ahead of myself.

Ben

[rickford66]

The memory is fine, with only a mimimal amount used compared to system RAM.  The CPU varies wildly.  It fluxuates between 80% or so down to 10% or so.  Not pegged by any means.

My gut is telling me this has something to do with the code running fast and somehow pushing the UI to the side, but aside from running synchronous, how do I prevent this?  Is there a rule in LV that says, only process the UI when the rest of the program isn't doing anything?  Also, why would this affect the rest of the computer.  Shouldn't the OS prevent that?

[Ben]

---

rickford66 wrote:

The memory is fine, with only a mimimal amount used compared to system RAM.  The CPU varies wildly.  It fluxuates between 80% or so down to 10% or so.  Not pegged by any means.

My gut is telling me this has something to do with the code running fast and somehow pushing the UI to the side, but aside from running synchronous, how do I prevent this?  Is there a rule in LV that says, only process the UI when the rest of the program isn't doing anything?  Also, why would this affect the rest of the computer.  Shouldn't the OS prevent that?

---

To answer that quesion in your case I would have to know what the problem WAS.

But I'll give you an example.Windows uses virtual memory. Virtual memory uses addres translation hardware to convert virtual addresses to physical addresses to find the data/instructions required by the CPU.

Most of teh time the address translation hardware can click away and never miss on any of the translations. If one of the process on the machine addresses outside its mapped address sapce or attempts to allocate memory, the address translation hardware needs to be updated so ti can mapt the virtual to physical correctly. The update of the translation logic requires operating in Kernal mode to get at the hardware and while updates are happening (find free physical, mapping the translation) all other process are locked out.

So something a silly as your OS deciding its time to index your disk to improve searching speed, could introduce a pause as you described.

I imagine you can simulate the "puase" by trying to open Excel while your ap is running.

Reapeating, the above is speculation.

The links that I have collected in that Tag list earlier are links I have been collecting for a couple of years and cover almost every performance related issue you could encounter. Please review them since your answer is probably in that collection.

Re: "OS prevent that?"

OS's (Operating Systems ) as evidenced by Windows virus susceptibilty, enable everything and prevent nothing (e.g Blue screen of death).

Take care,

Ben

Message Edited by Ben on 06-17-2010 08:56 AM

[rickford66]

That actually makes some sense to me.  haha   Thanks for the info.  I'll pick through the tags and see if anything turns a light on for me.

Thanks again.

Rick

[altenbach]

1. Is your VI set to anything above normal priority?
2. Are you using an event structure that locks the front panel until the event completes?
3. Can yo show us some code that demonstrates the problem?