×

Our Future . . .

When I initially created this site in 2014, it was to serve two primary purposes.

  1. To document the tips, tricks, and other higher level development practices that make programming for FRC in LabVIEW easier.
  2. Provide a common place for LabVIEW teams to find resources.

At first, this meant documenting the architectural and similar tools that I had learned on my way to becoming a Certified LabVIEW Developer, that had been put to use by the team I was currently mentoring (#3937, Breakaway). (This had the added bonus of helping the senior programmer that had been soaking all this up document it for his successor.)

Since then, this site has had a few additions and updates (mostly by me).

While I have often invited other teams (I am no longer in the AR area and have pretty much lost contact with Breakaway) on CD and at the regionals I've been at to write tutorials for specific topics that they had solved, I was rarely met with a response (specifically once - shout out to the Huskie Robotics 3061 for actually following through, but they were the only ones).

 

In recent years, I have found myself going through some family changes and needing to dial back my commitment to other activities.

This leaves this site both:

  1. Looking for a new champion/curator, that is willing to:
    • maintain the back end,
    • make sure material that becomes obsolete is either updated, or moved to the archives section of the menu,
    • and either write content or get other teams to write content to help this site remain relevant.
  2. Looking for a new source of funding/hosting. (I have been personall providing the $36/yr that it costs to maintain it using Google Domains for the domain name - and email - and Hosting24 for the hosting; I have thought about using some sort of a Donate button, but have not been able to find a platform that allows for *only* raising the target amount).

 

If you have any interest in seeing the continuation of this site, please let me know.

FRC LabVIEW Tutorials - Limit Switch

Table of Contents

Using Limit Switches

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.

Insertable VI

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.

Begin.vi

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.

Opening the limit switch in begin.vi

Actuator.vi

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

Block Diagram

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.

Using Joystick values to set 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.

Basic use of limit switch

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.

Using case switches for limit switch

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.

Adding Boolean control for auto

Now we will go to the front panel and clean it up a little bit.

Front Panel

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.

Tyding up the front panel

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.

Setting button action mode

Connector Pane

By convention, inputs are on the left so we wire the DevRef's and buttons to terminals on the left.

1- Select appropriate Terminal,

Setting the terminal

2 - Select Control or Indicator

Setting the control for that terminal

Finished

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.

click here to download finished version

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.

Some Possible Improvements

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

Request More Details

click here to request a clarification