The Frameworks that NI develops and delivers each year with the latest edition of FRC LabVIEW simply establish a program style. The framework is just a basic program template and style that changes and improves a little bit each year. You can develop your own program using your own style completely from scratch.
The essential elements every FRC robot program requires are:
- Communications with the Driver Station.
- Recognizing and processing the different competition modes arriving in the DS packets
- Autonomous operations
- Teleop driver controls
This is what the Project explorer looks like when you open LabVIEW.
The program flows Like this:
The Team Code folder contains all the code you should normally modify to fit your robot and game plan. If you add vi's of your own they should also be kept here. Nothing outside should be touched until you hit the Advanced slopes.
Open all your devices here, and create refnum names to uniquely identify each of them. This is called only once at the very start.
The Framework is setup here in Begin.vi to automatically call the Autonomous Independent.vi at the start of Autonomous Mode and to automatically kill it when Autonomous Mode ends.
Do NOT add an explict call to this vi in your code. It is set to be automatically called and adding your own calls will disrupt that background process and can cause your robot to be inoperable during teleop.
This is called only once, so put everything you want done during Autonomous Mode here. You don't leave this, so waits and delays can be used as desired here.
Typical driver controls. This is called 50 times each second as the Driver Station control packets arrive. Do NOT write code in here that waits or takes more than a few milliseconds to execute. If this vi takes too long to execute, then your driver controls will respond sluggishly, sporadically, or not at all. That means no While loops, no wait timers, no Watchdog Feed & Delay.
Normal driver operating code will usually be split between Teleop.vi and Periodic Tasks.vi
Teleop.vi gets the flow-through actions, such as driving via the joysticks, that don't require delays to give a mechanical mechanism time to complete operation.
Periodic Tasks.vi gets the complex time-consuming actions that need much time to complete, like a catapult that needs to be released and cocked again as part of a single joystick button press. Compared to computer speed it takes a very long time to physically pull back a mechanism, latch it, and release it again. Anything that makes you want to add a time delay or have to wait for a sensor to tell you it's ready can more easily be done in Periodic Tasks.vi than anywhere else.
This is called only once, but it is expected that tasks in here will execute within a never ending While loop or a Flat Sequence structure. Typically, you'll have several completely separate loops running in here to do mutually independent stuff. This can be used for timed sequences, for instance, if you have a mechanism that operates in several discrete steps. Say,
- A motor cocks a catapult
- A mechanical latch holds it back
- Pneumatics releases the latch
- Time delay while waiting for the catapult to complete it's throw
- Then repeats the loading/shooting cycle
This simply Closes all the devices you opened in Begin.vi to clean up when the program exits.