Allentown, here we come, 4/23/2014

One of the goals was to make Allentown this year.  I think there is going to be a great big check mark for that one.  John and I will be attending Allentown on Saturday morning 5/3/2014.  We are planning on being there around opening, and will probably leave in the mid-afternoon.  Just for jokes, I’m going to run a contest which I doubt anyone will win.  Both John and I will be wearing OPP T-shirts.  (They have both both OPP and Open Pinball Project on the front of them).  The contest is that the first person to stop us in Allentown and say, “hey, give me a free T-shirt”, you get a brand spankin’ new shirt out of my backpack.  (They only come in large or extra large so there you are…those are your choices.)  I fully expect that no-one will read this, so it just means that I have 6 more T-shirts that aren’t spoken for yet.  The T-shirts are supposed to arrive by Thursday of next week, so it is even questionable if they are going to get here on time.  Joe (the most prolific pinball contributor) did the concept and the artwork.  I’ll post a picture…when I receive the shirts which I’m really hoping is on Thursday or Friday of next week.  Enough with the free giveaways, and back to the open pinball project.

This week a ton more python code has been written, and I’m hoping to be able to run a simulated pinball game next weekend.  The debug interface in the previous blog post can be used to simulate inputs, and so a complete game should be able to be “played” and rules verified.  It is based on the simplerules.txt which was originally going to be compiled into Java, but has been hand compiled into Python.  (I will go back and write a python converter eventually, which will simply be translating the Java I’ve written into Python.)

The nice part is that the architecture has held up nicely.  I originally was going to simply rewrite simplerules.txt into straight Python without using the architecture.  I quickly found out, that it was even easier to use the existing architecture that I had set up (processing chains, standard function calls, etc).  That made it super easy and rather quick to translate.  I got most of that translated last weekend, and then wrote a lot of the standard functions this week.

So what is the new goal for the short term?  I’m going back to finishing the mini 12″ x 24″ pinball machine.  The new goal is to have it up and running by the York pinball show which is happily in October this year.  I don’t feel like dragging a whole machine down to York, so why not a full featured mini-pinball machine?  The pinball machine should be small enough that I can throw it in my backpack and pull it out and show some people if they are interested.  The “backglass” will be a 17 inch LCD monitor, but the image on the back will probably be a static image with scores overlaid on top of the image.  The machine will be made on my drill press, because I just don’t have enough time to get a CNC up and running.  The monitor will be driven with the Raspberry Pi will contain one solenoid, one input, and one LED driver board.

Next entry should be about getting the processing engine working.

4/12/2014, More Python

So I’ve mostly been working on the debug window for the python interface.  The idea of the debug window is that it allows a person programming the ruleset to see the current state of the pinball machine.  Comms and the rules can be stepped through one loop at a time, and solenoids can be individually fired to test wiring.  Here is a quick picture of the Debug window and what it looks like:

DebugWin

I’m planning on locking the frame size down a little bit better so the display looks more pleasant, but right now just working on getting the functionality.  Here is a quick walk through of the different frames.

Starting with the top most command frame.  It has choice boxes to either run or single step the rules thread and the communications thread.  The rules thread runs the rules for the pinball game.  During play it would add scores for switches being hit, play sounds, change the mode of the game, turn on/off light bulbs, etc.  The communications thread reads the switch inputs from input and solenoid cards and can send commands to solenoid cards to fire a solenoid or change its configuration.  The last box lists the state of the game such as attract mode, game running, multiball mode, etc.  The mode labels are written by whoever writes the ruleset.

Next section has the cards that are in the system.  The rulesData.py file contains a list of cards in the system.  The python script uses the INV_ADDR_LIST to populate the cards.

The input card lists the name for each of the sixteen inputs.  The debug window can simulate input pulses, or toggling the switch open or closed.  It lists the current status of the hardware card.

The next card is a solenoid card, and switch inputs can be simulated.  An additional pulse solenoid button is available to send a pulse to the solenoid to fire it.

The last card uses the NUM_LED_BRDS to list all the LED boards.  It lists the name of each individual bit, and the current status (on or off) is graphically shown.

That is about all that I have gotten finished this week.  Hopefully I’ll add some more stuff during the week, and actually start talking to the hardware cards.

 

Update 3/27/2014, Mostly Python

Finished the conversion of prototype code to the real code.  Wow, it looks much better at this point.  Fixed the organization of the code and much better design.  (Actually the design didn’t change, just the implementation).

Moved from 80s code development into the 2000s.  When the original stuff was written, it was tested by what used to be called printf debugging.  Since my background in Python was basically writing regression tests for scientific/telecomm gear, it worked well enough.  Python was used as a replacement for Expect.  (Doubt if anybody remembers Expect anymore, but once it ruled the serial communication world).  Well, writing python as you would expect really doesn’t do justice to python as a language.  This past week the time was taken to re-organize the code to better match pythonology.  (Yeah, that is a made up word).

Took the time to download PyDev as an IDE.  What a breath of fresh air, as opposed to using print statements to debug.  It took about 15 or 30 minutes to add it to Eclipse and get the project pulled into it.  In the next hour, the code was being improved by leaps and bounds.  Background compiling to look for issues, auto code completion, easy project searches, the features just go on and on.  PyDev has helped progress immensely.

What’s up next?  The screen outputs are done in PyGame, and the debug interface will be in TKinter.  Both exist natively on the Pi.  (Took a while to get both programs to play nice with each other since both of them wanted to own the main loop thread.)  Luckily the TKinter stuff is going to just be a debug interface to help people test their rules.  Next big update will include the debug stuff.

If anyone was foolish enough to grab previous versions of the OPP Pinball Frameword, I would suggest grabbing the latest version.  It is significantly better and has more features.

Update on 3/1/2014

I try to keep most of the stuff in the blog purely technical, but I have little to add technically.  Late winter blues have set in and things have gotten really busy at work.  There was a project that was not going to be delivered on time or meeting the features, and it finally got delivered on Friday on time and budget.  It meant a lot of hours to get it back on track, but now it is done.

Why does this matter to the pinball community?  Simple, they gave me a small thanks bonus which I’m going to use some of it to start buying parts for my CNC router.  I think that the Solsylva 25×25 should meet the needs perfectly.  While it only cuts in a 25×25 areas there are no stops on the y axis, so it should be pretty simple to move the playfield to two different positions to cut the whole length of the playfield.  I’ve been researching CNC routers for about six months or maybe a year, and it seems to match my needs pretty closely.  It is meant to be built from standard parts that you can get at a hardware store.  (That of course doesn’t include the stepper motors, drivers, etc).  The tolerance is reported to be about +/- .003 inches (about the thickness of 2 pieces of paper) which should be good enough for what I need.

Besides that, I’ve mostly been futzing around.  The basement is really too cold to do a lot of work, and since my job was so busy, most of my free time was eaten up there.  I built up a bunch of new boards so that I could finish Camelot, but I have not tried them yet.  They are soldered, but no testing.  I need a 60 cent part from Mouser and I don’t want to pay the shipping.  Grrrrrr.  I ended up buying the parts from Sparkfun since the price per part was cheaper, and the shipping was slightly less.

A few last ideas that are worth exploring down the road.  First one is using a screw drive to open and close the outlanes automatically.  It would involve moving the outline post to make the pinball easier or more difficult during a game.  Right now, in all the games the I know of, outlane posts are in a single position during a game.  Allowing the post to move would allow a game to become more difficult the longer it is played, or a player could be handicapped to make two people of different abilities to “challenge” each other.  Another thing that would be cool is that a route game could be set up as relatively easy.  As players get better (i.e. play longer), the game slowly makes the game tougher and tougher.  Kind of like a progression in replay scores.  Another option is when the game is started to start the scoring at higher values, but the outlanes are more open.  When people play a routed game, if the ball drains very quickly, there is little reason to put more money into the machine.  They feel somewhat cheated.  If the game is set up too easily, the operator doesn’t make money because too many free games are won.  Changing the outlane post position might address both of these issues programmatically.

Second idea is going to be incorporated into Disaster.  That is the Sharpe Attack mode (pun intended).  (Disaster and sharks, what is better than that, maybe a Sharknado?).  The Sharpe Attack is simply getting rid of the hold on the flippers.  Since all of the solenoids are controlled by PWMs, it is very easy to make them stronger, weaker, or even get rid of a part of the cycle and make it so the flippers can’t hold.  The name comes from the fact that if you watch a video of Josh Sharpe playing, (or really any good pinball player), they cradle the ball all the time.  It allows more control over the ball because it is starting at a known velocity, and makes the shots much more repeatable.  During Sharpe Attack, no cradling would be possible because the flipper hold would be set to off (or 0 ms in the config).  That would significantly change the dynamics of a game for a brief time period.

There is another pinball machine idea which I’m working, which will involve a reducing the flipper power during certain modes.  (basically a dreamy, or druggy mode)  Power and strength of any driven signal is easy to control since it is just a PWM and the duty cycle can be altered.

Power supply card tested

Finished testing the power supply card and mounting the power supplies on a piece of plywood.  As mentioned before, it is four PC power supplies connected in series.  The last three power supplies have their grounds floating so that it the end power will be 48V.  The power supplies must be electrically separated since the chassis of the first supply is gnd, 2nd supply is 12V, 3rd supply is 24V, and the last supply chassis is 36V.  I plan on adding a plastic cage over the power supplies to make them a little safer.  The other option would be to take apart the power supplies and try to separate the chassis from the grounds.

If you look at the pictures there are a lot of extra power supply connectors that can be removed.  The main 24 pin connector and the extra motherboard 12V connector are used.

What’s the cost of this monster…

4 PC power supplies (just checked Amazon, and they are $10 each).  Board that ties the power supplies together ($27 and that got me 10 of the boards.  Who knows what I’ll do with the extras.)  Connectors to populate the boards (bought 75 connectors for $24 off ebay).  My total cost was about $100, with plenty of leftovers to make another 5 or 10 of these.

Here are the pictures:  First one shows the four power supplies with 48V on the DMM.  Second picture shows the card dwarfed by all the extra connectors.  Last picture shows the isolating power connector.

superpwr48v pswcard isolatedgnd

Power Supply boards received and updating python scripts

Received the power supply boards today.  (edit:  I didn’t actually post this last week, so the boards came in 1/24.  That is around 3 weeks for the boards manufacture and shipping which is incredible.)   Unfortunately I wasn’t expecting them for another couple of weeks, so I didn’t purchase the mounting brackets to mount the power supplies yet.  The mounting brackets are simple aluminum L’s that then use sheet metal screws to secure the power supplies.  (edit:  I had to hang new curtain rods yesterday and the old hardware can be re-purposed to form the mounting brackets.  Hopefully I will have some time today to screw it together.)  The power supply boards allow four standard PC power supplies to be tied together to form a 48V supply at around 20A.  The board also outputs the power onto a single molex connector so that the power can easily be moved from the bottom of the pinball cabinet to the bottom of the playfield.  That should be more than enough power to power any of the solenoids that I need to on Disaster or even Camelot at this point.  It also has spade connectors for ease of connection.   Since I have 10 of the cards, I can simply use one card to tie all the power supplies together, then a second card under the playfield to connect to the solenoids using the spade connections. In that way, a single connector can easily disconnect the the playfield so that it can be removed.  (No more bundle of 100 wires that needs to be removed).  Here some pictures including the power splitter.   Since the power supply grounds need to float (after the first power supply in series), you have to disconnect the ground pin.  These power supply splitters can be bought anywhere for about $2 or $3 and if you remove the two screws to take it apart, there is a separate piece of copper that connects between the ground pins.  Remove that piece of copper and the power supplies are suddenly floating.  I feel it is a much better solution than modifying the inside of the power supply.

PowerSupplyPwrSplitter

The cards also contained a raspberry pi shield and an RS232 interface card.  When trying to separate the two cards, I destroyed one of the shields.  Arrrgghhh! Luckily I have 9 others.  I learned that when you score the cards to break the apart, you really need to score both sides of the card.  FR4 is really tough stuff.  That annoyed me, but it really didn’t matter.  I don’t have the parts to populate those two cards, so I’ll need to make another order from Mouser to get those parts.  (I also found a band saw with a metal blade at work, so I might use that to separate my cards from now on).

Started rewriting the python sample machine that I wrote a week and a half ago.  The first script was really just proving out the concept and making sure that everything was working properly.  The next version of the script breaks the different functions down into different “modules” to make reading the code a lot easier.

The new version of the script also breaks many of the parts into threads and interfaces.  The threads do the real work.  There is a thread that updates the displays, a thread to communicate with the hardware, and a thread that runs the game rules.  Since these have been separated, it makes sure that if one of the threads takes too much processing, the rest of the threads will continue without slowing down.  (Basically good design practice).  The second part is adding clean interfaces so that if somebody else wanted to write a game ruleset, they would only change one or two of the files, and wouldn’t need to change any of the communication or display python code.  Again, just good design practice.

The prototype code that I did for Joe was really dirty and just proof of concept.  The new code doesn’t do much more, but it is much cleaner.  It is a good example of the difference between prototype code and production code.

Initial Python Mockup done

So traveling over to the repository, the latest version has a python mockup for a pinball machine.   The idea is that there is a translite mounted in front of a monitor.  The translite has cutout areas so that the player’s scores, ball count, credits and current player is displayed.  All of these are in static locations so the translite is just a typical translite.  The simulation automatically scales between a mockup size and the full screen size so testing can be done more easily without having the simulation take the whole screen.

When coding it up, I decided that the monitor also needed to include general illumination fake lights to mock up general illumination behind the translite.  To make it clear, I made the general illumination lights appear like circles so they appear just as if they were 44 or 47 bulbs.  If doing it for real, the general illumination lights could be any shape that would make the most sense behind the translite.  The general illumination lights are turned on and off as a group.

Well if you have general illumination, you also need feature lights to highlight whatever needs to be highlighted in the translite.  You need Santa Claus on the backglass to light up when you pick him up in the Taxi.  The feature lights are triggered off simulated inputs.

I threw in a very simple set of rules which essentially contains a way to add credits to the machine, start a game, and drain the current ball.  Up to four players are supported.  When the game is playing, inputs can be simulated to add score to the active player.

It’s not much of a pinball machine if it doesn’t have sound.  When a game is playing, a background song plays continuously.  Inputs can also be simulated to play sounds on top of the background music.

All of the stuff is written using pygame.  I originally was going to use tkinter, but really wanted to support sound.  It has been “optimized” to only redraw (blit) changes in the screen, so it should run very quickly.  I could have cheesed out and redrawn the whole screen, but who knows how fast the Raspberry Pi will be able to draw to the screen.

This should work on a Raspberry Pi, without installing extra modules.  When I get the power supply boards, and the Pi shield in the next couple of weeks, I will try it out, but I’m not in a rush.  My development environment is very simple on a regular PC, so there is no reason to move onto the actual Pi until later.

It is currently only a simulation, so it doesn’t run the serial commands to interface with the input and solenoid cards.  That’s probably going to be the next step.

Here is a quick rundown of how to run the simulation:

Starting it up, you should see the positions of the player scores, and current player and credits/ball num displays.  The following commands (single key presses) are supported.
‘s’ go to sound mode, ’0′ to ’9′ will then play a sound (there are only about 5 sounds installed.  Used normally to trigger sound files.
‘i’ simulate input mode, ’0′ to ’9′ simulate an input
‘l’ light mode, toggle on/off feature lights, ’0′ to ’9′ simulate an change

Starting a game:
‘c’ add a credit
‘g’ start a game
‘d’ drain the ball

Quick walk through:
Start up the program.  Press the ‘s’ key to get into sound mode.  Press a couple number keys to listen to the sounds.  Next press the ‘l’ key.  (That’s an L)  Press a couple number keys and watch feature “lights” toggle on and off.

Now start a game.  ‘c’ gives a credit, and ‘g’ starts the game.  Background music should be playing.  Press ‘i’ to simulate inputs and add score to the player 1.  Press ‘d’ to drain the ball.  Notice the ball num going up.  (it is assume that the translite will have text indicating to the player which window is the ball num/credits and which window is the current player)  Drain enough balls (3) and the game is over.  The background music should stop.  Press ‘esc’ to leave

There is a batch file in the directory that automatically sets the right parameters on a Windows machine.  The command line is:

c:\Python27\python.exe startpin.py -port=COM1 -simWidth=854 -actualWidth=1366 -debug

Here is a quick screenshot of the simulation.

PinballFramework