LED-wiz alternative ?

[Arkay]

There will be much more info and schematics when it is all done and working, don't worry about that.

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.

For someone @ 4 posts you got a lot of knowledge, so things will fall into place at the time.

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

Just don't buy to many flashers, I seriously doubt if you gonna notice them when you have our new toys active (watch my last video for more insight)

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.

[lordindy]

Hi guys. I'm absolutely amazed at your skills and dedication.

I currently am using my Arduino board to drive my XBMC amblight system on my TV.

I have a question: I ordered a Raspberry Pi, and was intending on using it as another XBMC or a MAME unit. Now, I'm wondering....can the Raspberry Pi be used as an "evolution" of the Arduino board to control a driver board and gadgets?

[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!

Edited April 16, 2012 by Arkay

[shifters67]

HI Arkay,

I am concerned with just getting it working with windows and VP first. However it is a serial protocol - anything can talk to it in any language on any platform with a suitable driver. ( I have been using linux for nearly 20 years so i am not excluding anything!). The software will be open source and people can play to their hearts content.

BTW i just bought 6m of individually controllable RGB leds (same as pixel video demo) - there are already 964 events that can be run and i haven't yet set the table up to begin playing with complex ones (been using a 12 led prototype board!) :-)

regards

shifters

[Arkay]

HI Arkay,

I am concerned with just getting it working with windows and VP first. However it is a serial protocol - anything can talk to it in any language on any platform with a suitable driver. ( I have been using linux for nearly 20 years so i am not excluding anything!). The software will be open source and people can play to their hearts content.

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.

BTW i just bought 6m of individually controllable RGB leds (same as pixel video demo) - there are already 964 events that can be run and i haven't yet set the table up to begin playing with complex ones (been using a 12 led prototype board!) :-)

regards

shifters

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.

Edited April 16, 2012 by Arkay

[pixelmagic]

I have a question: I ordered a Raspberry Pi, and was intending on using it as another XBMC or a MAME unit. Now, I'm wondering....can the Raspberry Pi be used as an "evolution" of the Arduino board to control a driver board and gadgets?

The PI will be a nice thing in the future, but given the problems they have at the moment, the Arduino is much more stable at this moment. Who knows what the future will bring, but for now we have chosen for stability and availability in the long run.

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.

Finaly the cat is out of the bag

Check out this link: http://www.pieterfloris.nl/shop/product.php?id_product=507 for the LED strips. We fully support this type with a maximum of 8 strips of 1 meter (32 leds) from the software. Basicly you need 4 wires for 32 leds/1 meter (or 16 leds/50cm or whatever size you choose), Power supply (5Volt), ground, and 2 data lines to the Arduino.

Let's say you have a 'very big' cab and truly can fit 8x 1 meter of the strip, then you would have 8x32=256 RGB leds, all can be driven individualy, and you would only use 8x2=16 output lines on the arduino.

At the same time you can still use 4 ULN extention boards with 32 outputs each (4x32=128) and have also have 12 real pwm outputs on the Arduino available.

Sounds like some serious connections to me.

You want more ? No problem, connect a second Arduino and double the number of outputs.

More ? No problem, more is possible.

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.

We will keep that in mind !

[chriz99]

woohooo, got my 5m roll, also 32led/m 8806chip

[shifters67]

Hi Pixel,

just a quick correct - currently the Arduino is 'limited' to 200 devices (each led, contactor or solenoid counts as a device) due to memory.

Once we have beta testing underway this 'may' be extended to 250 memory permitting. You can daisy chain arduino's via serial.

I intend to have 2 arduinos in my cab, one in the main cab and one in the backbox, main cab drives playfield leds and other devices, backbox drives leds mounted aroudn the screen edge on the backbox. So 1 arduino = 200 deivces, 2 arduino = 400 devices etc. I think, pixel and myself discussed scaling up 8 arduinos to keep Chris happy! I have tested three and that seemed fine.

cheers

Shifters

[Arkay]

Finaly the cat is out of the bag

Check out this link: http://www.pieterfloris.nl/shop/prod...id_product=507 for the LED strips. We fully support this type with a maximum of 8 strips of 1 meter (32 leds) from the software.

Fantastic! Now. Where's my shopping list...... and wallet.....

pixel and myself discussed scaling up 8 arduinos to keep Chris happy!

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.

Edited April 18, 2012 by Arkay

[shifters67]

Hi Arkay,

the 1280 and 2560 have the same ram - 8k! Its only the program code memory thats different. I have both. We may want to use the 1280 depending on the FTDI driver compatibility - still working out the details

cheers

Shifters

[jeepguy81]

If at all possible it would be great to be able to use both 1280 and 2560. Only reason for me is I already have 3 2560's from other projects.

[Mysterioii]

Let's say you have a 'very big' cab and truly can fit 8x 1 meter of the strip, then you would have 8x32=256 RGB leds, all can be driven individualy, and you would only use 8x2=16 output lines on the arduino.

If for arrangement purposes you need to run each 1m strip back to your controller, then yes. All of the shift-register-based LED strips I've seen just dump the data lines off the end (they're manufactured in longer runs and just cut to length... as chriz99 pointed out 5m rolls are commonly available). In general they recommend additional power hookups every so often so you're not pushing the full amperage down the entire run of the strip but the data lines can just chain together. So with a little wiring from the end of one strip to the beginning of the next strip you should actually be able to drive that all with 2 data lines not 16. Good to have the flexibility though.

[Mysterioii]

just a quick correct - currently the Arduino is 'limited' to 200 devices (each led, contactor or solenoid counts as a device) due to memory.

Sorry if this has been said before, I haven't read the entire thread because it's gotten pretty long... I am not a pinball person, wouldn't contactors and solenoids only need one bit each? Are you saving 8 bits per LED channel (so 8 bits of PWM dimming control for single color LEDs, 24 bits of full-color control for RGB LEDs)? Or are you only considering the LEDs to be on or off? I think I'm missing something, I'm not sure why the different types of devices are being treated differently if they have radically different memory requirements.

[pixelmagic]

If for arrangement purposes you need to run each 1m strip back to your controller, then yes. All of the shift-register-based LED strips I've seen just dump the data lines off the end (they're manufactured in longer runs and just cut to length... as chriz99 pointed out 5m rolls are commonly available). In general they recommend additional power hookups every so often so you're not pushing the full amperage down the entire run of the strip but the data lines can just chain together. So with a little wiring from the end of one strip to the beginning of the next strip you should actually be able to drive that all with 2 data lines not 16. Good to have the flexibility though.

One important thing in pinball: speed, when you hook up 5 meters to 2 pins (it is possible) and you want to set the first and last to green and red, you have to address all the 160 leds in the strip.... not very speedy

Sorry if this has been said before, I haven't read the entire thread because it's gotten pretty long... I am not a pinball person, wouldn't contactors and solenoids only need one bit each? Are you saving 8 bits per LED channel (so 8 bits of PWM dimming control for single color LEDs, 24 bits of full-color control for RGB LEDs)? Or are you only considering the LEDs to be on or off? I think I'm missing something, I'm not sure why the different types of devices are being treated differently if they have radically different memory requirements.

You are indeed missing some things here, solenoids and contactors have got nothing to do with the led strips. The strips have PWM build in and it can be used. Driving other on/off items is done via the ULN boards.

[Mysterioii]

Ah so in memory you're treating LEDs as binary, either full on or full off? Are you handling any PWM for these LEDs in your code or is that ONLY for the strips? I presumed each channel would have variable levels of intensity but if you're going with off/on then I see where you're coming from.

I know what you mean about speed, that's why I said that it's good to have the flexibility there. I haven't used the strip in your example, the ones I have use a different chip, so I'm sure they're similar but non-identical.

I probably need to go back and re-read the whole 27 page thread, I like stuff like this. I'm not a huge pinball fan and am just getting back into upgrading my arcade cabinet, but some of the pinball cabs I've been seeing have got me interested... Just one arcade cab running mame and some console emulators and one well-made pinball table running a nice assortment of tables would make for a pretty sweet game room... I don't have a ton of space but could probably squeeze a table in (one of these days... after I knock out about a dozen other projects...)

[maxxsinner]

Let me know when you need details from me and payment Erwin. I understand that the software is not ready for release yet, but would like to get hold of the boards so I can plan the layout of my control gear and have them soldered up ready to go. Will have to ammend the electrical guide with a bit of a 'how-to' for these as well no doubt.

[pixelmagic]

Sorry guys, been real busy with other stuff lately, will post more details asap.

[BitPirate]

I know practically nothing about the Arduino board. This thread is on my next to read list.

In the mean time, something fun I came across, accomplished with this board Enjoy

[shifters67]

Lol what some people get up to!

He had problems switching fast outputs - i optimised my switching code for the led strips so i can write 100's of outputs in a few milliseconds :-)

The slow point is a bit on the comms - but with some help from Russ with FTDI code driven from a DLL instead of vbs and directly from vpinmame even that will be disapear (and its not easy to see at the moment using serial comms - its fast!).

If you are wondering why the delay on this - I have all my hardware now and need a week to take apart my cab and rewire with contactors and 8806 led strips and arduinos ( I am using two, one for back box and one for main cab - one acts as master, one slave, for 400 (maybe 500) outputs! ). That is currently scheduled for first week in June. Then i have a proper system on which to test, so a few weeks doing some more coding (its 95% done on arudino).

Pixel is on hols for June, so by July we should be starting to produce some example tables and documentation for people to test - well i hope!

So in summary, Pixel's hardware rocks and is done - i have samples, need to cab build to do proper testing - though you have seen Pixels videos earlier in thread which show it works fine already. Pixel is working in his website to do config and table mapping ala ledwiz (which given 200+ outputs not just 32) as you can imagine is complex). The final piece is driving via FTDI USB rather than serial which is the icing in on the cake! 8806 leds in full RGB rock :-)

regards

Shifters

Edited May 9, 2012 by shifters67

[evil eye]

I know practically nothing about the Arduino board. This thread is on my next to read list.

In the mean time, something fun I came across, accomplished with this board Enjoy

Haha, that's awesome. He's got some other good ones on his page as well. I enjoyed, "What Is Love?"

[arngrim]

Hi,

Any news about this very interesting project?

[shifters67]

Hi Arngrim,

i totally failed to rewire my cab last week (which was the plan) so i had a fully fledged cab to test on - may be a few weeks before i do.

PixelMagic is on holiday for a few weeks so no progress there. The project is gently sleeping for the summer :-)

We are probably close (read months!) to a beta test - the hardware is made - most of the software written.

Shifters

[RandyT]

While I don't wish to inject into a thread for a different product, this seems the most appropriate place, considering the title of the thread and the reasons being discussed.

I have seen numerous complaints here about "stuttering" or pauses on machines where the LED-Wiz is being used. So, I started looking through the ledcontrol.vbs code, and found that a very inefficient OCX command was being used to set the PWM levels in ways it was never designed to be used. Through discussions with the authors, I believe this has been remedied. But there is still one glaring omission that may be responsible for some of what folks are seeing. The LED-Wiz requires a short (1-2ms) delay between communications with certain USB chipsets, so when the OCX (the code the ledcontrol.vbs is calling) was written, it defaulted to a compatible mode which inserted a short delay to make sure that the hardware had time to process the previous set of instructions. The method of the delay used was the sleep API. Microsoft states that the sleep API delays updates to graphics redraws which occur within the same thread. When this is called many times in succession, as is the case when multiple events occur in a short period of time, the lack of screen updates would be apparent to the player. To me, this sounds like the cuplrit, as what is being described as "stutter" is the lack of graphic updates when the LED-Wiz is being communicated with, over and over, within a short time frame.

The most likely solution, or at least the first thing to try:

In the LED-Wiz OCX, there is a property which can be set to disable this delay. This would be the FastCom property, and it should be set to true. So those of you experiencing a lack of screen updates when using the LED-Wiz should try the following to see if it helps;

Get the latest version of ledcontrol.vbs on your system and find the following piece of code

Public Sub ResetLedWiz()

LedControl.Command ="PBA:48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48"

End Sub

and change it so it looks like;

Public Sub ResetLedWiz()

LedControl.FastCom=True

LedControl.Command ="PBA:48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48,48"

End Sub

If you have a specific USB chipset (OHCI-based), your setup might have a problem with this. But all UHCI-based USB chipsets (Intel, VIA) should deal with this just fine. If it does, in fact, cure the graphic update issues, you should also scale back the interval setting which controls how often the script communicates with the hardware. It may be that delays will no longer be necessary.

To Moderators: Please accept my apologies if this post is not where it should be, and feel free to move it somewhere more appropriate if this is the case. It seemed appropriate to post a possible fix to issues being described where the hardware was being blamed for what seems primarily to be software implementation issues .

RandyT

Edited August 31, 2012 by RandyT

[DeeGor]

Nice find Randy. I can't wait to get home and give this a try.

I will report back with my results.

[evil eye]

Nice find Randy. I can't wait to get home and give this a try.

I will report back with my results.

Hopefully you're back with good news. Thanks Randy!