Jump to content

RandyT

User
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About RandyT

  • Rank
    Lurker
  • Birthday 01/01/1965

Contact Methods

  • Website URL
    http://www.groovygamegear.com
  1. As the name implies, the LED-Wiz was designed primarily as a simple (not the extreme high-output type) LED controller, where these types of lock-ups or software crashes are of no real consequence. Any requirements outside of that basic capability, need to have appropriately designed circuitry to support them. By default, it was designed to remain in it's current state, so long as it has power. If the computer were to lock up, or the software to crash, and the LED-Wiz reverted to some other state on it's own, this could be a very undesirable thing for a number of different applications. As it is just not possible for such a generic piece of hardware to account for every possibility, in every application, it is always necessary to have application specific fail-safes built into any external circuitry attached to an LED-Wiz (or any other controller, for that matter.) However, I think something can be done in a custom firmware to partially address some of the concerns discussed here. Unfortunately, the firmware isn't field programmable with these units, so whatever I come up with would require changing the microcontroller, or purchasing an additional unit. Both of which would not be without some additional cost/downtime. So, keeping everything above in mind, there are a couple of possibilities: One would be an overall "watchdog" timeout. This would shut down the unit completely if a command were not received by the unit within a certain time frame. This would complicate software support a bit, and add to the bandwidth required for communication. It would also require that any application/circuitry/devices/etc would need to be designed with the understanding that an "all off" condition could occur at anytime, and steps taken to ensure that such a condition wouldn't leave things in a state which could cause an issue. It also negates the possibility of issuing a single command to the unit to autonomously drive connected LED's with one of the built in pulse modes, when no application is currently running. The other option would be to limit this functionality to only a particular bank of 8 outputs, which would be used primarily for quick "on/off" transitions (like to control small relays connected to solenoids.) Again, this wouldn't be a substitute for application specific fail-safes, or for the code issuing the proper "off" command to those outputs, but it could add an extra layer of protection. Either of these could affect the driver implementations, as they track the current state of the unit and it would no longer be in sync in this event. Since this function should only become active in a system "lock up" or crash scenario, it may not be an issue. But it's possible that the driver could, in the event of a simple application crash, "refresh" with the last known state when operation is resumed, depending on the implementation. That's something which would need to be investigated and taken into consideration. Any thoughts or possible interest in something of this nature? If so, what is the maximum "on" duration required for a normal "on/off" pulse in this application?
  2. 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.
  3. 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
  4. 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
  5. 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..
  6. 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
×
×
  • Create New...