12-19-2015 02:12 PM
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?
Solved! Go to Solution.
12-19-2015 02:31 PM
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.
12-19-2015 02:32 PM
12-19-2015 02:37 PM
12-19-2015 03:46 PM
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"?
12-19-2015 04:14 PM
12-19-2015 04:15 PM
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.
12-22-2015 03:08 AM
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).
12-22-2015 03:55 AM
12-22-2015 04:02 AM
OK, besides that seven zip is really well known as the standard for PD zip.