OPP Cards Displaying Status on Remote PC, 9/4/2014

So two weeks ago, a board was sent out to the board house (Iteadstudio) and all was well. I needed to get that work item done, so while it was being manufactured, and shipped I could do other things in parallel. I spent the next week trying to scare somebody away from the project, but utterly failed in that attempt. He has an old playfield Bullseye/301 with nothing to drive it. No cabinet, no electronics…basically a perfect match for using OPP cards. Joe has been dogging it lately (something about being busy with something other than designing his pinball machine), so I haven’t gotten as much feedback as I wanted from him.

I feel to insure the viability of an open source project, it needs to either be so simple that no documentation is needed, or there has to be enough information so that a person who understands the topic can easily find the necessary documentation. Pinball controllers are relatively complex. There are three main boards that are required to control a pinball machine. The overall design, architecture, and implementation are in my head, but how does a person that simply wants to re-use the board designs start with their machine?

The only way that I can make sure the information is available is to get somebody else to use the cards, and to document questions and steps during the process. Essentially take on an alpha customer to force the information to be generated. Joe was supposed to be that person, but alas, building a machine completely from scratch takes a long time. I’ve had the cards for more than two years (actually almost three) at this point, but things moved at a snails pace. (Much of it was caused by fear of actually cutting whitewood. If I had a CNC router, it would be a much easier process, but to build one of those, it is a couple month hit in time.) When the SS2 playfield was purchased, the decision was made to bring it back to life. It does not have a fan layout so that actually drew me to it. SS2 is relatively rare, which makes it more appealing to me. Next big step forward was getting a rotisserie. I had set up the Camelot playfield and batted the ball around, controlled all the solenoids, but it was sitting on blocks of wood, and with every flip of the flipper, it would almost fall off the table. Every time I wanted to work on the underside, it would be a half an hour production to go between the table top setup, and the leaning against the wall so I could solder it. A couple months ago I built the rotisserie, and it lets me move between playing and wiring in the span of about a minute. With the amount of testing that I did on the SS2 playfield and previous tests, I felt confident in the cards. When the new person contacted me about getting a few cards to drive his playfield, it seemed like a good match. He seems technical enough to get it working, and from reading his blog, it seems that he is better with a soldering iron than I will ever be. Once he gets some information up on his website I will post a link to it.

Last week I sent him enough cards to control the playfield and read all the switch inputs. After sending those, I immediately realized that he would need some sort of documentation to start the rewiring of the playfield. Well, all the information is in the blog, but who has the time to go through two years of my random mumblings (most of it pointless) to find the technical details. I’ve started a rewiring a playfield document to provide this information. The initial version of the document should be available in the repository by the time I post this blog entry. There is also another guy, (I think I’m calling him Pierre since he is from Canada), who says he wants to take care of the Google code repository wiki. That would be a perfect place to put much of this information or at least pointers of where to find it.

So last weekend after building cards, shipping cards, working on a document, etc., I finally got back to working on SS2. I finished the wiring for all the switch inputs, and wired the communications between all the cards. I dragged the laptop down to the basement, and ran PinBrdGui.py.

PinBrdGui is basically a debugging aid that I wrote a couple months ago. You tell it what serial port to look at, and it goes out and auto-discovers all the boards on that serial port. In SS2, there are two solenoid boards and two input boards. It displays the current state of each of the switch inputs on the input cards, and it displays if a solenoid has been triggered on solenoid cards. Input cards can also be configured to report edges, but that is not as useful to debug if the switches are working. When a solenoid bit detects the correct edge (usually falling edge since input bits are pulled up, and closing the switch grounds them), the next status read from the card will have a ‘1’ in the correct bit position indicating the solenoid has fired. After the status is read, the solenoid driver card clears the status bit automatically. That means if the main processor doesn’t get around to reading the status for a while, it will not miss the fact that a solenoid has fired. In the embedded world these types of bits are called clear on read bits.

So here is a link to the video of the laptop getting real time status of input bits, solenoid kicks, from all the SS2 cards. https://www.youtube.com/watch?v=jKv1SIMZt1w. Couple notes on the video. On solenoid card #1, you can see the lsb fluttering. That is caused by a manufacturing defect on the card (probably a whisker of solder). That should only take about 5 minutes to fix when I have the time. The PinBrdGui helped me figure out that issue immediately since I could leave the switch open and see the fluttering, and close the switch, and see the fluttering immediately stop. Some persistence should be added to the displaying of the solenoid status bits. Since the status rate is so fast and the bit is only set for a single frame, it is easy to miss a solenoid input bit going past. A frame rate should be added. I’ve estimated and calculated the worst case status frame rate, but having PinBrdGui print out the actual number of frames per second would be a great debugging tool.

I have notes to write about 10 more things, and frankly I need to finish the playfield rewiring document. In the above blog entry, I promised the document would be finished before I posted this. I lied. I’ll write more after that is in the first draft form.

Incandescent Driver boards, 8/23/2014

So as I’m typing this, the incandescent driver boards are finished.  Of course, since I can’t bear to waste an inch of PCB, I’ve also started working on the next generation of driver boards.

I’ve decided to start working on the next generation of boards.  This is solely based on the fact that I have extra PCB area.  The incandescent driver boards are 2.5 cm x 5 cm.  The PCB house I use sells 10 cm x 10 cm boards.  That leaves 5 cm x 10 cm of board space.  That happens to be just enough space for the next generation driver design.

Here are the list of improvements:

  • Completely open source solution.  The next generation will switch from the HCS08 processor to the an ARM based processor.  This allows to switch from Freescale’s CodeWarrior, to CooCox and the CoIDE which are both free and open source.
  • The first generation required an $80 debugger to program the bootloader in the processor the first time.  After that, code could be updated using the serial port and the boot loader.  The fact that the debugger is required, makes the first generation more expensive for people trying to independently create a pinball machine.  The next generation contains the debugger on the development board.  There is also an embedded bootloader, so if creating cards from scratch to make them cheaper, that bootloader can be used.
  • The HCS08 in the first version used a DIP package for the processor.  That package for the processor is end of life, so the cards would have to be laid out again.  That would involve switching from DIP packages to surface mount packages which would make home assembly more difficult.
  • The next generation uses a standard off the shelf development board.  The solenoid driver/input driver boards mount to the development board using the breakout header pins.  All soldering remains through-hole components to make it easy for hobbyists.
  • The first generation cards were either solenoid drivers or input cards.  The next generation allows the cards to be either input or solenoid drivers, or a mixture by populating the boards differently.  Since there are less different cards, a single order of 10 cm x 10 cm PCBs can build two complete pinball machines.
  • The next generation of boards have switched from 5V processors to 3.3V processors.  Previously a voltage conversion needed to take place between the solenoids drivers/input drivers and the Raspberry Pi.  Now that everything is running at 3.3V, that converter can be removed.  This makes interfacing between those two cards, that much easier.

So, I don’t really have time to write the firmware for the next generation of cards.  I’ve done minimal amounts of work getting interrupts working on the ARM processor, and blinking LEDs.  I started looking at doing the bootloader, but it would take about a full month of work to get everything up and running.  While it would be fun to do that, I’m busy getting the rest of the framework done.

That put everything on hold for a while, but then, suddenly a couple weeks ago somebody approached me to help with the Open Pinball Project.  This seemed like a natural fit to have him work on the next generation.  He has some Arduino experience, but we will see if he can show production quality firmware.

There are other things that are happening too, but there isn’t enough time for me to do all the updates this evening.

8/12/2014, Promised video of first flips

Not much to add from yesterday, but did a short video last night with the driver boards kicking all the solenoids.  Link is at:  http://youtu.be/x1HKE0BczPA.

Well, at least Joe will watch it.  (Enjoy Joe!  Hopefully your layout is coming along.)

Progress 8/10/2014, Popping MOSFETS like Jiffy Pop Popcorn…and more.

[Week ago information that wasn't posted]  Title pretty much says it all.  I got around to testing some of the MOSFETs that I was using with the flippers.  If the flippers are only around 1.2 ohms, and I throw 48V across them, it gives me about 40A of current (worst case, ignoring increases in resistance due to heat).  Needless to say, a 12A MOSFET doesn’t last very long at that point.

I tossed the flippers onto another channel on the solenoid driver (oops, it was one that I had set as a really strong kick), and of course popped another FET after about a minute of flipping.  I had already dropped the voltage down to 24V (since the power supply outputs it), but it was still a little bit too much current.  I had cheaped out on the FETs that I bought which is fine for all of the channels except for the flippers.  Those channels really need an IRL540N that can handle 26A continuously at 100C.  The funny part is that it would have worked on a newer pinball machine since the current is lower.  I may cobble something together so that I can keep moving, and I still have a good amount of wiring to do to get all the solenoids firing automatically.

Spent the time today to tighten up the rotisserie.  It is now much more stable, and an absolute pleasure.  I added foam beneath the playfield so that it couldn’t short to the rails.  The foam also raises the playfield enough so that the electrical components don’t touch the rail.

[New information]  Of course I wrote the previous stuff a week ago and never posted it.  Ordered the heftier FETs and got them in on Saturday.  Wired all of the ground connections to both the switches and the switches on the solenoids.  It took a couple hours but one of the kids helped me.  Eight year old children are able to cut wires to length, strip them, and do small amounts of soldering.  The nice part was that it only left about 30 minutes of wiring for today to get all of the solenoids working.  That happened before the end of the night, flipped the pinball machine around on the rotisserie, and there was a functional pinball machine.  Right before bed the kid tossed around the ball to fire all the solenoids.  There might have been an aha moment realizing that the wiring work brought the machine back from the dead.

So what do I have right now?  A powered pinball machine that the playfield layout can be tested.  The solenoids drivers are configured to drive the solenoids properly so no coding is necessary to get that to happen.  The goal of being able to test the layout without needing to program the machine has been achieved.  There are no rules, no switches that don’t attach to a solenoid, and no feature lights.  I have two GI light bulbs wired, which is used to tell if the machine is on/off.  Right now the drop targets aren’t working because I need to fix the broken targets, and wire those switches.  When the game is finished, the main processor will reset the drop targets, but right now, I have a separate switch to do it.  I still need to wire all the normal switches.  The feature lights I’m building another board so I can support the incandescent bulbs.  That is probably the long lead item at this point since it takes about 4 weeks to get the cards.

Video.  Yeah, words are great, but a video is the only proof that it is actually working.  I will probably try and get something together Monday night.   The flipper buttons are just hanging in mid-air at this point, so I need something a little better for them.

I also want to do some measurements on currents drawn etc.  I can’t find any truly good resources on the web about what the current curves should look like for flippers, pop bumpers, etc.  There are a couple sites which list resistances, but I don’t know the inductance.  I soldered up a current sense resistor, and I have a oscilloscope, so I should be able to get the information relatively easily and post it.

Progress 7/28/2014

I’ve decided to make the all of the titles of my posts completely boring.  Sorry.  Maybe I will feel a little more enthusiasm later in the post, but doubtful.

First order of business is that I built a rotisserie.  I started thinking that I needed one last week.  I wanted something that I could actually give the playfield some angle so that I could play a couple games if necessary.  I threw a sketch together and sent it to Joe, and he mentioned I was an idiot for trying to do it myself.  (My words, not his).  He sent me a link of a well thought out rotisserie that only took about an hour to construct.  What the posters didn’t mention is that you are going to spend about two hours at the local hardware store picking up all the materials, but that is mostly because I get to the nuts and bolts aisle and my eyes go all haywire.  Here is the link that Joe sent me.  https://pinside.com/pinball/forum/topic/vids-quick-and-dirty-rotisserie-guide.  Fantastically simple to build, and it costs around $100 at today’s prices.  You could easily cut the price by $20 or $30 if you are willing to cut the threads yourself.

Here’s the things I’ve learned building the rotisserie.

  • Either use a monkey wrench, or at least use a lever in the pipes torque the pipes together as much as possible.  I didn’t do that, and mine is wobbly.  It will be better when I pull the playfield off it and tighten it up, but I was too excited to use it.  (It was noted in the instructions, I just didn’t follow them).
  • I’m going to add wood blocks to the pieces of angle metal that hold the playfield.  Using blocks will allow me to adjust them to places on the playfield that have no components.  Making them out of wood means that I can power the playfield and not worry about it shorting out to the metal rails.  (I don’t think it was envisioned as powering it on the rotisserie, but since I only need a single 24 pin Molex power connector, it is very convenient for me to power it there.  It also makes it easy solder on the back and hopefully debug issues.)

After finishing the rotisserie, it was on to powering the playfield.  The end design uses the Raspberry Pi to turn the power supply on and off.  It powers the solenoid boards/input boards with 5VSB from a PC power supply (which is always on).  I tried powering it and just hard wiring the 48V power supply on.  The problem is that it takes about 100 ms for the processors to come up and do power on self tests, and during that time, the FET inputs are floating.  Not a problem in the real system, but it is annoying to hear the click at startup.  I ended up hooking up a wall wart for the 5VSB supply so that I can plug in the wall wart, then turn on the big 48V supply.

After initially turning on the board, I immediately blew out the fuse that I had for the flippers.  I’m missing something on how Game Plan configured their flippers.  I assumed one thing, and evidently that was wrong because I blew the fuse.  Spent a little time tonight debugging it, but didn’t get any closer.  I had it working well for a little bit, but it wasn’t at full strength.  As soon as I tried to make it at full strength I started having problems.

At one point last night, one of the solenoids started chattering.  It could be that I had a ground loop, but I couldn’t reproduce it tonight.  Originally the return to the wall wart had to go through the PC power supply to get back to ground.  (Again, not what would happen in the real system, but right now I’m cobbling a little bit of stuff together.)  I added a ground return line to the wall wart so ground would be connected properly.

So here is the first video of firing the solenoids on Sharp Shooter 2.  The pop bumpers sound really nice and crisp.  The flippers are weak because how they were hooked up.  I was only powering the hold coil of the flipper.  http://youtu.be/5w517evHcOE.

I just looked up the resistance on the flipper coil.  It is a 5008B and only has 1.2 ohms of resistance.  No wonder the original machine could run off 24V.  If that is the case I need to cut down the initial kick and hold significantly.  I was running originally running at 48ms initial kick, and 25% sustain, but I’ll try cutting it down to 16ms initial kick and 6.25% sustain.  That is definitely the strongest flipper coil I’ve ever seen.

Progress 7/14/2014

I’ve been working on the GenPyCode project in the Google code repository, and  rewiring the SharpShooter II playfield.  Progress is slow but steady.

Starting with the rewire of SharpShooter II.  The initial step is to get all the solenoids firing and active on the playfield.  Because the driver boards can statically configured, it is simple to set them up so the machine will be playable.   The machine won’t play a game, but will continually serve the ball onto the playfield, all the bumpers will work, the kickout hole will work, and I’ll probably daisy chain the drop targets so you need to knock down all of them to have the bank reset.  The end game will support two ball multiball, but that would take a bit of programming.

Right now, I’ve routed many of the wires that source and sink the 48V for the solenoids.  The 48V source is brought to the playfield using three lines:  upper playfield solenoids, lower playfield solenoids, and flippers.  Four wires are used to return the current from the two solenoid cards.  Three wires are used to source the current for the lighting.  The playfield GI was originally broken into two circuits.  A third circuit has been added to source the current for the feature lights.  Looking at the current rating of the wires, I’m definitely over doing the number of wires, but it allows for me to the ground wires on the back of the playfield.  (Less soldering for me to do.)

The feature lights for Disaster are going to use LEDs.  Since this is a retrofit, the feature lights are incandescent bulbs.  While the driver that I made was OK for individual LEDs (about 20 mA), an incandescent bulbs need approximately 200 to 250 mA.  That of course means that the original design will not work to sink that much current.  I’ve sketched out the new design for the drivers, which requires an individual MOSFET for each feature light bulb.  The serial register also needs to have open collector outputs so that the FETs can  be used as high side switches and the existing common ground returns can be reused.  The parts for the new drivers are ordered from Mouser.  I just need to get off my butt and layout the driver cards and order them.  I’m sure that I can fit the design on a 5 cm x 10 cm PCB, so  a single order will give me 20 PCBs.

Onto GenPyCode updates.  The GenPyCode Python project takes the simpleRules.txt file and generates the Python files necessary to run the pinball machine.  This is then run using the PinballFramework to operate the actual machine.  I originally did a lot of the code using Java, but since the Raspberry Pi doesn’t have perfect support for Java, I decided to rewrite it using Python.  Since then, the Python version has been significantly updated and more features added.  I’m now going back and adding the newer features into the simpleRules.txt.  It also adds features for more debuggability.   It currently creates python files for solenoid bits, input bits, and LED bits.  It also creates the constants for the sound files.

Next steps will just be continuing in the same vain.  I’m hoping to finish the wiring on SharpShooter II and then take a video.

Progress 6/20/2014

Haven’t had the time to do an update lately, so here it is.  Started by adding two new categories to the blog.  The first one is Pinball Framework which marks the entries about the Pinball Framework.  I went back and marked the last two posts, but probably won’t mark earlier ones.

So I added a couple more things to the Pinball Framework.  The new additions include image chaining, added ability to set player score display positions, support for non-HD aspect ratios, and new GUI for debugging cards.

Joe asked if the background image could be changed by making a call.  I one upped the request and added in support for image chaining, so now a group of images can be shown on the backglass with a wait in between each image.  At the end of the chain, the chain can be repeated to show the images again.  Chaining simplifies the programming of the backglass images since it happens independently of rules processing.

Player score positions were previous automatically located by the software which only worked for a single layout of the backglass.  Now the displays are located by picking the center point of the display, and the number of pixels for the height of the characters.  This gives much more flexibility.  While in that section of code, support was added for non-HD aspect ratio displays which is needed for the backpack pinball machine.

Last thing I added was a new GUI for displaying the state of the card inputs.  Previously there was a python script that needed to be configured for the card that was being tested.  The new GUI auto discovers the cards attached, and populates them in the GUI.  It then polls each of cards getting the input status.  It also supports kicking an individual solenoid.  A good general debugging tool which might end up being easier for other people to use.  It is located at PinBrdGui in the Google code repository.

While talking to Joe, he also mentioned he wasn’t sure he understood the wiring.  I wrote up a quick diagram of the necessary wiring and how it simplifies the required wiring.  Here’s the quick diagram.  Each of the driver boards support up to eight solenoids, but I only threw four down because I didn’t want the diagram to get too busy.


Now the next new category.  It is called Sharp Shooter 2.  I picked up an old racked out Sharp Shooter 2 playfield and a cabinet for it to go in.  Designed by Roger Sharpe who is one of the gods of pinball.  I hope I can make him proud.  So I was taking an old Camelot playfield and driving that with the driver cards.  There was always a nagging feeling that the project would be finished and the machine would be a dog to play.  Got the SS2 playfield for a good price and it should be a better playing machine than Camelot.

SS2 was originally a Z80 processor based machine.  It was produced by Game Plan which truth be told, I didn’t even know was the name of a pinball manufacturer.  Some information can be found on the internet, but I can’t really figure out the rules, and even so, I’m doubting they were very deep.  So I’m going to drive the playfield with new driver/input cards and add an LCD for a backglass/scoring.  The original playfield was driven with 24 volts.   I’m going to use 48V but make the solenoid pulses short.

Here’s a few quick pictures at the beginning of the project.

SS2Playfield SS2BackPlayfield

There is a set of eleven inserts, so I need at least eleven modes.  Here’s what’s currently in the notebook in no particular order:

  1. Sharp Shooter – some shooter inserts are lit red, some are lit white, if all white are knocked down reset with new group of red and white.  First red hit ends mode.
  2. Hustle & Jive – turn off tilt bob, fill all six upper lanes without allowing flippers to rotate the inlane lights.
  3. Sniper – can only hit blinking shooter target, then next one lights, etc.  Get five to complete mode.
  4. Target practice – blink random pop, then random shooter, then random inlane, spinner orbit, finish with kickout hole.
  5. Check hideouts – must get two standup targets within 60 seconds.
  6. Call the posse – spinner lane ten spins, then kickout hole, starts two ball multiball.
  7. Bar fight – hit each bumper ten times, each time a bumper is hit, it lights for 10% more time.  At ten hits it is constantly on.
  8. Ride for help – 5 orbits, then sink kickout and get two ball multiball.
  9. Sharpe Attack – Get five shooter individual targets, no cradling allowed (reconfigure flippers for no hold)
  10. Killem all – drop all shooter targets three times, sixty sec to drop bank, resets when bank finished
  11. Track the bandits – collect all lanes (can use flippers to rotate), knock down all shooter targets after all lanes collected.

That’s the current thoughts.  I’ll start by simply rewiring the bottom of the playfield for the new driver/input cards.