FIRST Robotics Competition Documents
Before getting started, we strongly recommend the Command and Control architecture for a team of developers. You can find this same discussion with respect to Command and Control here.
Parallel development in a graphical language has unique challenges when compared against the text-based languages. Merging two versions of the same function/VI isn't as simple as bringing the lines together. LabVIEW has a tool to compare the difference between two VIs to help you determine what changed between your version and the version saved on your source code control. Help documentation can be found here and here.
When considering how to approach that challenge, it's important to define a development strategy that allows multiple developers to make meaningful updates without consuming all of their time solving differences between updated versions. The simplest solution is to have a single developer. But, that doesn't solve the problem as much as give up. Instead, let's look at a way we can bring different developers into pieces of the project so several programmers can work at once. We will attack this problem with prior planning, setting up the project appropriately, and using stub VIs for various functionality we want to add to our robot project.
Creating the Robot Project
Create a project using the Arcade Drive selection. Ensure you choose a location that you can find easily. I've chosen C:\Robot Projects\Arcade Drive for this tutorial. That will leave you with something looking like the following image.
In order to bring the VIs into the project, we'll need to start by creating a Virtual Folder. To do that, right-click on "Team Code" and choose New->Virtual Folder. This folder can be named anything. It'll change once we modify the settings in the next step.
When this pops up the explorer dialog, select the folder you created. The name of the auto-populating folder will change to match the folder on your drive. In my image, you'll notice "subvis" was changed to "subVIs" to match what I created on my PC. You can immediately tell it's an auto-populating folder because it's blue with a little yellow figure. The grey folders are virtual folders. The latter will only help you organize your project. As an example, you can see Elapsed Times.vi is in the Support Code folder where Teleop.vi is in Team Code. However, these are both in the same folder on your PC. The auto-populating folder will sync with what's saved on your PC. That's a key property when working with multiple developers.
Now that we have an auto-populating folder to work form, we should add any team-based VIs to this folder. When a developer pushes a new VI to source code control, it'll appear to the other developers. When they pull from the source code control, the VI will not only be downloaded to disk but will also appear in the project. This allows different developers to work on different VIs, upload them, and share them all in a way that pulls all the correct links into LabVIEW without the frustration of manually placing these correctly on each PC and bringing them into the project.
These VIs can be added on the fly or they can be added as stub VIs to make developing higher level VIs, such as Teleop, easier. To create a stub VI, create a VI and save it. Make a meaningful icon and build the connector pane like you would for any subVI. As a general rule, feed a constant into any outputs to clear up the errors. Save this VI and add it to your source code control. While anyone working on a higher level VI won't be functional, they'll be able to code their VI without having any gaps while they wait for the functionality to be built up.
This kind of coding works best when breaking apart the robot into a modular software design and giving each developer a modular mechanism to program. As a last reminder, this works better with the Command and Control architecture.
