When Autonomous Independent is running, does the 2010 FRC LabVIEW framework permit the use of user-coded periodic tasks?
For example, hypothetical situation, let’s say there’s a rotary sensor on the bot that goes from 0 to 360 degrees, and you want to keep track of revolutions. A periodic task at, say, 20ms could do that while the auto independent code is running.
~
Unless you do something to prevent parallelism, LV is all about the parallelism. During Autonomous, the Auto Independent VI is running its code, the vision code is parallel and the loop is running – the code within may be disabled. The periodic tasks are always running, even when disabled. Robot Main is running. Start Communications is running.
Greg McKaskle
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?
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?
~
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.
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.
This is one of the things I really like about Lab View, it visually shows you what is happening. Some people just learn better visually.
This picture of Main.vi and Disabled.vi demonstrates both Serial and Parallel operations.
Begin.vi runs first, then Main.vi and the Vision/Timed tasks. This demonstrates serial because nothing else starts until Begin.vi has completed.
It demonstrates parallel because both Main.vi and Vision and Timed Tasks all run at the same time in parallel to each other and are not Dependant on each other to run.
I also used the disabled.vi to show how this mode works
As you can see, even though the robot is disabled, the dashboard is still being created. One thing to note, in this robot mode, all output to spikes, victors, jaguars, servos etc. on the robot are set to no output at all. This is for both safety and game management. Although, there is still feedback to the drivers station.
A perfect example of how this is a good thing is:
In one of our Autonomous routines we use the cameras image on the console to align our robot to the target even though the robot is disabled. We have to manually lift the camera into position to do this because the servo it is mounted to is disabled.
Which reminds me of an example of how it can be a bad thing (or rather something you have to be careful of). A PID loop with an I component located in Periodic Tasks will continue to accumulate error while the robot is in Disabled Mode. If you are thinking of putting such a loop there make sure you initialize it when coming out of disabled.
Hmmm, sounds like the voice of experience.:yikes:
There are a couple of techniques that I know of, there may be more, to prevent or minimize “Integrator Spin Up”.
One way is to hold the “Ki” to zero until the robot is enabled, then set it to the calibrated value once enabled. Another approach is to limit how much “Spin Up” is acceptable. Although, this method might limit the “Ki” value so that it is less effective when enabled.
The best way to accidentally prevent parallelism is to run a wire from one loop into to another. The second loop won’t run until the first loop is complete. If the first loop never exits, the second loop will NEVER run.
This is the most compelling reason to use local and global variables in LabVIEW. If you need to pass data between parralell loops, you can’t wire it, you need to use varaibles. eg: Vision Target information, and anything that the periodic loops are using/generating that are expected to change.
Kevin, I’m looking at our team’s code and I don’t see anything in there about task priority. Are you doing something special to establish priority for each of your tasks?
~
I believe there are special things you can do to set the task priority, but I was referring to the default behavior of the code from what I understand.
Can you post a brief summary of your understanding of the default behavior of the code (that is, as regards the framework’s management of tasks) ? I am very much interested in this subject, and trying to learn more about how the LabVIEW framework handles multitasking.
~
What you got from Mark/Greg in the other thread is certainly better than what I could provide. Everything I know about Labview was either self-taught, learned from FRC Mastery or learned from here.
OK thanks. I was just wanted to make sure I wasn’t misunderstanding something again.
By the way, if you are reading this Mark/Greg, I appreciate the patience and effort you put into answering all my questions.
~
No problem. By the way, if you feel confident that changing priorities is what you need, you can set priorities on a VI in the VI Properties dialog>>Execution tab. You can also set priorities on timed loops.
Of course I don’t have to explain that higher priority doesn’t speed up the CPU or anything magical, it simply gives cuts in the queue, right?
Greg McKaskle
I’d say “right”, but I’m still wondering if “cuts in the queue” includes not only “going to the head of the line” in the queue, but also preempting a presently-running lower-priority task.
I’m also wondering how the 2010 FRC LabVIEW framework handles what I will call the “standard form” periodic tasks, i.e. like the default templates provided in the framework periodic vi. Does LabVIEW set them up with the same priority? And if so, does the OS preemptively time-slice-multitask all equal-priority tasks, or is the multitasking strictly cooperative (in the “standard form”).
I say “wondering” instead of “asking” because I don’t want to make it sound like I’m insisting on an answer. But if anyone does know, I’d sure be interested.
~
For simplicity, the LV queue has been described generically as a Queue. In reality, it is implemented as a priority Q. OS threads are lazily allocated to service the head of each priority in use – by default a few threads per CPU core per priority in use. This means that if tasks at different priorities become available, the OS scheduler is aware of the requests and will schedule accordingly.
Not being on the VxWorks RT team, I can’t say exactly how the threads were created or how the Queue is implemented for the OS. I can’t say exactly how VxWorks is expected to behave in the case of competing priorities, inversions, etc. So, I’m being vague about the implementations I don’t know in great detail. If I had a cRIO available, I could write tests that measure the response, however.
Greg McKaskle
Interesting you should say that. I was taking a walk in the woods just this afternoon and had the exact same thought. If I had a cRIO, I would take the time to learn enough LabVIEW so I could write some simple experiments and get some insight. I’m going to ask around and see if the team would let me take it home after the season. Does the Chief Delphi forum go completely off the air off-season? Or do a few die-hards stick around?
~
It definitely gets much quieter, but some of us are here year round.
I’m going to go ahead and answer my own questions here, based on what I’ve learned since my questions were posted, for the benefit of any other readers who may have been wanting the answers to the same questions.
Caveat: Don’t take my word as authoritative. And a note to gurus: If I get any of this wrong please slap me upside the head:
Answer: YES. When a higher-priority task becomes ready to run it will preempt a presently-running lower-priority task.
Answer: YES.
Answer: The vxworks RTOS preemptively time-slice-multitasks all tasks of the same priority. In addition, tasks can cooperatively give up their time-slice when waiting for resources.
~
A+ on the quiz.
Greg McKaskle