[Greg McKaskle]

Regarding Flush:
I put flush in the LV implementation from the beginning so that camera code results or other potentially time sensitive values could have minimal latency. Rather than a write through where you are more likely to have inconsistent values, I chose to simply goose the timer and transmit all pending updates immediately instead of waiting for up to 99ms to transmit.

I didn't limit how often they could call flush and I'm not aware of an issue caused by it. As you mentioned, most values are updated at 50Hz, and that isn't much bigger than 10Hz. So if a user flushed each teleOp, they have only affected bandwidth by 5x at most. Also, only modified values are transmitted. I also allowed the user to specify how often their client or server waits to transmit updates. It defaults to 100ms and I haven't really heard of anyone using other values. For most NT stuff, 10Hz is fine.

By the way, the auto chooser for LV has its own rough edges. I'll document them here.

The selector presents all strings written to it within Begin.vi. Sometimes users don't find that initialization spot.
On selection, it writes the selection to the robot. But if the robot writes the value, it doesn't update the dashboard selector.
If the user builds a custom dashboard, they can change the default value of the selector, but the network table value isn't transmitted until it is changed. They would want to write the variable once anyway.

Hope to make it smoother next year.
Greg McKaskle