 |
| Switches, Lamps and Solenoids are all wired up. The playfield is almost ready to go into the cabinet. |
In the picture above, not only are the lights wired up, but so are the solenoids. The playfield is almost complete, ready for installation into the cabinet. I've simply fallen behind on updating the blog.
The only wiring left to complete is the switch and solenoid wiring for the very top eject hole. I won't be able to install the eject hole assembly and switch until the playfield is removed from the rotisserie, so for the moment wiring is complete.
Click on through to see the pictures and video...
 |
| Only 3 wires connect the playfield to the two power supplies and the computer. I can play the playfield in the rotisserie! |
Amazingly, there are only 3 wires that connect to the playfield. The thick black cable provides the 50 volt power. The thin black cable provides both 5 volt and 12 volt power. And the white cable is the USB cable that runs from the PC to the industrial USB hub you see in the picture.
Yes, the playfield is fully playable like this, still installed in the rotisserie, with only 3 cable connections. This has allowed me to fine tune switches and solenoids before the playfield even goes into the cabinet. I've also been able to test and make many enhancements to my software.
 |
| I'm currently testing 4 TVS diodes wired in parallel to protect the LED-Wiz. No failures in 2 weeks of testing. |
In the last post I revealed that a voltage surge had killed the LED-Wiz connected to the Pinball Solenoid Power Driver board, and I was testing TVS diodes to protect the replacement LED-Wiz board. In the last update, I had used a single 68v rated TVS diode, and it had lasted only about an hour. In the picture above, you can see that I have wired four 68v TVS diodes in parallel, which increases their effective power handling. So far, these four diodes have been running flawlessly for over two weeks. I'm actually waiting for one of these diodes to die so I can try the next voltage size up TVS diode, as I want a solution that only requires a single diode and not a bank of multiple diodes. But as long as this current solution works I'll keep it going.
 |
| The top side of the playfield assembly is almost complete as well. Just a few minor details to finish up. |
The top side of the playfield is also almost complete, as seen in this photo. All the reclaimed metal work has been polished and looks shiny and new. I've only got a few small details to address before the playfield is ready to come out of the rotisserie for final assembly on its way to the cabinet.
But you clicked on this post to see some lights, so here's your bone:
 |
| All 80+ lamps are lit up in this photo. It's even better in person. |
The playfield lights look fantastic! My decision to change bulb mounts, and bulbs, was definitely worth it. It's hard to capture just how great the lights look in pictures. The blue lights actually look blue in person, not purple.
I'm disappointed in the brightness of the general illumination lamps, especially under the trim around the edges. I'm thinking of trying out some different LED bulbs that may address the issue.
The pop bumpers would look better with opaque caps - I actually have an original opaque white Firepower cap, but since I only have one I haven't used it. If anyone knows where I can get some opaque white caps, or even better a few more Firepower caps, please let me know.
Since you made it this far, here's a bonus video. Nothing beats seeing the lights in action.
The light sweep is for demonstration purposes only, though it could be used as an attention grabber between games. The software already knows the position of every light on the playfield, and the light sweep is just a simple formula that uses the position data to sequence the lights on and off. In the future I may write some other formulas to perform more dynamic sweeps and other light pattern shows.
It is hard to notice in the video, but the lamps actually ramp up and down in brightness as part of the light sweep. The LED-Wiz command to ramp brightness is processed very slowly by the LED-Wiz hardware, too slow for actual gameplay use, and the vendor even recommends against this method in their SDK documentation. During normal gameplay I use a more efficient command to simply switch the lamps on and off, and the processing is much faster.
Soon I will have video demonstrating the solenoids working. Stay tuned...
That looks amazing! Its good to see those TVS diodes are working as intended as well.
ReplyDeleteI've been looking around at some different power supplies and I'm finding it to be a bit daunting. If you're using 24v solenoids with 3.2ohm ish resistance on the main coil then that's 7.5 max amperage draw from each coil! with a ton of coils I would still only expect about 4 to fire at the same time, and that would be a rare occasion, but that's still 28amps of draw!
What kind of power supply are you using to power this beast? And what all did you have to take into consideration? (Things like.. powering the solenoids and electronics off the same PSU as opposed to using two separate units).
Hi Wil,
ReplyDeleteI've had it on my to-do list to post about the power supplies, though I've been putting it off because it's not the most exciting topic. Since you're looking for the information, I'll go ahead and move power supplies to the front of the queue.
I know exactly where you're stuck, I was struggling with the same problem just a few years back. My math was more beastly than yours: Max 6 simultaneous solenoid firings (two flippers + 4 ball multi-ball) and 50v power. The solenoids I was working with were closer to 4 ohms, so the math was 12.5 amps x 6 solenoids for 75amps of draw! Yikes!
The math just didn't sound reasonable, and I wasn't able to find any published information, so I've had to do all my own hands on research using the biggest 50v transformer I could find (and afford) and I built my own power supply. Here's a few tidbits to tide you over until I publish the full post:
1) The measured resistance of a coil is only useful for identifying bad coils, and somewhat useful for comparing one coil to another. The measured resistance cannot be used in the power formulas, as the resistance of a coil increases dramatically when energized. This same challenge holds true when measuring resistance for LED's (and possibly other components as well). The resistance changes because the electricity flowing through them heats up the coil wires instantly. Your average multimeter cannot measure the resistance of an energized coil/LED without blowing a fuse; I'm not sure that any multimeter can measure this, especially since to energize the coil, you have to put it in a circuit, and now you're measuring the whole circuit, and the measurement signal would be lost in the power supply signal. Instead you have to calculate energized resistance by measuring amperage and voltage. I'll share more on this in my full post.
2) I've never found any technical literature or published formulas to support my following statements, I've only deduced this myself. While I think I'm right, and I have anecdotal evidence to support my claim, I can't guarantee that I am correct. - The current draw is not the same on both sides of your power transformer. Assuming you would be drawing 28amps on the solenoid side of the transformer, doing the math, 28amps x 24volts = 672 watts. On the house line side of the transformer, 672 watts / 115 volts = 5.85amps. My math ignores the inefficiencies of power conversion in the transformer, so I would add 25% back in on the calculated number, and theorize that a 7.5 amp 24v transformer is actually capable of supporting 28amps on the 24v side.
3) The solenoids fire for a much shorter time than you might be expecting. I was expecting 200ms, or 1/5th of a second. In my software I wrote a utility that allowed me to raise and lower the fire time to find the sweet spot, the threshold at which I felt I extracted the full power of the solenoid. Most solenoid assemblies had a sweet spot around 20ms, though the pop bumpers seemed to worked best at 40ms. These short fire times have two implications: 1) it is much much harder to have multiple solenoids firing at the same time, not impossible, but extremely rare; 2) even if the planets aligned and 6 solenoids fired simultaneously, the power draw is not constant but momentary. There seems to be some capacity for the power supply to handle momentary surges. The published power supply specs are for constant draw, not peak surge.
I'll cover all my math, test results and techniques in my power supply post, but I did a quick estimate and I think a 24v 2a power supply will meet your needs. I see them available online for $10 and up, cheap enough for you to get one to play with. My current power supply is a 50v 5a jobber, but I'm currently running it with a 3.15a fuse and haven't had any problems yet, even in many 3-ball multi-ball tests. I have even been thinking of downsizing my power supply.
Hope this helps!
Paul
This reply was a HUGE amount of help and thank you for stepping ahead of your plans to provide me with this information.
DeleteI had completely forgotten that the heat generated by the coil would affect the resistance and the math you provided explaining the amperage draw on the mains fits very well with what I had just recently found in my research (although you made it quite a bit clearer).
It sounds like you're controlling your solenoids using PWM (since you're tweaking the time via software). Is this correct and did you consider the alternative of using the older style of pinball solenoids with two coils (one high resistance kicker coil and one low resistance holding coil)? If you're simply toggling the coil on and off how do you handle "holding" the ball with the flipper so the solenoid wouldn't overheat?
Thanks again for being so active in your blog. I greatly appreciate the time you've taken to share your project and the time you've taken to answer my questions.
As always I'm looking forward to your future posts!
-Wil
Happy to help. Wish someone had been there to help me a few years ago. Though I have convinced myself that by not knowing what I was doing, I've come up with some brand spankin' new ideas...
ReplyDeleteI originally planned to use PWM for the flippers, and also as a game feature to reduce solenoid power until certain power-ups had been scored. I even coded the PWM features in my software. But when I first tested PWM on the flippers, the power supply made a horribly annoying high-pitched warbling/beeping noise. That alone was enough to make we want to ditch PWM. I've heard the same noise in youtube videos demonstrating PWM on diy pinballs, so this is a normal occurrence. Technical limitations of the LED-Wiz was the final blow, however.
When using PWM for things like solenoids, you want to use a Buck Regulator circuit - basically just an inductor and a capacitor - which converts the on/off PWM squareform to a nice, smooth DC power wave. My expectation was that the Buck Regulator might have eliminated the noise, but I never got that far in my testing.
The problem with Buck Regulators is that you need a very high switching frequency, several hundred thousand hertz, or even better megahertz, to keep the size down. The lower the switching frequency, the larger the inductor and capacitor need to be.
The LED-Wiz has a switching frequency of 60 hz... that's painfully slow. The physical size of the buck regulator circuit would have been larger than the flippers themselves! More expensive too!
So I scrapped my plans to use PWM, and for the flippers I'm using the old style dual-coil with an EOS switch. It's cheaper and much less complex, and works perfectly every single time. Not to mention it eliminates programming complex PWM logic. Sometimes the old ways really are better. I know newer Williams pins used dedicated Fliptronics circuits to replace the dual-coil solution, and I can only wonder if it was really worth it.
The fire-time that I mentioned is how long a solenoid is actually ON, not PWM. So the kickers, ball locks, ball savers, ball throwers, and credit knockers are only turned on for 20 ms, 1/50th of a second, before being turned back off. That's all they need to do their job. The pop bumpers I currently have going for twice that time. Sometimes I get a bad throw on the ball thrower solenoid, and while I think I just need to up the fire-time a bit, I went ahead and wrote code to verify the ball throw was successful, and re-throw the ball if it wasn't.
For flippers, I don't actually use a fire-time parameter at all. This means two things: they stay up as long as you hold them, and they also drop immediately when you release them. This is important, as you might barely press the flipper button before changing your mind - if there was a programmed firing time then the flipper would go all the way up before coming back down, but with no fire time they drop immediately, even if they didn't make it to the EOS position yet.
I recently realized that I can still implement the reduced power solenoid mode I originally envisioned, simply by reducing the fire time. So if I wanted the pop bumpers to be weak until the power-up targets were hit, I could chop their firing time in half to 20ms. This would add an extra dimension to the game and make it more challenging and rewarding. The logic is incredibly simple, and could probably be programmed with a couple dozen lines of code. Considering that I have over 5,500 lines of code, a couple dozen is quick and easy!
-Paul
You dont need to PWM the flippers, sort of. I switch mine on for 5ms, and off for 35ms, keeps the up nicely on a 50VDC psu. I fire them on until the EOS hits, and if EOS hits, pulse the 5/35ms while the flipper button is still held down. draws minimal current, and they dont get hot.
ReplyDeletekind of surprised you went so long before testing the high power solenoids! my solenoid board driver was the first thing I designed and tested (with no electrical knowledge! managed to fry a couple of FET driver chips but all is well).
Hi Stu,
ReplyDeleteI understand what you are saying, but I would like to point out that you have effectively PWM'd your flippers by your 5/35ms approach. In PWM terms, that is a 12.5% duty cycle and a 25 Hz switching frequency. No if's, and's or but's, you are using PWM.
The LED-Wiz did the same thing for me, but at a faster 60 Hz. The LED-Wiz solution worked fine in that it held the flipper up without overheating, but the horrible noise that came from the power supply was unsuitable for my admittedly oversensitive ears. And the 60 Hz frequency was just too slow to implement an effective Buck Regulator circuit.
I wonder if you have experienced this power supply noise as well? Perhaps not, as the noise is a harmonic of the switching frequency, and your dramatically lower switching frequency would produce a very different harmonic. The noise probably also has something to do with my specific transformer - if I tap on the transformer with my fingernail, I hear the exact same harmonic noise that bothers me, like the transformer housing is some kind of tinny echo chamber, and the process of using PWM somehow electrically 'taps' the housing from the inside.
I first tested my solenoids about 3 years ago. My latest design is only a few months old, and introduced a massive design overhaul, so from that aspect it may seem as these are my first tests with solenoids.
I'll have a lot to share in the near future - the machine is up and running well, I'm just behind the curve on posting updates. Thanks for stopping by and check in soon!
-Paul
well, PWM to me is like a sin wave, progressive. not so much on/off (but I understand the technical implementation of rapididly shifting on/off timing to get PWM).. but as I said in my first post its "sort of", I dont see it as real PWM, but understand how it could be seen as such.
DeleteThere is a noise, yes, but its no different from my real pins (I have two, a stern + sega, both are the same style of solid state flipper). not like some old EM's, when you held the flipper it was like a sewing machine. I found, most of the noise comes from, holding the flipper too long in the 'off' before powering it on for a few ms again, so you get this noise of the flipper hitting the EOS shank like a tattoo gun.
I like your descriptions of the various noises, it really paints the picture. I don't recall the sewing machine noise of old EM flippers, but perhaps I wasn't paying attention at the time.
DeleteTrue PWM is a square wave, on/off, same as flipping a light switch. With a very high switching frequency, the load behaves as if it is being fed a nice sine wave of a lower voltage, but the signal is actually a square wave. What you are doing is most definitely true PWM.
The Buck Regulator circuit (with an inductor and a capacitor) averages out the peaks and valleys of the square wave, making the output signal resemble a sine wave of a lower voltage.
I never heard any noise from the flippers themselves in my PWM tests, though my duty cycle was much higher than what you're using. While not scientific, I tested various PWM duty cycles by pushing on the flipper with my finger to see if I could get it to fall back down. I found that even with duty cycles in the low 30% range I could still push the flipper back down, but at 37% (equivalent of about 19v on my 50v power supply) it was strong enough to resist a strong push of my finger.
Silly me, back then I had no idea how much force a pinball impact would have released on a flipper, and thinking back I'm sure my finger push was way too light to simulate a pinball.
I'm really surprised your solution is working with only a 12.5% duty cycle. In my tests, that was too low to even keep the flipper up on it's own, much less with a pinball hitting it. Kudos to you for making it work.
It's amazing just how varied our results are. I guess that is one more reason I've become such a huge fan of the older style dual-coil flippers, there's absolutely no guesswork, no coding, no logic, no timing, no PWM noise, no real concerns. Just connect two wires and go. I'm still working through my software, adding features and testing gameplay, and once in a while I've gotten a program hang while the flipper was in the up position, leaving it stuck there for minutes as I reset the software. Had I been using PWM, I think at that time I would be at risk of burning out the flipper. With the mechanical EOS switch directly on the flipper, even a software hang can't hurt these puppies.
The only real issue with dual-coil flippers is keeping the EOS switch clean and healthy, but that was more of a challenge for machines in public venues. For low traffic home use, I truly believe the dual-coil EOS style flipper is the best possible choice.
well my circuit is a 3.3v micro (tested via pic32 and propeller) driving an MCP1407 FET driver that triggers a IRF640 MOSFET. The MOSFET is tied to a 50VDC/10A PSU. I didnt go the holding lug route as I didnt want another voltage running around (I think the holding lug off the top of my head is 9V? on the williams solenoids). As it is now I've got 50VDC for high power solenoids, 24VDC for lower power solenoids, 12VDC for LED GI/Flashers, microcontroller boards ect.)
DeleteMaybe my duty cycle is too short, I did hard push my finger and it felt strong enough, certainly it can hold the ball up, I expect the numbers will be tweaked later on, but its enough to start testing and gave me a baseline.
I do need to work in a watchdog incase the microcontroller gets stuck 'on'.
Greetings Paul,
ReplyDeleteI find your project incredibly interesting to follow. Although I don't quite understand all of the technical end of everything, I am curious about something...
What are your plans to generate the game sounds? I recently bought a Firepower and have been reading up about the game. On Pinwiki.com I discovered that sounds are generated by an analog synth on the sound board. So the sound board is receiving synth parameters from I assume the game ROM and from what I can tell it's monophonic. Only the speech calls are samples contained on the speech board. Was wondering if you plan to sample game sounds from a FP and have your CPU generate triggers for the various sound events in the game? I would also think the samples would playback polyphonic therefore not cutting off the previous sound event as it does in the original game. It would seem that sampling and playing back .WAV files would be much easier that replicating the parameters for an analog synth and getting it sound like the original game.
Just curious. :)
-Steve Ridge
Louisville, KY
Hi Steve,
DeleteThanks for following the build, and that is an excellent question. The solution, with the modern age of computers, is not nearly as hard as you're envisioning.
I've written my own pinball software, named Chameleon Pinball Engine, that runs on a Windows PC, and can be thought of as a configurable pinball ROM emulator. My software plays any available sound files, like wav or mp3 files, just as any regular Window's program can do. At this time I do not have any analog synth capability, though that might make it onto the programming to-do list.
At first, I used the basic built-in capabilities for playing sound files in the Pascal/Delphi language, but I found this to be problematic as it was monophonic (only playing one sound at a time) and multiple sounds would queue up and play out long after the triggering event had occurred.
In researching the problem, I came across a packaged solution named BASS, which is basically just a DLL file that I include as part of my program, and I hand off the sound processing duties to the BASS DLL. BASS allows the sound files to be polyphonic, and I'm not sure if there is a limit to how many simultaneous voices can play, but I haven't noticed any limit. All the sounds play in real-time, and are perfectly overlaid on each other.
Actually, the BASS sound solution is so effective, it has exposed another issue, which for lack of a better term I'll call multi-tapping. Sometimes a switch is incorrectly triggered multiple times in quick succession. Each tap causes the sound to play, and you end up with the same sound file playing multiple times, on top of itself, like an echo chamber. Ultimately I will resolve this with some multi-tap filtering logic in my code, which is something I need to also filter out unnecessary scoring and solenoid firing. For some reason my top Ball Lock is really bad about recording multi-taps, sometimes even without a ball in the lock, though I may have a wiring issue.
My software is designed to be easily configurable, and in my configuration files I simply link a switch or event to one or more sound files. My sound code is not complete, not by a long shot, as I don't have any background soundtrack or start-up sounds, nor a randomizer (at game end, Firepower doesn't play the sound same every time, it randomly plays one of many game over messages). But the core sound functionality is already working well.
As far as actually acquiring the sounds, the Firepower sound files were once posted on the web (and if you know where to look, you can still find them). I'm not sure how the sound files where originally compiled, but I'm fairly certain someone digitally extracted them from the Firepower ROMs.
The hardest part about using the Firepower sound files is figuring out when and where to use them. Most of the file names are vague, and while a couple are easily recognizable, the rest are challenging to identify. I'm actually using stand-in sound files from another famous game for most of the sounds, just to have something to play with, but I do have 'FIRE' and 'POWER' incorporated.
Legally, I wouldn't be allowed to deliver these original Firepower sound files in a commercial product (assuming I one day offer my software to others), but since the software has the capability to play any sound files, it would ultimately be up to the end user to choose their own sound files, original or not. These Firepower sound files are definitely 1980's low-fi, so replacing them with modernized, hi-fi interpretations would be a nice update, and would also eliminate any legal issues.
Thanks again for asking the question, and I hope my answer was sufficient. In the future I'll make a more dedicated post on sound processing.
-Paul
Hi Paul,
ReplyDeleteYour project is very very NICE !!
I'd like to build my custom pinball too but I have some difficulties in electronic field. Could I have your electric schema ?
Thanks
Bye
Fred
Hi Fred,
DeleteThank you!
You're question is a bit broad, I'm not sure what you're referring to by electric schema. Could you be more specific?
-Paul