Software Timed Loops using Wait (ms) and Wait Until Next ms Multiple

This document will discuss using two VIs, Wait (ms) and Wait Until Next ms Multiple, to give software timing to loops. This document assumes that the LabVIEW RT Engine is the execution platform. In our discussion we will assume that the VI is running in a time critical thread and that it is in the only time critical loop in the system. For a complete discussion of priorities and threads in LabVIEW RT, follow the link at the bottom of the page.

Wait Until Next ms Multiple

When Wait Until Next ms Multiple is called, it will return, or finish, when the millisecond timer value of the operating system is a multiple of the millisecond multiple input. For instance, if the VI is called with a millisecond multiple input of 10 ms, and the millisecond timer value is 112 ms, then the VI will only wait 8 more millisecond, at which time the millisecond timer value will be 120 ms, which is a multiple of 10 ms. Using this VI to time a loop means that the loop will be synchronized with the operating system millisecond timer value multiples. If called in parallel with other code in the same loop, the loop will have the period of millisecond multiple. This will not be the case if the other code takes longer than the millisecond multiple.

Using Wait Until Next ms Multiple to Time a Loop in Time Critical Priority

You must use this VI carefully in the time critical priority of LabVIEW Real-Time. Remember that if any VI sleeps in a time critical thread, then the entire thread sleeps. For this reason, you should control when the Wait Until Next ms Multiple executes, rather than placing the VI in parallel with other code. To understand why, let's look at an example control loop. In this example, we will read an analog input and then write an analog output. The desired timing of the system is shown in Figure 1. The vertical arrows represent 100 millisecond multiples.

In this first attempt, we do not dictate when in the sequence the Wait Until Next ms Multiple executes. The behavior of this loop will differ depending on when the Wait Until Next ms Multiple gets executed. If the Wait Until Next ms Multiple executes first, then the analog input will be followed immediately by the analog output. This behavior is usually desired, but is not guaranteed in the example above. If the Wait Until Next ms Multiple executes immediately after the analog input, then the analog output will not be able to execute until the Wait Until Next ms Multiple is finished. Again, this is because when any portion of a time critical priority VI sleeps, the entire thread sleeps. The resulting timing would be as shown below, in Figure 3. This behavior is usually not desired.
Instead of placing the Wait Until Next ms Multiple in parallel with other code, we can force it to execute in a specific sequence by using data flow as demonstrated below. With the example below, the analog input will occur immediately after the millisecond multiple, and the output will occur immediately after that.

When Wait (ms) is called, it will return or finish, after the time in milliseconds specified in the milliseconds to wait input. For instance, if the millisecond timer value is 112 ms when the VI is called, and milliseconds to wait equals 10, then the VI will finish when the millisecond timer value equals 122 ms. If called in parallel with other code, in priorities other than time critical, this means that the loop will have the period of milliseconds to wait unless the other code takes longer than the milliseconds to wait.

In LabVIEW Real-Time, it is not recommended to use this VI in parallel with anything in time critical priority. If the wait executes first, the whole thread will sleep until the Wait (ms) is finished, and the code in parallel will not execute until the Wait (ms) is finished. The resulting loop period will be the code execution time plus the milliseconds to wait time.

This VI does not provide reliably consistent timing, even in normal priority VIs, since jitter is accumulative.
Related Links:
Timing deterministic control loops
Understanding priorities in LabVIEW Real-Time applications

Reader Comments | Submit a comment »