Your definition of how things work is correct. The problem is with noise in the measurement.
The loop iteration in LV finishes when its contents finish. Thus it is gated by the slowest path through the loop. Placing a wait ms in the loop in parallel is a somewhat reasonable way to declare that the loop should take at least 10ms to execute, and it is pretty typical that it will result in a ~10ms or ~100Hz loop provided nothing else slows it down.
Looking more closely at the loop iteration, there are a number of parallel tasks inside the loop …
- False wired to loop continue
- 10 wired to wait ms
- nothing wired to the Elapsed Time
- DIO Get
- DIO Get
- DIO Get
Then there is a bit of code dependent upon the outputs of the DIO Gets and the global update.
I labeled the initial tasks 1 through 6, but that order isn’t fixed, or at least it isn’t guaranteed to be. One explanation of your measurement is that subsequent loop contents are scheduled in different orders. On one loop call, Elapsed time is called last, and on the next loop call it is called first. On average, I suspect the timing is fine. Looking at a small sample like the single number of elapsed times, you’ll see some, and apparently quite a bit of variation.
Also, you are using an early version of the Elapsed Times VI that returns a single measurement, with no statistical data to improve or represent the quality of the time measurement. I apologize for putting it out there like that.
In general, LV users don’t worry that much about the parallelism of small things like this, but it can introduce noise in your timing. Since timing can be very important, LabVIEW Real-Time introduced a new loop structure with a more precise definition of loop time. It is in the subPalette at the upper right and is called the timed loop. It is more complex to use, but far more capable and precise about timing. The terminals on the inside right of the loop even include measurements about when the loop was supposed to start versus when it did start, when it was supposed to end versus when it did end, etc. The LV framework doesn’t actually use any RT (real-time) elements in order to keep things simple.
We mentioned in another forum thread that we’ll be doing a presentation in St Louis about the architecture, and this includes improvements to it. Perhaps next year, we should offer a realtime version of the framework?
To verify this explanation works for what you are seeing, run the code and you should see a blur of numbers that are typically closer to 10. You can add statistics to the Elapsed Times. You can put the code inside the loop in a sequence structure and call the Elapsed time before or after the contents of the loop. You can also modify Elapsed time to show a graph of the delays.
Feel free to post additional results if things seem fishy.