Half Scale Pinball

• Building a Test Stand | Half Scale Pinball
• A fiberoptic DMD?! | Half Scale Pinball
• Ball Trough | Half Scale Pinball
• Ball Ejector Testing | Half Scale Pinball
• Return Lane | Half Scale Pinball
• Slingshots | Half Scale Pinball
• Testing Inductive Probes | Half Scale Pinball
• Half Scale Pinball

Building a Test Stand | Half Scale Pinball

On my way to a playable machine

These past months, I’ve been working to get the lower-third of the machine in a playable state so I can finally playtest. Thankfully, I’m nearly done as all I have left is the redesign of the flipper mech. The only problem is I didn’t have a way of propping the playfield at the correct angle or holding its sidewalls in place.

With full size machines, the playfield dimensions are at least somewhat standardized so you can borrow a cabinet from another machine or build your own from plans online but I’m not making a standard playfield. I do intend to build a cabinet for my machine but my playfield dimensions could still change so I don’t want to waste the time or money on the cabinet. Instead, I wanted to build something adjustable.

Aluminum extrusion FTW

I figured my best option was to build the test stand from aluminum extrusion. It’s relatively cheap, available precut, and reusable. I spent a few days in CAD and came up with this design.

Now, extrusion isn’t a precision component. The beams can be warped and bowed (they are after all the product of forcing molten aluminum through a die). Thing is, even if the extrusions were perfect, there’s no guarantee my table or floor are. To compensate for that, the playfield is resting on four adjustable carriages for levelling.

Assembly

Assembly went smoothly for the most part but there was one unforeseen problem. For the extrusions supporting the playfield, there are plenty of plates and brackets designed to join extrusions whose channels are parallel but I couldn’t find anything meant to join extrusions with perpendicular channels. What do I mean? Well take a look at these renders.

Now, you wouldn’t normally join extrusions like this; however, joining them the normal way would require cutting them to exact sizes and defeat the purpose of the stand. Joining them this way allows for excess extrusion so I can slide the joints closer/further apart to accomidate the playfield.

But wait, what about those little corner brackets in the picture? Well, there in lies the problem. You see, those brackets actually have little tabs on bottom meant to align them with the channel. Unfortunately, those tabs are spaced too far apart to fit in the channel sideways so for one of the perpendicular extrusions it’s not actually making contact with the flat part of the bracket.

While this does affect how precise the joint angles are, that isn’t really the biggest problem here. What I soon discovered was these tabs dig into the sides of the extrusion and effectively lock it in place even when you loosen the bolts. This makes it much more fiddly to adjust the dimensions of the stand than I had intended.

I’ve since thought of a few other ways I could have constructed the stand to avoid this but it’s good enough for now that I’m fine with it as is. Also note, I did find some different brackets that don’t have the alignment tabs; although, they may not work for this application since they are designed to attach from the ends not the channels.

If you get nothing else from this post, just take this as a word of caution in case you plan on building something out of aluminum extrusion as well. Hackaday has a great article on how to properly join and constrain extrusions if you’re interested.

Playfield

You may have already noticed the fancy new lasercut playfield. It’s a bit barren and this is far from a final layout (I don’t even know yet if I’ll be using the standard “Italian” design) but it will at least let me mount all the mechs I’ve designed for testing.

A fiberoptic DMD?! | Half Scale Pinball

…but why

You, being a sane and reasonable individual, are probably wondering how I could possibly think it was a good idea to build a fiberoptic panel for my pinball machine’s DMD. Frankly, I don’t even have a great answer to that so I’m going to mix things up this post and just present this whole ordeal in the order of events that led me here. I realize I went pretty far off the rails with this one so bear with me.

Design requirements

This all started when I got thinking what kind of display I wanted for the machine. While pinball has used many display types over the years, I wanted a display capable of showing bitmap animations which left me with two options: a dot-matrix display (DMD) or an OLED/LCD screen.

System Shock is fairly low resolution by modern standards so I felt the look of larger pixels would suit it better and while I knew it was possible to emulate the look of a DMD on a screen, I still preferred the look of a real DMD’s rounded pixels. So problem solved, right? Just buy a small DMD and… this is where things started to get messy.

Most pinball DMDs have an aspect ratio of 4:1 with a resolution of 128x32 pixels. Modern DMDs are typically constructed from two 64x32 pixel modules commonly used for digital signage. Unfortunately, these off-the-shelf modules are not, to my knowledge, available in pitches less than 2mm (pitch being the center-to-center distance of each pixel). That may seem small on paper but consider that a 128x32 display with a 2mm pitch would still be 256mmx64mm (~10"x2.5"). Again, that may seem small but my entire backbox is only 14" wide and I still have to fit speakers on either side of the display. Not to mention a full size display is just 320mmx80mm (~12.6x3.1") so it’s not even that much smaller. Clearly, I needed to find a better solution.

Half resolution panel

The “obvious” next question was: since everything else on the machine is half-scale, why not halve the DMD resolution as well? On paper, this solved a lot of problems since a display with exactly half the resolution would fit perfectly in a half-scale backbox; however, as is often the case, ideas that sound good on paper don’t always work so well in practice.

The fundamental problem with this approach is that a pinball’s DMD already has a soul-crushingly small resolution of just 128x32. Aurich on Pinside already did a great job explaining why this resolution is so limiting so I won’t rant about it here but just looking at the image below should make it clear just how little information you can fit in this resolution with any semblance of theming.

Now halve that already small display to just 64x16 (a resolution barely larger than some Tamagotchi models) and you’re left with something unusable for the kinds of animations I want (more on those later).

Custom panels

If I had to pick a moment where things really started to spiral out of control, it would be here. Hellbent on not using a screen, this is where I checked my sanity at the door and started down the path of building a custom DMD.

8x8 matrices

The first idea that came to mind was to buy a bunch of 8x8 pixel matrices and arrange them into a custom display. The problems with this approach became apparent right away though as I couldn’t find anybody selling these matrices in a size anywhere near small enough. Just using the bog-standard size, I would only be able to achieve a resolution of 32x8.

Through-hole matrix

Since prebuilt panels were too big, I figured I could just wire up a panel from scratch using through-hole LEDs. I had seen a video a while back from Ben Heck about the custom DMD he built for his Bill Paxton machine which gave me confidence this would work; however, I soon learned the smallest through-hole LEDs I could get (1.8mm) were still too big. Upon re-watching Ben’s video, I also realized his matrix wasn’t the full resolution so I lost confidence that I’d even be able to wire a full resolution display manually.

Surface-mount matrix

Since through-hole LEDs were too big, I turned my attention to SMD LEDs. There are a few different sizes of SMD LEDs but the smallest I could find were so called “NanoPoint LEDs” at a size of just 0.65mmx0.35mm. But wait, didn’t I just say I couldn’t manually solder the 4096 LEDs my panel would require? Yes; however, my plan was to have the LEDs pre-installed on a custom PCB through a service like PCBWay. That is at least until I totaled up the cost. The LEDs alone would be over $500 plus another $300-400 for automated assembly. I’m not opposed to shelling out money for this project but nearly $1k for a display is just wasteful!

Cost wasn’t even the main issue with this approach. Regardless of LED size, there are still physical limits on how close I can pack them on a PCB and still be able to route their power and ground traces. There may have been a way to make it work but I don’t have the PCB design experience (or any for that matter) to pull it off.

Fiberoptics

Of all the issues I mentioned above, one problem was common to them all: the physical limitation of how closely LEDs can be packed together. This got me thinking… if I can’t fit the LEDs any tighter, could I instead route the light from a larger panel to a smaller display? I briefly considered using lenses but that idea was soon squashed by another: fiberoptics.

I did some quick searching to see if anyone else had attempted something similar and sure enough two others had already uploaded videos of their designs: elliotmade and Dr. Tõnis Gadgets. With that validation, this seemed like a good idea; however, I couldn’t decide on how to build the display. My two thoughts were to either use a larger diameter filament and simply pack the filaments together for larger pixels or to use a smaller diameter filament and build a grid to space the dots out (like what the YouTubers had done). For testing, I decided to use one of the 8x8 matrices I bought earlier to prototype each approach.

Packed filaments

My plan for the “packed filament” approach was to build a square frame which would hold the filaments tightly together. I hoped the filaments would naturally arrange themselves into an 8x8 grid if there was no free space to go anywhere else. I was concerned some filaments, particularly in the middle of the matrix, would end up closer or further back and thus darker than others so I also built a bezel which would hold a thin piece of polycarbonate to the frame acting both as a display surface and a hard stop to push the filaments to. For this test, I chose to use 1.5mm filament as this was the largest I could go without a 128x32 display becoming too big.

On the LED side, I simply created a part which would snap onto the 8x8 matrix and allow the fibers to be press-fit into holes over each LED. I wanted to ensure the light from one LED couldn’t travel to a different fiber so I designed the part to fit flush against the panel but recess the fibers back to minimize light polution.

Unfortunately, the problems with this design were severe enough I couldn’t even test it. Right away, I found the filament did not fit into the frame I designed. I thought at first the filament was either larger than advertised or my printer undersized the part; however, neither of these were the problem. The issue turned out to be the filament, which hard been shipped as a roll, was trying to remain curved and thus taking up more space. I found I could just barely fit the filaments into the frame if I applied enough force but in doing so the filaments were not aligning into a grid like I had hoped and were instead forcing the frame apart leaving gaps in the display.

I probably could fix this with enough time and patience but seeing as how I was already encountering issues in an 8x8 display, I felt it best not to attempt with a larger panel.

Spaced filaments

For my second test, I borrowed most of the design from the previous experiment but changed the frame to be a solid piece with a grid of holes. I used 1mm filament for this test and initially designed the part with a hole pitch of 1.5mm to result in the same size display as the previous experiment.

This didn’t work out as planned either though. My printer has a 0.4mm nozzle and despite my best efforts there just wasn’t any way I could slice the part and have it come out correctly at this resolution.

In desperation, I tried increasing the hole pitch to 1.9mm and reducing the final resolution to only 100x25 dots to maintain a similar size. Thankfully, this did slice without error but my problems weren’t over yet. The holes in the frame came out inconsistent. Some were too large and others too small. Rather than spend an eternity tweaking the hole sizes and slicer settings, I felt it would be best to just drill out all the holes to 1.5mm and glue the filaments in place.

This was a mistake.

It took me four days of gluing to finally complete the display. Not only did I have to wait a couple hours between each row to allow the glue to dry (accelerant couldn’t reach the glue inside the holes) but it took ages to find which filament needed to go where. I knew I didn’t technically need to line the filaments up on the DMD and display sides since any mismatch could be corrected in software but I’m not a fan of fixing hardware problems in software.

The final assembly was done and to my delight it actually worked quite well save for two problems. The first being some filaments pulled out slightly from the frame while drying resulting in a few pixels which are noticeably darker than others. This could probably have been fixed with more QC but the second problem was more fundamental.

I had completely overlooked that a bundle of the filament would no longer be flexible so the two ends of the display could not be moved. What’s more, the curve of the filaments forced the assembly to contort into a curve as well making it much harder to work with. Like most issues I described, there is almost certainly a way to get around this in the final machine but at this point I was exhausted, defeated, and was frankly bored of this who endeavor.

Compromise

While none of the approaches I tested worked, I don’t feel the time was wasted. I learned a fair bit along the way and I’m sure I can find some other uses for the fiberoptics in the future. That said, I still need a display.

I decided to finally do the reasonable thing and resolve to just use an OLED panel but I still wasn’t happy with how how emulated DMDs look. I got to thinking though… what if I had the display render square pixels and just put a mask over the screen to make them round.

Frankly, I’m embarrassed I didn’t think of this sooner. It seems so obvious in hindsight. I thought at first the mask layer might be hard to manufacture given the hole size and spacing but I got an online quote to machine it from metal for around $350. That’s certainly not cheap but it’s not completely unreasonable either. I do have a couple other ideas though. I figure I could try with vinyl; although, I worry it will be difficult to apply without distorting. I’m also curious if a blank PCB would work given PCB routing is typically very precise and quite cheap.

256x64 panel

That just leaves one last problem, the OLED panel.

I’m usually skeptical of panels advertised for use with Arduino and Raspberry PI boards as they’re often controlled via slow interfaces that limit the refresh rate; however, I did find a 256x64px OLED panel with options for a parallel interface and even natively supports 16 levels of greyscale per-pixel (though I only plan to use 4).

Like the other pre-made displays I mentioned earlier in this post, the only problem with this model is it’s size… except in this case it’s a bit too small. The pixels of this display are only 0.53mm so the entire display is just ~135x34mm (~5.3"x1.3"). That’s a fair bit smaller than the 160mmx40mm (~6.3"x1.6") of a true half-scale display and the 192mmx48mm (~7.5"x1.9") size I was aiming for with the fiberoptic panels. Even with the speakers on either side, I think this panel would look a bit too small; although, I may get one to try out anyways.

High resolution panel

Another option would be to just buy a replacement panel for a phone, tablet, or similar and find a controller to drive it. I believe this would be the cheapest option by far given mobile displays are a commodity; however, finding one wide enough to fill out the space without being too tall will be a challenge. There is also no guarantee that I’ll be able to find a display driver capable of running it.

With some searching, I eventually found another promising option. 8.8" (~223mm) 1920x480 displays are apparently common in automotive applications and you can even buy some that natively accept HDMI. Size is once again a problem here though as the 217mmx54mm (8.5"x2.1") area is a bit bigger than I’d like. I could hide the extra pixels behind the bezel but it encroaches on the speakers at that point.

Animation sneak peek

Ultimately, I’m going to put more display testing aside for a bit and focus on other parts of the machine. That said, I want to leave you with some ideas I’ve been working on for potential DMD animations.

Disclaimer: None of these images are final. I don’t claim to be great with pixel art so I may even commission someone to remake them later.

TriOptimum Logo

The TriOptimum logo I’ve shown throughout this post is meant to be part of the attract mode. My intent is to periodically play a DMD-rendition of System Shock’s opening video. The green text of the hacker’s laptop is a big part of the reason I want a green DMD.

Fonts

System Shock makes use of several different fonts; however, my favorite is the retro-futuristic font, StopD, used to label each floor of the station. I plan on using this font for any large text in the game. Interestingly, System Shock uses a customized variant of the font (or perhaps an older version) as some letters differ slightly (for example, the Y). For this reason, I’ve gone through screenshots of the game painstakingly re-creating their version of the font pixel-by-pixel.

SHODAN

One of the creepiest occurrences in the original System Shock is how SHODAN’s face will periodically fade into view on displays showing static. I’ve always loved that detail and thought it would be cool if I could do something similar on the DMD. I think the effect works best when the player just barely catches it so my plan is to have the face rarely fade in behind the player’s score but dissappear before they have a chance to get a good look at it.

CAD Files

By the way, I’ve published STLs to Printables and the CAD to GitHub if you really want to try making one of these fiberoptic displays as well; although, I really can’t recommend it for anything more than an experiment.

Ball Trough | Half Scale Pinball

It’s working! (finally)

I know it’s been a while since my last post but I have a good reason… Borderlands 2 is a lot longer than I remembered. No but seriously I’ve actually made a lot good progress since my last post and now have a working ball trough, ejector, and auto-plunger to show for it.

My hope was to complete prototypes of the ball trough, slingshots, flippers, auto-plunger, and lanes so that my next post could feature them all working together. Obviously, that didn’t happen. I kept running into problems here and there that pushed a full test out. A few of the problems still aren’t fully resolved but I felt it was best to show what I have now before waiting for everything to be final.

So what problems remain? I’m sure you didn’t ask but I’m going to tell you anyways:

1. The current flipper design is bulky and likely to fall apart after moderate use
2. The auto-plunger needs to operate at 24v which means I need to redesign the flippers to work at that voltage as well
3. I designed for lane walls that were only 1/8" thick and I’m realizing now they’re too thin to screw into from the edge for mounting

I’ll talk more about those issues toward the end but for now let’s think positive and talk about that fancy new ball trough.

Design process

This is actually the third iteration of the ball trough design. The original plan was to model the ball trough and ejector as one piece but make the ejector chute/scoop a separate component. I eventually realized there was no reason the two components couldn’t be combined for easier assembly.

I also revised the playfield mounts in the second and third revisions. The first revision had heat-set inserts pressed into the top with the intent being to bolt into them through the playfield. While this would have worked at first, I was concerned the heat-sets would work their way out over time. This wouldn’t have been a concern if I had pressed the heat-sets in from the bottom of the part but there was no easy way to do that without compromising functionality. An easier fix was to just switch which side had the nut and which had the bolt. The new design features T-slots allowing four M3 hex bolts to be held captive in the assembly. The threads of these bolts pass through the playfield from the bottom and the whole assembly is secured from the other side using washers and lock nuts.

That’s not to say heat-sets have no place in this design though. The final revision added heat-sets to one half of the assembly and counterbores to the other allowing the two halves to be bolted together more securely and without protrusions on either side. This was done to give me more clearance for the circuit boards later (more on that in a bit). During final assembly I intend to use thread locker on the heat-sets to ensure the bolts can’t back out from vibration (being careful of course to not get any on the plastic).

Updated solenoid

Something that may not be obvious from the pictures is I’m no longer using the McMaster-Carr 70155K121 solenoid I tested back in February. While the 70155K121 was strong and much smaller than the first solenoid I tested, I managed to overlook one critical detail. The plunger on that solenoid was so long that it would have stuck out the bottom of the machine by half an inch.

Let this be a lesson to check dimensions in CAD before committing to a design 🤦‍♂️

Silly mistakes aside, the ball ejector is now using the much cheaper T Tulead ADD06190484. I don’t know why I never thought to check Amazon for solenoids before but this model is cheaper, stronger, and smaller than any solenoid I previously tested. At only 12v, this model is perfectly capable of ejecting balls from the trough even when all 5 balls are loaded or when two become jammed in the ejector chute.

Speaking of jams…

Just like it’s larger counterparts, my design uses five pairs of infrared LEDs and photoelectric diodes to detect how many balls are currently in the trough. The LED and diode pairs form an invisible beam at each ball position that is broken when a ball sits between them. The software simply needs to count how many photodiodes are blocked to determine how many balls are in reserve.

If a ball ever fails to eject or otherwise falls back into the chute, there is a good chance that it will become stacked on the next ball in the trough. An additional LED/diode pair is placed in the ejector chute to detect this condition. When this photodiode is blocked for more than a few hundred milliseconds, the software knows a malfunction has occurred and can either attempt to unjam itself or enter maintenance mode.

For the moment, I’m just hooking up jumper wires to the sensor pairs for testing. I would have liked to use proto-board; however, the LEDs are spaced 5/8" apart (the ball diameter) so the spacing doesn’t quite line up for standard pitch PCBs. Once the machine is nearing completion, I’ll send off for custom PCBs; additionally, I’ll add holes to the model for M2 heat-sets to mount the boards to.

WIP Auto-plunger

I created a rough working prototype of the auto-plunger but there is one big issue with the design. The kicker arm is only attached to the solenoid plunger using an M2 nut and bolt. While I could make the nut captive, the bolt will likely still become loose over time. I’d like to use a clevis pin instead; however, the smallest clevis pin I can find is 3mm in diameter but the hole in the plunger is closer to 2.8mm. I could try widening the hole but I’d rather just find a new solenoid model that’s more compatible and potentially smaller.

One thing I like about this design and have started incorporating into other mechs is how the solenoid is mounted. Screwing into the solenoid through the bracket does make replacing the solenoid more difficult but it makes for a much more stable mount. As an additional bonus, having the bolts held captive between the playfield and bracket ensures they can never work themselves loose even without thread locker.

If you’re familiar with how auto-plungers are designed for full-size machines you may have noticed there is no room for a kicker ball sensor with the solenoid mounted directly under the playfield. I didn’t have room on the right side of the shooter lane for an optical sensor either and I’d like to avoid capacitive sensors as I don’t like the look of sensor plates or conductive tape. I also considered making the kicker arm out of two insulated conductive plates and using the ball to complete a circuit between them but I decided to avoid custom metal parts for the moment. Ultimately, I’ve chosen to just use an inductive probe. Beneath the apron is a LJ8A3-2-Z/BY probe that pokes through the left shooter lane. With correct placement, I’ve found this probe to be very reliable at detecting when the ball settles on the kicker arm.

Revisiting the flipper

I’ve had a working flipper design since before I started this blog; however, experience designing other mechs and changes to the machine as a whole have made me rethink this design. For starters, the current design is unnecessarily bulky. This is largely due to the body being interchangeable between the right and left flipper assemblies; however, part of the bulk is due to the solenoid being mounted sideways and could be trimmed down by using the same mounting technique as the auto-plunger.

Parts availability and tooling is also somewhat of an issue. It’s not pictured above but the flipper bat and crank are reinforced by a 4mmx4mmx50mm shaft made of steel bar stock. The only 4mm bar stock I could find was made of hardened tool steel and wasn’t available in the length I needed. I was able to cut one shaft down to size with great difficulty but that’s not an endeavor I ever want to repeat. I’m currently investigating the options Misumi has for ordering custom rotary shafts as they look to have all the features I need (albeit at an eyewatering price).

Similar to my concern with the auto-plunger, I’m not happy with the linkage being attached using M2 nuts and bolts. Unlike the auto-plunger, the nut and bolt head are held captive; however, they do still become loose after a few shots. Switching to clevis pins should solve this issue but requires that I use a solenoid with a wide-enough hole to accommodate the pins I have in addition to making the linkage parts wider.

I also want to remove the skate bearing for simplicity sake. The bearing serves two purposes in the current design 1) to stabilize the crank shaft and 2) to prevent the crank body from sliding off the steel bar running through it. I don’t think I actually need the bearing to stabilize the shaft given it is already constrained by a fairly long precision PTFE bushing in the playfield; furthermore, the crank sliding off shouldn’t be a problem if I add a set screw.

This design isn’t all bad though. I was initially very worried that I wouldn’t be able to find flipper rubber in the right size or with many color options. As luck would have it, “Grifiti Band Joe” silicone bands ended up being the perfect size and came in several different colors. Newer prints of the flipper also include a rubber backstop to prevent damage to the linkage when the flipper resets.

Next steps

Once the flipper redesign is complete I’ll send off for a laser-cut playfield for an integration test. I also need to replace the relays in my prototype with MOSFETs so I can PWM the coils.

Just to level-set, all that’s a bit of a ways off though as I’m working on some upgrades to my 3D printer to support ABS printing and those upgrades will have it out of commission for a time. I also want the first full integration test to be well recorded so I’ll be spending longer than usual on its video.

Ball Ejector Testing | Half Scale Pinball

Ball trough design

On most pinball machines, a mechanism called the ball trough stores the balls not currently in play. Balls enter the trough through the playfield drain and are returned to play via a mechanism that ejects them back up to the shooter lane. There are several different styles of ball trough but I’ve decided to use the more modern design that requires only a single solenoid (pictured below).

I like this design for two reasons: it’s dead simple and leaves more space above the playfield under the apron which I plan on using for a special feature I’ll talk about more in a future post. The main drawback to this approach is it takes considerably more space under the playfield due to the solenoid placement and the fact that most push solenoids have plungers that extend fairly far out the back.

Solenoid testing

Given the limited space inside my pinball machine, I wanted to see just how big of a solenoid was required to eject the ball. To test the solenoids, I built a scoop roughly as tall as that needed in the final design and brackets to attach each solenoid to it. I ran each solenoid at an increasingly higher voltage starting at 12v until it was capable of ejecting a 5/8" (~15.87mm) ball with reasonable force.

Guardian Electric A422-064104-04

The first solenoid I tested was the Guardian Electric A422-064104-04. This thing is a chungus but I picked it because I thought I would need at least a 1" (25mm) stroke length to get the ball up the chute (spoilers: I didn’t). I should also note that up to this point, I had been buying all my solenoids exclusively from Allied Electronics & Automation because they seemed to carry more models than other suppliers. In hindsight, this was a mistake as their stock mostly caters to industrial applications not as constrained by size.

While the solenoid did work, I had to run it at 18v to eject the ball with reasonable force and its size wasn’t even the worst of its problems. It’s expensive, awkward to mount, and heavy. I mean really heavy. I was genuinely concerned mounting it under the playfield without supports would cause the surface to bow. This is what finally pushed me to check other suppliers for smaller models.

Something I’m only just realizing as I type this is I accidentally bought the continuous duty version of this solenoid when I really should have bought the intermittent duty variant (the A422-064104-03). Intermittent duty solenoids are generally stronger than their continuous duty counterparts given the former is allowed time to cool between uses and can therefore pass more current. Ultimately, I don’t believe this would have changed my opinion of this series though given they’re still too large.

McMaster-Carr 70155K112

The second solenoid I tested was the McMaster-Carr 70155K112. This model is what I ultimately decided to use in my design and for good reason. At only 12v and with a 1/2" (12.7mm) stroke length, this solenoid was capable of ejecting the ball with no issues. The benefits don’t stop there either. It’s lightweight, short, easy to mount, comes with a return spring, and includes a second plunger type.

This model does cost an eye-watering $40 per unit but I can look the other way given just how perfectly it works in this application.

As an aside, you may have noticed the scoop was redesigned for this test. I intended to reuse the scoop but that didn’t work out in practice as the bolts holding the original together conflicted with this solenoid’s bracket. I could have just removed the lower two bolts but I also wanted test printing the scoop with a flat back as the rounded back of the original didn’t turn out well.

In case you’re wondering, I never throw away unused/broken parts like the old scoop design. I store the unused parts, brims, supports, etc. by filament brand, type, and color in the hopes of one day recycling them with a filament mulcher/extruder.

McMaster-Carr 70155K121

The McMaster-Carr 70155K121 is essentially just the continuous duty variant of the 70155K112 I previously tested. The only reason I decided to test it too was to see if the ball could still be ejected with a lower force solenoid (spoilers: it could not). Most of the smaller solenoids I could find from other suppliers were weaker than this so I decided to stop my testing here.

Next steps

Now that I’ve chosen a solenoid, I can start designing the ball trough assembly. I expect this to take a while given the geometry will be relatively complex compared to my previous assemblies but that’s not to say I won’t be posting in the interim. I’ve got a few other projects on backburner that I’ll be sharing until the ball trough prototype is ready.

Return Lane | Half Scale Pinball

The prototype

I’ve completed a first draft of the return lane assembly; although, it’s not fully tested at this time. The problem is I can’t really test the lane without having the side wall and slingshot on either side to verify the ball behaves as I’d like. For the moment, I’ve just printed and installed a single lane on a test board.

The top plate of the assembly is largely cosmetic so for the final design I intend on making it more “blocky” to better fit with the 90’s DOS shooter theme of the original System Shock. I also plan on constructing the bottom plate from metal to reduce wear. I’m considering building the top plate from clear acrylic; however, I don’t have room under the playfield to add lights under it so that may be a waste.

Challenges with designing in OpenSCAD

For prototyping, I heavily leverage OpenSCAD’s Boolean operations to quickly create complex shapes; however, there is no direct way to create fillets. This posed a problem for the return lane prototype as the inlane has a concave fillet where the lane divider joins the flipper return lane.

There are a few ways to accomplish a concave fillet in OpenSCAD but they each have their drawbacks:

• You can programmatically draw the curve using the 2D subsystem but this is made difficult by the lack of a built-in Bezier curve library.
• You can subtract a circle from the corner but this gets more complex when the joint isn’t 90 degrees.
• Clever use of the offset module can produce fillets but they will be applied to the entire object.
• You could draw the part in vector art software, export to SVG, and import into OpenSCAD; however, the part will no longer be parametric.

The dimensions of the machine are bound to keep changing as I refine my designs so I opted for the simplest route of simply subtracting a curve from the lane using a hard-coded ellipse. It’s not elegant and it’s not robust but it does get the job done quick so I can move on to more important assemblies.

For the final part, I’m considering writing a Bezier curve library to let me draw the curve directly in OpenSCAD. I know Bezier curve libraries already exist for OpenSCAD; however, I’m pretty opinionated with how I structure my scad files so I’d rather write the library myself to keep everything consistent. I also have bigger plans down the road to build a dependency manager for OpenSCAD so it would be helpful to have some of my own libraries I can test with.

Slingshots | Half Scale Pinball

Testing

Last post I said I’d be working on the in/out-lanes next but I finally got all the parts in to run a full test on my slingshot assembly and just couldn’t wait. The video below demonstrates the assembly with a few different general illumination colors and explains how it all works.

For this test, I just used an Arduino 4 Relays Shield and some simple code to fire the solenoid for 1/10th of a second when either sensor triggered. I also wrote in a delay forcing the solenoid to remain off for at least one second after firing to give it time to cool down (not that it gets that hot from the short burst anyways). I don’t plan on using relays to drive the solenoids in the final machine as most will require PWM signals but the Arduino is sufficient for prototyping.

Overall, I’m really happy with how the assembly turned out. That said, this is by no means the final version as there are a few quirks I need to work out.

Areas for Improvement

Unnecessary Return Spring

In the video, you can see a return spring around solenoid plunger. Theoretically, this shouldn’t be needed as the slingshot rubber can also reset the plunger; however, I found it was needed in the prototype as the slot for the slingshot actuator is slightly too short causing the actuator to get stuck without the spring.

The only reason I want to remove the spring is because it’s reducing the solenoid’s power by a fair bit. I was originally running the solenoid at 15v; however, the addition of the spring required I increase the voltage to 18v to kick the ball with the same force. Running the coil at a higher voltage isn’t ideal as it both puts more wear on the coil and requires that I run all coils at the higher voltage as well (since I do not want multiple coil voltages in the machine).

Wobbly LEDs

To make the LEDs easily replaceable, I designed custom quick-change sockets to accept standard 5mm LEDs. These sockets are great for prototyping but they don’t grip the leads tight enough resulting in the lights flickering when the solenoid kicks. This is largely because the sockets are really just holders for 2-pin Dupont connectors and the connectors I have aren’t particularly strong.

Additionally, the Dupont connectors are only friction-fit into the sockets and do fall out over time. This could be fixed with some hot glue but I’m still considering other options such as different connectors.

Deadzones

The prototype uses a pair of LJ8A3-2-Z/BY inductive probes running at 5v to detect the ball (see my previous post for more technical details). The probes are compact, easy to use, and easy to mount; however, they have a fairly small detection radius which leaves quite a few deadzones along the slingshot. The most egregious deadzone is directly in front of the kicker which means the assembly is unlikely to ever kick the ball with full force.

Unfortunately, I cannot just put another sensor in the center deadzone as the solenoid plunger would block it. I could try mounting the solenoid vertically like on a full-sized machine but even then I doubt I’d have enough space for the probe.

One option I’m considering is to shift the solenoid closer to the flippers thus giving more room for sensors; although, this would require repositioning the lower sensor further up so I’d really only be moving the deadzone. Ultimately, I don’t want to change the sensor positions just yet though as where the ball contacts each slingshot will depend greatly on the upper playfield and may make the deadzones moot (or at least move them).

Testing Inductive Probes | Half Scale Pinball

Background

One of the goals for my half-scale System Shock pinball machine is to include fully-functioning slingshots. For those unfamiliar, slingshots are the triangular kickers located just above the flippers on most pinball machines. The slingshots are designed to kick the ball diagonally up or down the playfield on contact.

This video shows a great closeup of a slingshot in action if you’ve never seen one before:

Designing half-scale slingshots that can kick was actually pretty easy; however, finding a reliable way to trigger them was a whole other problem. On a full-sized machine, the slingshots are triggered by two leaf switches located just behind the rubber ring. The slingshot is activated when the ball deflects the ring causing it to close one or both of the switches. This mechanism works great for an ~80g (~2.8oz) pinball but not so well when scaled down. Even with the softest rubber rings I could find to fit my slingshots (75A), the measly 16.3g (0.57oz) ball I’m designing for just can’t deflect the rubber far enough or with enough force to actuate most physical switches.

To put the problem into perspective, the Gateron Clear keyswitch is one of the lightest keyboard switches you can buy at the time of writing with an operating force of just ~0.3N (0.06lb). Even with such a light switch, I would have to stack two of the 5/8" (~15.87mm) chrome steel mini pinballs just to operate it (let alone bottom it out) with the measly 0.16N (0.03lb) of force each exerts under gravity. Obviously, pinballs are going to be subject to more forces than just gravity and you can find a handful of other physical switches with lower operating forces; however, switches with such low operating forces often require excessive actuation distances or are too sensitive to vibration to use in close proximity to solenoids. I do know of one physical switch that can be reliably activated by the mini pinballs; however, that’s a topic for another day and it won’t work in this context anyway.

As I mentioned in my first post, physical switches are far from the only option for detecting the mini pinballs. Ultrasonic, infrared, and capacitive among others are all good candidates but for this post I will focus on inductive sensors. I specifically want to investigate the use of standard industrial inductive probes like you’d find on a 3D printer.

The Probes

There are plenty of inductive probes available from electronics suppliers but I chose to limit testing to two specific models: LJ8A3-2-Z/BY and LJ18A3-8-Z/BX. Why? The main features I like about these models are they’re easy to mount, trivial to interface with, and have flexible voltage ranges. It also helps they happened to show up on Amazon while I was browsing other parts. The main differences between the models are their size and maximum detection range. The LJ8A3-2-Z/BY advertises a range of only 2mm while the LJ18A3-8-Z/BX boasts an 8mm range at the expense of a much larger footprint.

Both sensors connect using only three wires: power (brown), ground (blue), and signal (black). Questionable wire coloring aside, both sensors are rated for an input voltage of 6-36v and will output a signal when metal is detected in front of the orange cap (or lack thereof in the case of the LJ18A3-8-Z/BX). The maximum range at which the sensors trigger is fixed regardless of the input voltage or at least that’s what the manufacturer claims…

Curiously, I discovered by mistake that running the probes below their rated voltages can nearly double the detection range in some cases. For example, running the LJ8A3-2-Z/BY at only 4v resulted in it consistently triggering at 4mm instead of the claimed 2mm. Unsurprisingly, there is a consequence to running these probes out of spec but it’s worth the tradeoff in my opinion and something I’ll discuss later in this post. I couldn’t tell you if this behavior is common to all inductive probes but I’ve found it to be incredibly helpful and is the main reason I’m writing this post.

Testing Detection Range

Knowing the detection range of each probe changes with voltage, I wanted to run tests to measure the extent of this affect; furthermore, I wanted to measure how far the mini pinball would have to pass over sensor before it was detected.

For testing, I first printed test jigs to align each probe and ball to the same height and let me slide the sensor closer to the ball along a ruler at various horizontal offsets from the ball. I then placed the ball at a known position along the ruler. For each combination of sensor, input voltage, and horizontal offset I would slide the sensor toward the ball until my multimeter showed the sensor had triggered. I would repeat the test a few times to verify consistency then record the distance between the edge of the ball and tip of the sensor.

Each sensor was tested at its lowest stable voltage, 5v, and 12v. I opted to not test at any higher voltages as I’m expecting to have power supply rails for 5v and 12v in the final machine but the only rail I’m planning with higher voltage is for driving coils and I don’t think it wise to run sensitive electronics off the same rail.

Each sensor was tested at three horizontal offsets:

• (A) Ball center aligned to the sensor cap’s center (no offset)
• (B) Ball center aligned to the edge of the sensor cap
• (C) Ball edge aligned to the sensor cap’s center

LJ8A3-2-Z/BY

4v was the lowest I could reliably operate this probe. At 3v, the sensor would trigger but not stop once metal left its detection area.

LJ18A3-8-Z/BX

5v was the lowest I could reliably operate this sensor. The sensor would not trigger at lower voltages.

Testing the Effects of Solenoid Interference

While prototyping the slingshot, I found activating a solenoid close to a probe would cause the probe to trigger. This wasn’t really concerning for the slingshot assembly on its own since I could just ignore the false activation in code but I was worried nearby unrelated probes might also trigger.

To test just how far away a probe would need to be to avoid interface, I first taped each probe to a known position on my ruler. I then placed my test solenoid (model A420-065573-00) along the ruler and fired it at different voltages while watching the probe’s output. If the probe falsely triggered, I would move it half a millimeter away and repeat until it no longer triggered. I repeated this test using the same probe voltages as my previous test and with three different solenoid voltages as I haven’t yet decided the final voltage for the game. Furthermore, I ran this test both with the solenoid facing the probe and with it beside the probe to determine how much the orientation mattered.

For each probe voltage, solenoid voltage, and solenoid orientation, I recorded the maximum distance I found interface as well as the minimum distance I found the probe to be clear of interface. The distance measurements were taken from the faceplate of the solenoid to the center of the probe and from the side plate of the solenoid to the center of the probe.

Hyphens in the following tables indicate configurations were I was unable to get the probe to falsely trigger even when directly touching the side of the probe to the solenoid.

LJ8A3-2-Z/BY

LJ18A3-8-Z/BX

Results

Ultimately, these tests have given me confidence that undervolting my sensors won’t be a major issue. The increased range (especially for the LJ8A3-2-Z/BY) is extremely valuable and I don’t expect it to be difficult to keep probes more than 4mm away from other assembly’s solenoids to avoid interface. I did find it interesting though that neither probe could be falsely triggered when run at 12v. This leads me to believe the probes are only susceptible to interference when run outside their rated voltage; although, I admittedly didn’t test within the lower end of their specifications.

All that said, the range of the probes is still a concern. Something to consider is these probes are too long to be mounted on top of the playfield which means they’ll have to be mounted under it. Even the best probe configuration I tested can still only detect up to 7mm but my playfield is already 1/4" (6.35mm) thick and that’s excluding the vinyl artwork. I could drill holes into the playfield and mount the sensors flush with its surface; however, it would be difficult to get a close enough fit to not cause the ball to jump when passing over.

This problem bothered me for a few days but I think I finally landed on a decent solution. By overlaying the playfield with a thin sheet of stiff polycarbonate 1/32" (~0.8mm), I can freely drill holes for the sensors in the wood layer while keeping the plastic play surface smooth. This solution comes with a few fringe benefits as well. Applying the playfield graphic under the plastic will help to protect it from the ball in much the same way Mylar film is used to protect full sized machines. This also allows me to hide the sensors if I attach the artwork to the back of the plastic rather than the wood.

Next Steps

I worry the sensors may still not have a wide enough radius to detect the ball reliably in game; however, I won’t know for sure until I finish the lower-third and can start play testing. If you’re not familiar, the lower-third is the literal lower 1/3rd of the playfield and includes the major assemblies: flippers, slingshots, the shooter lane, drain, and in/out lanes. I already have working prototype flippers and rough designs for the drain and shooter so next up are the lanes.

Half Scale Pinball

Background

Since 2015, I’ve been working to build a roughly half-scale pinball machine themed after the original System Shock. I got the idea from the various mini-pinball machines built on the Ben Heck Show [1] [2] and from having finished playing the original System Shock around the same time. This whole idea started when I noticed the serv-bots on the medical level closely resembled pinball pop-bumpers. From there, I began to think about how many of the objectives and mechanics in the game could be adapted to modes in a pinball machine.

While the project is far from complete, I’ve decided to start blogging my progress to help anyone else in the community wanting to build their own scaled down pinball machine. The world needs more mini-pinball!

Objectives

From the start, I knew my machine had to be fully featured. To me that means, all of the following mechanisms must be present and they must work more-or-less the same as those found on full sized machines:

• Auto-plunger
• Backglass
• Coin-mech (that only accepts dimes)
• Dot Matrix Display
• Drop Targets
• In/out Lanes
• Kick-out Hole
• Light Strips
• Multiball
• Playfield Inserts
• Pop Bumpers
• Rollovers
• Skill Shots
• Slingshots
• Spinners
• Tilt Sensor

I don’t know how feasible all of these features are but I strive to at least try each one. Additionally, I have a few general goals I’d like to achieve for my own peace of mind:

• Minimal high-voltage wiring
• Consumable components are easily replaceable
• All playfield mechs are designed to be reusable in other games
• Minimal custom PCBs
• Use as many original game assets as possible
• Avoid servos (I just really hate that high-pitch sound they make)

I have a few special features I’m designing in as well but you’ll just have to stay tuned to future posts to hear about those.

Challenges

One of the first and most persistent challenges of building a scaled down pinball machine is the OG buzzkill, physics. As Ben noted in his show, simply scaling down the ball’s diameter by half doesn’t really work all that well as you lose so much mass that the ball becomes uncontrollable. Taking Ben’s advice, I have chosen to use a 5/8" bearing ball as opposed to a 1/2" ball.

Even with the adjusted diameter, the 5/8" ball just doesn’t have enough mass to actuate most switches. As an experiment, I tried resting one of the mini pinballs on a Cherry MX Speed switch and to my horror it didn’t even begin to depress the switch. As others have demonstrated in their own scaled pinball projects, this limitation does have workarounds but it requires some creative use of alternative sensor types (eg capacitive, infra-red, inductive, etc.).

Physics isn’t the only problem we’ve got to contend with either. Finding solenoids with enough power and throw to actuate the playfield mechs has been far more difficult than I initially expected. Most higher power and longer throw solenoids are simply too big to fit into a half-scale cabinet and smaller solenoids lack the power or range needed to do anything useful. Thankfully, I’ve found this can be mitigated by overvolting smaller solenoids; although, only time will tell how long the solenoids last being driven at 150-160% their rated voltage.

Development

I personally prefer to work in CAD before making anything physical. I realize this is completely backwards from nearly everyone else; however, I find I just can’t picture the end result I want without drawing it out in CAD first. In a twist that’s sure to surprise some, my CAD tool of choice OpenSCAD. The reason for this is twofold: 1) OpenSCAD’s language really meshes with how I think (pun intended) and 2) Fusion 360 is borked for my Autodesk account and I refuse to make a new account just to fix their software.

In all seriousness, I have used Autodesk 3D modelling and CAD software in the past but being a software engineer by trade I just feel more comfortable writing code. That said, OpenSCAD leaves a lot to be desired (especially in the dependency management front) and I probably would have been a lot farther along by now had I forced myself to use something else. All that’s to say: your mileage may vary.

Current Progress

Unsurprisingly, that laundry list of features, challenges, and my odd choice in toolchains hasn’t resulted in the progress you’d expect to see after 7 years; however, that’s not to say I’ve been slacking either. I’ve made great strides in improving my development workflow with OpenSCAD libraries, tested numerous mech prototypes and sensors, and produced working assemblies for the flippers, slingshots, and drop targets. The screenshots below are renderings of some of the current progress and there will be more to come in future posts.

Wrap-up

That’s all I’ve got time to write about for now but be sure to subscribe to my RSS feed so you get notified of my future progress. In the short-term, I’m planning in-depth posts on the mechs built thus far and the challenges I faced designing them.