LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

deterministic while loop in windows7 environment

Solved!
Go to solution
Highlighted

@cbutcher wrote:

Wait for next ms takes you from e.g. 32 ms to 60 ms. I suppose it depends which is preferable.

 

Perhaps this is a rare use for a timed loop on Windows? Then you could have it reduce the waiting in the next iteration in order to get back on schedule, assuming that missing the timing was unusual... 

 


No, it's not.  You posted an idea that already handles the "if the loop misses timing, get it back on schedule."  The Timed Loop will add overhead making it harder to make timing in the first place.  If the application needs to be within +/- 1 samples, as stated earlier in this thread, the wait until next multiple does the same thing with far less overhead.  There's no need to bring timed loops into this.  (Especially as they present a safety net that doesn't actually exist here).

Message 11 of 12
(130 Views)
Highlighted

@natasftw wrote:

@cbutcher wrote:

Wait for next ms takes you from e.g. 32 ms to 60 ms. I suppose it depends which is preferable.

 

Perhaps this is a rare use for a timed loop on Windows? Then you could have it reduce the waiting in the next iteration in order to get back on schedule, assuming that missing the timing was unusual... 

 


No, it's not.  You posted an idea that already handles the "if the loop misses timing, get it back on schedule."  The Timed Loop will add overhead making it harder to make timing in the first place.  If the application needs to be within +/- 1 samples, as stated earlier in this thread, the wait until next multiple does the same thing with far less overhead.  There's no need to bring timed loops into this.  (Especially as they present a safety net that doesn't actually exist here).


I don't really see what you mean here. Wait until next ms multiple won't necessarily keep you within +/- 1 samples.

In the case that any individual iteration ends within the next iterations allocated timespan, it will behave similarly. However, if the delay can be larger than 1 iteration's period, even if the average duration is less than the allocated time, it will never realign.

Hopefully this shows what I mean (try changing the values of the controls):

Example_VI.png

Here we see that the timed loop finishes late for the first few iterations trying to catch up with the expected starts. The Wait ms Multiple just drops 5(?) iterations effectively, and then retains the 30ms interval. These are different behaviours, and the OP should choose either as they need.

If I measure for 300 seconds and have periodic delays, then the timed loop gives me the same number of samples I expect - 10000. The Wait (multiple) will give me fewer samples, but a larger fraction of them will be separated by the intended period.

In particular, the Wait ms Multiple makes no attempt to "get back on schedule" (quoting you quoting me) if you fall behind more than one period. Indeed, it has no way of even knowing such a problem occurred.


GCentral
Message 12 of 12
(103 Views)