Wait millisecond timer value

[ToeCutter]

At the moment there are two wait functions in LabVIEW that I know of:

-wait (ms)

-wait until next ms multiple

I propose a third option, 'wait until ms timer value' which waits until the system timer reaches the specified value.

What does this gain us? Suppose we want a loop to execute on the average every n milliseconds. We use the existing 'wait next ms multiple' in the loop. What if we want n to be non integer? It may not make sense to pass a fractional number to a wait function that doesn't offer that resolution, but it's a reasonable wish to have a loop execute on the average every n milliseconds for non integer n. How can we achieve this? Add n to a count each time we loop, then each loop wait the whole part of this accumulated value and take this off the count. The result would be a loop which takes sometimes a little under, sometimes a little over the specified number of millis due to rounding, but averages to the non integer value requested. The problem is the required wait function- wait(ms) will not do it- it doesn't account for the time the code in the loop takes to execute. Wait next ms multiple won't do it- it's no good when the wait is varying - what we need is to wait until a fixed timer count.

Hence the request.

[ToeCutter]

Well, it turns out I can do what I want using 'wait next ms multiple' to serve as 'wait until ms count'- works like a charm, but there will be issues when the millisecond counter loops. This can't be resolved using 'wait next ms multiple', but could be with my suggested function.

[crossrulz]

My fear is that someone will put in a wait unitl tick count is 10 when the tick count is 11.  You will be waiting for a LONG time waiting for the tick count to roll over and finally be 10.

[ToeCutter]

:manlol: Fair point, crossrulz, although this could easily be avoided by an extra 'timeout' input, defaulting to say 30s. Another option would be for the wait to wait until 'after' the specified count, so if you specify 10 when the current time is already 11 the function would return immediately, perhaps with some flag to indicate that the time had passed before the wait was started.

Point is, there is no work around I can think of for what I am trying to achieve without this functionality, and what I am trying to do seems to be something quite reasonable.

[RavensFan]

Rolling over is not an issue.  If you do all of your math with U32 just like the millisecond time puts out, the result of the addition rolls over just like the millisecond timer would roll over.

So 4,294,967,295 (the max value of a U32) plus 10 will roll over to 9.

[ToeCutter]

To illustrate the rollover issue, say you are waiting around 10ms. You calculate the time to wait until and it comes out to 1ms- i.e. 1ms after the counter has rolled over. Stick 1 into a 'wait next ms multiple' and it's clear it will wait about 1 ms, not 10 as required.

The problem is not with the math but the wait function being used- the 'multiples' are getting in the way in this instance.

[RavensFan]

So you aren't talking about a problem with rollover of the timers in general.  The problem is with the particular implementation that you have shown in the first reply to your idea.  I'm sure that is solvable with normal LabVIEW code.

I'm not sure why you need the idea you are proposing.  Rereading your original idea, you make it sound like a while loop iteration takes as long as the time it takes to execute the code PLUS the time of the wait timer.  That is not usually the case.  If the wait function is separate and not dependendent on other code in the loop, the wait happens in PARALLEL with the code.  So the overall loop iteration time will be the greater of the code execution time or the wait time.

[ToeCutter]

Ravens- I have taken a look and you are correct wrt to the parallel execution, however it doesn't solve the problem. To illustrate, I created the following:

The average loop time for the 'wait ms multiple' loop tends to 5ms with increasing precision over time. The caveat is that for obvious reasons the first iteration of that loop is not guaranteed to be close to 5ms- but this can be programmed around if it was an issue.

Meanwhile, the example using a plain old wait does not tend to exactly 5ms with time. It's over, again for obvious reasons I believe as there is some finite time between each call of of the wait function. This is why the wait function is not suitable for my requirement.

My code in my second post is only an example of why I believe this functionality is a useful addition and not something that can be 'programmed around'. I am open to other methods of implementing the functionality I want if someone can hint how.

[crossrulz]

You are trying for a set loop rate that averages to a value not divisible by 1ms?  The problem is that you are on a non-deterministic OS.  If you need that kind of accuracy, you really should think about moving to a RT system.  In the mean time, maybe the timed loop will do what you want?

[ToeCutter]

"You are trying for a set loop rate that averages to a value not divisible by 1ms?" - yes. This is perfectly achievable in practice and is not a limitation of the OS, in fact the example in my second post achieves exactly what I want to with the one exception of the problem on rollover, which as far as I can see can only be solved by a slightly modified timing function.

Thanks for the suggestion of the timed loop, but I can't see how it gets me where I want.

[JÞB]

Sub-milisecond Timing

This is not *NOT* an approach without drawbacks caveats and concerns.  Many of them are in the example code documentation.  But, if you want to get a loop to run "On average" with submilisecond resolution.  you can.