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

Publish Date: Oct 02, 2012 | 23 Ratings | 3.83 out of 5 |  PDF

Overview

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.

1. The Wait Until Next ms Multiple Function


When using the Wait Until Next ms Multiple function, 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.

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.


Figure 1: Desired timing of control system
Our first attempt to solve this problem is a simple loop with Wait Until Next ms Multiple (see Figure 2).

Figure 2: First attempt at timed loop


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.


Figure 3: Wait statement executes after AI


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.


Figure 4: Controlling the sequencing of events

Back to Top

2. The Wait (ms) Function


If the Wait (ms) function is called in parallel with other code, in priorities other than time critical, the loop has 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

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit