That's really coming together.
(Topic ID: 164849)
Quoted from XXVII:Awesome! Could you do a test? I believe the ball should not be able to sneak up the right side against the ballstop. With the left side all the way up, could you move the right side up and see if the ball is able to get past any of the rightmost holes? Same deal in reverse for the left side.
I tested this and the ball falls into a hole on the way up in both scenarios.
I don't think I'll be able to wire up for a test tonight, but I did get one side fully set up with pulleys and spline and I verified that by manually spinning the servo that the holding torque with no power is sufficient to hold the carriage in place under the load of the rod and other parts. I'll be able to start playing soon... with oversized holes, no lights, and no switches, but I can keep track of targets and scoring in my head. 
It occurs to me that CNC machining custom parts isn't exactly in the spirit of what we set out to accomplish. It's kind of addicting, though, having the tool on hand and knowing I can come up with something to solve a problem quicker than making it by hand.
I would offer this as an alternative approach to the rods, if trying to make everything by hand:
-Use a #6 bolt as a pivot point directly on one of the holes of the carriages.
-Drill a hole for the pivot point into the rod.
-Use lock nuts and washer to hold the rod onto the bolt, making them loose enough for it to pivot.
-Use about an inch long #6 spacer as the ball stop on either side, drill through the rod at those points and hold the ball stop onto the rod with a #6 bolt and screw.
In this scenario your pivot point would be spaced out a little more, so I'm not sure how that would impact things, if at all, but it's the easiest approach I can think of if you're doing it by hand. Otherwise you could potentially hand make some kind of holder in the vein of what I've come up with on the CNC machine, but I don't know how difficult it would be.
Quoted from winteriscoming:It occurs to me that CNC machining custom parts isn't exactly in the spirit of what we set out to accomplish. It's kind of addicting, though, having the tool on hand and knowing I can come up with something to solve a problem quicker than making it by hand.
I would offer this as an alternative approach to the rods, if trying to make everything by hand:
-Use a #6 bolt as a pivot point directly on one of the holes of the carriages.
-Drill a hole for the pivot point into the rod.
-Use lock nuts and washer to hold the rod onto the bolt, making them loose enough for it to pivot.
-Use about an inch long #6 spacer as the ball stop on either side, drill through the rod at those points and hold the ball stop onto the rod with a #6 bolt and screw.
In this scenario your pivot point would be spaced out a little more, so I'm not sure how that would impact things, if at all, but it's the easiest approach I can think of if you're doing it by hand. Otherwise you could potentially hand make some kind of holder in the vein of what I've come up with on the CNC machine, but I don't know how difficult it would be.
What I set out to accomplish was building a machine that required as minimal handwork as possible, which the CNC enables. Another option, since these pieces are small, is to upload the designs to a 3D printing store like Shapeways or Thingiverse, and those that don't have a CNC or 3D printer can have them made to order, delivered to their door.
Quoted from XXVII:What I set out to accomplish was building a machine that required as minimal handwork as possible, which the CNC enables. Another option, since these pieces are small, is to upload the designs to a 3D printing store like Shapeways or Thingiverse, and those that don't have a CNC or 3D printer can have them made to order, delivered to their door.
That's an option, too. Though for 3D printing I suspect the pieces are going to need to be fleshed out into 3d models. For CNC I generally just work with flat vectors. I'm not saying it can't be done, but a little work will need to go into it once the pieces are finalized. I don't currently seem to have any CAD software that allows easy importing of vector files.
I have almost no exposure to 3D printing at this point, though I do want to own a 3D printer. Is shrinkage in a 3D print something that needs to be considered? If I've got a piece designed to fit snugly around a 1/4" tube, and the 3D print shrinks, it might not fit.
I can make them into 3D. That would be very simple if you are just milling a 2d part. I just need an extrusion thickness
There wont be any shrinkage of an ABS plastic part, you will probably need to print a couple parts to dial in the tolerance though.
+1 for making a 3D model. I can do it as well as print sets. Going to be some trial and error as catboxer mentioned but once were dialed in, I can print off a bunch of sets.
I've only gotten a chance to do some quick testing, but so far I'm getting the rod to move fine with the servos. I currently have the servos configured in the software for a slower speed. I'll try it at full speed when I get a chance.
I do have this observation: Due to gravity, it moves a little faster going down than up. Does the original ICB work this way? One way I can think to lessen this if it's an issue is to actually make the down speeds slower than up. Currently the code is set up to only allow for one configurable speed, but it wouldn't be difficult to add an up and down speed.
Oh, and I added a rod test menu to the service menu. It opens a mode where the rod is free to move for testing purposes.
I think I have the speed dialed in to be manageable. These servos definitely have the capacity to go way too fast for fine movement.
A couple items of note:
1. The carriages are not able to get all the way to the extreme top/bottom along the guide rails due to the spline bumping up against the edge first. This is a bigger deal at the bottom because it means that with the trough hole being where it is on my current pf, I can't lower the rod all the way below it. The solution is likely to just extend the cut for the carriages so that they can move down more.
2. At slow speeds it's most noticeable, but my motors do not move at the same speed. I wonder how much variation there is in motors of the same make/model. If I start them both at the bottom and race to the top, my right motor lags behind slightly. It might be worthwhile to set up a configurable speed for left and right separately to be able to dial in potential differences like this.
3. My current rod mount/ball stop design doesn't hold the rod in as secure as it needs to be. I had a few cases where the ball fell behind the ball stop. At the moment I put a zip tie around the mounts near the ball stop to secure it better, but in the final design there's going to need to be a clamping point here.
This isn't likely something I would do, but here's an idea that could be cool: Remote Play
You set up a web cam and accept remote commands for joystick movement. You could let people play your game remotely.
I may have an LED solution that would make for relatively simple flat installation.
I had some solid nylon rod on hand and figured out that it can be used to diffuse the light. Making a small hole in the back of the pf next to the larger tube allows the LED to be mounted offset a little from the hole and the light doesn't end up with a blinding effect. The LEDs can be arranged flat against the back of the pf, with easily accessible solder points for wiring them up.
I took a look at my current pf and can easily find space to mount a light on every hole in this way, with the exception of the uppermost target hole. However the footprint of the LED that goes there could be cut down significantly to fit.
I think this is the way I'm going to plan to proceed with the LEDs. Now I just need to nail down how I want to mount the optos.
IMG_20160812_193225_(resized).jpg
IMG_20160812_193143_(resized).jpg
IMG_20160812_193111_(resized).jpg
Edit: Cameras do a terrible job of representing LED lighting. In person it doesn't look like a blinding glow at the point of origin.
Valparaiso, IN
If your using proper servo motors you should be able to control the speed exactly in the software. its how NC machines work. Now if you are just using motors and gearboxes then you will have to have some sort of speed controller to match them.
Quoted from Pugsley:If your using proper servo motors you should be able to control the speed exactly in the software. its how NC machines work. Now if you are just using motors and gearboxes then you will have to have some sort of speed controller to match them.
Yeah, we're controlling it with software. I was just stating that currently I've only got the software set up so that there's a single speed variable and both motors are being driven in both directions with the same value. It won't be difficult to separate out into 4 variables as needed. In this application I don't know that we need to get much more advanced than driving each direction at an established speed. I don't think we need to worry about ramping up or down the speed, but that would be possible, too.
Here's a mapping of LEDs and holes for the diffusing rods. Keep in mind that the LED PCBs can be cut shorter if needed, or you can buy the higher density kind with smaller footprint PCBs. Only that top target hole is going to have to be cut down creatively to fit.
playfield_-_LED_holes_(resized).pngplayfield_LEDs_(resized).png
I'm trying to map out paths for wiring from FadeCandy to each of the LEDs (admittedly while drinking) and it's hurting my brain... 
The FadeCandy is limited to 8 runs of 64 pixels each, and 6 inch max between each pixel (and we assume 6 inches from FadeCandy to first pixel in a run). The FadeCandy PCB is going to have to be mounted somewhere very close to or directly on the playfield, and with 83 (I think that total is correct) illuminated holes, we're looking at 2 different runs from the FadeCandy.
For the optos I'm thinking they can be recessed a little into the PF and anything going on with the LED PCBs wouldn't conflict for the most part if they needed to overlap. With the optos recessed and the LEDs pretty well flush against the back of the PF, I don't think we're at risk of the ball damaging anything. Any exposed solder pads could be taped over or get a glob of hot glue or some other insulating barrier to alleviate concerns about a metal ball shorting anything.
My current goal at this point is to add optos to each of the standard target holes and get something of a vanilla game going, with future plans to expand to sensors on other holes if we can come up with a good reason for there to be. At the moment wiring up 83 separate pairs of optos is kind of off-putting.
I'm starting out with no ICB in my collection, so even getting an ICB clone with expanded RGB light-shows would be pretty great. Anything beyond that is going to be ice cold beer on the cake. Once I get things pretty well going in the stock configuration, I'd be in a better place to think about additions anyway.
I found a much more suitable and accessible substance to diffuse the light at the edge of the tube: hot glue
It can fill any void along the edge and transmits the light very well. I also feel like this method going to eliminate the chance of light bleed where an LED from one hole illuminates another.
Quoted from winteriscoming:I found a much more suitable and accessible substance to diffuse the light at the edge of the tube: hot glue
It can fill any void along the edge and transmits the light very well. I also feel like this method going to eliminate the chance of light bleed where an LED from one hole illuminates another.
Nice! Simple, but effective.
Just made a big commit to the repository. This time, I've added LED support, converted config files to a single INI, and revamped the service mode. I broke some things and some of it is a bit sloppy, but I've strayed too far out without a recent commit and just had to get it out in its current state. I'm going to have to get into the habit of smaller, more frequent commits.
The attract mode now has a garish light show to prove it can do something. I've also added the LED positions from the OPC JSON file I made. I didn't have to painstakingly recreate this light arrangement again; I just parsed the hole locations in the JSON and spat them onto the screen in a for loop. This is just for development purposes since the actual game won't need this on the screen during attract mode. You can see OPC has mirrored what's on the ball balance screen.
Screen_Shot_2016-08-14_at_1.44.08_AM_(resized).png
I also added a pulsing light for the current hole being played. This is to prove light animations can be performed pseudo-asynchronously from the rest of the game logic, which was a concern that it couldn't be done without a great amount of difficulty.
Screen_Shot_2016-08-14_at_1.46.36_AM_(resized).png
The Service Mode menu has been rewritten into a less monolithic fashion. Each item on the service main menu is now a separate class. This is probably the route that GameMode.py will eventually go in order to make it simpler to dissect, modify, and integrate new game modes.
Switch configuration now has a switch detection sheet. Any switch that is active appears in a different color.
Screen_Shot_2016-08-14_at_1.50.35_AM_(resized).png
Rod testing has been integrated into the servo configuration menu item. Double tap the Start button to switch from the menu adjustment mode to movement mode, where the joysticks control the rod instead of the user interface on the LCD.
Screen_Shot_2016-08-14_at_1.51.14_AM_(resized).png
I've added an LED address menu item. This will eventually be fleshed out, but for now, it will tell you the index of whichever light you have selected with the joysticks. Since we are probably each going to potentially wire our games' holes in different ways, this feature will eventually do something like light up a hole on the LCD, then tell you to use the joysticks to go through and light up the actual hole on the playfield, which is going to be a different address than the game currently assumes (right now, arranged by height, then left to right) then use that information to correctly map the holes again.
Screen_Shot_2016-08-14_at_1.51.35_AM_(resized).png
My plan is to make it possible to create light shows using the PyGame's graphics utilities. I want to make a PyGame Surface object that you can animate on top of, then the code will sample the pixels from that Surface and light up the holes corresponding to those locations. That will allow you to easily do things like animate bars panning back and forth across the playfield, or a bubbles effect for the attract mode light show, or ripples spreading out from the current target hole, or scrolling text across the entire playfield, or play animated GIFs or movie files, you get the idea.
In other news, I ordered my CNC machine this morning, so I'll soon be able to join in figuring out the physical puzzles to this project. 
Quoted from XXVII:Just made a big commit to the repository. This time, I've added LED support, converted config files to a single INI, and revamped the service mode. I broke some things and some of it is a bit sloppy, but I've strayed too far out without a recent commit and just had to get it out in its current state. I'm going to have to get into the habit of smaller, more frequent commits.
The attract mode now has a garish light show to prove it can do something. I've also added the LED positions from the OPC JSON file I made. I didn't have to painstakingly recreate this light arrangement again; I just parsed the hole locations in the JSON and spat them onto the screen in a for loop. This is just for development purposes since the actual game won't need this on the screen during attract mode. You can see OPC has mirrored what's on the ball balance screen.I also added a pulsing light for the current hole being played. This is to prove light animations can be performed pseudo-asynchronously from the rest of the game logic, which was a concern that it couldn't be done without a great amount of difficulty.
The Service Mode menu has been rewritten into a less monolithic fashion. Each item on the service main menu is now a separate class. This is probably the route that GameMode.py will eventually go in order to make it simpler to dissect, modify, and integrate new game modes.
Switch configuration now has a switch detection sheet. Any switch that is active appears in a different color.Rod testing has been integrated into the servo configuration menu item. Double tap the Start button to switch from the menu adjustment mode to movement mode, where the joysticks control the rod instead of the user interface on the LCD.
I've added an LED address menu item. This will eventually be fleshed out, but for now, it will tell you the index of whichever light you have selected with the joysticks. Since we are probably each going to potentially wire our games' holes in different ways, this feature will eventually do something like light up a hole on the LCD, then tell you to use the joysticks to go through and light up the actual hole on the playfield, which is going to be a different address than the game currently assumes (right now, arranged by height, then left to right) then use that information to correctly map the holes again.
My plan is to make it possible to create light shows using the PyGame's graphics utilities. I want to make a PyGame Surface object that you can animate on top of, then the code will sample the pixels from that Surface and light up the holes corresponding to those locations. That will allow you to easily do things like animate bars panning back and forth across the playfield, or a bubbles effect for the attract mode light show, or ripples spreading out from the current target hole, or scrolling text across the entire playfield, or play animated GIFs or movie files, you get the idea.
In other news, I ordered my CNC machine this morning, so I'll soon be able to join in figuring out the physical puzzles to this project.
Geeze! Finish the whole game, why don't you? You come along with your giant commits and wipe out my tiny/messy contributions.
I tried running it on the RPi and there are going to be a couple of things to fix, but the lights are definitely working, which is exciting.
What did you go with for a CNC machine?
I have the latest code up and running on my RPi, but during the game mode it keeps locking up. This is the first time I've had LEDs and servos going at the same time, so I think something may be happening that's hopefully due to an overtaxed PSU and not some other issue. I'm using an old ATX PSU and I'm not sure of the specs off hand, but nearly all the time the RPi is complaining about under voltage (at least I think that's what it's complaining about). I have a much nicer PSU available that I'll swap in when I get a chance.
I'm excited to get lights and optos wired up so I can start playing, but I think I'm also going to have to order more polycarbonate tubing to be able to fill out all holes.
Quoted from winteriscoming:What did you go with for a CNC machine?
I ended up ordering the Inventables X-Carve 1000mm kit. https://www.inventables.com/technologies/x-carve
It has a max work area of ~31.5"x31.5". I will definitely have to figure out how to do the CNC tiling if I want to make a full sized ICB cabinet, but it's at least big enough carve the playfield itself without needing to move the piece on the work area. I decided on the X-Carve because the price was more in my comfort zone, its free Easel CNC software seems like it's good for absolute newbies like me, and it looks like the Inventables crew offer really amazing tech support.
xcarve-large-dewalt-a65627cceb9e3ea23f2e21b248c6f3a1_(resized).jpg
God I wish I had the cash to get one of those. But it's probably a pain to make work for cutting a pinball playfield
I had these directions on setting up the RPi in an earlier post, but have saved them to a text file, with some updates, in the Github repository so they don't get buried:
https://github.com/welovepinball/ball-balance/blob/master/RPi%20Setup%20from%20Scratch.md
I highly recommend once you get the Wifi setup that you remotely access the RPi through SSH for additional setup. On Windows I use PuTTy. You just put in the IP address of the RPi and then it asks for the RPi's login credentials, and you're essentially remotely using a terminal on the RPi. It's nice because you can copy and paste commands into the terminal. You can also run Python scripts to verify that they work without generating an error message, but unfortunately you can't run PyGame through it so you'll get to a point where it says it can't run.
As I've been running the code on the RPi, I have found troubleshooting issues to be kind of difficult when compared to running on Windows. The reason is that the PyGame screen takes over on the RPi and, as far as I can tell, none of our debug print commands end up on the terminal when exiting the game. Alternatively, in Windows both the terminal and PyGame window can be concurrently viewed.
I was in a situation where my motors weren't moving and it turned out to be due to some code changes that made the GPIO setup fail, but I didn't have any easy way to tell that this was happening. For the moment I added servo motor status to the servo menu, so that will tell you if the motors were able to be setup correctly in the software.
We should probably consider having some kind of debug mode that can be toggled on or off that prints messages directly to the PyGame screen.
It looks like there's a PyGame console module where a console screen can by overlayed, so maybe that's an option:
http://pygame.org/project-pygame-console-287-.html
It turns out that we probably don't need any kind of advanced console functionality in our game. For the moment I added a debug console menu to the service menu. It displays a debug print buffer that currently allows for 10 lines.
Printing to the debug buffer is managed in tools.py and can be used as follows:
tools.Debug_Print("text")
So basically anywhere that we have a standard Print command, should also be paired with this if we want to see the message in game.
At the moment it's a matter of going to the debug menu from service menu, but it would probably be pretty easy to print this text out on any screen as needed. We would just need to figure out how we want that to be managed. Do we have a dedicated key-stroke to toggle debug mode or do we toggle it in the service menu?
Quoted from winteriscoming:I have the latest code up and running on my RPi, but during the game mode it keeps locking up.
I think this was a power issue, though not due to my PSU, but because I was feeding everything power, including the RPi through tiny gauge wiring in a breadboard. The RPi was locking up during game mode when the servos are made to automatically move down to load up the ball. I got the same behavior with my beefier PSU that allows 25A on the +5v rail. Wiring the RPi directly into the PSU seems to keep it from freezing, and I notice the under voltage warning has gone away.
Quoted from Chitownpinball:Have yall come up with a n ame for this yet? With all the color..."fruity" something comes to mind.
Haha. No idea on names yet; we haven't nailed down a theme either. So far, I like the pirate theme idea the best, or a treasure hunter theme in the same vein as Indiana Jones or Tomb Raider. There's also a haunted house idea, which I'd love to explore if the America's Most Haunted audio assets have an open source license. lpeters82 already thought up a lot of good ways to reuse some of that content. I also remember people mentioning golfing and zombies, but I'm not personally keen on those themes. We could always just do a beer theme again, so we could call it something like Frosty Mugs (or "Eyes Coaled Bier" 
).
All the color is temporary though. I'm sure we'll have a little more discretion when we're designing the actual light shows and not do something overboard like we are right now. I don't expect we'll see any rainbow color shifting in our final design, aside from maybe service menu stuff for diagnostic purposes.
Quoted from Chitownpinball:"fruity" something comes to mind.
Quoted from XXVII:So far, I like the pirate theme idea the best,
Fruity Pirates! 
So apparently this game is not good for people who are freaked out by clusters of holes. This is popularly referred to as trypophobia, but per the Wikipedia page isn't an official diagnosis of the condition.
https://en.wikipedia.org/wiki/Trypophobia
So far my wife is not a fan of this project. 
Whelp... I succeeded in breaking 2 of my nice end mills. The first one ran into a metal clamp after I accidentally sent the program into offline mode and screwing up the position of the router, and I broke the 2nd one which was much shorter making sure nothing would hit the clamp, but snapped it right across the edge of the test piece of wood...
Now I have to order some more before I can cut any more tests. 
Edit: I'm going to try out some cheap end mills listed on Amazon. I'll report back with details if they're acceptable, but basically I'm getting 30 end mills for the price of only a couple of expensive ones.
Quoted from winteriscoming:It turns out that we probably don't need any kind of advanced console functionality in our game. For the moment I added a debug console menu to the service menu. It displays a debug print buffer that currently allows for 10 lines.
Printing to the debug buffer is managed in tools.py and can be used as follows:
tools.Debug_Print("text")
So basically anywhere that we have a standard Print command, should also be paired with this if we want to see the message in game.
At the moment it's a matter of going to the debug menu from service menu, but it would probably be pretty easy to print this text out on any screen as needed. We would just need to figure out how we want that to be managed. Do we have a dedicated key-stroke to toggle debug mode or do we toggle it in the service menu?
I'm in favor of a toggle in the service menu (we can default to enabled while we develop vs. having to toggle it on every time we run the program), and displaying the output on every screen. It would only take a quarter of a second of rod movement without GPIO enabled to blow out 10 lines of logs, so might as well display to every screen live instead of having a dedicated service mode feature. Just make sure the call to display is the very last thing in game.py before the screen flip and our console log will be rendered on top of everything else. It would be helpful to use a dedicated timer (pygame.USEREVENTS + 7) to remove messages that are older than a certain amount of seconds.
I'll be a bit more helpful once we nail down the theme or working on game modes. This programming stuff is out of my league.
Quoted from winteriscoming:I had these directions on setting up the RPi in an earlier post, but have saved them to a text file, with some updates, in the Github repository so they don't get buried:
https://github.com/welovepinball/ball-balance/blob/master/RPi%20Setup%20from%20Scratch.md
I highly recommend once you get the Wifi setup that you remotely access the RPi through SSH for additional setup. On Windows I use PuTTy. You just put in the IP address of the RPi and then it asks for the RPi's login credentials, and you're essentially remotely using a terminal on the RPi. It's nice because you can copy and paste commands into the terminal. You can also run Python scripts to verify that they work without generating an error message, but unfortunately you can't run PyGame through it so you'll get to a point where it says it can't run.
I just created a documentation folder and moved this helpful file into it:
https://github.com/welovepinball/ball-balance/blob/master/documentation/RPi%20Setup%20from%20Scratch.md
I also reformatted it into Markdown so that it differentiates Terminal commands from normal text.
I just followed the instructions to get my RPi set up and apparently it matters on the wpa_supplicant.conf step that the SSID and PSK are on separate lines. I see what you mean about the FadeCandy setup not being straightforward. We are going to need to write a script of some sort to collect the user's FadeCandy serial code and inject it into their FadeCandy configuration. Perhaps we can make it in Python and add it as a service menu item? I don't know enough about Python yet to know if it's possible to collect the serial from fcserver, or if it can be done in an OS-independent way.
Quoted from XXVII:I also reformatted it into Markdown so that it differentiates Terminal commands from normal text.
I didn't even know this was a thing...
Quoted from XXVII:We are going to need to write a script of some sort to collect the user's FadeCandy serial code and inject it into their FadeCandy configuration. Perhaps we can make it in Python and add it as a service menu item? I don't know enough about Python yet to know if it's possible to collect the serial from fcserver, or if it can be done in an OS-independent way.
I briefly looked up making command scripts to be able to package all of the setup into one step, but I figured you'd have to get all the way through setting up wifi and installing Git before you'd even get the script file, unless we had some other directions that let you start off with the script on your SD card. At any rate, it seems like Bash comes with some pretty robust scripting capabilites, so maybe it would be possible to save out the FadeCandy serial # into a variable that gets written to the configuration file?
Quoted from catboxer:For cheap end Mills I like Diablo brand from home depot.
My main issue with going to the store for end mills is that I only have 1/8" and 1/4" collets for my router. A lot of the stuff I like to do needs the smaller 1/8" shank end mills, and I can't find those in stores as often. There are a few Dremel bits that work well, though. I know there are 1/8" and other sized cutting bits on 1/4" shanks, too, but haven't tried any of those in fear of the cutting portion not being as long as the material I need to cut through is thick. I did a quick search on the Diablo bits on Home Depot's site and wasn't seeing 1/8".
Quoted from winteriscoming:I briefly looked up making command scripts to be able to package all of the setup into one step, but I figured you'd have to get all the way through setting up wifi and installing Git before you'd even get the script file, unless we had some other directions that let you start off with the script on your SD card. At any rate, it seems like Bash comes with some pretty robust scripting capabilites, so maybe it would be possible to save out the FadeCandy serial # into a variable that gets written to the configuration file?
Ok, so it should be possible to do this with Python. The serial number/s get saved to /var/log/fcserver.log. It should be possible to go in and parse those out and save them into the fcserver.json file, though I'm not sure if the location of fcserver.json (/usr/local/bin/fcserver.json) requires elevated permissions that would complicate things.
Alternatively, fcserver will use defaults for any connected device:
To use multiple Fadecandy devices or to set up a custom
mapping from OPC pixel to Fadecandy pixel, you can provide
a JSON configuration file. By default, all detected Fadecandy
boards map directly to OPC pixels using the following default
configuration. For more information about the config file
format, see the README.{
"listen": ["127.0.0.1", 7890],
"verbose": true,"color": {
"gamma": 2.5,
"whitepoint": [1.0, 1.0, 1.0]
},"devices": [
{
"type": "fadecandy",
"map": [[ 0, 0, 0, 512 ]]
}
]
}
Quoted from XXVII:I'm in favor of a toggle in the service menu (we can default to enabled while we develop vs. having to toggle it on every time we run the program), and displaying the output on every screen. It would only take a quarter of a second of rod movement without GPIO enabled to blow out 10 lines of logs, so might as well display to every screen live instead of having a dedicated service mode feature. Just make sure the call to display is the very last thing in game.py before the screen flip and our console log will be rendered on top of everything else. It would be helpful to use a dedicated timer (pygame.USEREVENTS + 7) to remove messages that are older than a certain amount of seconds.
It doesn't currently use a timer to clean it up, but I have added a debugging toggle (defaulted to true) to the Settings menu in the Service Menu, and attract mode, game mode and servo menu all show debugging text when the toggle is true.
Settings_Menu_(resized).png
debug_example_(resized).png
In retrospect, it should probably start at a lower point on the screen, but it's going to be overlapping whatever's on screen anyway.
Edit:
Also, thinking about cleaning up old items... it could just be a matter of starting a timer and at a given interval just send a blank string to the debug buffer. That would eventually clean it up if nothing new came in.
I made a few improvements to the debug display. It's now lower on the screen and a blank is sent into it to clear it out at certain intervals. I probably handled the timer inelegantly, but it seemed to me that the easiest way to manage it was to just increment a variable and when that variable gets so high, insert a blank and zero out the timer variable. The incrementing happens during the screen drawing, which I believe should be happening however many times the screen refreshes per second (are we at 60fps?).
I was just looking at my test pf and experimenting with limit switch placement and noticed the rod doesn't get higher than the highest holes to the point where I don't think the ball would be able to be carried over the top holes. Is the bar supposed to stop before being able to go that high?
The ball loader plate thing isn't too difficult of a contraption.
I've got it pivoting on a #6 bolt, with washers and a lock nut.
The piece that goes into the track is a #6 bolt with a 1/4" thick aluminum spacer aroud it. The return spring attaches to the back of this.
The arm out front that the rod would hit would ideally have the same kind of spacer on it, but I can't find the other one I bought at the moment, so it's just a bare bolt at the moment.
Unfortunately my test pf doesnt allow the rod to move down far enough to test loading up a ball.
IMG_20160818_103439_(resized).jpg
Quoted from winteriscoming:I was just looking at my test pf and experimenting with limit switch placement and noticed the rod doesn't get higher than the highest holes to the point where I don't think the ball would be able to be carried over the top holes. Is the bar supposed to stop before being able to go that high?
I double-checked the placement of the holes relative to the top of the playfield and the side cutouts and they are correct. The problem is likely that you are using the side cutouts as a channel for the linear motion bearings, but they weren't designed for something that bulky. They will have to be cut longer to compensate for the additional vertical space they occupy. Similarly, part of that channel is blocked by a thin, 0.75" thick piece of wood on each side of the cabinet that acts as the support for the length of the playfield glass, and as the spacer between the playfield and the glass. It's likely that we are going to have to change the playfield design by making the side cutouts wider to allow space for the spacer wood and the linear bearings.
Quoted from winteriscoming:The ball loader plate thing isn't too difficult of a contraption.
Yup, that's all there is to it! The original game is designed the same exact way. I'm glad the closer pivot point is still operable. You could probably move the rod arm bolt over an inch or so to the left and that might allow the rod to load the ball.
I'm going to measure out and model the whole original cabinet and placement of its parts to help alleviate a lot of these issues.
My CNC machine parts came in yesterday and I spent all night trying to get it assembled. It's probably going to take me at least another week before I get it ready to start cutting due to other obligations, but I'm on my way!
Quoted from XXVII:You could probably move the rod arm bolt over an inch or so to the left and that might allow the rod to load the ball.
Probably similar to the top, the bottom channels aren't allowing the carriage to go down far enough. Even if I moved the rod arm bolt to where the rod could completely open the out hole, the rod wouldn't be far enough down for the ball to fall out onto the rod. I've modified to allow for more travel up and down for the next pf I cut.
Quoted from XXVII:I'm going to measure out and model the whole original cabinet and placement of its parts to help alleviate a lot of these issues.
That would be awesome. I was thinking about glass placement relative to what I've already got and I think the carriage placement and rod holders are going to impact our ability to put the glass close to the pf. The only thing I can think to do would be to recess the guide rails into the pf or mount them to the back and design rod holders to where they hopefully don't have any parts that stick out too far... I wonder if we could get away with not relying on the glass as a barrier in the front. If the pf was tilted back a little more than stock, could that help? Or is this issue that the ball sometimes gets caught in between a hole and the rod and wants to shoot forward towards the glass?
Here's my current idea for LED mounting, hole numbering and wiring. None of the wires even approach 6", so I think this can work. I've got 2 runs. The first ends at 53 LEDs and the 2nd ends at 30. Any number of wiring configurations could be made, but I was just trying to figure out a decently short and easy path between most LEDs, keeping in mind the requirement that at least 2 runs would be needed from the FadeCandy PCB in order to accommodate 83 holes.
This view is from the front of the playfield, so the LEDs are facing you, but they and their wiring would be mounted on the back, facing towards you.
Hole 37, the top-most target hole, is going to be the biggest challenge for mounting the LED. My hope is the PCB can be cut down small enough, and only run 5v and ground to it once, that way only the signal wire has to go in and then back out. The next LED (38) can get 5v and ground from the previous one (36).
I was thinking LEDs could be held in by simply stapling their wires to the pf. Using ribbon cable, the wires shouldn't need to be inlaid into a channel, but I was thinking about maybe cutting the wiring path as a very shallow line with the CNC machine just as a guide to use when wiring.
Edit: UGH! It didn't even occur to me that I had the wiring starting right in the path of the right carriage. Even if the FadeCandy PCB were mounted right on the PF at that point, it would make runs of GI lighting more difficult. I suppose the FadeCandy should be at the top, with the 2 runs starting from the top down, and then GI can start at the top with a run each going to the right and left from the top down the sides.
Reply
Wanna join the discussion? Please sign in to reply to this topic.
Hey there! Welcome to Pinside!
Donate to PinsideGreat to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
