Quote:
The multi-tasking LabVIEW environment gets even more complicated when you recognize that vi's are operating in parallel and in fact operations within vi's are also operating in parallel.
|
understood
Quote:
|
There's nothing unique about Periodic Tasks.vi that's given it and all the tasks within it priority over Teleop.vi or Vision Processing.vi, etc.
|
understood
Quote:
|
The timer alerts the task scheduler when it needs servicing again. In fact you can use a timer with zero time just to break a task out of the CPU and send it to the back of the scheduler queue.
|
OK makes sense.
Quote:
|
Everything's clamoring for scheduled CPU time and somebody's going to have to wait sometime. It's non-deterministic in this framework. There are some low-level non-RT calls made too, but for our FRC purposes think of it as close-to-RT.
|
The point I was making is that the task time management in the LabVIEW framework is not preemptive, as I now understand it. So if the user creates a 100ms periodic task that takes 30ms to run, then a 5ms periodic task is NOT going to run at 200Hz. If the user creates a control algorithm in this 5ms task that depends on 200Hz execution, then the algorithm will not perform as expected, and may even be unstable. This is not a complaint, merely an observation, and a warning to other teams that may not already realize this.
~