HELP - Dashboard Digital Inputs to Select Autonomous Modes


I am having difficulty finding an example of how to code the Digital Input switches on the Dashboard to select between different autonomous modes.

I have set up a few different flat sequence structures but I have no idea how to use the Digital Input buttons or what to wire them to. Does anyone have a screen capture of how to do this?

Any help would be greatly appreciated. Thanks!

I can’t tell what “Dashboard Digital Inputs” you’re asking about. Can you be a little more specific?

The input switches within the I/O tab on the drivers station. They’re on the left.

Okay, you’re talking about the Driver Station, not the Dashboard. They’re two different programs.

If you don’t have a physical Cypress I/O board connected, then the I/O tab lets you set virtual digital and analog inputs. You can read them using the Compatibility IO functions, found in the DriverStation function palette.

The digital inputs are returned as an array of 8 booleans. Use an Index Array function to pull out the ones you want, or try a Boolean Array To Number function to turn them into a value that you can use as the select input of a Case block.

Thanks for the quick reply.

Because more than one switch can be activated at a time, do I have to code something that will prevent selecting two autonomous modes simultaneously? If so, what would that look like?

Also, is it possible to place a flat sequence structure inside a case block?

Sorry for the somewhat rudimentary questions. I’m very new to labview.

There isn’t any way for you to prevent more than one virtual digital input from being active at the same time. If you wish to use individual inputs to activate specific autonomous modes, you’ll have to decide how to make one take precedence over others.

You could turn the boolean array into a number from 0-255 and make the cases something like (128…255), (64…127), (32…63), (16…31), (8…15), (4…7), (2…3), (1), and (0, Default). That will give you eight different modes to choose from, with the leftmost selected one having priority if multiple inputs are on. The Default case will be selected if none of the inputs are turned on, so you can leave it empty and have it be a “do nothing” mode.

If that sounds like a lot of work for the programmer, you could use a binary-coded number to select among modes, though that’s not especially friendly for the person choosing it. Or you could use one of the virtual analog inputs, and make certain ranges of values choose certain modes.

Also, is it possible to place a flat sequence structure inside a case block?

It’s not only possible, it’s probably the most common way teams implement multiple autonomous modes.

Thanks for the help, Alan. This is where I ended up.

This is my autonomous code for 2013. It was my first time writing an autonomous code and it took way longer to figure out than I’d like to admit. The robot has a flat conveyor on top and a blocker arm. The idea is that discs are dropped onto the conveyor from the feeder station and then ferried to the low goal where they are conveyed into the goal. The blocker starts in the vertical position because it is outside the frame perimeter when it’s folded down.

There are 2 autonomous modes.

Mode 1 – The robot simply drives forward enough for the blocker arm to clear the tower then lowers the blocker arm.
Mode 2 – The robot drives forward, stops, lowers the blocker arm, waits for a time to allow other robots to move if necessary, continues to drive to the low goal, and dumps the discs into the low goal.

The driver switches between modes using the Digital Inputs on the Driver Station within the I/O tab. Mode 2 also uses the Analog Inputs in the I/O tab to set the time the robot waits. Both these inputs can be set anytime before the match, even while the Driver Station computer is connected to the field. The Driver Station remembers what settings (auto mode, wait time, etc.) were used last. We used this system this season and not only was it surprisingly simple, it also worked great.

Below is a screen capture of the final code. I’m not sure if it’s " technically correct" or “optimized” but it worked perfectly every time. I also included a picture of the robot for reference.

a. Case Structure (Programming > Structures) - This switches between T/F and a numbered set based on what is input into it. Mine takes an integer.
b. Flat Sequence Structure (Programming > Structures)
c. Drive Safety Config (WPI Robotics Laboratory > RobotDrive > Advanced) - I’m not even sure this is necessary but other examples had it…
d. Wait (Programming > Timing)
e. Build Array (Programming > Array)
f. Boolean Array to Number (Programming > Boolean)
g. Multiply (Mathematics > Numeric)
h. To Unsigned Long Integer (Programming > Numeric > Conversion) - Because the Analog input is a “64 bit real” (orange), it needs to be converted to a 32 bit integer (blue) before the Wait function will accept it.

My previous post requires an update -

In the Labview code, the Build Array function shows 3 inputs. It should only be 2. The Build Array and Boolean Array to Number functions output integers using binary math. Therefore, the first 2 switches could result in a maximum of 4 total modes - 00, 01, 10, and 11. From the Labview help: “If you wire an array of two Boolean values to this function and neither value is TRUE, the function returns a value of 0. If the first Boolean value is TRUE, the function returns 1. If the second Boolean value is TRUE, the function returns 2. If both Boolean values are TRUE, the function returns 3.”

And just so that it’s clear, the first switch corresponds to the rightmost digit. For example, if the Driver Station Digital Inputs read On, Off, Off, the Build Array function will return 001 and the Boolean Array to Number function will return “1”.


Here’s a warmed over screenshot of what I am using for 3 different autonomous programs (really Autononomous1, Autonomous2 and Default) on FRC3548 robot.
Note that I had to open a properties box and reorder these programs in order for them to agree with the Dashboard DIO selectors. In other words, there is a small bug in the FRC code and it doesn’t exactly agree with the Dashboard DIO selectors.
There is also an array index VI function? that I copy and pasted from FRC code.