Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

  1. Maniac

    Ledwiz Speedtest

    You can launch it directly. But if you use a 64 bit windows, you have to run it with the 32 bit wscript.exe. Please follow those steps: - click Start - write "cmd" without the quotes - press enter - in the window that opens type "c:\Windows\SysWOW64\wscript.exe path_to_speedtest\speedtest.vbs" without quotes and replace the path_to_speedtest with the path where you have placed the speedtest.vbs
  2. Maniac

    Ledwiz Speedtest

    No, this is a seperate project started by me and is not related to his project.
  3. Maniac

    Ledwiz Speedtest

    It should be help alot, because it reduces the waiting time for each command in VP from 16ms to 0,3ms. So nearly all of the stutter should be gone. Please note that you also need a controller board which you connect to the Arduino to have the outputs available. Since I've switched to an Arduino Leonardo it will be easy to create a PCB containing the Atmega32u4 (or smaller 32u2) directly on the controller board, so there is no need for an extra Arduino. Since you need the Controller Board in both ways this would cost about 20€ less. I'm planning to create such a PCB, including the possibility to daisy-chain the boards if you need more than 32 outputs and I want to ad a connector to drive Zebulons board also. There is still room for improvement on the ledcontrol.vbs side. Currently every 60ms the ledcontrol.vbs sends commands to VPM to ask for the lamp status, causing a little load at VPM. Currently there is no other way to obtain this information. The best solution for this would be to change the way VP and VPM interacts (like using VPM as a library in VP). So that VP always knows the state of all lamps and we can ask VP for this information.
  4. Maniac

    Ledwiz Speedtest

    Thanks, then it makes no difference for the communication if PWM is enabled or not for the LedWiz too. I just recognized that my PWM timer in firmware was still on 20 microseconds. This makes no sense in a productive environment and it was a just for fun test before switch over to hardware SPI. After rising it to 200 microseconds (which is still fast enough) I got the following results: Overall: 12ms per Call: 0,3ms Now I'm happy because all my Arduino work is a huge improvement at all Here is a deeper description to the per call value which is measured by the script: At default the ledcontrol.vbs updates the Output every 60ms and sends it to the LedWiz. If a lot of lights are changing this can happen every 60ms. Now the LedWiz takes 16ms to give the control back to VP. VP itself sleeps in this time and this causes the stutter.
  5. Maniac

    Ledwiz Speedtest

    I've optimized the Arduino a bit and use hardware SPI now. With full PWM (PWM always enabled in firmware currently) I got the following values now: Overall: 1398ms per call: 34,95ms This is a lot faster than software SPI, but still slower as the LedWiz (wihtout PWM). The firmware is currently running on an Arduino Leonardo which provides a virtual com port (the UNO uses an extra microcontroller which does the serial stuff and connects it to the hardware com on the Atmega).
  6. I've written a small script that (hopefully, since I don't own a LedWiz myself I can't test it) measures the time the LedWiz needs to submit a command. The script sets all PWM outputs to maxium (48) and then switches all outputs on and off 20 times. This means 40 operations in total. At the end the overall time and per call time is displayed. Someone who has deeper knowledge please check if the LedWiz commands are correct. I've tested the script using an Arduino instead of a LedWiz. Please post your values in this thread. Here is the script. Copy it into an empty file and name it speedtest.vbs Set LedControl = CreateObject("LEDWiz_Control.LED_Wiz") 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" LedControl.Command ="SBA:0,0,0,0,1" i = 0 t = Timer temp = Int(t) StartMs = Int((t-temp) * 1000) StartS = temp mod 60 while i < 20 LedControl.Command ="SBA:255,255,255,255,1" LedControl.Command ="SBA:0,0,0,0,1" i = i + 1 wend LedControl.Command ="SBA:0,0,0,0,1" t = Timer temp = Int(t) EndeMs = Int((t-temp) * 1000) EndeS = temp mod 60 DurationMs = EndeMs - StartMs DurationS = (EndeS - StartS) * 1000 Duration = DurationS + DurationMs WScript.Echo "running time complete: " & Duration & "ms. per call: " & Duration / 40 & "ms" Edit: For reference this are the values I currently get with my Arduino (PWM routines enabled). But there is still some room for improvements. Overall: 6843ms per call: 171ms Edit: Please also do a second run and exchange the line 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" to LedControl.Command ="PBA:40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40,40" This should enable PWM on all ports and we can see if it makes a difference in processing time on the ledwiz itself.
  7. I just recognized that on Indiana Jones the Extra Ball Button is set to S12. This is the left slingshot solenoid. If there is no rom event for this button we should set it to on.
  8. I've just tested the extended Arduino code with VP. At first I had my debug messages over serial still enabled and it verified the cause of the stutter caused by the ledcontrol. The ledcontrol.vbs invokes the ocx (LedWiz or mine) to send the command. VP itself waites until the ocx has done it's work. This results in the FPS drop/microstutter. Therefore we are forced to move the communication into a thread in VPM, so the communication doesn't block VP anymore. As an improvement to my board I want to move to the hardware SPI the Atmega offers, this should speed up the things on the microcontroller too. @Zebulon: I had a look at your board and it looks very interessting to me. Especially since you offer the possibility to drive the whole thing with an Arduino too. I think it should be possible to create a small PCB (maybe integrate an Atmega32u4 directly) with 74HC595. The outputs of the 74HC595 can be placed on a connector to connect to your board directly. Do you ship your board to Germany? If yes how much will it cost (board and shipping)?
  9. For now I decided to stay on the darlington arrays and use a Mosfet to drive the knocker. I'm currently adding PWM support to the Arduino, this already works with PWM levels set in the code directly. Next step is to extend the Serial interface to accept PWM levels from VPM. If got some new ideas during development. I've switched from the Arduino Uno to an Arduino Leonardo, so there ist only one Microcontroller to handle everything. This is a Atmega32u4 on the Leonardo. My idea is to use a Atmega32u4 or the smaller Atemga32u2 and solder it directly to the controller board, so there is no need for an extra Arduino PCB anymore. Who many outputs do you need? Are the 32 from the LedWiz enough? While reading the code of the PinDMD interface in VPM, I got the idea to implement the communication to the Arduino/Atmega directly in VPM. There is every information we need right there. If a Lamp changes we can push this directly to the Arduino. What do you think about this route?
  10. No, I think he means the work of fuzzelhjb. There is already a dx9 branch in the offical VP svn. As far as I remember there were also a thread at VPF about this, but I can't find it right now.
  11. Yes, as far as I understood him he can read the whole content of the FPT files, only writing back changes is not possible for him yet.
  12. I agree that the software side needs a lot of attraction, but we suffer also on open source hardware parts. For example there is only one shop where you can the LedWiz in Germany.. There the LedWiz costs 75€ (nearly 100$), because od the fact that on the offical site the LedWiz costs about 45$ I began to develop an own solution. My first try was using an Atmega8 and an FT232RL, but I had some problems creating a PCB and solder this. So I've switch to an Arduino which I had laying around from some experiments. With this i got a fast solution for my current needs, it lacks PWM support for now, but it's on my todo to add this (already some ideas how to realize it in the firmware). I also have in mind to switch over to a simple Atmega with V-USB implemention since the Arduino is a little overkill for this. But for now there are more important things to do for my cab. My self build joystick controller (based on an open source project) costs about 10$ in parts (also not finished, 3 analog axis are not working right now, but I'm fighting with the USB descriptor to get it work). On the software part there are a few things which are not up to date in VPinball/VPinMame and it's very MS orientated. IMHO at least this things have to be improved: - Switch to a more modern rendering interface, ideally add an abstraction layer, so other renderers like OpenGl could be added more easily - Let VPinball use VPinMame directly by a lib (dll) and not over the COM interface, so the switches, solenoids, etc. can be directly connected in the editor and not via script - Get completly rid of the COM interface and add a network interface where things like LedWiz and B2S can connect to. I think the current daisy chaining of the rom events is one huge performance killer in VP. (Currently I'm also trying to add a simple network interface to VPM to get atleast LedWiz and B2S out of the daisy chain. VP still uses the COM interface in this approach. - Exchange the table script language from vbs to a more open source one (for one step to linux compatiblity) - Implement real 3D objects to VPM - Get rid of all other win dependencies (for complete linux compatiblity) Unfortunatly all of this points are a huge load of work.
  13. Currently I'm thinking about how to power my Siemens solenoids and replay knocker. My idea is to add P-channel Mosfets to the Output of the darlington array. Another idea I got while planning this, that in the next revision of the driver board, all outputs of the darlington array or maybe the shift registers (need a deeper look if this is possible) are directly connected to the Mosfet. We could add voltage banks to drive a number of outputs (e.g. in blocks of 8 or 4) in a desired output voltage. This would increase the size of the boards a bit, but we can drive each output with a very high load. What do you think about this?
  14. Maniac

    Cabinet Source Code Available?

    If published the things in this thread http://vpuniverse.com/forums/index.php/topic/88-what-hardware-is-needed-to-be-developed/#entry2462 Is there really no one who can help me out with the cabinet source archive or diff?
  15. I've pushed my stuff to github. You can find it on https://github.com/ManiacPinball/hardware Currently the Com device used for the arduino is still hardcoded, therefore you have to adjust it before compiling the dll. Just open the Led.cpp and change COM10 in line 20 to your needs. In the arduino folder you will find the code which needs to be uploaded to your Arduino. In the eagle folder youl find the schematics and board layouts in eagle format. The pinjoy firmware is still missing, I'm trying currently to get the USB descriptor right for the 3 analog axis. The ledcontrol.vbs is a slightly modified version to use the usbled dll. I will update this file soon with the new version appeared recently.