Programming Retrospective
 

So, you LabVIEW using teams... after another great season of competition, we have some downtime to take a look at our code and think about what went wrong and, well, what went right!

As for us...

Right:
-Key constants on the robot were read from text files on the cRIO, making it easy to modify robot parameters without re-downloading code
-We achieved a high degree of encapsulation, allowing for easier code reuse and distributed workloads in the programming team
-We finally started using source control, which allowed for distributed work as well as all the other benefits

Wrong:
-Our system architecture had sensors "owned" by the systems that used them the most, but sometimes other systems needed to know their state too. This led to some messy compromises.
-Our logging system didn't capture enough data to debug an issue after-the-fact.
-It was difficult to test individual systems, or even individual components (such as turning a single valve off or on) without running debug code, making it difficult to verify repairs or changes to the physical robot.

So, what have you learned this year?

Re: Programming Retrospective
 

This year, I'm particularly pleased with our code. I go into some detail about how it works here. If you want to take a look at the code, you can find it here.

Re: Programming Retrospective
 

What did you use for source control? We had many issues trying to combine efforts of multiple programmers.

-- Len

Re: Programming Retrospective
 

We used SVN, integrated with Windows through TortoiseSVN. The 2011 version of LabVIEW has a diff and merge utility, so you can actually get a lot of work done. That being said, it's still easier if people are working on different VIs, so our high degree of encapsulation worked out well in that context.

Re: Programming Retrospective
 

I looked at using Git, with TortoiseGit, but ran into problems setting up a local Git server. Source control will be a summer / off-season task for us.

Our team has typically had one student who was a main programmer, and quite a few who joined that subteam for a day (and quickly wandered off). Now we have a few students contributing to that effort, and source control is becoming more critical.

Our "solution" this year was Saving a new version of the project and all touched files, every time something major was added or changed. This didn't work that well, in practice.

-- Len