[Greg McKaskle]

Since this is primarily a feedback thread, I'm not going to try to respond to most of the posts, but I want to ask a few followup questions on some suggestions and answer a few things.

Error rate:
The error console is a new thing that went in late in C++ and Java. It seems like a good idea, but uncovers code such as the camera initialization which shouldn't immediately retry on error. In fact, in LV the camera code spawns and runs in parallel and sleeps when it receives the "not ready" error that occurs during startup. Meanwhile, other error storms are easy to cause and currently lag the DS or cRIO or a bit of both. Some additional filters that count duplicates or otherwise avoid the storm is clearly an improvement.

On the D-pad:
The current protocol limits the number of axis and forces POV sticks or dpads to look like a pair of axis. Perhaps the Joystick stuff should be updated to send more info, and perhaps support feedback. Other feedback in this area?

Thread Wait():
I'm not nearly as familiar with the C++ implementation, but it sounds like this is a "teaching opportunity". If I understand your suggestions it is to spawn a specific task that is suspended so that teleop can continue. Either teleop or the independent task will set the resume time for the independent thread. That seems more like a useful pattern, and not an issue with wait(). I assume the default framework doesn't call wait() with a large value, that would not be a good thing to show. It sounds like there needs to be some examples showing how to accomplish asynchronous tasks and teaching the tradeoffs between that and wait() in a single thread.

Vision:
The NI-Vision IMAQdX driver now supports Axis cameras, and presumably it is better than the simplistic TCP stuff that was put into WPILib. We intend to evaluate that to see if it deals with the buffer allocation and buffer copies better than the simple implementations.

Greg McKaskle