[Greg McKaskle]

The presentation in St Louis was titled "Making the Most of LabVIEW for FRC: Performance, Debugging, Architecture". I was able to find the abstract online, but not the slides. Perhaps I don't know where to look. I might be able to find a version of the slides, but Doug Norman could give the official ones to you. They were also presented in August by Aaron Pena at the Austin off-season event, so maybe someone who attended has a copy.

The presentation first describes a bit of how to determine what your performance needs to be, then shows how to use the Elapsed Time subVI, the System Monitor, and/or the Performance Profiler to measure what your actual performance is and what components are responsible for the load on the CPU. Further in the slides, it covers a few architectural approaches for moving code from teleop and running it when it needs to run, rather than for every packet.

Basically, this revolves around using the Periodic Tasks more and the Teleop less. If you have a subsystem that needs to run every 200ms in order to check sensors and setpoints and update an outptut, you can put that code into periodic tasks and expose the setpoint using either global variables. If the subsystem needs to run when a setpoint is changed, then consider using an RT-FIFO -- a powerful realtime queue that allows you to choose when the loop should run, and allows the rest of your program to enqueue new setpoints or actions.

Other techniques for structuring your code is to look at using object classes. Object classes in LV are a powerful mechanism for code extensions and organizing things in larger teams. It allows for exposing some fields and hiding others so that subsystem complexity is more manageable. The most interesting thing about LV objects is that they are by value. Most languages use new foo() to return a pointer to a foo. Each piece of code that is handed the foo pointer interacts with the same foo. This makes some things easy, but parallelism quickly introduces errors. In LV, the constructor returns a foo on the wire. When the wire is branched or stored in a global, each is its own copy. This means that unless they contain a refnum, they are independent and can be operated on in parallel without introducing the same sorts of bugs. LV does the same thing for arrays and strings. Anyway, for most FIRST teams, I don't know that the code grows large enough to need to use object class mechanisms in order to manage complexity, but it is a useful technique nonetheless, and if a team wants to investigate it just to learn, I am certainly willing to assist.

Greg McKaskle