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
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
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.
Timing deterministic control loops
Understanding priorities in LabVIEW Real-Time applications