This optimization is not for the robot, rather it is for the developer. What is presented below is a methodology that - when combined with certain architectures, can minimize the amount of code necessary - thereby reducing the time to write it and the effort to debug/enhance it.
For the duration of this tutorial, it is assumed that the motors and joysticks have already been opened in Begin.vi, and that this robot has a wheeled shooter.
This configuration utilizes the producer-consumer architecture. This allows the code for controlling the actuators to be in one single place (periodic tasks) and the code to control it to be in either Teleop or Autonomous - depending on which mode the robot is in.
This setup has both a major advantage and disadvantage. The advantage is that the code for moving is reused, and does not need to be repeated in addition to the fact that if a control is changed in autonomous, the robot only needs to be re-enabled to use the updated variation.
The disadvantage is because the movements are stored in a control, one must go to edit > make current values default in order to make the changes be saved to the vi.
We start by adding a shooter speed to the default array of motor movements.
In the block diagram, we enable the for loop that uses the array, and update the current movement indicator (delete and recreate).
This loop will perform each instruction for the specified amount of time, then move onto the next instruction in the array. By adding what the shooter’s speed should be, it now controls the whole robot with this set of instructions.
Using an fgv to pass the shooter speed to periodic tasks, the autonomous.vi is finished.
In periodic tasks, the fgv is read and the motor is set.
By using the array of movements and the fgv, no code is unnecessarily repeated (assuming that the drive code used in teleop is slightly different), and by using the fgv, data checking can be performed that values that are input for the shooter speed are valid.