You have the essentials in your pseudo-code example.
There is one point that differs and that's with the use of the Watchdog.
The Watchdog should not be fed in a periodic loop. That'll end up defeating the purpose, in that the Watchdog will become a Watchdog only for that one Periodic task and not for anything else. It would never time out anywhere once you get your Periodic loop running properly, since this is a parallel task.
The Watchdog should be constrained to the primary Autonomous and Teleop data paths or sub vi's of those.
Instead a Timer vi is used. At the conclusion of the Timer it goes back on the OS task queue.
No long loop anywhere in our code should run unconstrained. They should all have at least a 10ms timer delay, so they don't prevent other concurrent actions. This has been the cause of many "sluggish" controls complained about by teams (it's the field's fault
).
I knocked off an example (untested) to illustrate the point in a LabVIEW context.
It includes two different ways to "kickoff" the sequence:
- Directly via joystick button
- Indirectly via a global (for instance, used during autonomous)
Quote:
Originally Posted by Ether
The infinite loop (lines 10 and 50) means that this task never terminates. So in that sense it's not "periodic", even though it uses the "machinery" of the periodic vi in the framework. true?
|
True, in my example below what's periodic is only the check every 100ms for if the sequence should be performed.
The Periodic Tasks vi does not get called periodically, it's only called once and the loops define for themselves what the period is for each parallel task within that vi.