Quote:
|
Assuming our new-to-LabVIEW programmers try to stay within the guidelines for proper use of the framework, and don't try to get too "clever", is there anything they could do inadvertently to "prevent parallelism"? I guess what I'm asking is, is there a short list of common LabVIEW programming errors (particularly for newcomers) that I should warn them about?
|
I'm sure Greg may have more, but the two main ones I know of are 1)Messing around with Robot Main without understanding what it does
2)Using loops and sequence structures inside Teleoperated or Autonomous Iterative (or in Auto Independent without feeding the Watchdog in the loop)
The main way that I know of to "prevent parallelism" by accident would be to create a loop somewhere other than Teleop (say...Preiodic Tasks) with no delay in it. All of our tasks have the same priority so one won't be preempted if it never gives up the CPU. The 2 default loops in parallel tasks have delays in them so either use those and change the timing if necessary or make sure to follow the same structure when creating additional loops.
Quote:
Originally Posted by Ether
The answer to the following question is probably obvious to a LabVIEW programmer (which I admittedly am not), but when you say "The periodic tasks are always running, even when disabled" ... why would a task continue running when it is "disabled" ? Maybe the word has a different meaning in this context?
~
|
Disabled in this case is a robot state.
When the robot is in Disabled Mode Periodic Tasks will keep running. They will also keep setting the state of the outputs if programmed to, but those changes will not be transmitted to the Spikes, Jaguars, Victors and Solenoids until the robot is enabled into either Autonomous or Teleoperated modes.