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

 

Rockin In 2014

Welcome to 2014 and it looks like it is going to be a very interesting year.  Many new things will be happening this year at the OPP, and I predict the starting of a serious shake-up in the pinball industry.  This year is definitely going to be fun!

People like to make resolutions at the end of the year, so here they are for the OPP:

  1. Have a Logo created
  2. Visit at least one show (Allentown or York, and maybe hit both) and bring a prototype.  (Best case, it is going to be a working white wood with almost no rules, worst case, it is going to be the EM converted to solid state using the driver/input cards)

Everybody needs a logo, and the OPP is but one of them.  As mentioned so many times before, I have no artistic talent.  ZERO.  I’ve reached out to my one contact, but nothing has come of it.  If you are foolish enough to be reading this, and have some small thread of artistic talent, send me an email.

mail

Enough with the begging.  On to the technical stuff, which is really where all the fun is located.

The power supply board is completed.  The design will be checked into the Google code repository in the next couple of days.  The board manufacturer is on vacation until 1/6/2014 so some extra days can be spent verifying the design.

Since the board is 10 cm x 10 cm, the extra unused space is being used for a respin of the RS232 interface card so that the communication connector matches all the other connectors in the system.

The last piece of the card is a custom Raspberry Pi shield.  That card contains the Raspberry Pi header, voltage translator, a MOSFET so the Pi can turn on and off the power supply, and all of the connectors necessary to interface with a complete system.  I continue to believe that the Raspberry Pi is going to be my best option.  I love the HD streaming video, and hey, I already have one.  My friend is trying to talk me into switching, but I haven’t found any good reason to consider another platform at this moment.  When I get the Pi shield, it will be more difficult to switch to a different card.

The Pi is going to provide the SPI interface (LED drivers), UART (a COM port running at logic levels instead of RS232 levels) and single GPIO bits for stuff such as turning on/off the power supply.  There are standard connectors for the solenoid drivers, input drivers and LED driver boards.  There are also spade terminals to provide the higher current voltages such as powering the LEDs for lighting.

There is a bug in the current version of the LED driver board.  It is rather simple to fix it using a cut and a jumper, but the first hard bug in a design is always disappointing.  That board was done very quickly and is the easiest of all the boards, which seems to make it most likely to have a bug.  I’ve re-thought the strategy of that card, and will change the connector so that a single control line can turn off all the LEDs at once.  It will make “blanking” all the lights that much simpler.

Kicad has been updated to a newer version, so many of the design files are also being updated.  As a stretch goal, generic part numbers will be added to all the designs with a python look up script to make ordering assemblies that much easier.  Doubtful that this will be completed before the check-in of the boards.

I noticed some of the headers have pin 1 on the left side of the connector and other have pin 1 on the right side of the connector.  I’m pretty vigilant in making sure I don’t mess stuff like that up.  I finally went through the documentation between Molex and TE Connectivity and they pin out their connectors in opposite directions.  Super annoying.  It means that when I build up boards, I have to make sure that I use an assembly picture to make sure all the connectors are rotated properly.  I added pictures of populated boards to the interface document, and that is the safest way to make sure they are correct.  Here is a link to  the current version of the interface document.  Wiring diagrams were also added to make wiring solenoids and inputs a little bit easier.

That’s all for right now.