Switches in the FAST Modern Platform¶

In the FAST Modern Platform, all switches are connected to individual FAST I/O boards. Different I/O boards have different numbers of switch inputs:

FAST I/O 3208 (32 switch inputs)
FAST I/O 1616 (16 switch inputs)
FAST I/O 0804 (8 switch inputs)
FAST Cabinet I/O Board (24 switch inputs)

In the FAST Modern Platform, all switches are direct switches! In other words, there is no switch matrix to deal with. No diodes are needed on switches, and opto switches can be directly connected without needing separate interface boards. The processor on each I/O board polls each switch every millisecond. (In other words, it literally scans the switches 1,000 times per second!)

Switches are connected to each I/O board in groups of 8. Each set of 8 switches has its own 11-pin 0.100” connector. (So the I/O 3208, which supports 32 switches, has 4 connectors for 8 switches each, the 1616 has 2 connectors for switches, and the 0804 has 1 connector for switches.)

Here’s a close-up view of one of the 8-switch connectors from a FAST I/O 0804 board.

The 11 pins of each connector are broken down as follows:

8 pins for your 8 different switches. In the photo above, these are the pins labeled 0-7.
1 “key” location, with a missing pin to help you (or your customers) make sure they plug the right connector into the right place and that it’s not backwards. (The “K” position in the photo above.) On boards with multiple sets of switch connectors, the key pin is in a different location on each.
2 ground return, or “common” pins. (The two “G” connections in the photo.) You really only need one, but there are 2 for convenience since you might have switches coming in from multiple directions and it could be cleaner to have two groups of common ground returns.

Advanced Switch Debouncing¶

The FAST Modern Platform has advanced switch debouncing capabilities. You can configure separate “debounce close” and “debounce open” times for each switch with their own custom settings depending on what role they perform in a machine.

You can do an internet search for the full geeky details of switch debouncing, but here’s a quick overview if you’re not familiar with the concept:

Whenever a mechanical switch opens or closes, there’s a literal “bounce” as the mechanical contacts come together or separate. How much bounce and how fast it happens depends on lots of things—the type of switch, how it was activated, etc. If you were to hook up an oscilloscope, you might see that a switch that was open goes closed-open-closed-open-closed (all within a few hundredths of a second!) before it settles on being closed. From the human perspective, it’s still “instant.” But in a pinball machine, we actually need to filter those out. After all, if a ball rolls over a switch, or the ball hits a standup target, you only want the switch to “count” once—you don’t want a rollover switch to count 4 times when the ball only rolled over it once.

Since the processors on the FAST I/O boards query the switches every millisecond, with switch debouncing, you configure that switch input to say (for example), “make sure this switch stays closed for a solid 10ms before we actually count it as being closed.” (All electronic pinball machines did this, even back in the early 80s. Remember 10 milliseconds is still 1/100^th of second!)

Another reason switch debouncing is important in pinball is because the underside of a pinball playfield is extremely “noisy” in terms of the electromagnetic spectrum. For example, the magnetic field generated by a nearly solenoid (which is just an electromagnet) can sometimes cause a few millivolts to appear on a switch line which might make it look like that switch was closed for a very brief period. Debouncing is also used to filter those out.

The FAST Pinball platform lets you configure debouncing time windows on a switch-by-switch basis, meaning you can fine tune the debouncing of your switches to match their function. For example, for a slingshot or pop bumper, you might want an aggressive switch close debounce time to ensure that even a slight graze by the ball will activate it, whereas a switch sitting on top of a magnet might need a longer time so it doesn’t get triggered every time you turn on on the magnet. You can even use debouncing times with ball devices to ensure the ball has “settled” before reporting the switch closure and taking action.

Pinball machines of the '80s and ‘90s handled the debouncing in the main game software, meaning that poor 2 MHz CPU spent a good chunk of its time constantly polling switches and comparing their states to their previous states and keeping track of timers to know when the switches should be considered closed.

In the FAST Pinball Modern Platform, the processor on each I/O board handles all that debouncing timing and polling. All the game software has to do is configure the switch to say, “Only tell me when Switch 1 has been hit after it’s been active for 10ms”, and then you never have to worry about it again. (All of these rules are dynamic and can be changed at any time.)

Switch Numbering¶

The FAST platform maintains a single list of switches. Every switch has a number, the first being 0, up through the total number of switches in your system. (e.g. the totals of all switches from all I/O boards.) The order of the switch numbers in the list is based on the order of the I/O boards in the I/O Loop. The first board (the one connected to the Neuron's "NODE OUT" port) starts with its first switch as number 0, up through the total number of switches it has, then the second board continues the numbering, etc. The following diagram illustrates this and provides some examples: (click to zoom in)

Since different I/O boards support different numbers of switches, the exact switch numbers reported to your host computer will depend on the specific combination of I/O boards you have as well as the order of the boards in the I/O Loop. (The actual number of each switch doesn’t matter in a practical sense, it really only matters when you’re writing your game code.) Note that on I/O boards with more than one set of switch connectors, the individual pins are labeled based on the switch numbers for that entire board. (0-7 on one, 8-15 on the next, and so on.)

Note that each I/O board doesn’t actually “know” whether a switch is physically attached to a connector or not. (Really a disconnected switch input looks the same to the computer as a switch that never activates.) So the switch numbers are based on how many switch inputs each I/O board has, not what’s physically connected.

Switch reporting to your host computer¶

Of course whenever a switch changes state (from open to closed and from closed to open), a message needs to be sent to the host computer so the game code can take action. With the FAST Pinball platform, that message is only reported after the switch as been debounced (based on whatever debounce settings you’ve configured for that switch).

These messages are typically sent to the host computer automatically, and asynchronously. That means that whenever a switch changes state and has been debounced, the FAST controller immediately sends that switch change notification to the host computer—the host computer doesn’t have to ask for it or repeatedly poll anything.

The actual process works something like this:

A switch connected to a FAST I/O board changes state.
The local processor on the I/O waits for the debounce time window and ensures the switch stays in the new state for the entire debounce time. (If the switch changes back, that means it didn’t really change state, so no further action is taken.)
Once the switch is confirmed to have changed state, the I/O board sends that message out via the FAST I/O Loop. This message is passed to the FAST controller.
The FAST controller sends the message to the host computer via the USB / serial connection.

If you connect to your FAST controller via a serial terminal, you can actually see the switch messages. They come through with either a - (meaning a switch closed), or / (meaning a switch opened.) We chose - and / because they look like the schematic symbols of switches being opened or closed.

For example, if Switch 16 changes from open to closed, you’ll see a message -N:16. If switch 23 opens, you'd see /N:23. These messages are consistent and short, and all the same length, so they’re easy to parse and hide the debouncing logic and other complexity that’s handled by the FAST platform.

The FAST platform has several commands you can use to configure your switches. (And again, you can reconfigure any switch at any time even while the platform is running. So if you wanted to implement a “drunk mode” where there’s a 100ms delay between the flipper button and the flipper flipping, you can just send a new configuration for a 100ms debounce time and the platform will handle it on its own. No timing or special code is required. When that mode is over, you can reconfigure the switch back to its original debounce settings.

There are also commands which you can use to read the states of all switches. (This is used when a machine boots up to read in the initial states of all the switches, for example.)

Opto switches¶

Since all switches in the FAST Modern Platform are direct wired (e.g. there is no switch matrix), you can connect the IR receiver / detector directly to a switch input. You will still need a separately powered IR emitter (which is easy to wire since it’s just always on).

Note that due to the way IR detectors work, the switch states are “backwards”, in that the switch will report as closed / active when it is receiving IR light (e.g. when the ball or switch is open), and it will switch to open / inactive when the IR beam is blocked.

This is not a problem. In fact modern game frameworks like the Mission Pinball Framework let you specify that a switch is “normally closed” which will invert the readings automatically, but it’s something you should know about, especially if you’re just playing around and reading switch changes directly via terminal software.

Autofire “quick action” switch configurations¶

Another helpful feature of the FAST platform is the ability to configure so-called “autofire” combinations of switches linked to specific drivers. This is used where you want the least amount of delay possible between when a switch changes state and a coil fires (or turns off). The most common example of this is for flippers, but also for pop bumpers and some types of diverters.

In the FAST Modern Platform with FAST I/O boards, you can configure these types of linked switch/driver rules which are then completely handled locally on each I/O board by that board’s local processor. This means that once that switch is debounced, that coil will fire instantly, without needing data to go around the FAST I/O Loop or to go to the host computer via USB. (In that case, the switch change event is still sent to the host computer like any other switch, but in this case it’s already fired or turned off the coil before the host computer even knows about it!