Hi ya'll.
While building up the willpower needed to repair the pinball machine (both the left bumper and Chipkit) I've got sidetracked somewhat -
I'm building a CNC-machine.
Wait, what?
It actually makes sense thou.
A lot of times I've found myself thinking "if only I had this" or "if only I had that" and quite frankly, it would seriously decrease the time needed to prototype and produce things. Among the first things to be processed would be custom solenoid holders for the pinball machine. I'm planing on making a functional prototype out of MDF board and then use that prototype to cut out a proper machine out of heavy duty wood (or aluminum). The size of the CNC will be large enough to allow a full scale pinball machine to be cut out (one part at a time obviously), but will not be limited to that.
The design is flexible enough to grow in all axises in case it really kicks of and I need to move it to a separate location. But looking around in the apartment there's few things larger than a pinball machine, so I'll most likely be able to cut out any piece of furniture, toy or thingamajig I can think of - especially since the Y-axis is extendable indefinitely.
Another cool thing is that when the mechanic X,Y,Z axis are in place, the actual device can easily be changed into a 3D-printer, pick&place or a laser cutter etc. The driver board I've ordered alongside the motors is already prepared for powering external devices, and should the need arise, driver boards for additional axises can be purchased cheaply on Ebay.
After that, well...I'll be taking orders on stuff to fabricate!
(I'm actually planning on selling both blueprints and actual DIY CNC-machines when done...)
Wednesday, January 23, 2013
Sunday, January 20, 2013
Major Setback, or Sergeant Crap.
I left the USB-cable dangling outside the pinball machine, still connected to the Chipkit MCU.
Then my daughter found it.
And pulled it.
Now I've got to get myself a new Chipkit.
Then my daughter found it.
And pulled it.
Now I've got to get myself a new Chipkit.
Thursday, January 10, 2013
Parts of me...
Thought I'd post a couple of pictures on some of the playfield parts.
 |
| 1) The 'Advance Clock' lane of the upper level. A passage feeds the ball from the top level to the right orbit. |
 |
| 2) The custom habitrail from the upperlevel to the right inlane. It seem to be held up by magic, floating in mid-air... |
Monday, January 7, 2013
Walking backwards into the future...
I have (finally) started to wire up the lights and switches... About time, if I may say so.
The machine is now autonomous in terms of starting a game, loading balls, autolaunching, ball search, multiball etc, so an actual game can be played. Without any rules.
I've begun thinking about the rules and have a basic framework set up, but nothing's programmed yet.
Due to some unfortunate incidents it took a little longer than it should've. But we'll get to that later.
All right,
As I wrote before, the machine is now autonomous.
When inserting a credit and pressing start, or simply pressing start during free play, a game is started.
The game then checks if there's any ball in the shooter lane and launches one in case there's none.
During the initial ball launch a switch hit other than the shooter lane switch is required to properly start the game. In case the game is started and a ball magically falls down the shooter lane, that ball is automatically kicked back into play.
When the drain switch is hit, the bonus sequence starts and the ball is kicked back into the ball-through.
Then another ball is ejected to the shooter lane and the next ball is played. In case there's no game running the drain simply kicks the balls out of the way. This is also the way balls are being loaded into the game after maintenance etc.
In case no switch is hit for a 25 second period a ball search is initiated. All relevant solenoids (and the motorized target bank) are being pulsed three times during seven second windows, stopping at any time if any switch is being hit. In case no switch has been hit after a total of 46 seconds the ball is considered lost and a new ball is autolaunched (or simply ejected, in case that's the preferred option chosen). Should the lost ball somehow return to play, both balls will be lost when either of them drains.
I've experimented with multiball and thought of a simple system -
A total number of balls are being requested by the game and in case there's less than that number of balls, a new balls is autolaunched into play. Great care has been taken in designing it, so that it's non-blocking and allowing for easy gameplay design. In case a ball is drained and the "shoot again" timer is still active, the drained ball doesn't decrement the total ball count requested, causing a new ball to be launched into play.
It's simple and very elegant i.m.h.o.
I will combine this with an additional ball counter so that the game hopefully never looses track of any balls. I need this since it's a 4-ball multiball game and there's a physical lock involved. In case the lock is partly filled and another multiball is launched, one or more balls will be released from the lock. During single ball gameplay and the lock is missing balls, the locking could be restored until the same amount of balls has been locked as before the other multiball - or simply become virtual locks instead.
( Actually, I have a mode that allows you to collect any number of balls to use in multiball, sort of like an unlimited ball save timer until the last collected ball has been drained )
 |
| 1) Wires, wires, wires. And that's not even half of them. The power cables are connected in a network with multiple contact points so that the power always (as in - hopefully) get routed to most switches and lights in case a connection breaks somewhere. I bless the testing mode I've developed which has already helped me tremendously while troubleshooting. |
The machine is now autonomous in terms of starting a game, loading balls, autolaunching, ball search, multiball etc, so an actual game can be played. Without any rules.
I've begun thinking about the rules and have a basic framework set up, but nothing's programmed yet.
Due to some unfortunate incidents it took a little longer than it should've. But we'll get to that later.
All right,
As I wrote before, the machine is now autonomous.
When inserting a credit and pressing start, or simply pressing start during free play, a game is started.
The game then checks if there's any ball in the shooter lane and launches one in case there's none.
During the initial ball launch a switch hit other than the shooter lane switch is required to properly start the game. In case the game is started and a ball magically falls down the shooter lane, that ball is automatically kicked back into play.
When the drain switch is hit, the bonus sequence starts and the ball is kicked back into the ball-through.
Then another ball is ejected to the shooter lane and the next ball is played. In case there's no game running the drain simply kicks the balls out of the way. This is also the way balls are being loaded into the game after maintenance etc.
In case no switch is hit for a 25 second period a ball search is initiated. All relevant solenoids (and the motorized target bank) are being pulsed three times during seven second windows, stopping at any time if any switch is being hit. In case no switch has been hit after a total of 46 seconds the ball is considered lost and a new ball is autolaunched (or simply ejected, in case that's the preferred option chosen). Should the lost ball somehow return to play, both balls will be lost when either of them drains.
I've experimented with multiball and thought of a simple system -
A total number of balls are being requested by the game and in case there's less than that number of balls, a new balls is autolaunched into play. Great care has been taken in designing it, so that it's non-blocking and allowing for easy gameplay design. In case a ball is drained and the "shoot again" timer is still active, the drained ball doesn't decrement the total ball count requested, causing a new ball to be launched into play.
It's simple and very elegant i.m.h.o.
I will combine this with an additional ball counter so that the game hopefully never looses track of any balls. I need this since it's a 4-ball multiball game and there's a physical lock involved. In case the lock is partly filled and another multiball is launched, one or more balls will be released from the lock. During single ball gameplay and the lock is missing balls, the locking could be restored until the same amount of balls has been locked as before the other multiball - or simply become virtual locks instead.
( Actually, I have a mode that allows you to collect any number of balls to use in multiball, sort of like an unlimited ball save timer until the last collected ball has been drained )
The slingshots, VUK's, saucer and bumpers are wired up as well.
But when testing I noticed that something isn't right with the new power-driver board I order last.
For some reason the bumper rigged to that card stopped working - and after a little troubleshooting (to be very modest) I replaced the MOSFET with a spare one and it started working again.
Unfortunately - most of the switches on the right side of the board stopped working. It turns out the shift register that handled those 8 switches had been fried. Once that was fixed everything was good.
For a while.
Then the very same bumper broke down again. This time without killing any switches however, to my great joy. The MOSFET is probably busted thou. The card is a pain to remove so I'll probably won't be doing anything more on it until I need it.
I had the same problem with the magnet a while ago, so I'm thinking the diode might be broken on the bumper and causing a reversed voltage spike to fry the MOSFET, perhaps? In any case - that's five broken MOSFET's on the same card. None of the other cards has had any troubles at all, so I'm leaving my options open on this one.
Subscribe to:
Posts (Atom)