Quote:
Originally Posted by Mark McLeod
[*]A completely blank vi - An infinite While loop
- A Timer task (the CPU will wake up the enclosing While loop)
- A 1ms Task (completely independent of Timer)
[/list] |
OK, let's use the above as the basis for discussion.
Let's call "the completely blank vi" the "5ms periodic vi" since it's no longer blank.
This 5ms periodic vi has inside it an infinite while loop (is that the right way to say it?)
Inside the infinite while loop are two tasks:
1) a 5ms timer task, and
2) a 1ms task
Assuming the above is correct and I haven't mangled anything yet,
Something has to initially "call" (is that the right word?) the 5ms periodic vi to kick-start it. Is that correct?
Once started, it will run forever (until some other process stops it) because it contains an infinite loop. OK so far?
Both "tasks" within the infinite while loop must complete before the loop can loop back and re-start. Yes?
Since the 5ms timer task doesn't "complete" until the 5ms timer expires, that establishes the period of the 5ms periodic vi. How am I doing?
The 5ms timer task is implemented as an interrupt (or some other mechanism) that allows the CPU to go do something else while the 5ms is ticking away. That allows the CPU to run the 1ms task while it's waiting for the 5ms timer task to complete. Still OK?
When the 5ms timer expires, the 5ms timer task is now complete, and, since the 1ms task has also completed (since there are no other tasks in this simple example which would prevent it from doing so), all two of the tasks in the 5ms periodic vi are complete, so the loop re-starts. Please tell me I'm close.
Now, my questions:
1) It seems, in the above example, that it is important that the CPU somehow knows to start the 5ms timer task first, and then go run the 1ms task. If instead it ran the 1ms task first, wouldn't that task have to complete before the 5ms timer task even got started? Then the period of the 5ms periodic task would not be 5ms. Is the location of the graphics within the the diagram the key to telling LabVIEW in what order to execute?
2) Now, if there are other tasks in the system (besides those enumerated in this simple example), and if the CPU happens to be busy with some other task when the 5ms timer task completes, then the loop does not re-start right away, correct? It has to wait until the CPU finishes whatever it is doing? AND... any such delays are cumulative; ie the system doesn't compensate by short-cycling the next loop. So the effect of other tasks is not to create jitter, but rather to reduce the effective frequency of the 5ms periodic vi. True?
~