Arkay

Fantastic! Now. Where's my shopping list...... and wallet..... Lol The arduino really is perfect for this implementation with such an array of connectivity available. I'd assume these would all be 2560's due to the amount of ram on board? It's a pity it's limited by available memory, is there no way to add more ram? Cheers, Arkay.

Shifters, Not suggesting you'd do anything otherwise. I've just seen the potential for open projects to become dependent on a platform through innocent and obvious choices of toolsets. Nothing more. As I said you guys are way way ahead of my thinking. I was just thought dumping last night at 2am after reading it all again and you're free to ignore anything I might suggest I won't be offended. I was more thinking about the way the signals are sent to VP-Fx, from VP with regard to the serial code embedding in vpinmame as Russ suggested, and also about the configuration tooling. I'm no expert in any of this, just interested and only offering up thoughts for discussion. Love what you've done with this. As I said the arduino code isn't an issue anyhow, but the tools that support it could easily become focused to the obvious platform that it will be used on at first and I was thinking of some other cool things that could be done with the boards from Linux etc is all. e.g. If you think about the config tools for ledwiz and/or ipac etc. They are really platform independent boards, but to program them you need to have Windows. That was the sort of thing I was getting at. I know Pixel has already mentioned a web based tool, so it probably wasn't really worth mentioning. It was more a thought to keep in the back of your minds than an immediate design choice as I know you guys have a million other important things to still focus on. But somewhere in those million things to do sometimes comes the temptation of using a fast easy to use toolkit that is platform dependent that becomes the defacto standard was all I was trying to say. Forums/text can be so hard to get ideas across on sometimes. 964 events!!! That's fantastic that you've been working only with a 12 led prototype board and have done so much code already I wired up 9 (managed to kill the 10th!), to play with, lights are so much fun! That's a ton of work you've done. Any links for the led strips? I was wondering how Pixel had them wired up all individually addressable. I'd love to play with VP-Fx if you guys ever need beta testers and I'm eager to buy some boards as soon as they become available. All this is so much fun it really is a massive distraction to actually getting a cabinet up and running! LOL!. Cheers, Arkay.

Guys, Just read the entire thread (again), such a great thread! In reference to the pinmame code and possibly moving the serial comms there I was just wondering if it is worth considering the possibility of non vpinmame effects triggers. Though most cab owners seem to prefer VP it would be great to be able to add effects to FP and/or current/future simulators. e.g. Farsights Pinball Arcade and the possible unity project (Though this uses pinmame so would inherit the code anyway), it may be a good idea to consider more generic ways to get the events to the arduino. Speed wise a direct comms approach from within a thread inside pinmame sounds like it could instantly remove the stutter on some tables, but the same could also be possible via running say a "VP-Fx" service that listens for incoming events and those events could then be sent from within pinmame or from external scripts and/or anything capable of dumping events into the VP-Fx queue for processing out to the toys. That way threaded code within pinmame can still achieve the same speed increase (via removing blocking code), but you're also in a position to enable effects to be triggered from pinball arcade, should Farsight for instance expose their events to cab owners via some yet undeveloped method. Or people may modify FP scripts to trigger toys or some totally different non pinball related use for this solution may also exist (e.g. home automation!). As you're only talking bytes sent without need of any return traffic causing potential stutter, all sending programs should remain fast irrespective of what writes to the "VP-Fx queue buffer". FP-Fx will process the queue at the same speed it always has. The only issue is how fast the messages get to the queue for processing. I loathe to suggest a queue based setup given what UVP does to tables but I think that it may suffer from similar blocking code issues as the ledwiz. The above might also give the Farsight guys reason to consider exposing events for cab owners as they've already expressed an interest in making their software cabinet friendly. Just a thought. I know you're hard at work in a beta stage but ideas like this, though I'm sure you're already way ahead of my thinking, can sometimes trigger ideas that can lessen the amount of re-work later on. It might be technically infeasible. But you never know. Please take it only as a suggestion. What Pixelmagic and Shifters have accomplished in such a minimal time is nothing short of amazing. I was wrapped making my arduino flash 9 leds in pretty sequences when I first got it. Can imagine how much fun has been had in development of this solution! Cheers, Arkay. P.S. One last suggestion. Though VP is windows only at present. As VP-Fx is essentially serial comms it should be possible if not simple to send commands to a programmed arduino regardless of platform so it would be a shame if somehow it were inadvertently tied to windows only when there is potential for use on any platform in the future (e.g. pinmame compiles under Linux/OSX, got it running today). So perhaps another thing to keep in mind as present/future simulators may well be cross platform. I know this is all very future focussed but I can see your hard work being the standard for a long time to come!

As I knew there would be I know you're still developing. Just like keeping an eye on it and planning what I'll be doing when I get to that stage of my build. Yep. I've read everything there is to read while I wait for some parts to show up. Hasn't been a lot of need to participate in conversations as yet as you guys have it all covered. Very little I can add. Amazing community I've stumbled into. That's for sure I never planned to use too many. Betweeen 3 and 5 under the PF glass at the back. Don't need anything on top. The effect is really for the player. Doesn't have to be for the neighborhood But I understand the temptation to light it up big! Will keep an eye on the progress. Keep up the great work! Cheers, Arkay.

Doh. Yes. I meant 1A. Dunno why I had watt in my head.. Cool. that's what I thought. Thanks for the clarification. I have already ordered an arduino which is on the way. As for what toys that is yet to be decided but I'm thinking a standard setup of 8xcontactors (or equivalent), shaker motor, wiper motor, 5 crees (or similar), 2 flashers. Yet to decide on the number of RGB leds and/or lit buttons for the front of cab/flippers. Either way I'll need at least 32 output, possibly more. But a lot is going to come down to the total current draw at any given time. I don't want to be burning out chips, even if they are simple/cheap to replace Ok. Thanks for the feedback. Though I still have a lot of thinking/planning to do. At the moment I don't have a very clear image of my requirements so until I do I'll keep reading, working on other parts of the cab, and see how the new solutions pan out. Thanks again for the info. Thanks again for the work on this solution/idea and the answer to my questions. I'm hoping at some stage someone will come out with a full schematic using just VP-Fx to drive all the toys in a cab, as I seem to be getting my solutions messed up having researched everything from no toys through ledwiz to Vp-Fx in the past few weeks yet not having wired/seen any of it in real life. It's all theory to me at present. Think I'll just start putting things together and worry about it on the way. Starting to get "analysis paralysis".... Cheers, Arkay.

Hi Pixelmagic, Just wondering if you (or anyone), could clarify a couple of things for me? The new solution seems to have 16x500ma outs and 16x1w outs. I think I might be confused between a combination of your initial driver board (with all the mosfets/optocouplers), and the original 595 multiplexer board vs the new shield/driver. Just curious as to what I'd need to run totally ledwiz free on a new build. Am I missing something or is the new driver board that uses the same chips as a ledwiz capable enough to handle the full current of the crees and able to do PWM for the motor? As there are only 16x1w outputs then 2 boards would be required as the cree's alone take 15 high current outputs, assuming a standard build with 5 crees, wiper, shaker, knocker and 8 contactors. Given there are no optos/mosfets on the new arduino driver, does the new driver board still require fuses, relays and H-bridge the same way the ledwiz would? and if so, is it still possible to get the mosfet/opto driver board so we can go arduino->595's->mosfet/optos->toys? without fuses/relays etc? Also, can the arduino solution drive 12v and 24v toys on the same driver board? Thanks for the clarification. Loving the availability of this stuff. You've put in a lot of work and done a great job on these and I can't wait to get a hold of things to start playing with the solution. Cheers, Arkay.