Jump to content

LED-wiz alternative ?


pixelmagic

Recommended Posts

  • Replies 363
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I am so dissapointed with my led-wiz, I hope you are able to get this perfected enough that most of us will delve into it.

EDIT: TO clarify, the led-wiz device itself is fine, but I am dissapointed with the performance toll it takes on VP etc. I'm sure this has more to do with the antiquated way VP/PinMame etc runs and not necessarily on the led-wiz hardware itself.

Edited by guruguys
Clarification
Link to comment
Share on other sites

Hi Pixel,

only 75 left huh - may need to add some more :-)

How about another 50? :party:

Shifters

Hmm, seems I have been to fast in counting, a recount tells me that I have around 134 direct outputs and around 90 RGB leds empty, so no hurry yet.

Oh wait, I forget we can put the Arduino's connected to each other, so I still have unlimited !:tee:

luvthatapex Wow, that's impressive! Is it difficult to configure tables? It looks awesome.

We are thinking of the best way to do it, while at first glance it looks difficult I hope we can make some nice config tools to make it a lot easyer.

At the moment the Arduino configuration (think about what toy is connected to what port/hardware) can be made in a web interface. This can be a lot, I have over 120 lines for my current config (looks like D171 W39 0,D,0,48,53,4,314,9,0).

Then we need the reference from the tables, basicly like LEDwiz does, but here comes the event driven approach around the corner. For contactors it could be the same as LEDwiz, but on flashers, do you really only want to flash 2-3 flashers in 1 color on a event ? I think not, you have to think in events, when a Troll in MM comes up, i want a part of the playfield LED's flashing in a ugly green Troll color. Same with the Castle destroy, you will want to have a lot of flashing, even when the Castle is not moving. The approach I have at the moment for this is to put the table config in detail in a webtool, and take it to the next part of the config.

Last but not least, as most people will have completely different configs, it is going to be hard to make something default. But I have some ideas on how we can still make it easy to configure, again with a webtool, combining your personal config from the first part, the generic table config from the second producing a ready to work with config file. We are looking on maybe giving some hints (other people have used event xx on group xx for this) to make life easyer.

Anyway, we are not done, and the above is only the small part that I have to contribute, the main accomplishment is done by Shifters and his magic creative work on the Arduino. I am truly amazed in what he has made so far and can honestly say that if I would have made this, it would be way less advanced, if working at all.

This one is for you Shifters: :party:

Link to comment
Share on other sites

Great work you did with Arduino !

I've got a few questions :

are all arduino boards compatible with your system ? For example, this one :

http://cgi.ebay.fr/ATmega328-P-20AU-USB-board-USB-2-0-Cable-for-Arduino-V3-0-Nano-AVR-/180798066408?pt=LH_DefaultDomain_71&hash=item2a18678ee8

I just want to control a few solenoids for force feedback (half a dozen, I think ), and maybe a few leds (start button, launch button). So I don't need thousands of outputs.

I'm not a develloper, I just know HTML-css, had made some AS2, php and javascript code before (but I barely remember). Do you think I can use and understand this kind of system ?

In one word, is it something user-friendly, or only reserved to devs ?

thanks

Edited by sundaypinball
Link to comment
Share on other sites

Hi Sunday,

I am using 1280 and 2560's - the main reason the code is currently 52K (12K+ lines of code!) and it uses about 5+K of memory. None of the other arduinos have sufficient resources. We choose the 1280 and 2560 not so much for the number of outputs but the memory. I have used official boards and clones and both seem good - cost is circa $30/£20/Euro25 per board.

Bear in mind that the arduino will only drive 40mA max per output at 5v, if you want to drive what you intend you need to look at Pixels driver board.

I also have a rasperberry Pi order for interest :idea:

shifters

Link to comment
Share on other sites

thank you for your answer.

I am using 1280 and 2560's - the main reason the code is currently 52K (12K+ lines of code!) and it uses about 5+K of memory. None of the other arduinos have sufficient resources. We choose the 1280 and 2560 not so much for the number of outputs but the memory. I have used official boards and clones and both seem good - cost is circa $30/£20/Euro25 per board.

Ok, too bad cheapest cards can't handle your system. It would be a very good alternative (price) to ledwiz, for my purpose (only a dozen of "events" to send).

Bear in mind that the arduino will only drive 40mA max per output at 5v, if you want to drive what you intend you need to look at Pixels driver board.

I didn't know that, I believed that "simple" relays should be suficient ?

Link to comment
Share on other sites

So without a driver board, the arduino canno't be used to replace the ledwiz ?

I'm asking because drivers boards are expensive. So the combo arduino +driver board will cost more (or equally) than a ledwiz board.

Thinking about that, I heard about Pacdrive board. It seems cheaper than the ledwizz. Can it be used with eficiency for a very simple setup :

3 bumpers

2slingshots

1 shaker

?

thank you !

Link to comment
Share on other sites

So without a driver board, the arduino canno't be used to replace the ledwiz ?

I'm asking because drivers boards are expensive. So the combo arduino +driver board will cost more (or equally) than a ledwiz board.

Thinking about that, I heard about Pacdrive board. It seems cheaper than the ledwizz. Can it be used with eficiency for a very simple setup :

3 bumpers

2slingshots

1 shaker

?

thank you !

There will be new driver boards very soon, that will be with lower power like ledwiz, but also better price. The arduino alone cannot replace the ledwiz, it was not designed that way.

BTW, the VP-Fx solution was never designed for a cheaper repalcement of the ledwiz, it is a upgrade from ledwiz with much, much more options.

Link to comment
Share on other sites

There will be new driver boards very soon, that will be with lower power like ledwiz, but also better price

INteresting, do you have any links to share about that ? I'm not hurry, I've got plenty of work on my cab for the next weeks, so I can wait to buy a ledwiz or something similar.

thanks

Link to comment
Share on other sites

INteresting, do you have any links to share about that ? I'm not hurry, I've got plenty of work on my cab for the next weeks, so I can wait to buy a ledwiz or something similar.

thanks

Bonjour !

No links yet, just that the driver board will use 3 digital outputs off the arduino board and outputs 2x16 digital outputs, 16 on ledwiz leven (500ma per output in theory (!!!)) and 16 doubled outputs. All outputs with screw connectors and al IC's can be placed on feet, so when you should blow one, exchanging is easy.

Furthermore where will be a Shield for the Adruino available if all goes well, that supply's easy access to connect the driver boards and other hardware.

Will be placing updates on that in this topic, so keep watching ;)

Link to comment
Share on other sites

Sounds great, even if I'm not sure it 's the kind of products I'm searching for...

In fact, I just need about just a dozen of outputs : 3 bumpers, 2 flippers, 1 knocker, 2slingshots, 1 ball eject, 1 rumble motor...If someone create that kind of poorman driver board I'll be happy :top::proud:

Link to comment
Share on other sites

Sounds great, even if I'm not sure it 's the kind of products I'm searching for...

In fact, I just need about just a dozen of outputs : 3 bumpers, 2 flippers, 1 knocker, 2slingshots, 1 ball eject, 1 rumble motor...If someone create that kind of poorman driver board I'll be happy :top::proud:

No lights ??

Link to comment
Share on other sites

I'm not a lights guy I presume...It's like virtual backglass, it's not something particularly interesting for my own taste. I'm more concerned about controls, forcefeedback, sound, that kind of things.

Of course if I buy a ledwiz or other interface with hundreds of outputs, I'll add some lights...Just because since I'd pay for these options, I'll use it. But if someone create a light version of ledwiz, with maybe 16output, with a significantly cheaper price, I'll be the happiest man.

Link to comment
Share on other sites

A little late, sorry if this has been discussed but I don't have time to read the entire thread.

There is a simple way to get more inputs and outputs on the arduino. Only requires 3 pins each. Here is a good example of this (btw, this is me in the video, so shameless plug).

I can provide schematics and sketch code for this. Just let me know

-Frank

Link to comment
Share on other sites

A little late, sorry if this has been discussed but I don't have time to read the entire thread.

There is a simple way to get more inputs and outputs on the arduino. Only requires 3 pins each. Here is a good example of this (btw, this is me in the video, so shameless plug).

I can provide schematics and sketch code for this. Just let me know

-Frank

Lmao that's awesome!

Link to comment
Share on other sites

A little late, sorry if this has been discussed but I don't have time to read the entire thread.

There is a simple way to get more inputs and outputs on the arduino. Only requires 3 pins each. Here is a good example of this (btw, this is me in the video, so shameless plug).

I can provide schematics and sketch code for this. Just let me know

-Frank

Nice work :D We also use the same kind of thing to get more ports, thanks for sharing !

Link to comment
Share on other sites

This may just be crazy talk, but if the LEDWiz OCX is using synchronous communication, as Mr. Silver mentions (and I believe it probably is - it's not really designed for heavy load, so the concept of it using a buffer probably never entered RandyT's mind when he was rolling the OCX code in VisualBasic), wouldn't it be possible to write a new OCX that buffers incoming commands and sends them to the LEDWiz on a separate thread, thus isolating us from the synchronous communication?

Sure, if enough commands come down the pipe from VisualPinball, the buffer will fill up and commands to the LEDWiz will get behind, but the delay to get the commands through wouldn't be excessive in most cases (in fact, I bet you'd be hard pressed to even notice it), but the important thing is that a command given to the OCX would return immediately, rather than waiting for the LEDWiz to accept the command, so VisualPinball isn't delayed - and this would only happen under heavy load. Under normal circumstances, the LEDWiz would be keeping up and commands would shoot through as fast as always.

It sounds to me like the stuttering problem is more of software issue than a hardware issue. Judging by the little LEDWiz utilities you can download from GroovyGameGear, it wouldn't surprise me to discover that the OCX does the absolute bare minimum to get commands processed (the little utilities are really clunky and slow), which means it's using blocking code that waits for the LEDWiz to acknowledge the command before continuing - which is fine, if we have a separate thread accepting and buffering incoming commands to be sent when the LEDWiz is ready for them.

There are LEDWiz DLLs out there that can be used to roll such a multithreaded OCX. Sadly, I wasn't able to locate any source code for the DLL, so we'd have to actually use the DLL (as opposed to including the code directly in the OCX), but that's not entirely terrible. I even found some example code in various languages that show how to use the DLL I found.

Maybe something worth thinking about?

Link to comment
Share on other sites

This may just be crazy talk, but if the LEDWiz OCX is using synchronous communication, as Mr. Silver mentions (and I believe it probably is - it's not really designed for heavy load, so the concept of it using a buffer probably never entered RandyT's mind when he was rolling the OCX code in VisualBasic), wouldn't it be possible to write a new OCX that buffers incoming commands and sends them to the LEDWiz on a separate thread, thus isolating us from the synchronous communication?

Sure, if enough commands come down the pipe from VisualPinball, the buffer will fill up and commands to the LEDWiz will get behind, but the delay to get the commands through wouldn't be excessive in most cases (in fact, I bet you'd be hard pressed to even notice it), but the important thing is that a command given to the OCX would return immediately, rather than waiting for the LEDWiz to accept the command, so VisualPinball isn't delayed - and this would only happen under heavy load. Under normal circumstances, the LEDWiz would be keeping up and commands would shoot through as fast as always.

It sounds to me like the stuttering problem is more of software issue than a hardware issue. Judging by the little LEDWiz utilities you can download from GroovyGameGear, it wouldn't surprise me to discover that the OCX does the absolute bare minimum to get commands processed (the little utilities are really clunky and slow), which means it's using blocking code that waits for the LEDWiz to acknowledge the command before continuing - which is fine, if we have a separate thread accepting and buffering incoming commands to be sent when the LEDWiz is ready for them.

There are LEDWiz DLLs out there that can be used to roll such a multithreaded OCX. Sadly, I wasn't able to locate any source code for the DLL, so we'd have to actually use the DLL (as opposed to including the code directly in the OCX), but that's not entirely terrible. I even found some example code in various languages that show how to use the DLL I found.

Maybe something worth thinking about?

I really think you are on the something. When you have a really fast CPU the hardware keeps up fine.

This supports your theory completely that it is the software communicating not the hardware.

Link to comment
Share on other sites

I really think you are on the something. When you have a really fast CPU the hardware keeps up fine.

This supports your theory completely that it is the software communicating not the hardware.

Well - kind of. The limiting factor should be the LEDWiz's ability to process commands fast enough, and when it can't, the PC is forced to stop and wait for it to be ready for the next command - which causes the calling program (VP in this case) to wait, too - thus the stutter. A fast PC shouldn't really help, in that case.

Perhaps the problem is lessened just enough to help the stutter, but it shouldn't have a massive impact in theory.

I wonder if if it's a VB code that causes the slow down? Maybe it's a combination of things. Some testing is probably in order to really find anything out for sure. At this point, it's all a bunch of guessing.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...