Jump to content
Due to a large amount of spamers, accounts will now have to be approved by the Admins so please be patient. ×
IGNORED

Resurrecting a pinball machine using arduino.


Recommended Posts

Rebuilding my second pinball using an Arduino. Thought I'd share my successes and set backs.
I'll post progress reports as I go otherwise this will need an index. In real life I've almost finished this but still ongoing.

I started with just the base cabinet of Big Town, a 1978 Playtime machine. Early SS. The back box was missing so no electronics or score display, just a base cabinet. The play field is in excellent condition but I'm confident it is an overlay due to the bonus light covers looking like they are under a clear film. All the working parts under the play field are in good condition and will come up nicely after a clean and service.

b01.thumb.jpg.509d931c2090d13b7974256077d169b0.jpg

b02.thumb.jpg.50c72ab3be071ada4faa926424c657c4.jpg

I'm still only new to the arduino and it's idiosyncrasies so this is also a story of my learning them and hopefully to help others understand them and not spend the time I did sorting out what should work and what doesn't.

The first step was to strip out all the parts and wiring I wasn't going to need mainly to see what I'd need in the way of inputs and outputs on the arduino. He's the board stripped and my LEDs  and wiring added. The only parts replaced on the board were the resistors for the flippers. As for the LEDs, I used 1 single strip of WS7811. It was a strip of 100 and wasn't needing them all so it was easier to leave some in circuit and not use rather than cut the wires and spend hours rejoining them. You can see 3 cable tied to the wire on the right hand edge. A right angle bracket and a cable tie holds them perpendicular to the play field. I did number them after this pic was taken for future reference - I highly recommend that step!

b04.thumb.jpg.23e59e9e65e822f7915bc68fc6b6589a.jpg

Before I could think about building a back box I had to find out if I could even have four score displays. This game only has 6 digits per score so I bought some 7 segment displays as 2 x 3 digits. Of course I couldn't find any in Stralya so went to Aliexpress. Picked some up dirt cheap. The MAX7219 chips came from Jaycar. I built up 6 digits on a vero board along with the MAX7219 chip.

b05.thumb.jpg.1a3651b80db0f9c08148a948bd3b5945.jpg

I know, I didn't need a 100K pot but I wasn't sure of the resistance needed and I had these sitting around the workshop. Bonus is it allows the brightness to be adjusted.

As you can see the MAX7219 is on the wrong side of the board so I have a flat surface on the display side for mounting.

b06.thumb.jpg.51d865e7a49ff56f2ab819b71e7f3558.jpg

I connected it to a MEGA and with some software got it displaying. Good start. I built a second and tried to set up as daisy chained with Data Out going to Data In on the next MAX chip. Absolutely no luck getting it to work. After too much time spent on that I got the shits and modified the code so the displays weren't daisy chained. They used a common clock signal but had different outputs for their data and chip select. This was going to use an extra 6 digital pins so dilema number one - I wasn't going to have enough digital pins for all the rollovers and targets. Only solution I could think of was to use a UNO to control the scoring and a MEGA to control the machine with serial data transfer of the scores between them. I moved the 2 displays to the UNO and tried sending player one and player two scores to it. Short story is I eventually got it working using serial comms via Tx and RX and serial.write(). Encouraged, I built the 3rd and 4th displays plus a 5th one which only had two single digits - credits and balls. Hot tip - you can't upload code to arduinos when they are connected via TX and RX. I found that solution accidentally but did read about it later.

Now this is where I made a mistake - I had this score sending, receiving and displaying working perfectly, UNO to UNO as my test.
I decided to incorporate the sending scores code into the MEGA which was going to control the pinball machine. It had software on it from my first pinball project.

Loaded it up, ran it and started getting garbage on the displays. Via monitor window I could see my Serial.print() statements in the MEGA code were sending unwanted data to the UNO! Researching I found I couldn't use Serial.print() when using serial comms via TX and RX. Bugger. Researching also showed the MEGA has multiple serial TX RX ports so simple solution is to use Serial1.write() for my data sending and use the next pair of tx RX pins. Wrong, supposed to work but buggered if it would work for me. Still getting bad data sent. More research and I discovered wire.h library. Gave it a try and nothing sent, more research and discovered the serial pins are different on the MEGA to the UNO example I was working off. Changed to the SPI and SCL pins on the MEGA and BOOM, had it working MEGA to UNO still with all the Serial.print() statements in place in the MEGA code and no errors. An added bonus is code can be uploaded while they're still connected unlike with using Serial.write().

Beer time.

b07.thumb.jpg.62460f6f56113e107025c221d712abc9.jpg

Now about the data sent. I wanted to keep it simple. None of this send player number, send ball number, send score player etc. I decided to incorporate all that data into one data packet. To send the player number,ball in play, credits and the score I used an array of 10 characters.

Array cell 0 - Player
Array cell 1 - Ball in play
Array cell 2 - Credit

3 to 8  is the score -
Array cell 3 - 100K
Array cell 4 - 10K
Array cell 5 - 1K
Array cell 6 - 100
Array cell 7 - 10
Array cell 8 - 1

Array cell 9 - 48

So Player 2, ball 4, 1 credit and a score of 234500 is sent as 241234500.
48 is the end of data.

At the receiving UNO I parse out the data and send to the displays. One data packet sent, keeping it simple.

They're sent as char so a simple matter of subtracting 48 from the the received cell and boom, you've got your integer value. After the simple conversion from char to integer the rest is simple.

0 to 2 is simple.
The score almost as simple - score = (cell[3]*100000)+(cell[4]+10000)+(cell[5]*1000)+(cell[6]*100)+(cell[7]*10)+cell[8]

Cell[0] (Player) determines the chip select so which display the score is sent to.

Hot tip time  (my learning curve) -

You can't upload to arduinos when they are connected via TX RX and you're using Serial.write().

You can't use Serial.print() when using Serial.write() via TX RX.

The MAX7219 needs a 10uF and 0.01uF cap across the supply voltage close to the chip. This is written in the data sheet but it's on page 10 of 17 so very easy to miss, as I did.

Next time I'll show the building of the back board and installation of the displays.

 

 

b05.jpg

Edited by Maxthecat
  • Like 8
  • Thanks 1
Link to comment
Share on other sites

Great stuff mate. Keep it up! I was talking to someone on the weekend and they asked (keeping in mind I have no idea) is it possible that if this machine has a virtual file for vpin then can you extract that code and use it in Arduino? Probably showing my ignorance with this question...

Link to comment
Share on other sites

34 minutes ago, robm said:

Great stuff mate. Keep it up! I was talking to someone on the weekend and they asked (keeping in mind I have no idea) is it possible that if this machine has a virtual file for vpin then can you extract that code and use it in Arduino? Probably showing my ignorance with this question...

Not on an arduino. I think of them as PLCs rather than a computer.

  • Like 1
Link to comment
Share on other sites

Part 2 - The back box.

Now I had proof of concept on the scoring I started on building the back box. No idea of the size so I went with the dimensions of the last pinball machine I had here. It's a simple MDF box with right angle pine trim around the front. This provided a 5mm lip for the glass to sit up against and not fall out. It's on a small plinth.

b08.thumb.jpg.174830ca4c86591ab3e9aa37eca8dad9.jpg

Ordered glass after measuring 15 times. Turns out it's a perfect fit. 15 times measuring seems to be the way to go. Maybe next time I'll get the glass first then build the box around it. The art work was tricky. All I had to go by was pictures on line. The final product is a patch work of several images found on line and stitched together and many hours on photoshop. There are several changes to the real thing but that's mainly to make my job easier and not go mental. No need to go into changes in detail. I would liked to have the artwork printed in translite but went with the cheaper option of officeworks ($12). The artwork isn't perfect and back lighting would have shown that.

Here it is with the glass sitting over it. The diagonal lines on it are a reflection of the corrugated iron roof above.

b11.thumb.jpg.a787d57bb6954371737444388fee050e.jpg

The glass backing board is 6mm MDF. More careful and multiple measurements of the score display locations and I was confident of cutting out the display holes. I painted black through and around the holes to hide the MDF from the front.

b09.thumb.jpg.c2c1a94e5787345b9856ea9ffaa985d6.jpg

A bit tricky mounting onto 6mm MDF so I built a mounting bracket out of scrap perspex. A flat base, 2 parallel pieces which the arduino sits between and then pieces on top of the parallel pieces but over hanging 1mm or 2mm to the inside. The arduino board simply slides in and stays there. The flat base was double sided taped to the MDF.

b13.thumb.jpg.f1a616db5486daa4ac6fdd06d8788fbc.jpg

All the parts mounted (temporarily for now), you can now see why the MAX7219 chips went on the wrong side of the circuit board.

b16.thumb.jpg.073a8adf6f617f1a852f344f711b5549.jpg

Oh, almost forgot, the red filter over the LEDs! Due to the design I needed something thin. What's thinner than cellophane - nothing. I went to the newsagents and picked up some cellophane for a budget breaking $1. I found 4 layers did the job so taped 4 layers to the backing board over the display openings. You can't tell it's cheap arse $1 cellophane and not transparent red perspex. There's a reflection of me in the pic looking very satisfied with the final product.

b12.thumb.jpg.597febd8d11e2e48e0f959194f76ed79.jpg

 

To be continued . . . . . . . . . .

 

 

b16.jpg

  • Like 8
Link to comment
Share on other sites

Part 3.

Next job was to connect all the targets contacts and rollovers to the MEGA. I used a MEGA shield with terminal strips for a more secure connection. I added plugs and sockets between the contacts/rollovers and the shield so I can remove the MEGA if needed. As mentioned in the opening post I'd wired all the contacts very early on and labeled all the wires as I added them. Saved having to meter each one later to see where it came from. I started at digital input 49 and worked my way back down. The solenoids were also wired earlier. For the system I was using I needed 24VDC going to each solenoid so that was daisy chained between them and a ground wire coming back from each one.

bb19.thumb.jpg.e530192f8baf9913a12bafa68a9372a1.jpg

With wire connections done I ran the code to determine everything was okay. I will eventually provide the code. At this point in time I still haven't 100% finished the project so I'm still doing refinements. The basic idea of the code at this early stage is it sits waiting for the start button to be pressed. When pressed the code loops through looking for a contact to be activated. The inputs are set as active low and when detected a void is called. For testing the code simply adds 1,000 points to the score and Serial.print() prints the name of the contact activated. Once they're all proving to work I change the points scored from the test 1,000 points to the actual game points. Some have no point. I also left the Serial.print() with the name of the contact for now.

Then the fun part starts. Working out the rules then writing the code to reflect the rules. This involves switching off and on LEDs, adding bonuses based on what targets are down, adding an extra ball code, setting variables to reflect all these conditions. Sounds tricky but it's really quite easy but it does take a lot of testing and modifying code so not something done over a weekend! I won't go into detail about the code here. When released it will be well commented and I will answer any queries.

Once I had it working for one player I had to allow for four players. Extra variables added, more code added and more testing done. Eventually got 4 players working and the game stopping after 5 balls.

Now getting back to the back box artwork with the little bastard LED sitting to the left stating 'CREDIT' - I was so tempted to take the easy way out and change 'CREDIT' to 'PLAYER' and get it reprinted but I don't do easy. I decided to add two buttons. One to add credits and another to select the number of players. EG - Add three CREDITs and as the PLAYER button is pressed the CREDIT decrements and LED lights up next to the score windows. I didn't bother to sit down and work out a plan on paper, I just jumped in and started adding code. Big mistake. I spent way too many hours going around in circles, eventually walked away for a while, came back and saw the solution. I had my IF statements outside the SWITCH. Swapped around and magically it started doing what I wanted it to do.

Happy with that I added a 24VDC power supply. Flippers, pop bumper, kicker were all directly connected to the 24VDC and contacts on the board or buttons operated them by supplying a ground. All the coils had a diode added across them for back EMF protection.

The target reset and ball kickout hole and ball release are operated via the arduino. All the solenoids worked when testing with 24VDC except the target resets. I took one target set apart and gave it a thorough clean. Still only 2 targets could be pushed up. I measured the coil and it was 20 Ohms. Something odd here. I found a copy of the schematic on line and found the answer. The target resets had 125VAC to a bridge rectifier going to them. Doing some calculations which I honestly forget while writing this I determined 48VDC will trigger the target reset solenoids. Got another 24VDC PSU, series it up with the current 24VDC PSU, connected to the coil and BOOM, targets reset! Had to make some changes to the solenoid wiring, the target reset solenoids were taken out of the 24VDC daisy chain loop and 48VDC supplied to them.

Dual 24VDC 10 Amp PSUs. Lower supplies 24VDC and the upper adds 24 for a 48VDC supply.

bb20.thumb.jpg.959d88a2f686fb5f4a6f98d426ec68b0.jpg

Software testing was next. Added code to the software to operate a solenoid then checked with the multimeter the arduino was switching the output on and off. Wouldn't want it switching on a solenoid and leaving it on.

Solenoid switching is done by setting the arduino analogue output initially to a LOW state. This keeps the MOSFET off. To activate a solenoid the output is set HIGH. This switches on the MOSFET. A delay() is added to hold the MOSFET on then the output is set back to LOW. The delay ensures the coil operates fully
The resistor network for controlling the MOSFET gates and holding the outputs high is on the scratch pad area of the MEGA shield. Two connectors send the signals off to the MOSFETs.   

bb21.thumb.jpg.12b5c9425b98b1c2b6ccbb9075b3e18f.jpg

I've only used 4 of the possible 10 MOSFET drivers. I can still add 3 x solenoids for chimes and I haven't added the extra ball knocker yet.

I'm still undecided whether to source or build a chime unit or to use MP3s and put the scoring arduino to more use and have it play the music. I've heard the sounds this machine should make and they are shit house. A chime unit is the easiest option. I have the code there from the previous project.

Back box - Black tape is a temporary fix unit I'm sure they don't need to be removed. MOSFETs are extremely temporary on that board! I had them sitting on that board from a previous project. It's so temp that I'm using the fuse in the IEC input unit to fuse the 24VDC. I used the same home made mount for the MEGA as the UNO. 

bb18.thumb.jpg.f6ec204998d11fda4c614555b95d484a.jpg

Built back box attached and working.

bb17.thumb.jpg.5e13f0a532bf20e9a2c2dd756133b4d6.jpg

 

 

 

  • Like 9
Link to comment
Share on other sites

Decision has been made re sound.

The owner of the last machine I restored has kindly let me head over and record the chimes. Recording should be good. The machine is on a remote property in a quiet shed out the back so no back ground noise to pollute the recording. Maybe the odd rooster crowing.

 I'm hoping to send a signal to the UNO which handles the scoring and it can play the recordings.

At this stage no idea how I'm going to achieve it. Willing to listen to and advise.

Link to comment
Share on other sites

2 hours ago, thegrunta666 said:

All I can advise is to drink beer whilst doing it, It honestly helps...Also will you send a serial output from the Arduino to a Mp3 player?. keen to see how this project finishes up, thanks for the posts.

Is there any other way?

  • Like 1
Link to comment
Share on other sites

On 19/09/2021 at 3:36 PM, Maxthecat said:

Decision has been made re sound.

The owner of the last machine I restored has kindly let me head over and record the chimes. Recording should be good. The machine is on a remote property in a quiet shed out the back so no back ground noise to pollute the recording. Maybe the odd rooster crowing.

 I'm hoping to send a signal to the UNO which handles the scoring and it can play the recordings.

At this stage no idea how I'm going to achieve it. Willing to listen to and advise.

Looking at DFPlayer to play the sounds.

Waiting on their arrival.

They're dirt cheap so I bought a few just in case I can play one chime then play another chime on another DFPlayer and I can get the harmonics of two chimes.

Or is that putting to much thought into it?

Link to comment
Share on other sites

those dfplayer modules can be frustrating to deal with, with stuff like ignoring file names and actually playing files (and ordering them) based on the order they were copied onto the SD card. Using multiples will be helpful as well as they can sometimes have inconsistent delays when stopping playback and trying to start a different file. You can get results with them, you just need to keep fighting with them until you figure out what will work best for your project. For furious game play you might want to consider a few modules with the same file set, and use them in a "rolling buffer" kind of way - to get both the harmonics and response times.

Link to comment
Share on other sites

21 hours ago, AskJacob said:

those dfplayer modules can be frustrating to deal with, with stuff like ignoring file names and actually playing files (and ordering them) based on the order they were copied onto the SD card. Using multiples will be helpful as well as they can sometimes have inconsistent delays when stopping playback and trying to start a different file. You can get results with them, you just need to keep fighting with them until you figure out what will work best for your project. For furious game play you might want to consider a few modules with the same file set, and use them in a "rolling buffer" kind of way - to get both the harmonics and response times.

Thanks for the input. So many other aspects of this build have been frustrating so no change there by the sound of it.

Using them as a starting point. If a better methods comes up then I can switch to it.

Link to comment
Share on other sites

Most modules in the cheap end of town I have played with struggle with responsiveness with actual MP3s. The DFPlayer also supports wav files and it was far snappier playing back and controlling them. I am guessing it is because the controllers on board are pretty low spec and take a while to set up the MP3 playback. I recommend trying the uncompressed wav file route - at least until you start putting sound tracks in too 😄

Other tips: When you want to update a file on the SD card, be sure to format it then copy back the files. Deleting or modifying files can fragment the SD card enough to make playback hiccup on these little guys.

Edited by AskJacob
  • Like 1
Link to comment
Share on other sites

2 hours ago, AskJacob said:

Most modules in the cheap end of town I have played with struggle with responsiveness with actual MP3s. The DFPlayer also supports wav files and it was far snappier playing back and controlling them. I am guessing it is because the controllers on board are pretty low spec and take a while to set up the MP3 playback. I recommend trying the uncompressed wav file route - at least until you start putting sound tracks in too 😄

Other tips: When you want to update a file on the SD card, be sure to format it then copy back the files. Deleting or modifying files can fragment the SD card enough to make playback hiccup on these little guys.

I was going to go down the WAV path. Good tip of reformatting.

Link to comment
Share on other sites

  • 2 weeks later...

Good news everybody . . . I have 3 DFPlayer boards playing 3 different chimes!

3 x DFPlayer boards is allowing the 3 chimes to be play simultaneously giving the harmonics and not cutting off one chime to start another.

The speakers are out of a Sega driving cabinet and they were in a tuned boxes so the sound quality is quite good. Will post pics when it's all running.

I now need to incorporate the code into the pinball code and hope it all works.

Wednesday is day 10 of 10 days straight of work and have 7 off from Thursday so plenty of time soon to get the chimes running in the pinball software.

  • Like 2
Link to comment
Share on other sites

  • 2 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...