cpu usage while loop

[Labuser16383]

Labview manuals state that a while loop should always contain a "wait for ms" vi to unlock the task for that duration.

However i thought it comes out the same if i use the same ms wait time for the timeout of an event structure inside the while loop

and omit the "wait for ms" vi.

Unfortunately the timeout of the event stucture does not seem to unlock the task so that the frontpanel reacts very inert in this case while it reacts
prompt in the other case.

Has anybody deeper explanation for this behaviour?

[altenbach]

You need to show us your code. We don't know what you mean by e.g. "unlock", "task", "inert", etc.

Most likely you are not doing it correctly.

[mikeporter]

Deeper explanations need code to look at.

Mike...

[Dennis_Knutson]

Not every while loop requires a wait. Not every event structure requires a timeout event. If there is nothing in your timeout event, just delete it. I don't know what you mean by 'unlock the task'. In the absence of an event, the timeout event is executed every x number of milliseconds. CPU usage should be very low with an event structure and button clicks would be very responsive. Please post your code.

[Labuser16383]

Thank you for your feedback. The question was not about how to set up a correct while loop, but why the two cases are different.

It was more about understanding of the lv task handling. In my understanding a timeout is not much different from a simple wait.

What i meant by unlock the task: If the while loop is executed in one task and the frontpanel in another task, then the front panel is blocked until

the while loop task gets unlocked. The "wait for ms" seems to unlock the while loop task in order to hand over to the user interface.

During the wait for timeout the while loop seems still to aquires it's task so that the user interface is blocked until there is a little time between
execution of to runs of the loop.

So what is the difference in the implementation of the wait for timeout and the wait in "wait for ms"?

[Dennis_Knutson]

The timeout is not at all like the wait. You've been told that. The user interface is not at all blocked unless you have some code inside the timeout event or the code in one of the other events is still executing. If you don't have any code, it's pointless to have a timeout event. You should not have any while loop in any of the events. That is almost certainly the cause of your problem but you still have not posted your code. Also, please use the correct terms. There are events, not tasks. The user interface would be handled by multiple events.

[RavensFan]

What exactly do you mean by a LV task? 

I don't know what you mean by "a while loop executed in one task" and "the front panel in another task".  How do you execute a front panel?

If you post some code that is an example of your situation, we might be able to figure out what you are talking about.

[Labuser16383]

Ok, i was trying to reproduce the observation and isolate it from the rest.

I've written now three producer consumer variants :

1.) no wait at all (loops execute as fast as they can) -> cpu load increases of course. however this was only the negative test.

2.) 50ms timeout instead of using a "wait for ms"

3.) 0 ms timeout but 50ms "wait for ms"

I did not examine a blocked frontpanel with this testcode. Probably it was caused by something different in the original vi which i fixed simultaneously
without recognition when i changed variant 2) vs. 3) in the original vi.

For me it was a result that variant three seems to be a click saving option to variant 2 because you don't have to insert an extra "wait for ms" vi. 

It does not show up with higher cpu load than 2).

[Dennis_Knutson]

Please either post a snippet or standard zip file.

[Labuser16383]

OK, besides that seven zip is really well known as the standard for PD zip.