(Topic ID: 156038)

FAST or P-ROC controllers?

By iko

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-power-filter-supplies_(resized).jpg
    Screen_Shot_2016-04-08_at_10.07.00_PM_(resized).png
    Screen_Shot_2016-04-08_at_10.06.34_PM_(resized).png
    project-thunderdome-cc_(resized).jpg
    debounceswitcho_(resized).jpg
    IMG_20160406_103114_edit_(resized).jpg
    WP_20160325_23_39_23_Pro_(resized).jpg
    science-dog1_(resized).jpg
    337fdc973ee7960404af000ced85f3be70aa2258165264b03643349aa86f9593_(resized).jpg

    There are 187 posts in this topic. You are on page 3 of 4.
    #101 7 years ago
    Quoted from Mocean:

    Stay classy.

    Is it not true? Go back and look at the post history, or maybe check the PMs Rosh has sent me.

    I'm really a chill dude, but this is ridiculous.

    #102 7 years ago

    its really hard to stay nice

    #103 7 years ago
    Quoted from Wolfmarsh:

    Is it not true? Go back and look at the post history, or maybe check the PMs Rosh has sent me.
    I'm really a chill dude, but this is ridiculous.

    Regardless of your history with Rosh, what does that have to do with the PROC and FAST boards and how one performs over the other? If its getting old, don't feed the fire.

    #105 7 years ago
    Quoted from Nelly:

    Regardless of your history with Rosh, what does that have to do with the PROC or FAST board and and how one performs over the other? If its getting old, don't feed the fire.

    You're right. I shouldn't have left that last sentence there, and I've now removed it. I'll stay focused on the differences in the platforms.

    #106 7 years ago

    I find it difficult to say good or bad about either board or software without Successfully using it. Really bothers me when people say stuff about something that they have never experienced. Even when they say anything without completing a game in general brings me annoyance

    #107 7 years ago

    It's too easy for things to take an unpleasant turn in these threads. I always want the conversations in threads to be as if we were all sitting in the same room talking about making pinball. Like when we are all Expo or any other show. Sure, we are all in our respective camps, but that didn't stop us from chatting in person as people who like to build pinball. I am pretty sure every P-ROC user in this thread who was at Expo made their way to the FAST booth to see the games people were building. Just as all the FAST users at Expo went to check out all the P-ROC games. There aren't THAT many people doing what we do, so just because someone's game runs a different hardware set, doesn't mean I wouldn't want to check it out and learn more about it.

    Rosh and I have disagreed on threads in the past, but I will always seek him out and see what's going on with his projects. MOcean loooooves to pick at me in the forums, but in person, we were civil and talked about what he has done on the Buffy pin. Believe it or not, even Gerry and I talk at each show we cross paths at.

    I think that is why it hurts sometimes that these forum threads turn out this way. I really try to conduct myself here just as I would in real life. Maybe in person, people are faking it, I don't know. I would hope not.

    Aaron
    FAST Pinball

    #108 7 years ago
    Quoted from Bonnevil69:

    I find it difficult to say good or bad about either board or software without Successfully using it. Really bothers me when people say stuff about something that they have never experienced. Even when they say anything without completing a game in general brings me annoyance

    Well, I have used both. So don't dismiss me as biased either.

    I had it working *successfully* with p-roc apart from the faster bus speed picking up on some bit changes from the ground bounce. (It's now filtered better in firmware, I'm told.)

    I have it working well now on FAST. (You saw it at Expo.)

    But my experience with it and opinions don't seem to count.

    #109 7 years ago

    well you got me there Mark. lol. But you just annoyed me because you haven't completed a machine Mohahaha

    #110 7 years ago
    Quoted from Bonnevil69:

    well you got me there Mark. lol. But you just annoyed me because you haven't completed a machine Mohahaha

    I'm getting there! I'm just slow.

    #111 7 years ago
    Quoted from fastpinball:

    It's too easy for things to take an unpleasant turn in these threads. I always want the conversations in threads to be as if we were all sitting in the same room talking about making pinball. Like when we are all Expo or any other show. Sure, we are all in our respective camps, but that didn't stop us from chatting in person as people who like to build pinball. I am pretty sure every P-ROC user in this thread who was at Expo made their way to the FAST booth to see the games people were building. Just as all the FAST users at Expo went to check out all the P-ROC games. There aren't THAT many people doing what we do, so just because someone's game runs a different hardware set, doesn't mean I wouldn't want to check it out and learn more about it.
    Rosh and I have disagreed on threads in the past, but I will always seek him out and see what's going on with his projects. MOcean loooooves to pick at me in the forums, but in person, we were civil and talked about what he has done on the Buffy pin. Believe it or not, even Gerry and I talk at each show we cross paths at.
    I think that is why it hurts sometimes that these forum threads turn out this way. I really try to conduct myself here just as I would in real life. Maybe in person, people are faking it, I don't know. I would hope not.

    It shouldn't be easy for things to take an unpleasant turn in these threads! Why is this familiar?

    You have written more than 20% (as of now) the posts in this 100+ post thread, so I would say you've driven the direction. Now you're insinuating that there is or should be some kind of animosity between usergroups, designers, and manufacturers. Of course you and Gerry talk, why wouldn't you? I don't get it.

    I don't think the OP was asking for the designers of this system to battle it out, they just wanted some opinions from users. I like the approach of stating a few facts, maybe provide a link or contact information for people that have follow-up questions. The flood of assertions is a turn-off, particularly when they appear to be sniping specific comments and trying to pull them apart. There's also obviously a lot of history here, and vague references to stuff or specific people makes very little sense, at least to me.

    People just need to chill! Pinball is fun!

    #112 7 years ago
    Quoted from Law:

    You have written more than 20% (as of now) the posts in this 100+ post thread, so I would say you've driven the direction. Now you're insinuating that there is or should be some kind of animosity between usergroups, designers, and manufacturers. Of course you and Gerry talk, why wouldn't you? I don't get it.
    I don't think the OP was asking for the designers of this system to battle it out, they just wanted some opinions from users. I like the approach of stating a few facts, maybe provide a link or contact information for people that have follow-up questions. The flood of assertions is a turn-off, particularly when they appear to be sniping specific comments and trying to pull them apart. There's also obviously a lot of history here, and vague references to stuff or specific people makes very little sense, at least to me.
    People just need to chill! Pinball is fun!

    We have definitely gone down the path these threads usually do. An initial question draws us all back into the thread and we get where we do.

    I need to stay focused on our content and docs so it is easier for people to do their own research and comparisons more easily. This will let potential users ask more specific questions that the docs, guides, videos do not cover. Then we don't need to debate in a forum loaded with assumptions or a lack of information, instead we can discuss design choices, best ways (opinions, of course) to accomplish certain tasks, etc.

    I have got some stuff to wrap up today and then I'll be getting ready to stream this evening. Should be online at 7pm PST at twitch.tv/fastpinball

    I'll have a fresh whiteboard up to jot down all the good questions that need to make it into our docs!

    Aaron
    FAST Pinball

    #113 7 years ago
    Quoted from Wolfmarsh:

    Is it not true? Go back and look at the post history, or maybe check the PMs Rosh has sent me.

    Just to be clear, I don't do Gerry's bidding, or anyone else's, if you feel I was sent to 'ride your nuts', as you so elegantly put it, I can assure you that was not the case. I don't need anyone to tell me when or how I should voice my opinions. Anyone who knows me will tell you that I speak my mind and I don't kowtow to anyone. If I PM someone is for the purpose of allowing me to speak my mind to someone, without making it public or bringing other folks into it, or derailing a thread, as has now happened here, but since I felt this to be a personal attack on my character, I had no choice but to respond here. And as far as the PM, that I am sure you are referencing, I think you well see how others have now acknowledged publicly what I was talking about. If you had issue with what I PMd, you certainly could have responded back with your issues with what I said. I have always respected your opinions, even when we have disagreed. We certainly don't have to agree on everything or even anything, but I'd like to think we can express and communicate our thoughts directly and privately when appropriate.

    As I have said in the past, I try to be supportive of everyone in the homebrew and boutique space, regardless of what hardware or software they are using. I also give credit where credit is due, as I did earlier this week when in a slack channel when I was acknowledging Brian when talking about how easy it was to hook up a Stepper to the P-roc, based on the work he had done. I have sent you PMs and made posts on a range of things to help you with Spaceballs, as I have done on dozen of other projects. And to make one more point about working together in the community, from now on when you are doing a config, and you type the word "Tock", please think of me, since that was a term I had proposed to Brian when a bunch of us were dialoging around timing things for lampshows, etc. It was an insignificant contribution and certainly not looking for credit or acknowledgement, just want it to be like a song stuck in your head.

    #114 7 years ago

    You mean these tocks?

    "(D) Tocks: are gone, shows now operate on real-world time"

    https://missionpinball.com/docs/mpf-0-30-release-notes/

    I think it's better if we just avoid each other.

    Consider that my gentle request, that you don't reach out to me again, especially privately.

    #115 7 years ago

    De-ja-vu. All these threads end up with a 'war of the boards', my mums better than your mum bollox.

    The only thing I would say is better (just by nosing) is MPF support, ten fold. I probably would never use it myself because I've done enough pyprocgame and I'm currently leveraging a .net version from compys port.

    If you have no python experience or think you may struggle I would advise to use MPF, but it doesn't matter on the board you choose, right? Having made boards since 2009 makes no odds to the software & quiet support.

    #116 7 years ago
    Quoted from Wolfmarsh:

    You mean these tocks?
    "(D) Tocks: are gone, shows now operate on real-world time"
    https://missionpinball.com/docs/mpf-0-30-release-notes/
    I think it's better if we just avoid each other.
    Consider that my gentle request, that you don't reach out to me again, especially privately.

    Moving to time based, that makes sense and it was I had originally suggested to him to better synch with videos, etc. Guess you need to go update the configs you have on github, although I think Jan said that there are upgrade scripts that can handle that.

    You are welcome to avoid me (or ignore me), but as I said, I don't kowtow to anyone, but I will certainly respect your request to not private message you.

    15
    #117 7 years ago

    I'd like to add some perspective here as one of the core devs of MPF, and as someone who wrote the original platform interface for MPF for both P-ROC / P3-ROC and FAST, so I *really* know the ins and outs of each hardware platform, possibly better than anyone in the world. (I mean I am one person who knows both at a really, really low level, both in terms of hardware and APIs. Obviously the designers of each platform know their own stuff way better than me.)

    First, both hardware platforms work fine. (I don't mean in MPF, I mean in general.) Neither vendor is selling a bad product. Sure, some users started on P-ROC and moved to FAST, some will start on FAST and move to P-ROC, some will use P-ROC forever, some will use FAST forever. But really if you're making a home brew machine, you can pick either and be fine.

    Designing a pinball controller platform involves a million little trade-offs. Connector style, fuse style, board layout, driver architecture, etc, etc. Both the FAST and P-ROC systems were designed by professional engineers who do EE as their main day jobs (Gerry Stellenberg for P-ROC, Dave Beecher for FAST.) They are both competent, professional designers--not guys moonlighting or pretending to know what they're doing. Obviously each of them made the decisions that made the most sense to them based on their experience and what they were doing with their hardware.

    Of course it's easy to pick apart the minutiae of one platform versus another, and when you stack up all the "negatives" of one platform you can come up with a huge list that makes it look like that designer was incompetent. But that is true of anything. The reality is that both platforms are 99% identical for 99% of users, so of course the only way you can compare them is to focus on the 1% that's actually different, which is really minor in the grand scheme of things. (I mean really, when you're talking advantages/disadvantages of RJ-45 connectors versus Molex, you're really getting into the "frosting" of things.)

    All the differences between the two platforms are ideological. Linear versus switching power supplies. Fuse location. Bus speed. Openness of a protocol versus openness of a daughter board. Through-hole versus SMD. Combined versus discrete boards. Serial versus direct LEDs. Library written in C that lives on the host computer versus library written in C that lives on the controller board, etc, etc. (And there are probably hundreds more differences at this level between the two of them.) If every customer made their own list of these types of things and called them "must haves", then no one would buy anything and everyone would design their own boards.

    Comparing P-ROC to FAST is like comparing a 2016 Honda Accord to a 2016 Toyota Camry. For 99% of consumers, in 99% of use cases, they are for all intents the same car. Yeah, you can find little differences here and there and blow them up to be huge ("I need my cupholder here, not there!"), but taking a step back, they're the same car. Some people are dyed-in-the-wool Honda people. Some people are die hard Toyota people. And some people drive trucks. The Toyota designers obviously think their cars are better, the Honda engineers think theirs are better, but at the end of the day, consumers make a buying decision on something way more arbitrary, like which car they've always bought, or which Super Bowl commercial they liked better, of which one was cheaper, or which dealer was closer, or which sales guy was nicer to them, or which one their friend bought, or which one their enemy didn't buy....

    It's all the same here.

    I have two machines in my pinball dev lair, one running FAST, one running P-ROC. They both work. There are people using each platform successfully. There are people who are negative on each platform too. But at the end of the day, for 99% of people, either one is fine.

    What's most important is that lots of people continue to build their own pinball machines, because lots of us really love pinball and are excited to see what people build! So use P-ROC. Or use FAST. You can't go wrong either way. (Same for software. Use MPF. Or use PypinprocHD.) Just use something and build pinball!

    #118 7 years ago

    Brian, thank you for a very informative post. I'm a lurker who had the same question as the original poster, and it sounds like either board will work for most people. I guess the way to differentiate between the two would be to see which one has better support for a new user who isn't sure about how things should be wired together. I've looked at the open P-ROC forum and saw that newbies asked questions and got answers and they were able to build pinball machines, and while it's not public, I'd imagine that the FAST community has something similar on their Slack channel.

    However, the tone of this thread makes me want to avoid both camps. With few exceptions, everyone seemed to hold a grudge against the other platform and the people who support it. It got really personal, really fast. I'm just looking to build a pinball machine, not join a cult. I think I'll put my purchase on hold for a while. Linolium had a good suggestion about developing without hardware first, so maybe I'll do that and see which group becomes more mature by the time my game is ready.

    -1
    #119 7 years ago

    Sorry, FAST gets a down vote from me.
    Why? Their website has mostly out-of-stock controllers with no information.
    WTF is a Nano controller - looks like maybe 3 ICs... Does it use the cheap; low horse power arduino nano controller?
    negative points for not having that information directly posted on the product page.

    On the P3-Roc side, They have all that info on the product page... and it's "instock" available for immediate purchase.

    When FAST starts demoing soon-to-be-in-production machines on their platform... then I'll consider them; for now... they are nothing more than the cheaper; lesser option.

    -2
    #120 7 years ago
    Quoted from fastpinball:

    Michael,
    Talk to Gerry about this. If he felt compelled to address a topic of "treating people with respect" there must be something to it. Treating people with respect should be a given.
    Aaron
    FAST Pinball

    What a crock of sh*t. I have NEVER seen anyone treat people with more respect than Gerry.
    Even when placed in difficult positions.
    You sound butt-hurt for some reason. I didn't hear Gerry attack your product - or your character. Yet here you are; likely being a d1ck because up until this point... you could say anything in this thread and be taken serious.

    Now you are just a troll because you don't like a grown up adult conversation.

    ----
    And to the rest of you FAST proponents... why don't you stop going into every funking thread saying "you shoulda used a FAST controller". You add no value... and to me appear to be a mob operating on behalf of FAST... trying to convince everyone that Trump will be the best president ever. Glad Aaron is your friend and gave you free boards... stop making every Proc thread about you. Thanks.

    #121 7 years ago

    Brian thanks for posting that, I think that really sums it up well. Could have closed the thread after your post and called it good but unfortunately zitt had to chime in with another knee jerk reaction. Seems like this topic is rather polarized for some. Im happy that proc and fast are both making boards and pushing homebrew forward and hope that they both continue.

    I will say that regardless of gerrys opinion on some of the engineering aspects of the fast boards, it makes sense to pursue something a little different otherwise it would be kind of remaking the same product. Brian's Camry accord anology seems to fit the situation well. If there are multiple ways to solve a problem you are bound to get multiple solutions. I'm happy to see 2 solutions out there. Perhaps there will even be a third down the road

    #122 7 years ago

    I found this thread instructive and interesting with plenty of good points made by passionate people.
    It's really cool to have all these home-brew projects come to life thanks to solutions provided by Gerry and Aaron.
    Would love to develop one game myself (or rather, completely rewrite code for a spinball Jolly Park - a good layout with an atrocious ruleset)
    But I do not have the time as moderating pinside is full-time job...

    Would hate to have to close it or ban people with first-hand experience with game development.

    So... keep it civil, thanks.

    #123 7 years ago
    Quoted from Mbecker:

    I'm happy to see 2 solutions out there. Perhaps there will even be a third down the road

    I would agree with this, if retheming existing or building custom pinball machines was a mass market opportunity. However, as much we all like to dream, at the end of the day it's a real niche. There has to be enough volume of controllers being sold to make it worth while for the various suppliers to stay in the business.

    I have no idea on the profit margin on these controllers, although I doubt it's going to make anyone rich enough to give up their day job. The market just isn't there to be selling tens of thousands of controllers. The only way those kind of sales might happen is if they get picked up and used in bigger production runs of machines (which we see starting to see happen for P-ROC / P3-ROC with TBL, BOP 2.0 and then the whole P3 multi-game platform).

    I have to declare some interest here, as I designed and supply a board which allows the P-ROC (I've been told it works with FAST WPC too) to run a System 11 machine. This is a pure hobby for me, I supply the blank PCB with or without a kit of parts just at whatever it costs me. I will build and test one too if you need and I have time, I charge the grand sum of an extra £30 (UK pounds) to cover the 3 hours it takes.

    When the board first came out there were a lot of comments around the number of Sys11 machines that were going to be made more up to date. Now here's that niche thing (although Sys11 is a niche within a niche). In the 3 years since the board was designed, I've sold a grand total of around 35 of them. However, I'm only aware of perhaps 8 of them actually being used, the others seem to have dropped off the radar and I assume are gathering dust somewhere (although I suppose they might be in use by folks who just keep quiet).

    Now I don't care about that, since like for so many people this is a hobby I really enjoy and you get out of it what you put into it. Never thought I'd design a PCB in my life, but it was fun to learn. But at the controller level, the more suppliers that join in with FAST and P-ROC, the slimmer the pickings are going to get, to the point where it might not be worth it for anyone. If there really was mass market potential for home-brew and retheme machines then the more the merrier, but I really don't see that happening.

    As for which to choose? Personally I'm in the P-ROC camp as that's where I've always sat and I see absolutely no reason to change. Support has been excellent from both Gerry personally and the community as a whole, and the hardware works great. For new folks coming along, given a lot of folks (including me) don't understand the really deep technical stuff, it might come down to your preference for programming framework. If you want to code in Python pure, then the one of the pyprocgame derivatives is what you're looking for in which case your controller choice is P-ROC / P3-ROC. If you want a "potentially-less-programmy" framework, then MPF is certainly up and coming and I'm very excited to see how that develops. Doesn't help with your platform choice then though, since it'll run with both P-ROC and FAST. My only concern here is that if Brian, Gabe or Jan get run over by the proverbial bus and MPF development stops, then FAST is kind of dead in the water as it's only framework that supports it at the moment.

    So in summary, when choosing, I'd say look at what support is available, look at what's already in use "out there", look at what product is physically available and then make your choice. At the moment I think P-ROC is the better choice in all these areas, although Aaron is clearly passionate enough that FAST will eventually clear the "we're still building, testing, documenting so bear with us" hurdle and then the decision might be less clear. Or it might get clearer, who knows.

    But please, no 3rd mainstream option unless someone knows something about the size of the niche that I don't

    #124 7 years ago

    While *almost* off topic of the thrashing at hand, has anyone been watching this project for pinball controller boards: https://openpinballproject.wordpress.com/

    We are talking around $50-$100 to get a whole game going (I think, I have a hard time figure out much with this project as it is VERY early). I did support their kickstarter and am looking forward to receiving a set of boards. No idea how this will shape up, but I really like the ideas going into the project.

    #125 7 years ago

    Non.... i make remakes, so i don't need them

    #126 7 years ago

    I just want to say I love all y'all. And I'm working on my game right now. It's got something from Gerry, something from Aaron, some mpf, some pypinproc, old and new, something blue, some BS, and a tiny truth. United Nations up in here!!!! It's like getting married... Mix of this and that.

    Peace and love kids. It's just pinball and we all suck at it.... That's why we build. Except Keith, he is just too good for normal machines and that's why he's making his own

    I'm a good 2-3 weeks before I'm ready to release the first of the series but I'm working on creating graphics for everyone to use. And I'll take requests. I'm a vid producer and I have easily time to do a few of these a day. So here is my peace offering....

    https://www.dropbox.com/s/3j3muqdknbt0rgn/Stuff%20to%20look%20prettytest.mov?dl=0

    Disregard the last one if you're not keen in mpf....

    #127 7 years ago

    Cool videos!! Would you be open to me adding them to PyProcGameHD/SkeletonGame when they are done? --except the last one in the sequence, of course

    #128 7 years ago

    Yeah. I'm going to make a repository of vids and sound effects. My plan is for them to be available for mpf, skeketon, whatever else to help speed writing good rule sets.

    That's the whole point behind these frameworks. Let the people who like doing something do it. And let the individual build the next great game unemcumbered. Shoot me a PM with a logo you want to use and I'll make one of those for skeleton.

    And I'll start requests for specific games prob in May. I need to build my graphics first

    #129 7 years ago

    I'll make one for fast and proc too... Cover my bases. In open pin proj shoots me a logo I'll cover y'all too

    #130 7 years ago

    I'm a software developer of 15 years so I'm writing my own framework in .net and haven't had to edit a single config file (my application does the work for me)
    I bought my Proc hardware over 3 years ago when there wasn't really any other options. I normally go for the underdog if I see it has a benefit (I'm still one of the few rocking a Windows Phone) and when Fast was announced I've been keen to see it develop.
    While the P3Roc uses the modular idea of putting switch boards under the playfield near switches I dont see that benefit outweighing the cost of buying all the additional boards versus the 16x8 switch matrix that I get as part of the Proc board. Especially considering I will be getting very close to using 128 switches on my machine.

    What counts against the Fast hardware at the moment is the lack of documentation. From my perspective it seems that the people using the hardware at the moment have had direct interaction with the team or MPF guys to get it working. I'm in Australia so that isn't a possibility. Going to the Fast website I cant read up on what hardware I should get or how it all works together. I can figure a lot of stuff out for myself but if I ordered a bunch of Fast boards I would have no idea where to start, I don't see a support forum.

    I think the biggest thing that Brian has done with MPF is good documentation and an easier to follow and install framework. The pyprocgame process has been difficult even for someone like me. So many dependencies that it's very easy for one to fail to install correctly and the whole system collapses. While the documentation is around it is very fragmented and spread between pdfs, wiki, forum.

    Now that I have almost bagged everyone (How can it take Stern so long to make software? Surely they should have a system in place where all they have to do is link assets with modes, assign scores to modes/shots and then inherit/extend modes from base classes (modes) like multiball etc... Does anyone know what language they are using?) Ok. Now that is everyone.

    Pinside has a lot of bitching. I spend most of my time in the custom threads as they tend to contain the most well reasoned discussions and some people are doing some seriously cool stuff. Obviously there is going to be debate between Proc and Fast as they are both going for the same small piece of turf. They both seem capable (I myself would like to see more examples of Fast in action before making a choice on my hardware for my second pin). I have personally used Proc and I can say that I have been quite happy with the hardware and was surprised how quickly I was able to get a pin flipping (getting past that is quite a task though).

    Completely OT, how awesome are 3D printers?! First test print for my GoT Wall Lift ball lock.
    WP_20160325_23_39_23_Pro_(resized).jpgWP_20160325_23_39_23_Pro_(resized).jpg

    #131 7 years ago

    Very Nice Print Lachied. I used to hate printers. Till i got one and it sure does help on some stuff
    But it will never replace me working with clay. I enjoy it too much

    #132 7 years ago
    Quoted from Bonnevil69:

    Very Nice Print Lachied. I used to hate printers. Till i got one and it sure does help on some stuff
    But it will never replace me working with clay. I enjoy it too much

    Yeah clay is just so relaxing. And you can put in so much more detail. I'm thinking about trying to 3D print mechanical forms for accuracy and correct dimensions, then cover in a layer of clay to sculpt finer detail.

    #133 7 years ago

    That would work pretty well i think. Ive been using it to make stamps of repeating patterns then go over it again to bring detail and make it look random. Total time saver. Looking forward to seeing your pin done

    #134 7 years ago
    Quoted from lachied:

    What counts against the Fast hardware at the moment is the lack of documentation.

    This is true -- the website in particular really needs some specs. They do have a number of google docs that have more overviews of how to wire things, etc. that were shared when I purchased. They need some work and some polishing for sure but I feel like I could have had a flipping machine by now without too much trouble following what they do have so far if I had not gotten distracted with a house purchase and subsequent projects. I hope to get back on track soon though-- itching to get something running, been dreaming about it for years now.

    #135 7 years ago

    ...gosh.

    #136 7 years ago
    Quoted from iko:

    Hi,
    I'd like to build a pinball from scratch.
    I've read a lot of topics about it but unfortunately I've seen nothing about wiring FAST or P-ROC board with led, coils and servos.
    I'm a software developer and I'm not worried about coding or using (for example) the mission framework. I'm worried about the electrics step because of lack of documentation.
    Please anyone can help me?
    All suggestions are welcome.
    Thanks
    Bye
    Fred

    Alright, so now that I'm out of popcorn, I guess I can reply here:

    I've programmed games using every commercially available pinball controller on the market. I'm an engineer at heart (and by profession), so while I've been able to get all of these to work, I will tackle this from the perspective of someone just getting into building a game.

    I've programmed for games as simple as single ball redemption pins, games as ambitious as a Pinball 2000 version of Demolition Man (conversion kit for DM), and for games as mechanically complex as Pinball Circus, and now Wizard Blocks. All of these use different control systems, mainly P-ROC, the PinHeck board (running AMH), and the Pinball 2000 system. They're all in different programming languages.

    With that said, I wanted (and want) to try FAST, but have not been able to get a set of demo boards for a variety of reasons, so I can't attest to its functionality, though the MPF is well documented. MPF has a different strategy than the other framework for P-ROC -- PyProcGame.

    PyProcGame is designed as a set of simple building blocks that allow you to really create some excellent games, but there's a slightly higher starting cost. We give you a mode stack, some common device handling code (for Troughs), a basic game framework with DMD control and a service menu, and we set you loose. The power of said framework is evident in such games as Cactus Canyon Continued, Demolition Man 2000, Buffy, Wrath of Olympus, Kugler Family Pin and most of the other ones in the P-ROC showcase. This simplistic design has (and continues to) withstand the test of time. You've got a dozen (if not more) people who have made great games with this framework, who are available all throughout the day on our Slack channel, which is mostly open to the public who are creating games. Just ping me for an invite.

    MPF aims to do a lot more of the "leg work" for you. It has a lower startup cost in the sense that you can get things flipping with a few lines of YaML code, but when frameworks make assumptions like that on behalf of the designer, updates can quickly break things. Obviously things like this will get more gracious over time. Brian is great to work with.

    If you want a solution that is in both boutique and production games, and is available for purchase today for either a completely custom game using a new playfield OR custom rules on an existing game, then use P-ROC. I've practically thrown these boards off of a cliff both physically and electronically, and they're tough. Gerry offered to replace my boards for something as simple as the boards showing up with slightly bent header pins -- an easy fix (which has not occurred since in boards he's shipped).

    I cannot attest to FAST since it was not available at the time we started the current project. Aaron has alerted me that they have controllers in stock now, so I'll likely be doing some testing in the near future, and will report back where appropriate about that experience!

    The PinHeck system is probably the cheapest in terms of board cost, but you have a lot of heavy lifting to do. Sure it boots in 2 seconds, but the entire system is in C (or very lightweight C++), there is no framework, and there's very little documentation in terms of DMD tools or game code. Though the guys working with the board internally at Spooky are doing very cool things with it. We've, however, had opto problems with this system and ended up making a series of modifications to run the opto interface on a standard WPC board.

    ======================================
    On a side note -- the "pot shots" should probably stop. Its noisy and tends to detract from the information about building games that people are here to seek. Just focus on creating a great product, and your words or opinions don't mean anything until you've used said product or have a product on the market. You don't learn until you launch.

    -- Compy

    #137 7 years ago
    Quoted from briancox:

    I felt the hardware had a slight performance advantage in auto-fire mode (like the machine-gun effect you get on your thumpers), and being able to adjust the debounce of the switches made things a little easier.

    Hi Brian, I'm curious to explore this to understand the source of your feeling. When you were experiencing machine-gunning with the P-ROC, were you using MPF or pyprocgame? I was just talking to MPF developer Jan, and he discovered that MPF was not setting the P-ROC's reload_timer, whose sole purpose is to eliminate machine-gunning bumpers. Perhaps this was the source of your issue? This is apparantly fixed in MPF 0.30. Regarding the actual bumper response time, the P-ROC's debounce mechanism by default is much faster than FAST's; so the P-ROC should respond to that initial switch event as quickly as you would expect. Bumpers are pulsed in response to switch events automatically assuming the rule is defined in your software (all of the frameworks expose this mechanism).

    Adjusting a switch's debounce timer to be slower would make the bumper's intial response time worse; so I wouldn't recommend that as an option, regardless of the hardware. I encourage people to make their debounce and switch scan speeds as low/fast as possible to eliminate mechanical bounce in the actual switch mechs which typically bounce in microsecond frequencies. Dealing with ball settle times is a different type of debounce, and that's generally handled via software switch handlers. pyprocgame has a built-in mechanism for easily adding delay times to software switch handlers for ball settling. I'm unfamiliar with how MPF does it, but I'd be shocked if it didn't have a similar mechanism.

    - Gerry
    http://www.pinballcontrollers.com
    http://www.multimorphic.com

    #138 7 years ago
    Quoted from gstellenberg:

    the P-ROC's debounce mechanism by default is much faster than FAST's

    Not sure how it could be faster in P-ROC. We handle the debounce of the switches directly on the FAST I/O board's ARM processor itself using 1ms resolution. So a debounce time set for a switch is the specific value you set for it, there is no system scan time to account for because it happens directly on the board that read the switch input.

    Aaron
    FAST Pinball

    #139 7 years ago
    Quoted from BrianMadden:

    But really if you're making a home brew machine, you can pick either and be fine.

    Quoted from BrianMadden:

    Designing a pinball controller platform involves a million little trade-offs. Connector style, fuse style, board layout, driver architecture, etc, etc.

    I guess this depends on your definition of "fine". To imply the differentiating details don't matter suggests I wasted my time worrying about each and every detail when designing a product that addresses most of the common issues pinball machine developers would face in the best way possible for them. On the contrary, I think the time spent thinking through all of the low level details to ensure the best user experiences possible was absolutely imperative. Yes, there are always tradeoffs, but the justifications for the choices made and the specific things traded off determine what makes a product easier to use, more extensible, more future-proof, more resistant to failures, etc. Given that the core functionality between the products is similar, the details absolutely matter. In fact, all else being equal, they likely drive the purchasing decisions.

    Obviously I'm an engineer, and I sell and defend my products like an engineer, focusing on the technical advantages, the way they fulfill users' needs, availability of software frameworks, how quickly and efficiently we answer customer questions and solve customer issues. If these things don't matter, then the product is completely commoditized, and that's far from the case here.

    If people do care about details, solving problems, and making their lives as easy as possible, then they should buy P-ROC products for all the reasons I described here: https://pinside.com/pinball/forum/topic/fast-or-p-roc-controllers/page/2#post-3069859. If people don't care about the technical details, then it'd make sense to use the product that has the most software framework options and biggest support community, which again is the P-ROC.

    There have been discussions about people coordinating the creation of technical comparison charts between our products to make it easier for people to differentiate and choose. I'm happy to participate.

    - Gerry
    http://www.pinballcontrollers.com
    http://www.multimorphic.com

    #140 7 years ago
    Quoted from fastpinball:

    Not sure how it could be faster in P-ROC. We handle the debounce of the switches directly on the FAST I/O board's ARM processor itself using 1ms resolution. So a debounce time set for a switch is the specific value you set for it, there is no system scan time to account for because it happens directly on the board that read the switch input.
    Aaron
    FAST Pinball

    The specific feature I described, and what you quoted, was the debounce mechanism (and the default value for it). The P-ROC's default debounce mechanism is 2ms if software doesn't change it. It's 4ms by default in pyprocgame and MPF (which is actually a bug - I think it should remain 2ms). What is the default debounce time in your boards? I've been told it's much higher (like 30ms), but I'm happy to be corrected if I was misinformed.

    What you're describing here is response time for bumpers and things, and that happens after the switch events (whether debounced or not). For that functionality, The P-ROC and your boards are functionally equivalent. Anything under a 5ms response time is fine (as shown by response time and perception experiments in humans), and the P-ROC's response time is 1ms for the switch event (non-debounced) and up to 1ms for the driver command; so 2ms max. These rules are all located in the hardware in the P-ROC solutions too. The difference is that the switch boards and driver boards are separate when using the P3-ROC. The latency to the P3-ROC is in the microseconds; so the fast response time is maintained. Further, having the rules in the central component makes the P3-ROC not care if the switches controlling the drivers are in the same vicinity or not. They're all the same from the controller's perspective. That's important for things like flippers, since flipper buttons are in the cabinet, and the flippers are on the playfield.

    - Gerry
    http://www.pinballcontrollers.com
    http://www.multimorphic.com

    #141 7 years ago
    Quoted from gstellenberg:

    The specific feature I was described, and what you quoted, was the debounce mechanism. The P-ROC's default debounce mechanism is 2ms if software doesn't change it. It's 4ms by default in pyprocgame and MPF (which is actually a bug - I think it should remain 2ms). What is the default debounce time in your boards? I've been told it's much higher (like 30ms), but I'm willing to be corrected if I was misinformed.
    What you're describing here is response time for bumpers and things, and that happens after the switch events (whether debounced or not). For that functionality, The P-ROC and your boards are functionally equivalent. Anything under a 5ms response time is fine, and the P-ROC's response time is 1ms for the switch event (non-debounced) and up to 1ms for the driver command; so 2ms. These rules are all located in the hardware in the P-ROC solutions too. The difference is that the switch boards and driver boards are separate when using the P3-ROC. The latency to the P3-ROC is in the microseconds; so the fast response time is maintained. Further, having the rules in the central component makes the P3-ROC not care if the switches controlling the drivers are in the same vicinity or not. They're all the same from the controller's perspective.
    - Gerry
    http://www.pinballcontrollers.com
    http://www.multimorphic.com

    The default debounce time for switches in our system is 30ms, but can be what the user would like. The 30ms seemed fitting for the majority of switches in a game, which are rollovers, targets, spinners, etc. For devices that should trigger faster like pops, slings or flippers, it would probably feel better for the player to dial it down a bit. But again, it can be anything.

    The debounce time I am referring to here is the time that determines if the switch has settled long enough to be considered "active," If a driver, for a coil for example, is configured to be triggered by that switch, it fires that coil immediately when a switch becomes "active." We tell users to configure the debounce times for their switches so that they trigger when they want them to. By resolving locally on the same board that driver fires immediately and THEN reports the event to the controller and host system for scoring. So rather than telling users to set the debounce times as low as possible so their coils fire faster, we tell users to configure their switch to trigger when they think it feels right and the coil will fire immediately as it was configured to, as a result.

    We have found that even new users find this concept pretty logical. You determine when the switch is adequately triggered, and then what should happen when that is the case. But everyone comes into making pinball with different backgrounds and experiences. We hope our efforts make it as easy to get a game going and feeling right, as possible.

    Jan and Brian have a concept in MPF that provides a platform specific "long and short" default debounce time parameter for when switch events should trigger slower or faster. While you would read the differences in the values used between the FAST and P-ROC as FAST having values that are longer than the P-ROC's values, the important thing to recognize is those are the values that get the user the result they want on each platform. We say "set the value to Xms for a response time of Xms" whereas (and this is just how it was described to me) the P-ROC platform has "to result in a response time that feels like Xms, set the debounce time to a lower value (or might have been zero)."

    We both get to the goal of the game feeling right a little differently, but it gets there. And that gets people making the pinball they love!

    Aaron
    FAST Pinball

    PS: sorry for the long post! Been in documentation mode lately! Plus it's fun to talk technical details too!

    #142 7 years ago
    Quoted from gstellenberg:

    That's important for things like flippers, since flipper buttons are in the cabinet, and the flippers are on the playfield.

    Oh! I forgot to mention that the first bank of 8 switches in the FAST Loop Network of I/O boards is treated as "local" to all boards in the system. This switch data moves through the network immediately behind our watch dog. So that way we don't have a latency issue even when switches and drivers which require that immediate response are not on the same board.

    We added that in after building with the hardware for a bit. I felt like it would simplify wiring and it has for me!

    This is fun stuff to talk about because it doesn't come up very offer with most users or in questions from potential users. But like we all say, this is the boring stuff we focus on from the engineering side so that designers can be designers and programmers can be programmers!

    Aaron
    FAST Pinball

    #143 7 years ago

    Configurability is great when necessary. When not necessary, it creates more opportunity for confusion and frustration. In the case of individual debounce timers, you'll find that the majority of your users will resolve a lot of periodic frustration by lowering the debounce timers to just a couple of ms. I guarantee (yes, 100% certainty) that anybody detecting switch events on a modern-style ('80s+) pinball machine with 30ms of debounce time will miss switch events. Ever play an older Bally game and see switch events get missed? Happens all the time, and those games debounce in 16.666ms. Ever time a ball going up the playfield from a fast flip on a modern flipper? We've done exactly that with our ball-tracking on the P3. With 30, or 16, or even 10ms debounce timers, you will miss switch events.

    I'm curious to hear a real-world example where somebody needed to use a debounce timer above 2 or 4ms. If all of your users change their code right now to use 2 or 4ms debounce timers for *every* switch on their game, they will all be much happier.

    This is just one of many examples where those details Brian waived off matter. The implementation decisions and trade-offs I made were done to give P-ROC users their best possible chance to succeed. That your users aren't asking about it yet doesn't mean it won't be important to them when they get farther along with their designs. Programmable debounce per switch will, at best, waste a little bit of your users time by forcing them to configure something that shouldn't need configuring. At worst, it'll cause them endless hours of frustration debugging missed switch events (probably thinking it's a software bug). I'd encourage Brian and Jan to override your defaults by setting debounce to 1 or 2ms for all switches permanently.

    - Gerry
    http://www.pinballcontrollers.com
    http://www.multimorphic.com

    #144 7 years ago

    Reading Gerry and Aaron's conversation with each other makes me feel smarter already

    Seriously, what these two guys have done for homebrew pinball is incredible, and the outstanding work of the two and their teams has done terrific things in making pinball design more accessible. Maybe someday it will even reach the level where I can design and build one!

    #145 7 years ago
    Quoted from gstellenberg:

    a fast flip on a modern flipper? We've done exactly that with our ball-tracking on the P3. With 30, or 16, or even 10ms debounce timers, you will miss switch events.

    I have not timed it, but when hitting normal targets and switches we used the 30ms time and it was all right. But again, it's one param to change. If users say they think a different value makes for a better default, we can update that default value in our firmware. Users with hardware already can update that using our bootloader and new users would get the new value. No big deal, it's not a hardcoded value that other system functionality relies on it begin a certain value. It's a single setting in MPF, as well.

    When moving up the playfield on your P3 you cover lots of "switches" on the grid locating the ball over the LCD, I assume. What kind of resolution do you have over your screen? It's gotta be pretty high to get that kind of tracking you use to show the smoke trails following behind the ball. But yeah, that ball is going to be moving extremely fast over the plastic on a strong flipper hit and the debounce of those switches would have to be as small as possible to track it.

    Do you debounce the reads of the ball location on the playfield with different timing as you would on any of the physical targets on your upper playfield? I would think that you would need to, but we don't have that kind of ball coordinate tracking required so I honestly haven't had to consider how it would perform. That would be something to discuss with Dave in the mix. If we were to do a resolution tracking of the ball we would create a different type of switch.

    In the FAST system we have 2 kinds of switches: SN: Network Switches (those on our I/O boards) and SL: Local Switches (those connected directly or "local" to the controller). We broke them apart because the way we get input from each is different. The Network Switches have their switch events reported to the controller, according to their debounce settings. The Local Switches (which we use on the FAST WPC Controller) require us to scan the switch matrix and then evaluate what we read to determine if the switches were active long enough to warrant a switch event. Again, factoring the debounce requirement.

    If we were doing something like you do for your P3 video screen ball detection, I would imagine needing a 3rd type of "switch" like SC: Switch Coordinate ? (Just riffing here) The way we would manage the switch reads would need to be more complex. Needing way more events that would be On-then-Off happening extremely quickly at times. Based on the speed of the ball, you would get events back at different locations at different times relevant to each other. Based on that relative location and timing of the reads compared to each other you could know where the ball is likely going to go (speed and trajectory tell you it will be far more likely that the next read will be following that same line). Obviously that gets more complex as you add multiball. But you can see how we wouldn't be evaluation those reads the same as we did the other two types of switches.

    I am sure there is so much more to it , but my point is that we are focused on the requirements of traditional pinball minus what you are doing on the P3. If future pinball creations had users needing something to take care of similar ultra fast coordinate based reads that your P3 over screen input requires, we would come up with a method for doing so. But as I am sure you know, that is definitely a massive feat to make it respond the way the player thinks it should. By separating out the handling of the different types of input, you can avoid burdening one method by the needs of another.

    Man, are you coming up to the NW Pinball Show in June? It would be fun to talk about this stuff in person over beers.

    Aaron
    FAST Pinball

    #146 7 years ago
    Quoted from WaddleJrJr:

    Maybe someday it will even reach the level where I can design and build one!

    You just need to start! I have found designing/building pinball to be a great way to show me cool new things to learn. Without the challenge, I would have never learned all I have these last few years. Tell me three years ago I would be building SMD boards with tweezers under a microscope and I would have told you you were crazy!

    Dave and I (and everyone else we have gotten to work with on the FAST adventure) are having a whole hell of a lot of fun with all this. Everyone we share this experience with are constantly inspiring each other directly or indirectly to do something great and then make it just a little better than that.

    You can do it.

    Aaron
    FAST Pinball

    #147 7 years ago
    Quoted from fastpinball:

    You just need to start! I have found designing/building pinball to be a great way to show me cool new things to learn. Without the challenge, I would have never learned all I have these last few years. Tell me three years ago I would be building SMD boards with tweezers under a microscope and I would have told you you were crazy!
    Dave and I (and everyone else we have gotten to work with on the FAST adventure) are having a whole hell of a lot of fun with all this. Everyone we share this experience with are constantly inspiring each other directly or indirectly to do something great and then make it just a little better than that.
    You can do it.
    Aaron
    FAST Pinball

    I'd certainly be able to get a game physically up and running with the board system recognizing switches and interacting with solenoids. However the challenge I face with the systems is being able to program complex rules. I know enough about programming to create simple stuff, and to see other things and figure out how they work, so maybe as MPF evolves and gets more documentation and completed games it'll give me the tools with which I can learn enough to jump in.

    #148 7 years ago

    Hey guys -
    Okay, I'll be the dumb one here..

    I know, *technically* what a switch 'bounce' is. But what's a *debounce* timer? And how can a faster timer 'miss' a switch input?

    #149 7 years ago
    Quoted from Coyote:

    Hey guys -
    Okay, I'll be the dumb one here..
    I know, *technically* what a switch 'bounce' is. But what's a *debounce* timer? And how can a faster timer 'miss' a switch input?

    A debounce timer is the time in which a switch won't recognize another hit. The best example of a debounce timer we all know is modern tilts. If you give a modern game a big shake, the tilt bob may touch the ring 6 - 8 times in the few seconds following the move, but it only registers one or two dangers.

    #150 7 years ago
    Quoted from WaddleJrJr:

    Maybe someday it will even reach the level where I can design and build one!

    go fo it I am (pushing a square wheel up a hill by making my own hardware system, but I've got it working nicely).

    There are 187 posts in this topic. You are on page 3 of 4.

    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/fast-or-p-roc-controllers/page/3 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.