It is often advantageous to use limit switches to set how far an actuator can go. It is possible to configure hardware using limit switches and Talons, so that the limit switch directly inputs to the Talon, but presented here is a software solution.
For the sake of this tutorial, we will construct a VI that takes in the DevRef's for each piece of hardware associated with this example, and performs the logic to set the motor. This will allow this VI to be used in Autonomous and/or Teleop, or if it needs to be run all the time, can be placed in Periodic Tasks.
Just a formality, but we will start by opening the necessary hardware in Begin.vi. For this example, we will use two limit switches, a joystick, and a motor.
In this example, we are constructing a vi, that can be called frequently to set the values of the motor based on joystick input, and we will add front panel controls in to allow for running this VI in Autonomous and passing in constants to control the motor.
For an example on having a motor remain in a state until a new input, we will refer you to our State Machine Tutorial
We are assuming that the hardware has already been opened. To allow this VI to execute as quickly as possible, we will rely on the calling VI to provide the DevRef's as opposed to Refnums.
Let's start simple and use two buttons and some selects to set the motor.
Now, this is good, but we wanted the limit switches to turn off the motor at its limits, so let's add that in. One way to do this is to use more selects such that when a limit switch is pressed, it allows the value to be anywhere within a range that is either stopped or goes the other way. Like below.
NOTE: This is configured for the limit switch to report true when pressed, depending on how it is wired, this may be backwards, if this is the case, merely insert a not gate in between the read and the select.
At this point, the wiring is becoming a little chaotic, but we want to keep our constants so that this vi is generic and can be used year after year and by multiple teams, so we will switch to using multiple nested case structures.
This is good, we have the motor set by the joystick buttons and using the limit switch to not allow the motor to continue past the limit switches.
Now we want to add some Boolean controls in that will allow us to call this VI in Auto and ignore the joystick input.
Now we will go to the front panel and clean it up a little bit.
At this point, we just want to tidy up a bit by doing some alignments and fitting horizontally and vertically by aligning the tops of the clusters and one of the buttons, then a horizontal gap between them and finally the second button was aligned left and vertically compressed.
For this VI to truly be universal, we need to set the buttons to latch mode allowing the VI to be called once, setting them to true in autonomous, then called again without passing anything so it reads the joystick.
By convention, inputs are on the left so we wire the DevRef's and buttons to terminals on the left.
1- Select appropriate Terminal,
2 - Select Control or Indicator
And with that, this vi is ready to be brought into the robot project and called to set the actuator motor from anywhere. - Auto, Teleop, or Timed Tasks.
WARNING - reading joysticks in multiple locations tends to cause lag, if you need more controls than you wish to put in here, move the joystick code outside and pass in the button values.
One could configure this vi with memory so the motor continues on its path until it reaches a limit switch or the command is changed, please see our tutorial on state machines.
One could set the DevRef input terminals to required so that they cannot be left un-wired on accident.
One could configure it using Functional Global Variable architecture to open the devices itself on the first run, then remember the DevRefs