Monthly Archives: November 2016

11/18/2016 – Stencils for Surface Mount Incandescent Wings

If you have ever populated surface mount boards by hand, you know that a stencil for spreading the solder paste is invaluable.  Before the Kickstarter, I tried to do it by just spreading the solder paste on using a dental pick, but I would get too much in some areas and not enough in other areas.  This would mean that I would have to go back through and use solder wick to clean up the extra lead.  It also meant that I would have to rework 2 or 3 pins per incandescent wing board.  Identifying issues and fixing them took a long time.

During the Kickstarter, I knew that I was going to need to build up about 30 of the incandescent surface mount boards for the big spenders.  Building them up using the through hole cards would take a long time to clip all of the leads and solder all those pins.  (The incandescent wing has the most solder connections on it.)  I ended up getting a stencil from OSH Stencils because they were the cheapest.  I dropped the Gerbers for the stencil in the repository so other people could order one if they needed it, assuming nobody would ever need one.

A couple weeks ago, the Mezels said they sold out of the incandescent surface mount boards.  I was surprised.  I reached out to OSH Stencils to see if there was a way to make the stencils available using a link so people don’t need to upload the Gerber files to order them.  Luckily the guy had just added that feature to the website.

If you are populating a surface mount incandescent wing board as a low side switch (i.e. enable and disable the ground connection to turn on and off the bulb), use this link:  Low Side Incandescent Wing Stencil.

If you are populating a surface mount incandescent wing board as a high side switch (i.e. enable and disable the power connection to turn on and off the bulb), use this link:  High Side Incandescent Wing Stencil.

If I needed to build 8 or 10 boards, a stencil would definitely make sense.  Less than that, I would probably just muddle through it and not get the stencil.  It is really based on what your time is worth.  The other nice part of the stencil is because you always get the right amount of solder paste, my yield rate jumped to 100%.  (i.e. I never had to rework any of the boards)  That made testing that much faster and more convenient because I could run through and test all 30 of the boards without needing to stop and fix issues that I found.



11/15/21 – Why is it so hard to explain grounding?

I think that the most common question that I ask people when I’m trying to help them out (after all the initial questions), is, “Are your grounds correct?”  It’s really important to get your grounds correct.  If the grounds aren’t correct, all sorts of issues will occur that will be nearly impossible to figure out.  The other issue is that trying to figure out grounding moves you from the realm of hobbyist to something a little bit deeper.  The nice part is that there are some rules of thumb that you can use to greatly simplify the issues that you will run into.  Hopefully laying out the rules of thumb will make it more understandable.  (Note:  This will not make you an expert on grounding, but it will hopefully give you some pointers.)

Rules of thumb:

  1. All current sourced by a power supply should return to that power supply.  (Don’t mix electrons up).
  2. All grounds should be connected together as close to the power supplies as possible.
  3. Big loops of wire, (especially with lots of current going through them) are bad.
  4. Bundles of wire containing both high current wires and signal wires are bad.

That’s it.  That’s all you have to worry about.  If you keep those simple things in mind, you will be fine.  Let’s dive into each of the rules and see what I’m trying to say about them.

All current sourced by a power supply should return to that power supply

OK.  Let’s talk about SharpeShooter3 (SS3) since it has five PC power supplies in it.  When I’m debugging, it actually has six power supplies in it, but we’ll ignore that.)

Four of the power supplies are connected in series to give me 48V.  Since each PC power supply only creates 0-12V, I basically connected the 12V of the first power supply to ground of the second power supply, etc.  To make that work, you need to disconnect the earth ground pin on the second, third and fourth power supplies.  If the earth ground isn’t disconnected, the power supplies will smoke.  (I think there is another connection that needs to be severed, but I can’t remember at this point).  If interested in that, read the old posts on the MaxPower card that I did.

So let’s assume for this discussion that those four power supplies form a single 48V power supply.  (Unfortunately, cheap 48V power supplies weren’t available when I made the MaxPower board.)   The 48V drives most of the coils in the pinball machine.  So that power supply has 48V and ground on the DC side.  (I’ll call that ground, gnd(48v) for this discussion).   So when I fire a coil, all of the current goes through the coil, through the MOSFET (which turns the coil on and off) and ends up at gnd(48v).

Now the next power supply, powers the computer and all the Gen2 boards.  The computer running the rules uses gnd, 3.3V, 5V, 5VSB and 12V.  The Gen2 boards use 5VSB and gnd from that same power supply.  (5VSB is the standby voltage that a PC power supply has.  It is always on even if the power supply’s higher voltages are turned off).  Let’s name that ground, gnd(5vsb) for this discussion.  Again, all of the current from that power supply needs to be returned to it.  Since the Gen2 boards are detecting when switches are closed, the switches must be attached to gnd(5vsb).  The inputs of the processor are internally pulled up to 5VSB.  When grounding the pin to indicate that the switch is closed, it must be attached to gnd(5vsb) because the current came from the processor’s power supply.

All grounds should be connected together as close to the power supplies as possible

So we have two power supplies with two different grounds (gnd(48v) and gnd(5vsb)).  You may wonder why we can’t just keep them completely separated.  That would work except for the MOSFETs which are where it starts to get interesting.  The Gen2 boards fire the solenoids.  To get a n-channel MOSFET to turn on and fire a solenoid, the gate of the MOSFET needs to be brought to about 3V above the source pin of the MOSFET (which is connected to gnd(48v)).  Since these are two completely separate power supplies, gnd(48v) may not be the same voltage as gnd(5vsb).

What you say?  But they are both ground.  How the heck can they be different voltages.  Just trust me…they can be because of how most switching power supplies work.

To get the MOSFETs to fire, we need to tie those grounds together.  Instead of connecting them near the MOSFETs, the best place is back near the power supplies.  In my case I have all the power supplies in the backbox.  The ground connection occurs in the backbox.  It doesn’t occur under the playfield where the MOSFETs are.  The reason for that is, if it was connected near the MOSFETs, some of the current from the 48V power supply may accidentally get mixed up and go to the 5VSB power supply.  Remember the first rule.  Don’t let current from one power supply get confused and go to the ground of the other power supply.

People have been known to add a 2 or 3 ohm resistor between the grounds to make sure that the current doesn’t get confused.  Yeah, that would work, but isn’t really necessary if you tie the power supply grounds together near the power supplies.

Big loops of wire, (especially with lots of current going through them) are bad

The only time that you really need to be conscientious of loops of wire is if it is carrying solenoid current.  Solenoid current can easily reach 5 or 10A which means it is really important to pay attention to loops.  Loops of wire with current running through it creates a magnetic field and can be affected by magnetic fields.  (That is how a solenoid works).  While a solenoid has many hundreds of turns to increase the magnetic field, even a single loop is bad.  Minimizing the size of loops is always better.

Do not do the following:  Do not run the 48V power line to power the solenoids down the left side of the bottom of the playfield, and run the gnd(48v) on the right side of the playfield to return the current.  Running the wires in this way, it would form an immense loop which is really bad.  (It also means that the loop of wire acts as an antenna which is a double whammy).

In a perfect world, I would run the solenoid power and grounds (48V and gnd(48v)) on the bottom of the left side of the playfield, and run little branches to each solenoid across the bottom of the playfield as necessary.  I would cable tie the 48V and gnd(48v) together because inducing noise between those signals doesn’t matter, so that would make the wiring that much cleaner.  Then I would run all of the logic voltages (5VSB and gnd(5vsb)) on the right side of the bottom of the playfield to keep them as far away from each other as possible.

The problem is the world is not perfect, so I didn’t really follow this rule 100%.  I tried to keep the 48V and gnd(48v) as far from the switch signals as possible.  Of course, if you have a pop bumper, by definition, there is a switch in close proximity to the solenoid.  Don’t worry about it.  It’ll probably be fine as long as you don’t cable tie those signals in a bundle and have the wires parallel to each other for 10 or 12 inches.

Bundles of wire containing both high current wires and signal wires are bad

This brings me to another point.  Impulses of current are also bad.  Going from 0A to 10A in a very short time induces voltage in wires that are run in parallel.  This is why I cable tie 48V and gnd(48v) together, but never cable tie those wires with a switch return.  The amount of induced voltage depends on the length of the wire where the signals are running in parallel, the square of the distance between the wires, and the speed of the change in current.  You can’t change the speed of the change in current (well you could, but then your flippers and pop bumpers would be weak, so that really isn’t an option).  You can minimize the length of wire that is parallel (i.e. don’t have gnd(48v) and logic inputs in the same bundle).  You can also try to make sure that those wires are as far from each other as is practical.  They will be close in many cases, but as long as they aren’t running in the same bundle, you will probably be fine.

So in my case Gen2 cards are distributed and so the longest lengths of wire that I really have under the playfield for inputs is 5 or 6 inches at the most.  If I have a 7 bank drop target, I put all of the inputs for detecting the drops are down in the same bundle because it makes things clean and tidy, and none of those wires are carrying much current, so they aren’t going to induce voltage in any other wires.

My ribbon cables for communicating between cards runs down the middle of the playfield.  That gives me some distance between the solenoid wires (48V and gnd(48v)) which are on the left side and the critical processor communication signals.  I’ve even broken this rule when going around the drop bank because it was a shorter ribbon cable to go near the solenoid wires that reset the drop bank target.

So I haven’t mentioned the lights and how they are powered.  Currently they are powered using 5V from the processor power supply.  (This is the high current 5V supply on a PC power supply)  I separate this voltage and ground from my 5VSB and gnd(5vsb) to make sure that the processors don’t get affected by the lights turning on and off.  That means that I have a third ground for lights that is gnd(5v).  That is probably not strictly necessary.  Since I am using LED bulbs, each bulb turning on and off really doesn’t create that much of an impulse in current.  Of each bulb takes 50 mA, so it would take 20 bulbs lighting up all at once to get an impulse of 1A.  Not nearly as much of a worry as the solenoids.  If I was really serious, I would run all those wires near the solenoid wires.  Ehhh, more than likely it doesn’t matter, and since the bulbs are distributed evenly around the playfield, I actually ran the 5V power down both the left and right side of the playfield.  That just made wiring easier for me.

That’s it.  Those are my rules of thumb when wiring a playfield.  If you follow them, you should have pretty good luck.  If interested, read up on the difference between a MOSFET and a Darlington transistor.  Old pinball machines used Darlington’s while most people are using MOSFETs in their homebrew pinball machines today.  Darlington’s back in the day couldn’t be driven directly from a processor because the amount of current through the Darlington is directly proportional to the amount of current put into the base.  This means that a second driver is needed to supply that current.  Glad we don’t have to do that anymore.  (If you have worked on pinball machines long enough, you have probably seen the big 10 ohm resistors that are limiting the current to the base of the transistor, and you have probably found a couple of them laying at the bottom of the back box because they got so hot they desoldered themselves.  Ahh, the good old days.)

11/2/2016 – Bring out your dead

I’m going back and resurrecting the old OPP pinball framework.  The reason was that it should be the shortest path to getting back to having a running SS3 game.  Problem is that the architecture of the boards changed so some of the assumptions that I made are not going to work.

So with the OPP pinball framework, you create a text file that describes your hardware and how you want the hardware to be initially configured.  This file is converted into Python files that are used by your pinball rules to identify bit positions on the hardware.  If you look in the Python directory of the repository, the converter is called GenPyCode.  Here is a quick link to the text file that is used for SS3.  The generation can be done off line since it really only happens during initial development.

So if you take a gander at that file, it is pretty simple.  It basically has multiple sections.   The sections include SOLENOID_CARDS, INPUT_CARDS and LED_CARDS.  That worked great with Gen1 cards because each of those cards were dedicated to a single purpose.  Now with Gen2 cards, each card can have inputs, solenoids, and LED or incandescent wings.  That change is pretty simple because I just have to keep a list of which wing is which by looking at the individual pins, and I can return errors if a wing board is configured as two different things.  Fantastic.

Then last night, I ran into a problem.  The file generates constants so when programming your pinball machine, you can verify that certain things happen.  The constant must uniquely identify the physical bit.  For example, I have a seven target drop bank (SHOOTER letters are on the inserts), and I want to reset the drop bank if all the targets are down.  GenPyCode automatically generates the constants.  In Python, the first drop target is InpBitNames.INP_DROP_TRGT_1S, second target is InpBitNames.INP_DROP_TRGT_2H, third target is InpBitNames.INP_DROP_TRGT_3O, etc.  To check if all the drop targets are down, I simply OR all those bits together to make a mask, and check to see if all those bits are 0 when read from the hardware.   Very simple.  Whatever scheme I come up with, I want to easily be able to combine masks together to form larger groupings.

The problem is that I also embed the card number in the constant so the framework can tell which bits need to be compared.  This all falls apart with Gen2 cards, since there are 32 possible bits and I don’t have enough space to put the card number in the bit mask.  I finally figured out a good solution last night, of embedding the card number, wing number, and then the mask for the input.  So for 32 bit architectures, the card number is 5 bits, the wing number is 2 bits, and there are only 8 possible bits on each wing, so that easily fits within 32 bits.  Sweet.  That will mean I don’t have to rewrite large portions of the pinball framework.

Another time that I use this is to program multiple lights at once.  Let’s say I want to make all of the drop targets blink to indicate that you should shoot at them.  I can simply OR all the drop target bits together, and pass them into standard function called Led_Blink_100, and they will all start blinking.

That’s what I’m going to be working on for the next couple of weeks so that I can get another video together.  At that point, I will hopefully be back to the same spot that I was a year and a half ago.  (Of course, now using newer and better hardware).