Jump to content

Darkfall

Platinum Member
  • Posts

    138
  • Joined

  • Last visited

Everything posted by Darkfall

  1. Wow. This thread has been dead for 2 months. Are we still happening here? Is there a build thread somewhere that I didn't see?
  2. 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.
  3. $100 USD Paypal'd. Awesome idea, man!
  4. 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?
  5. Totally awesome, Blur! I've posted on the LEDWiz mod thread on VPForums on what to do. Once they get this going (which is super easy!), they won't have to install FPLaunch, then install the LEDWiz mod over it - just install FPLaunch and go. Thanks again, Blur!
  6. Link works fine for me, too. Maybe just a short term hiccup? Maybe no PDF reader installed?
  7. Hi, pinballlooking. FPLaunch needs to be recompiled if the script is changed. My modifications come with a recompiled FPLaunch WIP4, so you need not worry about it. Just throw it all in per the instructions, and you're done.
  8. He needs it to be a command line tool, so he can execute it from the FPLaunch script, though.
  9. Cool. I'm sure it'll look good when you're done with it. We have faith *grin*. Yeah, I turfed my pause button, since the exit button does the job perfectly. I actually turned my pause button into a Favorites button for HyperPin, so I could quickly narrow down my table list to just the stuff I play most often. That was Blur's suggestion, and it was right on the money. It seems to me that everyone has an exit button, which pauses the game and brings up the goodies - that should work for everyone, I'd think. I suppose for those that don't want the score display, there could be an option in the .ini to disable it, or something - though, really, it's pretty cool. Sometimes I want to know how close I am to breaking a high score while playing - with this, I can see at a glance by just hitting exit to enter the pause menu - pretty ideal.
  10. I like it. Looks cool. It's hard to tell from the image, since it's scaled - it looks like it's trying to do a DMD sort of dot-matrix display, but the lettering appears to be connected with solid lines, as opposed to being made of dots. I suspect dots might be some fun to do, and that's why it looks that way? Or is it just the scaling on the image that's made it look connected like that? Either way - great work!
  11. Thanks, Blur. I'll give it a whirl tomorrow and let you know how it worked out.
  12. I'd love to try. I have focus issues exiting tables almost all the time, and sometimes when launching tables (it'll stay on the loading screen now and then, and I have to ALT-Tab to sort it out). Thanks, Blur.
  13. Input from the master is always good! Totally agree. I plan to add fuses to all of my LEDWiz outputs when I get a chance - it's just smart practice.
  14. Fuses are a matter of taste. Some people fuse everything (for example, a 500mA fuse between every LEDWiz output and it's controlled device - LED, relay, or whatever), plus fuses on every power lead to different things. Some people fuse just the power leads, and some people rely on fuses in the power supply. Fuses protect things on both ends of the connection. If the target end draws too much power (a shorted connection at an LED, for example), the fuse will pop. If the source end suddenly surges power at your target end (say the LEDWiz suddenly feeds 12 volts to your 5 volt device), the fuse will pop then, too. When I did mine, I ended up not using fuses and was just very careful about my wiring. My power supply does have a master fuse, so if I get a power surge from the wall, it should protect my devices from that - but I have no internal protection. For a solid, professional build, you should have a few fuses internally - especially on the more expensive parts, like the CREEs. Relays are primarily for loads that draw more power than your controller board can handle. For example, a shaker motor draws far more power than the LEDWiz can deliver directly, so you put a relay on the LEDWiz's output, and the relay switches the larger power to the device. We're talking about the smaller relays here - not the larger contactors being used for force feedback uses (who typically aren't switching anything - they're just there to make a thump). For the larger contactors (which are relays, but they're designed to switch high amperage loads, like big electric motors), these are about noise and vibration. In most cases, people aren't connecting anything to these on the switching end - they're just energizing the coil to make the relay close and make a thump to enhance the in game sounds and actions. The Siemens one most commonly mentioned isn't a North American part, so it's difficult to get here. There are lots of other contactors available, and most make enough noise - just make sure you don't get a solid state version, since those make no noise at all. You want an electromechanical contactor, so there's a moving part inside. Different ones make different levels of noise, so it's tricky to say "just go get a contactor and it'll sound like the Siemens". Some might, some might not. Everyone has their own preference on how noisy they want these things to be, too - trial and error, or the recommendation of someone else who's found one they like, is the best answer for that. For the diode, yes. It's necessary. If you don't put a diode on a coil-driven device, it will unleash a return voltage when the coil is de-energized, which is generally disliked by controlling devices like the LEDWiz. The diode will only allow voltage to pass in one direction, so it allows power to get to the coil to energize it, but won't let any power to return when the coil releases. Not having the diodes can cause problems ranging from slowly killing your LEDWiz to causing the LEDWiz to freak out to blowing up your LEDWiz instantly. Diodes are dirty cheap (well under a buck). Make sure you get diodes with enough capacity to deal with the coils release voltage - for my contactors, I put 3 amp diodes on them, just to be safe. For my little relays that fire my contactors, I put little "signal diodes" on them, since they have tiny coils. What I did with mine is have a DIN rail with a bunch of terminal block modules on it. I put all of my electronics on a board behind the DIN rail (LEDWiz, IPAC, PC, dedicated power for LEDs, relay boards, etc.) and ran all of their connections to the DIN rail. From the DIN rail, wires ran out to my "external" devices (buttons, CREEs, LEDs, contactors, etc.) My philisophy was that anything on that board must pass through my terminals to get to stuff in the rest of the cabinet. This allows me to label each terminal for clarity and easy diagnosis, and it keeps things neat - no guessing where wires head off to. For stuff that needs to be disconnected from time to time (my backbox topper, for example), I put in-line connectors on it (molex plugs - only big ones. 24-pin, in the case of my topper). For my RGB flipper buttons, I ran wires to a 4-position screw terminal strip, then from there I sent wires to each of the buttons for red, green, blue, and common, since they were to all be the same color - one set of leads from the LEDWiz does the job, and I just split out to the buttons at the strip next to the nearest button. Hopefully all that helps. You'll likely get other opinions, but most will be along the same lines - just in varying degrees on "anality" *laughs*. I'm a bit of a perfectionist, so I'm pretty anal. For those that are less worried about perfection, they just screw stuff wherever and run wires in a rats nest. Everyone picks a place in between that they're happy with.
  15. The plans for the next version looks awesome. I'm really looking forward to the flyers and stuff during pause - very cool!
  16. The relay is what is being powered by the LEDWiz. The CREEs connect to the relay, so the LEDWiz never actually sees them as a load - it only sees the relay's coil as a load - thus the 500ma limit on the LEDWiz isn't an issue, as long as the relay doesn't draw more than the 500ma. As for connecting the CREEs in parallel, I would say that should work. You'll want appropriate resisters that match the CREE in question between the relay and each CREE, however. As for what those resisters should be, that is partially dependent on what voltage you intend to drive the CREEs at. Most would use 12 volts, so the resister for the MC-E should be a 25 Ohm, 3.08 Watt, and the T6 should be 13 Ohm, 6.37 Watt. The MC-E is 4 LEDs on one star, and I have no experience with that setup, but you may need 4 resisters for each one - though they do come as parallel or serial configuration on the star, so that might change things completely in terms of number of resisters and the resister's values. It's not clear from the website I'm looking at whether the resister they recommend is to drive each LED in parallel (thus 4 resisters) or all 4 in serial (thus 1 resister). Someone else with experience on that configuration (assuming a star is what you'll be using) is probably better able to give a solid answer for those.
  17. That looks awesome, Zeb!
  18. Totally understand. Perhaps I'll put the "How to Play" button back into my build plan for now, then. Less buttons is great, but it's a little ways off, and I'd prefer not to be without the ability to see game rules. I can always reassign the button to something else later. Thanks, samwyze.
  19. That is pretty cool. There's so much that can be done with the pause screen. It's a great place to grab information like scores, rules, etc.
  20. I wasn't asking for a deadline - just whether or not we had a decision on what was happening with the flyer and instructions buttons being needed or not. If there's no decision yet, that's fine - I'll work around it - but if I don't ask, I'll never know, right?
  21. A quick question - where did we land on the showing the flyers and stuff during pause? I'm in the middle of a cabinet build, and I deleted the Flyer and How to Play buttons in favour of this idea (and the pause button, actually, since that was going to work with a short press of exit, I was told). If I need to put those buttons back, it'd be good to know now, before I start drilling holes Thanks!
  22. I'd say that AHK isn't actually trying to read the files directly - it's just calling whatever plugin is installed to display the files. I'm guessing, but that'd explain the Adobe controls showing up. If you have Foxit Reader installed, I imagine you get Foxit controls, instead. The conversion from PDF to PNG is probably cleanest, for this type of thing, I'd think.
  23. I love that custom pause image!
  24. What's that black thing screwed to the wall, and do I want one?
  25. Here's my dual 46" LCD cabinet build thread. It's over on VP Forums, as well: Project Wildfire
×
×
  • Create New...