One reads a command global and sets the drive-motor speeds.
One reads all the nav sensors (accel's, gyro, encoders) and writes to a global.
One reads a command global and sets the camera-gimbal servos
One is for Vision

In the teleop/auton modes, we look at the Nav data and the joystick inputs, and set the commands to the motor-globals.

In each of my free-running VI's (other than vision), I have a WAIT = 10 msec so that they'll run at most twice for each DS-cycle. But I'd like to adjust that arbitrary number with one that is based on the expected response times for these sorts of actions.

I wish I had the time during our recent build-sessions to play around with some timers and find out for myself, but alas, today my hands were on power tools much more than the keyboard

Do y'all put these WAIT's into your standard parallel VI's? or do you let them free-run as fast as they can? If/when you let them free-run, what sorts of elapsed times would you expect from them?

Free running literally means take all available resources, pretty much maxing out the CPU. This won't necessarily do harm unless you have some lower priority tasks which may now become starved. It will also add lag to other tasks since at any given point in time, the CPU will have to finish the excess loops before it gets to the task that waited in line.

Moral: Almost always delay your loops in some way. The ideal way is to make them run when new data arrives or is needed. In some cases this is more easily done using a time schedule, but that has its own set of tradeoffs.

At this point, I wouldn't recommend it unless you have an issue. But when you have time, read up on the notification mechanisms, and especially the FIFO.

I like using Queues to control my sub-loops. Queues are FIFO arrays; I enqueue a command from teleop or autonomous and dequeue from the loop that handles the commands. If you don't specify a timeout, the dequeue vi will wait until a command gets enqueued, effectively pausing the loop until it's needed. As a bonus, if the loop takes a long time to finish an iteration, other commands will still be added to the queue and processed in the order they were added.