That's not 100% accurate.

Here is a great article from Maxim Semiconductor, written by a friend of mine.

https://www.maximintegrated.com/en/app-notes/index.mvp/id/287

Wow that was a lot of quality information, thanks for posting.

Also based on the response in this thread it sounds like I should start turning the many pages of nonsensical scribble into somehow playable
IMG_20160406_103114_edit_(resized).jpg

That is a great reference! For the more EE-squimish, here is something more simplified, based on what I teach my class on a first pass introduction to the subject:

Take away the control system, all the fancy stuff and think about a single leaf switch mounted to a pinball machine and an Arduino connected to the switch. I'm using the Arduino for simplicity's sake. It runs a single program, running a single loop, that is constantly checking to see if that switch is open or closed. What we care about in pinball is when a switch transitions from open to closed and back to open again.

We assume that switches attached to targets close because the ball strikes them, but that's not always the case. Pinball machines get bumped and jostled and even adjacent coils firing can momentarily close those switches just from vibrations. Since those vibrations can close switches when the ball isn't there, we don't want is to treat EVERY closure as a result of the ball hitting it... We need to throw away these spurious closures and, in essence, this is what debouncing is.

One approach to solve this problem, is to scan the switch less frequently. Suppose I slow this down so I only read the switch every 10ms. If I see a closure twice in a row, then I know that the switch was closed for 10ms, so something_ is clearly pressing that switch down. Consider the following, where I check the switch every 10ms (at exactly times 0, 10, 20, 30 below) where '+' is closed and '0' is open

time = 0------10-----20-----30----40
state = ++++++++00000000000000

Using the this tactic of ensuring that two consecutive reads report closed (the "debounce" part is to throwing away a closure that doesn't read as closed twice in a row), this works in the example above, because the switch was closed at the read that occurred at time 0, and again at time 10 (from my high quality ASCII art it appears that the switch was closed for about 14ms).

10ms is a very long time to wait between scans, and as a result we could wind up missing perfectly good closures, even those that are 10ms long! Consider the following:

time = 0------10-----20-----30----40
state = 00+++++++0000000000000

The closure starts at time 4ms, but we didn't see it at time zero. We see it for the first time at time 10, but it's done by 18ms (before 20ms) so we don't see it on the next scan!

So, even if I want to say it needs to be closed for 10ms, those scans are too infrequent/slow. We missed a 10ms closure! If we scanned every 5ms, we would have seen it at time 5ms and again at 10ms, and again at time 15ms, so our rule would have to be that we want to see the switch as closed three times. Even 5ms will break down if we come up with some worst-case examples. So it would be better for me to physically scan every 2ms (or faster for that matter) and use software based logic to determine how many consecutive closures would be from a ball-strike instead of a random vibration.

It's slightly more complicated than this simplistic explanation, but not very. Vibrations can also open a legitimate closure early, which is covered in the excellent article wolfmarsh posted.

If we look at the history, debounce values have evolved based on hardware capabilities, increased ball speed, and another of other factors. It needs to be data-driven, and carefully determined. If the hardware scans as quickly as possible, you can refine what you do with consecutive values the values in software. If you are scanning too slowly in the hardware, you might not see enough of the truth to make a good guess.

I don't explain any of this when I teach my P-ROC/PyProcGame unit. I do it in the unit before, when we wire up an Arduino to a pinball switch matrix --on the P-ROC is just works

I love the ASCII art!

Ok. I think I am starting to understand the differences between systems and why it is confusing. If you are scanning all your switches on intervals like you described, you will want to do that as often as possible to get your consecutive switch reads to determine that the switch was pressed long enough to be considered "active." I think the time that if being called debounce time in the proc world is actually the time between switch scans.

In our FAST hardware and our SN: switches (these are the switches connected directly to our FAST I/O boards) we are "scanning" our switches every 1ms. When we say "debounce" time for a switch becoming active is say, 10ms, it is 10 consecutive 1ms intervals. That 1ms resolution makes it easy for the user to say "respond when the switch is held for 10ms" which is a time value, not a scan read interval.

The way your describe the proc switches is the way we have to read switches when we use our FAST WPC Controller and the associated switch matrix (the SL: Local Switches I described above). There we don't have the 1ms resolution because we are having to go out and scan the switches like you describe. I don't recall that scan time off the top of my head, but I will find out because now I am curious too!

Thank you for the explanation (and the art!) it helps to clear things up, gets us speaking the same language.

Aaron
FAST Pinball

Okay - thanks guys!

One question - if it possible for a ball to only activate a switch less than 10ms? That seems *extremely* fast for a pinball.

sure. hit a microswitch and look at it on a scope! the thing with microswitches is not so much when a ball hits it stays closed, is that it bounces a LOT when it closes before staying 'closed'.

see jack ganssle's article

http://www.ganssle.com/debouncing.htm

his 'switch O' is a typical microswitch that you'd see in ball troughs etc.

"One actuation yielded 7 clean zeroes levels ranging in time from 12 to 86 µsec, and 7 logic ones varying from 6 to 95 µsec"

debounceswitcho_(resized).jpg

quite a lot less than 10ms!

We default our switch debounce on times to 30ms. The more recent posts make me understand why 30ms seemed so long (when you are looking at it as a scan time).

With how we read and debounce our switches on our FAST I/O boards, a 10ms time is pretty short.

Aaron
FAST Pinball

Good call. I always default to the old timey leaf switches. Microswitches are snappier. This is where being able to individually configure your debounce times per switch is really useful. Not every switch type needs to be debounced the same way.

Aaron
FAST Pinball

So what happens when your auto-fire coils react to a switch hit? They pulse a coil for around 30ms, and probably ignore further switch inputs for that pulse duration (so your coil isn't on continuously.) This effectively lengthens the debounce time to the coil pulse time.

This is useful for "tuning" your jet bumper nest, where a stronger (longer) coil pulse kicks the ball harder but won't react to a quick rebound. This gives the impression of a laggy bumper. Somewhat unintuitively reducing the coil pulse allows the bumper to react to quick rebounds, giving the lively bumper action we love.

If your layout is prone to bumper resonance your software can alter the coil pulse "on the fly" to avoid such activity.

Many of the details surrounding the P3's ball tracking are patent pending, and it's an important competitive feature; so I'll keep the details secret for now. Suffice it to say that the underlying mechanisms on which we build our ball tracking implementation are available in both the P-ROC and the P3-ROC. The P-ROC and P3-ROC are designed to help people to build traditional machines and/or advanced machines.

Lots of good, low-level discussions about debouncing. My main point is that this is one feature you shouldn't necessarily *need* to understand. You should just be able to buy and wire up a controller board, install the software framework of your choice, and get reliable switch events. With the P-ROC, that's what you get. Debouncing works, and you won't miss switch events. If the FAST boards really do default to 30ms debounce timing, regardless of whether it counts 30 scans 1ms apart, 2 scans 30ms apart, or any other combination, then you will absolutely, 100% guaranteed miss switch events and have to debug and tweak every switch (well, or just override the default with 2ms).

To answer your specific question though, like BloodyCactus said, yes... a ball will oftentimes activate a switch for less than 10ms. Consider a rollover or lane opto switch and a fast moving ball.

Ok, which topic is next on the list?

- Gerry
http://www.pinballcontrollers.com
http://www.multimorphic.com

Agreed, but what you're describing isn't switch debouncing, at least not the same type of debouncing we've been discussing above. In the P-ROC, we call this "reloading". Switches are still optionally debounced, but after one event results in a coil firing, subsequent events on the same switch are ignored until the reload timer expires. The reload timer can be enabled per switch rule, and it's typically only enabled for bumpers (pops and slings). Pyprocgame enables the P-ROC's reload timers automatically for all devices in your PRBumpers section. With MPF, there was apparently a bug keeping the reload timers from getting set. I'm told that's fixed in MPF 0.30.

- Gerry
http://www.pinballcontrollers.com
http://www.multimorphic.com

Just to clarify, the debounce time is just a factor of when the switch is determined to be active, not the whole time between coil pulse times. There are a couple factors there. Once a switch is determined active, we immediately trigger the driver and it pulses for the time and the PWM strength we set it to. Our driver configurations also include a "rest time" that says "this driver cannot be triggered again until Xms have passed." I believe the "rest time" guidance is 2x the pulse time to ensure the coil doesn't get damaged.

To get your pop bumpers acting just the way you want for your playfield geometry, you can adjust any of the settings I described. For the example of the endless pop bumper, I would probably account for that scenario in my higher level software because there does not exist a state machine for the devices in the FAST I/O boards. Where "If pop bumper is triggered more than X times in a row without any other switch triggered, reset the rest time of the driver on that coil to be longer" and then gravity should help out and get that ball off the pop and when the time was right, reset the rest time of that driver back to what I wanted.

But again, this is where, in my opinion, there isn't a "one (or 2) size fits all" for fine tuning your game's device timing. I don't see it as having to

I see it as you can refine each switch to make your game feel just right. As much as we would all like to just broadly set values for everything (whether 30ms, 10ms, 2ms, whatever) you are setting yourself up for frustration if you don't plan to spend some quality time with your game layout fine tuning the physical device performance.

Knowledge is power. The more you know about the concepts and how it all comes together, the more aware you are of all the options you have. While many of the cases can be addressed in some smart default values, knowing how they work is a great chance for you to learn and empower you to make your game really feel great. It's part of the magic of making pinball! Plus, if you are anything like me the idea of "just do this, it works" is torture. I gotta dig in deeper and know why.

Aaron
FAST Pinball

Right on. That is what we call the "rest time," except we tie the "rest time" to the driver. In the FAST system, a switch is just a switch. What reacts to the switch events is configured to know when and how to react. So a switch will still report switch events to the controller, even if the driver is ignoring the switch per it's "rest time."

We worked hard to keep things simple and "just what they are." You fine tune switches and drivers separately. Combining the configurations of both gives you the device experience you want. Even our "greenest" users seem to get it and in no time can "talk the talk" with the more experienced users. I love witnessing the learning that goes on around working on pinball. I learn something new all the time. Love to share it.

Aaron
FAST Pinball

You know what everyone? I think we need a little thunderdome up in here........TWO BOARDS ENTER....ONE BOARD LEAVES.....TTTWWWWOOOO BOARDS ENTER...ONE BOARD LEEEAAAVVVEEESSSS!!!!

Pinball board showdown.........hahah

project-thunderdome-cc_(resized).jpg

Dave isn't a Pinside guy, but I wanted to get him familiar with this thread. With the push back over the 30ms comments, I figured it wouldn't hurt to dig in and find out why we even got to that value as a default. So I asked Dave why he chose 30ms for the default switch debounce. He said this comes from the scanning of switches on older Pinball Machines. When creating the FAST hardware he used Twilight Zone as one of the development games. That machine has an 8 by 9 switch matrix. The original hardware on some machines goes to an 8 x 10 matrix. It takes two scans for a switch to register closed (in most cases), so 20mS + a little to compensate for the switch not being in sync with the scanning of the switches. The half way point of one scan is around 10mS, so there is the default number 30mS. He said the number was not meant to become a standard, but only used it as it seems to work well on one of his favorite machines. He said if for some reason we need a create a "Set all switch defaults" command we can add it, but he also added that's why "for" loops were invented.

We are driving this with a computer correct?

We want the experience to be positive from the first time you use it. Setting a sling too aggressive and have it shotgunning for a newbie is much worse than a missed switch. For slings, we usually set a more aggressive switch close time, and even longer switch open debounce time. Mileage will vary, but most slings will all have the same values, as would pops, rollover switches etc. You are not tuning each switch if you decide to do that, you are adjusting for each type of switch. If you find your leaf springs are not properly aligned, you can change the open and close times to compensate. You could also have your game software adjust these in real time if shotgunning is occurring due to misaligned switch or other obstruction. The older pinball machines had no control over this. Your only choice is to trigger on scan pass 1, 2, or 3... Each pass being 8 - 10mS long. If we can at least meet that specification, we are no worse then all the great pinball machines out there.

Dave says what he really wanted to do with the FAST hardware is to create complex rules using only a few parameters. For instance, having a ramp lift up so a ball can pass under it when triggered by a spinner sending switch open and close events each rotation of the spinner. Then automatically lowering the ramp with another switch, or a specified timeout period. If the hardware does this much abstraction, the coding portion becomes incredibly simple. Simply wait for switch events and do some cool stuff.

Dave (by way of Aaron)
FAST Pinball

PS: I also found out that the scan time that we read the switch matrix with our SL: (Local Switches) which we used on the FAST WPC Controller is 0.5ms.

Dave and I have been rocking on the FAST Docs. I have established an standard set of wiring color that we use in all our demonstrations and I have brought that into our documentation, as well. I have included some images here showing the FAST Power Filter Board as it would look in an actual wired example, a wiring diagram and a block diagram.

The work is now applying the treatment to the rest of the hardware and THAT will be a lot of hard work out of the way. Then back to some more fun stuff?

Aaron
FAST Pinball

PS: Please let me know if I made any mistakes or if additional clarification on these examples would be useful.

Screen_Shot_2016-04-08_at_10.06.34_PM_(resized).png

Screen_Shot_2016-04-08_at_10.07.00_PM_(resized).png

fast-power-filter-supplies_(resized).jpg

nice work Aaron, look forward to more info

So, a thought occured to me to ask another possibly silly stupid question -

I saw that FAST, at least, has interfaces for WPC games (and Sys11, I think, though I can't recall exactly at this time..)..

What/how could these systems (FAST *or* P-ROC..) be connected to older games, like Classic Bally/Stern or hell, less populous games like Gottlieb?

You would have to do like Mark S. did and make your own interface board for the system (drivers, lamps) and deal with the display aspect.

Currently P-ROC can drop right into a WPC, WPC-95, Stern Whitestar or Stern SAM machine. P-ROC users have also been able to interface to System 11 games using Mark Sunnucks' System 11 interface board and controlling it with the same programming tools and languages as you would on the WPC/Stern machines.

System 11 games I can think of that are being controlled with the interface board and P-ROC: Whirlwind, Earthshaker Aftershock, F-14 Tomcat and I know there's more, but I can't recall the exact titles off the top of my head.

If this is something you're looking to do, we're more than happy to get you set up via video chat, our live Slack chat, phone or email.

Don't forget the Data East machines that can also take advantage of the PROC and Marks board.

D'oh! I suppose we have Joe Kaminkow among others to thank for that

Ah, okay! I didn't mean to focus on the Sys11 stuff, I just thought I remembered seeing something for it.

I was actually toying with the idea of trying to come up with something for my other two games - Nudge-It (Gott, Sys 3, which has horribly incomplete software plus the addition of a ticket dispenser!), and Meteor (Stern, MPU-200, just for the hell of it). But, my first and foremost requirement would be keeping the game's wiring un-modified, so that in a short amount of time, it can be restored to original. (So, no wiring hacks, essentially.)

The Stern's switches and coils would be easy, actually, since the switches are already on a matrix, and coils are direct. Lamps, I'm not sure about, since they're direct (no matrix).. The Gottlieb's coils would be easy. The switches and lamps, though, with that co-joined twin matrix system, no clue.

Like Buffy the Vampire Slayer -- the re-theme of Swords of Fury?

Oh snap! Well it looks so modern that I had no recollection of it being a SoF. Correct, the Buffy pin is powered by the P-ROC, System 11 equipment and Mark's interface board. Its a fine example of the possibilities in one solid, playable package.

I'd really like to see an interface board for Gottlieb System 3. There's some cheap DMD games in need of a rewrite.

I would extend that to the System 80s as well..... The System 3s and System 80s had some of the more unique layouts in all of pinball during their time. Honestly, they only thing that made them suffer was their software.

Road Kings 2.0

Can't believe I forgot to mention Jim's newer Bally control boards (applejuice here). If you want to do the Stern Meteor thing, that would be a consideration.

Ni-Wumpf could do any of the system80s (maybe not B?). In reality, the hardware (besides from the displays, which aren't too hard to drive) has fairly similar IO to a Bally (dedicated lights, switch matrix, and NPN solenoids), I'd imagine with some adapter wires it could be run using the replacement Bally/Stern boards. Or even original Bally boards, there's a rewritten and documented ROM for those....

Actually, it's a real shame someone hasn't done something similar to the code editor for Ni-Wumpf to generate 6800 ASM for the pinball construction kit (site seems to be down? http://webcache.googleusercontent.com/search?q=cache:zmshKZssOnoJ:www.pinball4you.ch/okaegi/pro_pck.html+&cd=1&hl=en&ct=clnk&gl=us). I haven't used it but it seems like the only real weakness is that people need to be able to write assembly to work with it, otherwise we'd probably have new rulesets for half the ballys and sterns out there...

Interesting, is there info somewhere?

Not sure if this is the one shimoda was talking about, but: https://pinside.com/pinball/forum/topic/mypinballs-custom-pinball-controller-for-ballystern-games

Yeah, Jim's boards for Classic Bally/Stern would be the way to go for that era of game if you just wanted to rewrite the software and make a cool custom machine using the classic hardware.

You can get those here:
http://mypinballs.com/electronics/store.jsp

They plug right into the existing wiring.

Ah! Okay, that's what his "(applejuice)" comment was for! I was preferring something that used FAST or P-ROC (since I know python a *LOT* better than Arduino's C code..) However, I'm subscribed to that thread, will be looking into it..!

4 pages in, someone specifically asks about a pure C environment and still no one mentions FreeWPC

But just like JJP, Heighway, Chicago Gaming, Stern Spike and others with hardware systems the debuted after Proc existed

I'll think you'll find that there was one framework that was out way before P-ROC and it's the one that'll be the most similar to what HP uses.

(I know, this discussion was more about hardware boards but meh, had to wave my little FreeWPC flag)

The thing that made me look at MPF over P-ROC was the fact that at the time I looked, I had to write the code to make the start button flash when credits were available with the P-ROC framework. Now, that might seem petty, but it showed to me that you were expected to do *everything*. MPF seems like a pinball OS, P-ROC felt like an industrial control OS. I didn't feel like I wanted to reinvent the wheel for each game I made. I'm sure Gerry will have something to say about this.

FWIW the Ben Heck system looks freakin' awful to me. The guy has no idea about source revision control, 17,000 line single file for *all* the game logic, random code and comment indentation, no sign of DEFINEs to help with code clarity, code randomly commented out with no reason why, reseeding the PRNG at the start of each game, but not reseeding the PRNG with a static value for tournament games, liberal use of Ifs when a select/case statement would be clearer to read, no debug flag, so you have to go uncomment out every single debug print to turn it on, I could go on and on but you get the idea.

MPF works with P-ROC. I think you may be mistaking the word P-ROC with the pyprocgame framework.