LED-wiz alternative ?

[DeeGor]

Well, I tried modifying the ledcontrol.vbs with the LedControl.FastCom option, but it seemed to screw up my ledwiz port assignments. It's not like a shift in assignments either. One time I loaded the table, my RGB strip turned red, then another time I started the same table, it was blueish/green. Normally the strip is set to Blue for the table. As soon as I commented out the LedControl.FastCom option, everything returned to normal.

I really hope we can figure out the delay issue. It would be great to be able to use UVP with the ledwiz.

[RandyT]

Well, I tried modifying the ledcontrol.vbs with the LedControl.FastCom option, but it seemed to screw up my ledwiz port assignments. It's not like a shift in assignments either. One time I loaded the table, my RGB strip turned red, then another time I started the same table, it was blueish/green. Normally the strip is set to Blue for the table. As soon as I commented out the LedControl.FastCom option, everything returned to normal.

I really hope we can figure out the delay issue. It would be great to be able to use UVP with the ledwiz.

This is the chipset issue I was referring to. How old is the LED-Wiz?

I still encourage others to try making the change above to see what happens on their systems..

[mattdavis]

Hi Randy,

My LedWiz is new and I will be glad to try, but it won't be until this weekend. I am just to the stage of setting up tables and have not played enough to find one that has an issue. Anyone know a sure fire ledwiz caused stuttering table? It seems Monopoly has a reputation of always having stutter issues- but I am not sure if its problem is ledwiz related or not.

This is the chipset issue I was referring to. How old is the LED-Wiz?

I still encourage others to try making the change above to see what happens on their systems..

Edited August 31, 2012 by mattdavis

[DeeGor]

This is the chipset issue I was referring to. How old is the LED-Wiz?

I still encourage others to try making the change above to see what happens on their systems..

I purchased it on 6/24/2011.

Well under the 3 year mark.

[RandyT]

Interesting. It seems that some type of delay is still necessary with the OHCI chipsets (which I am pretty sure is the one on your system at this point). UHCI controllers (Intel and VIA chipsets) should work with the FastCom property set to true. The OCX and the use of the sleep api is still what I believe is causing the "stutter" issue. The LED-Wiz is used primarily with a DLL in other applications, and slowdown has never been an issue. I'm not sure how compatible DLLs are with VBScript.

I'm pretty sure I can use an alternate method of delaying the output (only 1 or 2 milliseconds is necessary) and will compile a new OCX with this other method. As I cannot test for this myself, I will need a volunteer to try the new OCX and let me know the results.

If you are interested, please email me and we can see if this can be remedied. I'd rather not continue to de-rail this particular thread, so if there is a better place to continue the discussion, we should probably move it there.

*edit*

Please continue discussion -> here

Edited August 31, 2012 by RandyT

[arngrim]

Hello,

I'm still collecting all the stuff I will need for my cab project, which is advancing sloooooowly.

So my cab will maybe ready for the end of the year, or more later, I depend from one guy that is doing a lot of different things beside.

So I have several possibilities:

I don't use toys until this project is finalized, but I don't have an idea when this project can be mature (in about 6 months, 1 year? I don't want to add any pressure, just for my information )

Or I use Ledwiz until, but this stutter issue is bothering me, although I didn't see a Ledwiz cab in real, so I can't estimate the gravity of the problem.

By the way, is there a help in this solution use Zebulon booster board cards?

Thanks all in advance for your hard work

Arngrim

[shifters67]

Hello,

I'm still collecting all the stuff I will need for my cab project, which is advancing sloooooowly.

So my cab will maybe ready for the end of the year, or more later, I depend from one guy that is doing a lot of different things beside.

So I have several possibilities:

I don't use toys until this project is finalized, but I don't have an idea when this project can be mature (in about 6 months, 1 year? I don't want to add any pressure, just for my information )

Or I use Ledwiz until, but this stutter issue is bothering me, although I didn't see a Ledwiz cab in real, so I can't estimate the gravity of the problem.

By the way, is there a help in this solution use Zebulon booster board cards?

Thanks all in advance for your hard work

Arngrim

Hi Arngrim,

i have all the hardware from PixelMagic to rebuild my pin including leds/multiplexors/power boards etc. The majority of the software for the arduino is done and has been fully working since march/april. What we are doing is taking a break over the summer to enjoy (the poor!!) weather and will return in the autumn to the project. I know Pixel is busy with work at the moment but his boards (read back through the thread) can do it all but there is nothing stopping some one adding there own board design either - it will be an open software platform on standard hardware.

The arduino software probably needs a revisit for a month of so to finish off the software once my cab is rebuilt with the new extras. By default the arudino will drive contacters, led strips, flashers, motors, etc i.e. support for all kinds of devices are built in already and working/tested. You can add additional toys to it when ever you want and it supports 100's of devices at once on a single board with multi-board support already done/tested and working.

Areas for improvement over the autumn/winter:

1) Pixel to finish config web site (ala ledwiz device mapping to outputs)

2) Produce some more example table configs to go with the mapping (rather than Pixels infamous MM obsesstion )

3) Try and work with Russ to drive the arudino via FTDI directly rather than serial protocol (which works incredibly well btw) and do a custom dll to link in directly with pinmame rather than via events in the VB. However even if this does not work in version one, the arudino software runs on events not directly driving outputs ports so the software is an event processing engine not a simple slave drive to the digital outputs. This means one event which is only a few bytes long can drive dozens or even hundreds of outputs e.g. fancy led strobes or patterns, contactors and motors all with one command.

The advantage of the arudino approach is its a protocol, which could for example be ported easily to the Rasberry Pi or Arudino 2560 replacment with out chnageing all the PC side of the software and hence could be supported longer term as the speed and capacity of these little mini machines improves.

regards

Shifters

[arngrim]

hi Shifters,

Ok I have read you comments and the post again, I understand more what I need for my cab hardware wise.

Do you know if there's a possibility to use crees at 700ma with the arduino + shield + (current?) driver boards?

Regards

Arngrim

[shifters67]

Hi,

Pixel has flashers with his current driver board - not crees but similar

Shifters

[pixelmagic]

(rather than Pixels infamous MM obsesstion )

What the H*ll ?? Almost bought a real one last summer !!

Hi guys, I will slowly try to get into Pinball-Mode from now on, winter is coming fast and the outside jobs are almost done.

First question needs to be: are we still interested in this new additions (ok, year old). No need to spend a lot of time into it if besides Shifter, Chris and me no other people want to be using it.

Second one: there seems a lot of news on the market, a new VP, not much news on Unity, Real DMD's are hot, is there other news I need to know ?

Latest status update to my best memory:

• hardware as good as ready
  
• driving software as good as ready
  
• interfacing in VBscript works, but has stutter like Ledwiz
  
• interfacing between VP <> ***x needs work on low-level interfacing
  
• Played a game last week (yes, MM) with ***x, works, but stutters on lots of action
  
• Oh yeah, and the sh*tload of effects possible is totaly awesome !!
  

Lets hear it, now gonna do some reading in this forum.

Erwin

[jeepguy81]

Glad to see you back Pixel, I for one am still interested in seeing this to use in a cab. Been slowing picking up pieces here and there that I come across for my eventual build.

[Aurich]

First question needs to be: are we still interested in this new additions (ok, year old). No need to spend a lot of time into it if besides Shifter, Chris and me no other people want to be using it.

Definitely interested!

Randy had indicated he was considering working on the LED-Wiz stuttering (he seemed to have an idea why it was happening and that it was solvable) but then he stopped posting to the pinball boards as far as I can tell. I haven't reached out to him, but he seems more focused on the MAME crowd still, so it would be good to have someone who cared about the needs of our cabs actively working on solutions.

[RandyT]

Randy had indicated he was considering working on the LED-Wiz stuttering (he seemed to have an idea why it was happening and that it was solvable) but then he stopped posting to the pinball boards as far as I can tell. I haven't reached out to him, but he seems more focused on the MAME crowd still, so it would be good to have someone who cared about the needs of our cabs actively working on solutions.

People shouldn't take my silence as "not caring" about the needs of users on this board. I spent quite a bit of time conclusively determining that the stutter folks have been attributing to the LED-Wiz, is in fact caused by the additional overhead of the scripting necessary to make external hardware work, and not the LED-Wiz or the supporting OCX. I think it's safe to say that this has been confirmed, as I expected, by the third point of PixelMagic's post above. I have also communicated on a number of occasions with the script authors to provide them with information to improve the script for use with the LED-Wiz, and those improvements were equally beneficial for other hardware it may support in the future. There is another approach I have been formulating, but this would need the help of the script writers, as it would likely require a major rewrite of their code.

The reason the "stutter" issue hasn't been fixed by me is because it's not a hardware issue. It's the load from the extra VP scripting which doesn't need to be executed when no external hardware is being used.

RandyT

[shifters67]

Hey Pixel!

Good to see you back - going to rebuild my cab as a test bed with full hardware in the next few weeks so start doing a test table script for testing - hmmmm how about doing one for MM

cheers

Shifters

What the H*ll ?? Almost bought a real one last summer !!

Hi guys, I will slowly try to get into Pinball-Mode from now on, winter is coming fast and the outside jobs are almost done.

First question needs to be: are we still interested in this new additions (ok, year old). No need to spend a lot of time into it if besides Shifter, Chris and me no other people want to be using it.

Second one: there seems a lot of news on the market, a new VP, not much news on Unity, Real DMD's are hot, is there other news I need to know ?

Latest status update to my best memory:

• hardware as good as ready
  
• driving software as good as ready
  
• interfacing in VBscript works, but has stutter like Ledwiz
  
• interfacing between VP <> ***x needs work on low-level interfacing
  
• Played a game last week (yes, MM) with ***x, works, but stutters on lots of action
  
• Oh yeah, and the sh*tload of effects possible is totaly awesome !!
  

Lets hear it, now gonna do some reading in this forum.

Erwin

[Aurich]

People shouldn't take my silence as "not caring" about the needs of users on this board.

Sorry Randy, wasn't meaning to disparage, you just seemed to not be active here anymore like you are over at say, BYOAC. Obviously you're still keeping tabs!

I guess I had mistakenly thought you had found a solution on your end that was more more independent of the scripting, but just hadn't had time to implement it.

[evil eye]

People shouldn't take my silence as "not caring" about the needs of users on this board. I spent quite a bit of time conclusively determining that the stutter folks have been attributing to the LED-Wiz, is in fact caused by the additional overhead of the scripting necessary to make external hardware work, and not the LED-Wiz or the supporting OCX. I think it's safe to say that this has been confirmed, as I expected, by the third point of PixelMagic's post above. I have also communicated on a number of occasions with the script authors to provide them with information to improve the script for use with the LED-Wiz, and those improvements were equally beneficial for other hardware it may support in the future. There is another approach I have been formulating, but this would need the help of the script writers, as it would likely require a major rewrite of their code.

The reason the "stutter" issue hasn't been fixed by me is because it's not a hardware issue. It's the load from the extra VP scripting which doesn't need to be executed when no external hardware is being used.

RandyT

This is great news still. At the very least, it sounds like we are on the correct path now to solving the problem.

[pixelmagic]

People shouldn't take my silence as "not caring" about the needs of users on this board. I spent quite a bit of time conclusively determining that the stutter folks have been attributing to the LED-Wiz, is in fact caused by the additional overhead of the scripting necessary to make external hardware work, and not the LED-Wiz or the supporting OCX. I think it's safe to say that this has been confirmed, as I expected, by the third point of PixelMagic's post above. I have also communicated on a number of occasions with the script authors to provide them with information to improve the script for use with the LED-Wiz, and those improvements were equally beneficial for other hardware it may support in the future. There is another approach I have been formulating, but this would need the help of the script writers, as it would likely require a major rewrite of their code.

The reason the "stutter" issue hasn't been fixed by me is because it's not a hardware issue. It's the load from the extra VP scripting which doesn't need to be executed when no external hardware is being used.

RandyT

Hi Randy,

Can you please share the point(s) on where you think some progress can be made with the VBscript ?

We are looking into making a separate program for catching the ROM events and then driving the Arduino. If this can be done by VBscript maybe we make some progress.

Thanks in advance !

[RandyT]

Hi Randy,

Can you please share the point(s) on where you think some progress can be made with the VBscript ?

Understand that the solution may not be "one size fits all" for any hardware being used.

I need to do some more evaluation of the code used in the script and the tables, but essentially, we know that the script overhead is what is very likely the root of the problem. This comes from the need to do data management and compilation for transmission to the hardware, or at least to whatever code is responsible for communication. The more work which can be handled externally, and the less which needs to be done by the script, the better things are likely to be in the end. All activity needs to be event driven, and communication intervals managed by external code to provide the best performance, using the least amount of overhead possible from within the VP scripts. I suspect that this will require a major overhaul to the current script, and certainly to the communication handler, as the methodology will be different.

One unpleasant possibility is that the issue is caused simply by the script calling any outside procedure. If this is the case, then no amount of optimization using these methods will yield much improvement.

I've stated before (perhaps it was on one of the FP forums) that the ideal approach would be to use low level hooks into the code to fire external events based on the firing of internal events. This would also need to run in a separate thread, or even a separate core. However knowing this, and being able to do it, are something quite different.

[pixelmagic]

Hi Randy,

Thanks for the answer, and it sort of confirms the fears we had before. Our current option is not using the VB scripting at all for the communication, as indeed that seems to be where the trouble is coming from. VB just has to many things to do allready in a running table, this seems to be the latest drop.

As said before, we are looking into directly 'listening' to the ROM events, much like Russ and UltraVP does. If we could do that, convert the commands in our own software and if needed buffer or maximize the data to the device i think we could have a winner.

Anyway, to be continued

[Aurich]

I ordered an LED Wiz, hoping it works out. I'm also going to try Zebulon's new board to wire it all, which has the Arduino input option, so if you figure out some magic in that realm pixelmagic I'm more than down to swap over to that solution, in theory it should be pretty painless and not require any new wiring for new controller hardware. Feel like my bets are hedged!

[swisslizard]

Hi guys

I'm more than happy that this fantastic project is beeing continued.

Just finished building my cabinet and now I'm trying to find a way how to drive all those nice gadgets I've aquired. Since the ledwiz does not have enough outputs to drive all of them a alternative solution is a must for me.

Thanks for the hard work. Cant wait to try this solution.

[shifters67]

HI all,

the new arudino duo looks interesting - if i can get hold of one!! With considerably more memory i recon i can at least triple the number of devices supported and more, as for events, i could probably put enough in to keep even Chris happy!!! With a 84Mhz processor its a lot more powerfull.

Have a look http://arduino.cc/en/Main/ArduinoBoardDue.

Pixel - will this work with existing boards and shields given the voltage differences or is this for version 2 :-) ? Oh and answer your email

regards

Shifters

[russdx]

about time arduino used a man mircro and not these little piddly 16mhz things lol

[swisslizard]

By the way, the new Arduino mentioned in Shifters message is available again.

Unfortunately the shipping costs to Switzerland are kind of insane.

[pixelmagic]

I ordered an LED Wiz, hoping it works out. I'm also going to try Zebulon's new board to wire it all, which has the Arduino input option, so if you figure out some magic in that realm pixelmagic I'm more than down to swap over to that solution, in theory it should be pretty painless and not require any new wiring for new controller hardware. Feel like my bets are hedged!

Dunno if it will work with other boards, not designed it with that in mind. Sorry

HI all,

the new arudino duo looks interesting - if i can get hold of one!! With considerably more memory i recon i can at least triple the number of devices supported and more, as for events, i could probably put enough in to keep even Chris happy!!! With a 84Mhz processor its a lot more powerfull.

Have a look http://arduino.cc/en/Main/ArduinoBoardDue.

Pixel - will this work with existing boards and shields given the voltage differences or is this for version 2 :-) ? Oh and answer your email

regards

Shifters

The current input boards need 5V for the driving, but 3.3 MIGHT work.... Lets keep focused on the Arduino Mega board for now and make that work first, then look for options on V2.0.

My preffered situation for V2.0: Raspberry Pi communicating on low-level with Pinmame, Pi driving dedicated Arduino board(s) (for the # outputs). Configuration for your specific tables with hardware done with web-interface running on your own Pi, getting the config data from the internet on request. Live testing and simulation possible for all effects.

What ? yeah... let me have my dreams

Email answered