(Topic ID: 133900)

Custom game: P3-ROC or FAST?

By Edenecho

8 years ago


Topic Heartbeat

Topic Stats

You

Linked Games

No games have been linked to this topic.

    Topic Gallery

    View topic image gallery

    fast-dbi-010-1.jpg
    fp-cpu-003-1.jpg
    switch_overview.png
    There are 89 posts in this topic. You are on page 1 of 2.
    #1 8 years ago

    Greetings! Long post imminent. Pinsiders likes to have opinions, and I would like some of yours especially if you have experience with either.

    I am tired of just talking about “what custom pinball themes would be cool” to make, and will try to actualize it into something real. Working on draft# 3 of the playfield design for a MASS EFFECT pinball, and the time has come to get a wood working.

    I have read about P3-ROC and FAST pinball boards , but I still feel I lack enough technical insight as to which I should choose. My criteria:
    1. I am a programmer, but I would still like good documentation and intuitive code/framework.
    2. As of now my only experience with wiring and such is from fixing machines. I would like the least amount of wiring and complexity, to the degree its possible of course. After all, we are talking about a pinball machine Also documentation/tutorial on how to setup everything with power supply, wiring and such is desired.
    3. Price.

    Currently this is what my machine will have:
    - 3 flippers
    - 1 Magnet
    - either a) 14 standup targets and 1 dropdown target or b) 6 standup targets and 9 dropdown targets
    (depends if the cost will shoot up with the extra 8 dropdowns input wise).
    - 1 spinner
    - slingshots (ofc)
    - NO popbumpers.
    - 2 ramps
    - A certain amount of rollover/gate switches for in/outlanes, orbits, ramps etc.
    - LCD display
    - Maybe a motor for rotating a toy (BDK's joker revealer) if possible.

    I got a tips from Gerry what a normal pinball machine would require:
    P3-ROC:
    1x P3-ROC 275$
    2x PD-16 200$
    4x SW-16 240 $
    1x PD-8x8 (for a lamp matrix) 100$
    1x PD-LED (for LEDs) 90$
    Total with VAT:1131$

    And then I saw the FASt bundle which is much cheaper but maybe have less of something:
    FAST Pinball core bundle: 499$
    (1) FAST Core Controller
    (1) FAST I/O 3208
    (1) FAST I/O 0804
    (1) FAST Smart Fuseblock
    (50) FAST RGB LED Inserts
    Total with vat: 623$

    But I assume there is some difference between those two,
    can anyone help me point them out? Would the FAST core bundle suffice?
    Also the Mission Pinball Framework seems very intuitive.

    If you are still reading this, thanks
    Morten

    #2 8 years ago

    Did FAST do your math for you?

    Just 4x Sw-16 amounts to $1k so you're well out there.

    You don't have to use the P3-ROC, you can use the standard and do away with most extras apart from the LED?

    That one has built in lamp/switch matrix. Only need for the switch boards is to make closer connections to them.

    #3 8 years ago

    With all respect due to Brian's awesome work on MPF, for me as a programmer, I don't find MPF to be as intuitive as a real structured programming language. That is, I'd rather code and use all of the Internet as a Python resorce --Python being a transferable skill and what not. That's just my biased opinion though.

    Going with a PROC affords you the opportunity to use either MPF, PyProcGame, or my PyProcGameHD+SkeletonGame (SDL2 graphics support, make games quicker, yadda yadda).

    The P-ROC family is mature. The PROC we run on campus typically has an uptime of about 200 days before I shut down a game (in the odd semesters when I'm not teaching students to code for the machine).

    I think the pricing on the Fast hardware site is being frequently confused as a "less expensive" option.

    That Fast Bundle gives you the ability to wire 40 direct switches and 12 drivers. All the Rgb leds are handled through a serial bus, which you can do on the P-ROC, too but comparing that to the pd-led is comparing apples and oranges. Anyway, if you're specing both options you really should equip them comparably!

    Instead of going with a P3-ROC, consider a P-ROC, which supports 32 direct switches and a 64 switches in a matrix, simultaneously (a total of 96 switches). It cannot use the sw16 add on boards, but that's a small price to pay if you don't mind wiring in a matrix. The proc is $325

    To build the same capabilities as that fast bundle (actually more capability since you can drive 16 drivers):
    +16 drivers on a pd16 (+$100)
    +teensy3.1+ws2811 board (+$45)
    +50 fast led boards ($64)

    $534 for a proc option. That's cheaper than the comparable fast bundle.

    Am I wrong?

    #4 8 years ago
    Quoted from Mocean:

    Anyway, if you're specing both options you really should equip them comparably!

    Absolutely, thats part what I need some help with getting correct, to get a fair comparison
    Also determine what i need and not need.

    Quoted from Mocean:

    Instead of going with a P3-ROC, consider a P-ROC, which supports 32 direct switches and a 64 switches in a matrix, simultaneously (a total of 96 switches). It cannot use the sw16 add on boards, but that's a small price to pay if you don't mind wiring in a matrix.

    If there is a way to avoid wiring it all in a matrix I would really prefer that (ie an easier way). Gerry wrote that the P3-roc made wiring MUCH easier, that is why I initially put that up against FAST. But he also said that I could go for the P-roc, in which I would use the following:
    1x P-ROC 325$
    1x PD-16/master 110$
    1x PD-16 100$
    1x PD-8x8 (for a lamp matrix) 100$
    1x PD-LED (for LEDs) 90$

    Total: 725 $

    But maybe I would not need all that is there? Though I am leaning slightly towards what makes it the easiest to wire and put together.

    #5 8 years ago

    That Fast setup only has 12 drivers. In general the stuff is fairly comparably priced, so if you're getting wildly different prices it's a good sign you've got a different configuration for one of them (although I've told Gerry that IMO the SW-16 boards are too expensive, but I don't think that's because of profit, they just seem to have a bunch HW on them to make them really flexible).

    The P-ROC community is MUCH larger, so if you want that shared suffering when things go wrong, cheers for successes, or checking out what / how other people are doing stuff that's a strong argument for that direction. Fast may or may not eventually get as large, they just started actually shipping so it's too early to tell.

    Disclaimers: I've been around in the P-ROC community since the start and helped on some code stuff. I've talked with the Fast guys but not used their hardware.

    #6 8 years ago
    Quoted from ecurtz:

    That Fast setup only has 12 drivers.

    Will that mean only room for example 12 coils?

    #7 8 years ago

    I went over my current playfield blueprint and tried to make a short list of the switches. As of now, it seems to be 44 switches, but Im sure there are some I might have missed.

    switch_overview.pngswitch_overview.png

    Forgot to add the magnet. But realize I have yet to research how a magnet works in pinball, if it is using a switch/or how it detects a ball passing over.

    #8 8 years ago

    You know, one thing you might consider to save some funds is to use a driver board and flipper board from a WPC machine. The Proc is set up out of the box to support them. The other thing you might want to use is a system 11 driver board. Search the proc forums for information on that option.

    One of the things I discovered working with my Proc on Popeye and Flash was that the programming is realitivly straight forward once you understand the framework and its limitations. The really hard part (at least for me) is the animation and music. On the surface it looks easy, but it is very time consuming to find the clips, edit them, and format them for use in a new machine. At least pyprocgamesHD makes incorporating them into the game.

    #9 8 years ago
    Quoted from Edenecho:

    I went over my current playfield blueprint and tried to make a short list of the switches. As of now, it seems to be 44 switches, but Im sure there are some I might have missed.

    Don't forget any cabinet switches - flippers, tilt, service buttons, etc.

    #10 8 years ago

    Good morning! I am getting my first cup of coffee and headed into the workspace here shortly. I'll chime in with some configuration options for you then. I can also include a new controller option we shared publicly for the first time at CAX that should be the right fit for you game form factor and $$$-wise.

    Aaro
    FAST Pinball

    #11 8 years ago

    I wouldn't let a switch matrix scare you. Once you understand how they work on a component level, I believe it is pretty easy to setup. Also, the column and row matrix driver hardware built right into the Proc. it's an 8x8 matrix, and it's already there. You might as well use it.

    #12 8 years ago

    If you're starting out, maybe MPF is a good option, I don't know and never will try it but they have the right idea with the documentation.

    Will be too much time learning pretty much the same thing (ported pyprocgame) = waste of time + rather not have dumbed down.

    Pyprocgame lacks docs to start with, some of it was confusing, unless you have a step up using Python already it's just another learning curve.

    I'm stuck in my ways already with the std pyprocgame , HD pyprocgame and Panda3D, these are more than enough for my needs and can't see me wanting to get into Skeleton game either. But again, if you're starting out maybe just jump on the Skeleton game will be best & p-roc.

    netprocgame will be a nice option as soon as it's released with Unit3D Pinball, no doubt I'll be jumping on that.

    #13 8 years ago
    Quoted from epthegeek:

    Don't forget any cabinet switches - flippers, tilt, service buttons, etc.

    Thanks, Knew there was some basic switches id forgot! Working with the design virtually has its tolls

    #14 8 years ago

    You might look into a pinheck board. Couldn't tell you for sure if it would work for your particular game, but I think it would be cheaper overall.

    #15 8 years ago

    Thank you for your patience! My having a bit of coffee is really better for all of us!

    After looking at your specs, here are some suggestions:

    Suggestion #1:

    (1) FAST Core Controller @ $269
    (2) FAST I/O 3208 @ $338 (2 x $169)
    (1) FAST Smart Fuseblock @ $24
    (50) FAST RGB LED Inserts @ $64
    ---------------------------------------------
    Total: $695 USD

    This gives you: Control of 256 RGB LEDs, 64 Direct Input Switches, 16 Drivers, Option for 2 Daughter Boards, hardware enable for switching off high voltage (tie to the coin door), Beaglebone Black interface (which includes: safe shutdown circuitry, audio codec and output), DMD interface, etc.

    Suggestion #2:

    (1) FAST Nano Controller @ $179
    (2) FAST I/O 3208 @ $338 (2 x $169)
    (1) FAST Smart Fuseblock @ $24
    (50) FAST RGB LED Inserts @ $64
    ---------------------------------------------
    Total: $605 USD

    This gives you: Control of 256 RGB LEDs, 64 Direct Input Switches, 16 Drivers, Option for 2 Daughter Boards, hardware enable for switching off high voltage (tie to the coin door), etc.

    The new FAST Nano Controller was the result of the growing trend towards LCD displays and the desire for a lower cost entry point into the FAST system. The FAST Nano Controller was first shared during our talk at CAX last weekend.

    fp-cpu-003-1.jpgfp-cpu-003-1.jpg

    You also mentioned the desire to add movement to toys. We have a Servo Motor Controller Daughter Board ($29) which controls up to 6 servo motors and seats directly into any of the FAST I/O boards.

    fast-dbi-010-1.jpgfast-dbi-010-1.jpg

    We certainly are new on the pinball hardware scene. We spent the last couple years developing the FAST hardware and the firmware/protocol that runs it. Traveling to shows around the country gave us the opportunity to meet a lot of people interested in building pinball. Many people came forward with advice and insight that they were compelled to share when they heard there was new hardware being developed. We studied the work of the forefathers and sought to bring in new technology to provide the solid base to build on for years to come.

    We were very excited to meet Brian and Gabe of Mission Pinball who added our hardware to the list of those supported by their Mission Pinball Framework (MPF). We worked hard to make sure that our hardware and firmware made that experience as smooth as possible. Plus it has been a lot of fun getting to know them! By working on the hardware while they work on their software, we have enjoyed the camaraderie that goes with it. I challenge you to find any pinball software better documented than the MPF! Brian is a documenting madman!

    While you certainly have options, we hope you would consider our offering. The active developer base using FAST hardware is small at the moment, but its growing with each package of hardware we ship. If you choose the FAST/Mission combo and find that the FAST hardware, support and community is not for you, you can always change hardware later and still use your code. But we will do our best to make sure that thought never crosses your mind!

    Yikes, this post is dragging on. Please let me know if you (or anyone else) have any questions. All these details and more will be coming onto our revised website here soon. I am not the documentation pro that Brian is, but its getting there!

    Aaron
    FAST Pinball

    #16 8 years ago

    open pinball project, still the cheapest solution out there (and open source). For around $100 you have everything you need to run a pinball machine minus a computer ($50) and an LCD monitor for the display ($40)
    https://openpinballproject.wordpress.com

    #17 8 years ago
    Quoted from Edenecho:

    1x PD-8x8 (for a lamp matrix) 100$
    1x PD-LED (for LEDs) 90$

    Is there a reason you are getting both a lamp matrix and a LED board? Usually it's one or the other.

    Might be able to shave off a little by going only with the PD-LED for your lamps.

    #18 8 years ago
    Quoted from pkiefert:

    Is there a reason you are getting both a lamp matrix and a LED board? Usually it's one or the other.
    Might be able to shave off a little by going only with the PD-LED for your lamps.

    It could be to have more RGB LEDs? The PD-LED says it only drives 28 RGB LEDs.

    Aaron
    FAST Pinball

    #19 8 years ago
    Quoted from fastpinball:

    It could be to have more RGB LEDs? The PD-LED says it only drives 28 RGB LEDs.
    Aaron
    FAST Pinball

    Or 84 traditional LEDs or a combination of both LEDs and RGB LEDs.

    #20 8 years ago
    Quoted from pkiefert:

    Or 84 traditional LEDs or a combination of both LEDs and RGB LEDs.

    For sure. I was just guessing at that being the reason for both.

    Aaron
    FAST Pinball

    #21 8 years ago

    Or you could use a teensy3.1+Octo2811 for $45, connected via usb to any controller pc (beaglebone, etc) and my code (based on MarkS/Snux's) and you can control something like 4096 Rgb LEDs from pyprocgame, including the Fast led boards ones. You don't need this option if you're using a fast board, but you will if you're using a proc family board since Gerry is quite vocal that he does not recommend the specific ws281x serial protocol under the playfield.

    #22 8 years ago
    Quoted from Mocean:

    ... but if you're using a proc family board since Gerry is quite vocal that he does not recommend the specific ws281x serial protocol under the playfield.

    That's correct. I specifically chose to develop a parallel LED drive system (PD-LED) because chained LEDs using single-ended digital control lines are not recommended for use under pinball playfields (noisy EM environments). While certainly much more convenient in theory, chained LEDs usage under a playfield is asking for trouble. Depending on a number of factors, they might work, and they might not. You likely won't know until you finish your machine build. IMO, any system encouraging the use of serial LEDs with single-ended control lines without explicit disclaimers informing users about the potential pitfalls should be avoided.

    You'll note that one of the bigger pinball manufacturers has avoided digitally controlled LED chains for this specific reason, and at least one other one is changing from serially chained LEDs to parallel ones after dealing with issues.

    That said, there are some situations where chained LEDs with single-ended control signals make sense in pinball machines (ie. above the playfield, away from changing magnetic fields). So we are adding a firmware option to our PD-LEDs to allow some of the pins to drive LED chains. When used in this manner (or in combination with the parallel outputs), the PD-LEDs will be able to drive 512 RGB LEDs each. The documentation will be sure to spell out the pitfalls of trying to use serial LED chains under the playfield and encourage users not to do it.

    - Gerry
    http://www.pinballcontrollers.com

    #23 8 years ago
    Quoted from toyotaboy:

    open pinball project, still the cheapest solution out there (and open source). For around $100 you have everything you need to run a pinball machine minus a computer ($50) and an LCD monitor for the display ($40)
    https://openpinballproject.wordpress.com

    Agree. I don't know why OPP doesn't get more love when it comes to custom pinball games.

    I'm using it to get my Bullseye301 running. Haven't had a lot of time to work on it, but I put up an initial post of the hardware on the board, just have to search for it.

    #24 8 years ago
    Quoted from pkiefert:

    Is there a reason you are getting both a lamp matrix and a LED board? Usually it's one or the other.
    Might be able to shave off a little by going only with the PD-LED for your lamps.

    Thats was just what Gerry wrote me as an option with P-Roc. Dont know enough about exactly what I need yet. I have made the list of switches, coils and will be starting on the inserts/lamps but that is bound to be changed as I am developing the rules, getting some new ideas etc.

    #25 8 years ago
    Quoted from Edenecho:

    Dont know enough about exactly what I need yet

    Once you know what you need, we can discuss exact sets of boards that will work for your specific situation. We intentionally designed a modular control system so you could piece together a system to meet your specific needs. This means you don't need to buy a bunch of features you'll never use, and you can add boards to the system if your needs expand.

    - Gerry
    http://www.pinballcontrollers.com

    #26 8 years ago
    Quoted from gstellenberg:

    That's correct. I specifically chose to develop a parallel LED drive system (PD-LED) because chained LEDs using single-ended digital control lines are not recommended for use under pinball playfields (noisy EM environments). While certainly much more convenient in theory, chained LEDs usage under a playfield is asking for trouble. Depending on a number of factors, they might work, and they might not. You likely won't know until you finish your machine build. IMO, any system encouraging the use of serial LEDs with single-ended control lines without explicit disclaimers informing users about the potential pitfalls should be avoided.

    For sure. If you don't follow best practice guidance (keep light runs short, don't run them in parallel to high current, adequately power them, don't use poor connectors, etc) there is the potential for noise/issues.

    But let's be honest here, Gerry specifically chose to develop a parallel LED drive system and not focus on chained LEDs because the RGB LEDs were not commonplace or affordable yet. As the price has come down, it made sense. We just intersected with the trend better because we started later. This also allowed us to implement a means of controlling lights and affordable RGB LED form factors that doesn't require you to limit the LED you use, RGB or white, based on price. If you use one of our RGB LEDs and it only ever stays white, no big deal. But Gerry is listening to demand and accommodating.

    We have chosen to focus on the promotion and support of the products we have developed. We are not going to make a proactive effort to stake "us vs. them" into every single thread that pops up on pinside. Gerry has his design choices and preferences, we have ours. Ford/Chevy. Coke/Pepsi. We tried to factor in all that we could into the choices we made and continue to do so. If we are pushing out a product, please know that we considered what it would take to support it. The risk/reward, the cost benefit, etc. We will certainly include best practice guidance for using RGB LEDs controlled in the method we implemented. Right now, most of that support is given one-on-one. This is making for a great basis for the documentation and guidance needed more broadly.

    Aaron
    FAST Pinball

    #27 8 years ago

    Aaron: the title of this thread and the point of the OP was specifically P-ROC vs Fast. So... this is totally the place for that, no?

    #28 8 years ago

    This thread seems to be an appropriate place for a technical discussion about our offerings. I'd love to see that happen without unsubstantiated assumptions made about design choices.

    Quoted from fastpinball:

    For sure. If you don't follow best practice guidance (keep light runs short, don't run them in parallel to high current, adequately power them, don't use poor connectors, etc) there is the potential for noise/issues.

    Short runs won't help. Adequate power won't help. Better connectors won't help.

    Shielded cables *may* help. Routing around noisy areas *may* help (if you can predict the noise patterns). There are certainly ways you can tried to reduce the chances of having problems running single-ended digital lines through noisy EM environments, but it should still be avoided when possible or at least used only when you're aware of the pitfalls.

    There's ample evidence in the industry of the problems with serially chained LEDs. Ignore at your own risk.

    Quoted from fastpinball:

    But let's be honest here, Gerry specifically chose to develop a parallel LED drive system and not focus on chained LEDs because the RGB LEDs were not commonplace or affordable yet.

    I replied above with my reason for choosing a parallel LED drive system. Your assumption (and implied accusation) is incorrect. Chainable LEDs were absolutely available and affordable when I designed the PD-LED in 2012. At least one other pinball manufacture was using them. Being available and affordable doesn't make them the right design choice. I chose a more expensive solution (parallel driven LEDs with a high pin-count FPGA) because it's more reliable and fault tolerant.

    Quoted from fastpinball:

    But Gerry is listening to demand and accommodating.

    Of course I'm listening to customer needs. I've made many changes to our products in response to them. That said, I'm also not going to recommend something that I don't feel is reliable; so I cannot in good conscience recommend using single-ended LED chains under a playfield. Further, I will absolutely encourage people not to design in features that are known susceptible to issues.

    Quoted from fastpinball:

    We have chosen to focus on the promotion and support of the products we have developed. We are not going to make a proactive effort to stake "us vs. them" into every single thread that pops up on pinside.

    You'd rather attack me then my products. That's fine, but I won't respond in kind.

    - Gerry
    http://www.pinballcontrollers.com

    #29 8 years ago
    Quoted from Mocean:

    Aaron: the title of this thread and the point of the OP was specifically P-ROC vs Fast. So... this is totally the place for that, no?

    Certainly. The point I was trying to make was I don't jump into threads with the intent to tear down other designs. Quotes like Gerry's below:

    Quoted from gstellenberg:

    IMO, any system encouraging the use of serial LEDs with single-ended control lines without explicit disclaimers informing users about the potential pitfalls should be avoided.

    "OMG! Stay away from FAST because they are using technology that when used improperly has the possibility of issues!"

    But these conversations are reminders that we MUST get our product details and documentations wrapped up (seriously, working on it in any spare minute I can!). So many of these questions would be answered! AND it would allow us to highlight what we think are big positives, too. Like how getting your FAST hardware up and running and communicating with the controlling PC only takes the installation of the FTDI Virtual COM Port driver. Or how getting the Mission Pinball Framework to run on FAST only requires defining the 3 FAST COM ports in the MPF config file.

    Aaron
    FAST Pinball

    #30 8 years ago

    I understand it might get abit heated between devs when comparing products, I just wanted to get input on the technical and practical differences between the two systems and what would suit my needs (some which I am also working out long the way).

    I agree that documentation surely will answer alot of my questions, and also Im sure there are questions I havent even thought of yet, so looking forward to it. Its also very valuable to hear from users of each of the systems, since they usually dont have the same marketing/financial interest as the owners/developers of a product normally have

    #31 8 years ago
    Quoted from gstellenberg:

    You'd rather attack me then my products. That's fine, but I won't respond in kind.

    Where was I attacking you personally?

    The closest to an attack was the assumption that you probably didn't design your LED controller firmware to run serial RGBs because it wasn't commonplace or affordable. I applogize if my assumption was off. In the time we have been doing this since early 2013ish, this has been true. RGB LEDs have become more affordable and useful in the WS2812 package. I wasn't saying that you weren't aware of the tech or anything like that. This is the same way that we are watching other LED technology pricing come down so we can make other form factors and controllers that allow us to get them to market in a way that makes sense for our business and makes them affordable to users.

    I may be frustrated by the tone of your comments from time to time or getting pounced on by your buddies, but I don't mean to make this personal. Heck, I had even posted about my Lexy experience at CAX earlier: https://pinside.com/pinball/forum/topic/lexy-lightspeed-cax-2015#post-2580144

    I don't want bad blood between us. I respect the engineering work you do. Seriously. When you came by our booth at CAX I was excited to show you what we had built because I figured you, more than most, would appreciate all the hard work that it takes to make hardware. Plus the FAST WPC Controller you were holding I built by hand (like 350+ tiny surface mount parts!). When you asked where we made our PCBs, we shared it with you. No big deal.

    Let's conduct ourselves like we do in person. Civil and respectfully. I'll do my best to make sure my posts don't skew personal. If they could be taken that way, please give me the benefit of the doubt. I will do the same for you.

    Aaron
    FAST Pinball

    #32 8 years ago
    Quoted from taylor34:

    You might look into a pinheck board. Couldn't tell you for sure if it would work for your particular game, but I think it would be cheaper overall.

    No lcd. Big no no for 2015 => Future

    #33 8 years ago
    Quoted from horseypin:

    No lcd. Big no no for 2015 => Future

    Good to know. I like DMD for the..retro sakes, but I have decided I want to use an LCD for this project.

    #34 8 years ago

    OK, Aaron, sounds like we're on the same page now. I obviously appreciate your candid and positive thoughts about the P3, and I always enjoy discussions about technical features and reasons for technical decisions on all of our products. We have competing and very similar control system products; so some of the conflicts are unavoidable. Creating and supporting innovative pinball machines and products is my full-time job (with very long hours), and I've lived and breathed these technical discussions for over 6 years now. So, intentional or not, it's all a bit personal.

    Edenecho,

    If you have specific features for which you'd like to understand implementation differences, by all means let us know. The first post compared pricing on two very dissimilar configurations.

    - Gerry
    http://www.pinballcontrollers.com

    #35 8 years ago
    Quoted from gstellenberg:

    OK, Aaron, sounds like we're on the same page now. I obviously appreciate your candid and positive thoughts about the P3, and I always enjoy discussions about technical features and reasons for technical decisions on all of our products. We have competing and very similar control system products; so some of the conflicts are unavoidable. Creating and supporting innovative pinball machines and products is my full-time job (with very long hours), and I've lived and breathed these technical discussions for over 6 years now. So, intentional or not, it's all a bit personal.
    Edenecho,
    If you have specific features for which you'd like to understand implementation differences, by all means let us know. The first post compared pricing on two very dissimilar configurations.
    - Gerry
    http://www.pinballcontrollers.com

    Right on, man.

    Aaron
    FAST Pinball

    #36 8 years ago
    Quoted from gstellenberg:

    If you have specific features for which you'd like to understand implementation differences, by all means let us know. The first post compared pricing on two very dissimilar configurations.

    Yup I get that now, part of the reason I wanted input because I thought there had to be some differences, I just did not know what. Ill go deeper through the posts tomorrow and will get back with more details/question im sure, Im still quite "in the dark" as to what may suit my needs and eager to learn more about what both system offers and what suits me.

    #37 8 years ago
    Quoted from gstellenberg:

    That's correct. I specifically chose to develop a parallel LED drive system (PD-LED) because chained LEDs using single-ended digital control lines are not recommended for use under pinball playfields (noisy EM environments). While certainly much more convenient in theory, chained LEDs usage under a playfield is asking for trouble.

    First off; this is new to me, and therefore a little "greek" as we say over here

    What is visually the difference between chained leds and led inserts through the pd-led? Are chained basicalle one single chain going through every led under the playfield while with the pd-led its one wiring out to each led insert and back to the board?

    #38 8 years ago

    I have a PROC and I will say that the customer support that Gerry provides is excellent. I had trouble getting my TZ working and Gerry (and the PROC community) were invaluable in getting the issue resolved. Quick, friendly, and efficient.

    I haven't used FAST so I can't comment on their customer support but I know that PROC is top notch. It's helpful to be able to post a question on pinballcontrollers.com and get an answer in a short amount of time, especially if you're new to custom pinball.

    #39 8 years ago
    Quoted from Edenecho:

    What is visually the difference between chained leds and led inserts through the pd-led?

    Visually, as in how the LEDs look? It depends. If you want to update your LEDs slowly, there's likely no difference. If you want to update your LEDs very quickly, you might run out of bandwidth for LED chain updates. Each time you want to update any LED in the chain, you have to shift data all the way through the other LEDs. Certain systems don't have enough bandwidth to update the entire chain 30-60 times a second for smooth LED fading, resulting in noticeable flicker. This depends on the number of LEDs in the chain and the bus bandwidth.

    Quoted from Edenecho:

    Are chained basicalle one single chain going through every led under the playfield while with the pd-led its one wiring out to each led insert and back to the board?

    From a wiring perspective, that's essentially it, though some chain controllers support multiple chains. From a control signal perspective, chains involve single-ended digital control signals that are passed through each LED to the next. Digital noise on those lines will screw up the data (resulting in incorrect color data being sent to the LEDs). Voltage spikes on those lines can kill the chips (the chips are actually LEDs + integrated circuits for control). Parallel LED circuits typically drive individual color enables to each diode on the LEDs. Digital noise on those lines is imperceptible visually, as are typical voltage spikes.

    As always, there are a lot more technical details that are beyond the scope of this discussion, but as general guidance:

    If you want simplified wiring and less expensive control logic, and if you're ok with the potential of your LED boards dying, go with the LED chains.
    If you're ok with the parallel wiring and more expensive control logic, and if you want your LED subsystem to be more reliable and fault tolerant, go with the parallel connected LEDs.

    - Gerry

    #40 8 years ago
    Quoted from Edenecho:

    What is visually the difference between chained leds and led inserts through the pd-led? Are chained basicalle one single chain going through every led under the playfield while with the pd-led its one wiring out to each led insert and back to the board?

    "Chained" means that the RGB signals are all driven from a single, common source. The LED is enabled by a bit that shifts through the chain. As this bit shifts down the chain, the RGB levels change for the next LED in the chain. Once you've shifted through the entire chain, the whole process repeats itself. This bit is driven by a single ended driver. It's a clock signal more or less and is the source of all of the headaches Gerry is RIGHTFULLY warning you about. Quite frankly, Gerry could modify his FPGA in about an hour to support chained LEDs and announce support for them using PROC (hell, I'll write the damn verilog myself! ). He won't because he is 100% correct ... they are problematic under a pinball machine playfield. Yes, you would only need 4 wires for signaling, but you will have problems with that clock wire if it is single ended.

    "Parallel" means that you will have three wires driving each LED for a red, a green, and a blue level. If you want to drive 8 RGB LEDs, you will need 24 wires. It's more painful to wire up and it costs more, but it is the proper solution (unless the chained LEDs use a differential signal ... then then and only then will chained LEDs be acceptable for pinball use).

    In terms of visual appearance while playing, you won't see any difference if you're driving serial LEDs properly vs their parallel brethren so long as you're using a reasonable timing on the LED chain and there is no noise. It basically comes down to lighting an LED for X uS then shifting the "enable" bit downstream to light up the next LED for a few uS ... rinse, lather, repeat.

    I work in the robotics industry, develop FPGAs for a living, and design a PCB here and there ... I deal with noise all of the time on high speed serial links for vision applications.

    Trust me, use the parallel solution. You are going to save yourself a LOT of grief in the long run. You WILL have intermittent light failures using single ended chained anything under a pinball machine playfield. Shielding won't help, routing won't help, nothing will help.

    You have a shot at getting lucky and things may work at first. However, you might bump a solenoid a few mm closer to a single ended wire and suddenly cause intermittent bit flipping every X number of times that solenoid fires. Hell, I've wired up piss poor examples of single ended connections that would cause a clock on a wire to go crazy if you move your HAND past said wire just as an example as to why long, single ended traces/wires are silly (I'm being a bit unfair as there was zero ground wire near the clock wire, but you get my point).

    While I am no device physics expert (I know people that understand this stuff as if it were "normal" to understand this stuff ), I do know enough that differential wiring and differential routing do plenty to control effects from noise. A differential receiver is looking for a difference between two voltages to signal a one or a zero. A differential driver drives a signal at a + level on one line and a - level on another like. They are intertwined ... the intertwining has the effect of canceling out some noise. More importantly is how the receiver works. Again, the receiver looks for a difference between the two voltages. If some kind of noise is induced on the twisted pair and causes the lines to move to a higher or lower potential, the receiver will still interpret the one or zero properly because it is merely focused on a difference and the wires will tend to drift in the same direction.

    Now, single ended connections require a voltage threshold to indicate a zero or one. Let's say you have a single ended wire driving the clock input of a flip flop (or the lamp select input on your serial LEDs) with a threshold voltage of 1.8V that is rising up to 3.3V. Now, let's say a solenoid fires, induces a spike on the single ended line that causes a fast ramp rate, spikes the signal up to 4V, causes a swing down to 1.5V for about, I dunno, 60 us, and swings back up and levels off at 3.3V. See the problem? You've caused two clock edges to occur ... you might get lucky and 60us would be ignored by one LED for a bunch of different reasons. You might have an LED that is sensitive to the 60us time and it might flip state. If you were using a differential input clock, the + line would jump up to 4V, but the negative line would also follow suite ... no glitch occurs .

    There's also the issue of noise causing stress on the inputs when the voltages swing really high or low, but the amount of time the voltage is out of spec usually causes no damage.

    You want to think of all of those single ended connections as mini antennas too. You will induce electromagnetic currents on that antenna and will get intermittent bit flips thanks to pinball solenoids. A bit flip in a one hot shift register (which is all an LED chain is) is pretty much fatal . These kinds of errors are a complete pain in the ass to debug ... especially when you are writing brand new software and have no idea if you light show issues are your fault or some hardware failure.
    Moreover, these kinds of problems make game coding not much fun if you ask me . I'd rather be solving gameplay problems vs. hardware failures.

    Do yourself a favor, just get the system that offers the parallel LEDs ... you will never thank me for this suggestion as you will NOT have any issues at all, thus no need for thanks .

    Good luck on your game!!! You home brew authors do some amazing stuff!!!

    #41 8 years ago
    Quoted from Edenecho:

    Yup I get that now, part of the reason I wanted input because I thought there had to be some differences, I just did not know what. Ill go deeper through the posts tomorrow and will get back with more details/question im sure, Im still quite "in the dark" as to what may suit my needs and eager to learn more about what both system offers and what suits me.

    It may have been a lot easier if you said what language you are proficient in. Should help to make your mind up along with costs and all the other jargon's being thrown at you here?

    Python > pyprocgame or mpf
    Java > go netprocgame
    C# > go netprocgame
    C++ == ?

    #42 8 years ago

    I am mainly developing in C# (through work), but thats means java is also basically the same, also I started out with java throughout my bachelor. I actually thought of programming this pinball through some framework based on python could be a nice way to also get into Python. I might be wrong, but I dont think the langauge in itself is the main obstacle as long as the framework is well documented and contains examples, tutorials etc. The physical part is probably more challenging.

    I read through some of the MPF documentation yesterday and it seemed quite okay.

    So I guess the language in itself is not that important for my choice if it is between C# or Python (even though they are quite different). Currently I am programming a little in VBScript for future pinball, so I can adapt to new language if there is tutorials and documentation/examples. But good point, Horseypin.

    Will check into netprocgame.

    #43 8 years ago
    Quoted from megadeth2600:

    "Chained" means that the RGB signals are all driven from a single, common source. The LED is enabled by a bit that shifts through the chain. As this bit shifts down the chain, the RGB levels change for the next LED in the chain. Once you've shifted through the entire chain, the whole process repeats itself. This bit is driven by a single ended driver. It's a clock signal more or less and is the source of all of the headaches Gerry is RIGHTFULLY warning you about. Quite frankly, Gerry could modify his FPGA in about an hour to support chained LEDs and announce support for them using PROC (hell, I'll write the damn verilog myself! ). He won't because he is 100% correct ... they are problematic under a pinball machine playfield. Yes, you would only need 4 wires for signaling, but you will have problems with that clock wire if it is single ended.
    "Parallel" means that you will have three wires driving each LED for a red, a green, and a blue level. If you want to drive 8 RGB LEDs, you will need 24 wires. It's more painful to wire up and it costs more, but it is the proper solution (unless the chained LEDs use a differential signal ... then then and only then will chained LEDs be acceptable for pinball use).
    In terms of visual appearance while playing, you won't see any difference if you're driving serial LEDs properly vs their parallel brethren so long as you're using a reasonable timing on the LED chain and there is no noise. It basically comes down to lighting an LED for X uS then shifting the "enable" bit downstream to light up the next LED for a few uS ... rinse, lather, repeat.
    I work in the robotics industry, develop FPGAs for a living, and design a PCB here and there ... I deal with noise all of the time on High Speed serial links for vision applications.
    Trust me, use the parallel solution. You are going to save yourself a LOT of grief in the long run. You WILL have intermittent light failures using single ended chained anything under a pinball machine playfield. Shielding won't help, routing won't help, nothing will help.
    You have a shot at getting lucky and things may work at first. However, you might bump a solenoid a few mm closer to a single ended wire and suddenly cause intermittent bit flipping every X number of times that solenoid fires. Hell, I've wired up piss poor examples of single ended connections that would cause a clock on a wire to go crazy if you move your HAND past said wire just as an example as to why long, single ended traces/wires are silly (I'm being a bit unfair as there was zero ground wire near the clock wire, but you get my point).
    While I am no device physics expert (I know people that understand this stuff as if it were "normal" to understand this stuff ), I do know enough that differential wiring and differential routing do plenty to control effects from noise. A differential receiver is looking for a difference between two voltages to signal a one or a zero. A differential driver drives a signal at a + level on one line and a - level on another like. They are intertwined ... the intertwining has the effect of canceling out some noise. More importantly is how the receiver works. Again, the receiver looks for a difference between the two voltages. If some kind of noise is induced on the twisted pair and causes the lines to move to a higher or lower potential, the receiver will still interpret the one or zero properly because it is merely focused on a difference and the wires will tend to drift in the same direction.
    Now, single ended connections require a voltage threshold to indicate a zero or one. Let's say you have a single ended wire driving the clock input of a flip flop (or the lamp select input on your serial LEDs) with a threshold voltage of 1.8V that is rising up to 3.3V. Now, let's say a solenoid fires, induces a spike on the single ended line that causes a fast ramp rate, spikes the signal up to 4V, causes a swing down to 1.5V for about, I dunno, 60 us, and swings back up and levels off at 3.3V. See the problem? You've caused two clock edges to occur ... you might get lucky and 60us would be ignored by one LED for a bunch of different reasons. You might have an LED that is sensitive to the 60us time and it might flip state. If you were using a differential input clock, the + line would jump up to 4V, but the negative line would also follow suite ... no glitch occurs .
    There's also the issue of noise causing stress on the inputs when the voltages swing really high or low, but the amount of time the voltage is out of spec usually causes no damage.
    You want to think of all of those single ended connections as mini antennas too. You will induce electromagnetic currents on that antenna and will get intermittent bit flips thanks to pinball solenoids. A bit flip in a one hot shift register (which is all an LED chain is) is pretty much fatal . These kinds of errors are a complete pain in the ass to debug ... especially when you are writing brand new software and have no idea if you light show issues are your fault or some hardware failure.
    Moreover, these kinds of problems make game coding not much fun if you ask me . I'd rather be solving gameplay problems vs. hardware failures.
    Do yourself a favor, just get the system that offers the parallel LEDs ... you will never thank me for this suggestion as you will NOT have any issues at all, thus no need for thanks .
    Good luck on your game!!! You home brew authors do some amazing stuff!!!

    Thanks for a VERY detailed and informative post regarding the lightning, it is somewhat brighter (hehe) for me now

    Is this still as relevant/not that relevant if I wont have no RGB LEDS, just plain white and single colored LEDS for different inserts?
    Havent yet decided, there are som spots where RGB leds could be useful making jackpots/mode arrow inserts change colour based on the mode, but most of the inserts wont be needing more than one color. as of now at least

    #44 8 years ago

    Don't waste your time scripting with FP imo. You could learn vbs with VP & also Python.

    "Try before Buy" with VP & pyprocgame.

    I moved a wordpress blog over yesterday to the new Minds.com and do have a couple of guides for setting up.

    https://www.minds.com/blog/view/470998283494371328/p-roc-with-vp-10-setup
    https://www.minds.com/blog/view/470994854273363968/easy-setup-for-lamps-visual-pinball-and-pyprocgame

    There should also be a starter table over on Pinball controllers.

    MPF = no virtual platform.

    Bilbox stated that Unit3D was also going to be able to link to existing boards, so you can also use Unit3D and netprocgame as a virtual platform to develop on as well as your machine.

    #45 8 years ago

    I plan to make both these guides outdated very soon. I've rewritten the single-click installer so things like the zlib error and DPInst problems are fixed, and I intend to make a second add-on installer that will add VP support automatically.

    As for which language to go with, you can get a flavor for what the pyprocgame (or PyprocgameHD or SkeletonGame) code is like from the admittedly incomplete documentation, here: http://pyprocgame.pindev.org/manual.html

    I had been planning to take over the pyprocgame documentation, but that was before I wrote PyProcGameHD and SkeletonGame on top of that. (WIP Docs at: http://pinballprogramming.com)

    There has been years of game development of many proc/pyprocgame based projects so the forums are full of answers and helpful folks. There's a lot of open source games to look at for answers. MPF might be new, but Brian is clearly committed to making it a reality. It's core concept of BallHoldDevices is from FreeWPC, and that's a very solid abstraction idea.

    The good news is, it's a great time to be starting such a project, which ever path you take.

    Plus, it's a lot of fun

    #46 8 years ago

    Serial driven LEDs are never a good idea under a pinball playfield IMHO.

    --
    Rob Anthony
    Pinball Classics
    http://LockWhenLit.com
    Quality Board Work - In Home Service
    borygard at gmail dot com

    #47 8 years ago

    Well the zlib isn't a problem for all, including myself, that issue came from others that tested my games and DPInst doesn't really matter virtually testing.

    To make those very simple failsafe guides outdated you're already 6 months + too late (it's just a small update to the normal old wiki setup) and I waited a long while for your guide before making them. They're for people that play my games and why not post them to OP who clearly doesn't know about this?

    You said the same thing about starter tables and not to bother before because ""You were going to do it", but nothing ever surfaces. Yes you're busy the same as everybody else, but same old same old mate.

    Don't take that as too much of a dig because I've appreciated every single second you put into this. I wouldn't have 5 p-roc games to my name if it wasn't for you either, not anyone else, but you had been the most helpful.

    Unit3d is "hopefully" going to make the virtual process with VP/pyprocgame obsolete for me anyway. I feel there's far more opportunity using C# and that's mostly because I have more experience with that language than Python and they have a better graphics engine, Unity. It's far more advanced and easier than pygame, panda.

    I'm hoping it doesn't take me too long to port over to netprocgame.

    But do I convert a 90% finished game over to netprocgame? This probably isn't worth the time and to just to stick with a perfectly working pyprocgameHD , buy p-roc, just build the machine and be done with it and move onto the next, but any future creations I would like to move to c#.

    #48 8 years ago
    Quoted from horseypin:

    You said the same thing about starter tables and not to bother before because ""You were going to do it", but nothing ever surfaces. Yes you're busy the same as everybody else, but same old same old mate.

    Nothing ever surfaces?

    Quoted from horseypin:

    Don't take that as too much of a dig because I've appreciated every single second you put into this. I wouldn't have 5 p-roc games to my name if it wasn't for you either, not anyone else, but you had been the most helpful.

    How could I not take it as "too much of a dig" --you are discrediting me on a public forum saying I'm always too late and nothing_ ever surfaces?

    By your own admission: You run my Visual Pinball-PROC bridge. I supplied you with tons of help and code. You run my VGA version of pyprocgame?

    Nothing? How about the truth, just not enough for you.

    Your idea of gratitude stinks. No good deed goes unpunished.

    Good luck with MPF, Brian. This is what you have to look forward to.

    #49 8 years ago

    You have told me "not to bother" writing guides, starter tables before because you were going to do them and you did it again.

    That has nothing to do with Gerrys bridge & framework ports. You read in between the lines and it's not the first time either.

    #50 8 years ago

    Well this was slightly derailing guys, feel free to take those personal discussions through pm's. I am not programming my idea finished in fp, thats just playing around to get a little feel with music, some basic lights etc but primarily making a playfield blueprint.

    I tried a little vp but it feels so outdated visually which kinda turns me off somewhat. The plan is not to maje a complete virtual pinball before making it physical.

    There are 89 posts in this topic. You are on page 1 of 2.

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great 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+!


    This page was printed from https://pinside.com/pinball/forum/topic/custom-game-p3-roc-or-fast and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.