Knocker coil burnt

[RandyT]

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?

[mjrhp]

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.

That's certainly how I see the device - this particular issue with the knocker coils is such a special case that I wouldn't expect a device like the LED-Wiz to account for it, since it's so far outside of its intended function. In virtually every other case, the LED-Wiz does exactly what you want by delegating all of the control logic to the PC-side software. The knocker is different only because the consequences of a software fault are so dire.

However, I think something can be done in a custom firmware to partially address some of the concerns discussed here.

One [possibility] 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....

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.

It's great that you're brainstorming on this, so I apologize for the cold water I'm about to throw on it, but I actually don't think I'd find either of these approaches workable, for a number of reasons. First, anything coarser than one-output granularity would mean I'd have to reserve a whole bank (or a whole LED-Wiz!) to the knocker, since that's the only device in my setup (I think) that needs or wants a time limit. Second, the way you put it - that "this wouldn't be a substitute for application specific fail-safes" - means that I'm still going to want an external hardware timer, and if I have that anyway, it becomes redundant to enable such a feature on the LED-Wiz. Third, if the scheme is based on receiving keep-alives from the PC side, it can protect me from application crashes/freezes, but not from simple bugs where the software continues to run properly but leaves the coil turned on due to a non-crashing coding error. Fourth, again if this is keep-alive based, the VP/FP software (and possibly individual tables) would all have to be modified to know about it and send the keep-alives, so I probably can't use it until some point in the future when all of the software I use is upgraded. If any software is unaware, it means I can't use it for that software, and if I can't use it for any software I'm running then I still need an external protection circuit. Fifth, again with the keep-alives, I don't think I could trust the software to make it impossible to keep sending keep-alives in every possible wedged condition - one thread could get stuck while another keeps going and sending the keep-alives, for example. It would take some seriously careful software engineering to guarantee that the keep-alives definitely stop on error. What this all adds up to is that I have a whole bunch of reasons to still want the external timer circuit, in which case the utility of also having something on the LED-Wiz is minimal. Yes, that might add another layer of protection, as you say, but it seems like a much weaker layer of protection than an external timer. A timer is simple, isolated, and wired directly in front of the coil, so it should be robust against any sort of upstream fault.

This is probably beyond the scope of what can be implemented on the LED-Wiz, but here's what I'd see as a good approach from the user's perspective. If you could designate individual outputs at the *config* level to be time-limited, such that an ON command for that output is always taken to mean "turn on for <configured milliseconds> and then turn off", I think that would address all of the issues above. It would have single-output granularity, obviously. Putting it at the config level would eliminate any compatibility issues because the software wouldn't have to change anything it's doing. Making it a simple timer mechanism rather than a keep-alive-based fault detector would mean we wouldn't have to trust the software to cooperate correctly; it would operate independently of any software faults or errors. And because it's independent of the software, we should be able to trust it as the primary protection mechanism - we might still want to put in a slow-blow fuse, but I think an external timer would be redundant.

At any rate, if it's easy to put something like that in, great. But I'm content to just add an external timer circuit, since it's only the one output where I need it.