On 2026-07-16 6:59 a.m., Don wrote:
I use Williams knockers for simulating gun bangs on my carnival rifle
range. The knocker is underneath of the counter that secures the rifles.
I'll post some photos if anyone is interested...
Yikes! That is way more protection than is realistic for my project.
My next step is to incorporate various solenoid drivers into the
apparatus. Protection may be packed into the (previously unknown to me)
NXP33886 used in the LATCHING VALVE CIRCUIT shown at the bottom of this
link:
<https://www.theleeco.com/support-resources/engineering-tools/electrical-engineering/drive-circuits/>
Pease's solution is far simpler and fewer parts count.
I've dug through the Art of Electronics-3rd Edition (& X Chapters), but >haven't spotted a half decent diagram for current limiting MOSFET
solenoid drivers. They only list that subject with respect to Power >Supplies.
Looking to limit the current for six MOSFETs driving solenoids that draw >around 2A at 28VDC. These are only momentary solenoids and will burn out
if the CPU locks up and the watchdog fails. I need redundancy in this >circuit...
An old way for doing that was to have a capacitor in series with the
driver transistor so you only can get a short pulse. That is pretty
simple to implement, but I'm curious if there is anything more modern
that may be more foolproof? With MOSFETs I suspect one could use a >non-electrolytic cap in series and get a 1/4 to 1/2 second pulse...
Yeah, I'm not an electronic engineer, but you folks have known that as
long as I've been rummaging through this group.
Thanks as always!
John :-#)#
John Robertson <jrr@flippers.com> wrote:
On 2026-07-16 6:59 a.m., Don wrote:
<snip>
I use Williams knockers for simulating gun bangs on my carnival rifle
range. The knocker is underneath of the counter that secures the rifles.
I'll post some photos if anyone is interested...
Yikes! That is way more protection than is realistic for my project.
My next step is to incorporate various solenoid drivers into the
apparatus. Protection may be packed into the (previously unknown to me)
NXP33886 used in the LATCHING VALVE CIRCUIT shown at the bottom of this
link:
<https://www.theleeco.com/support-resources/engineering-tools/electrical-engineering/drive-circuits/>
Pease's solution is far simpler and fewer parts count.
Yes, please post photos of your Williams knockers.
My hometown hosted its annual fair last week. A Las Vegas comedian/magician/hypnotist made an appearance at a midway venue.
During his act, people desperate to be the center of attention -
drama queens - allow themselves to become hypnotised. It doesn't seem
to matter if they make total fools of themselves, as long as they're
center stage and are rewarded with receiving a round of applause
afterward.
You may have confused the complex 555 circuit with the relatively
simple circuit at beneath it. That circuit contains only a NXP33886
IC. The chip inputs MCU signals to directly drive a solenoid without
further ado.
Don <g@crcomp.net> wrote:
Correction: complimentary emittor follower output verbage removed.
Don <g@crcomp.net> wrote:
Jan Panteltje <alien@comet.invalid> wrote:
<snip>
Would this work? fixed gate drive:
+
|
solenoid
|
|----
------| |
|<----------
| |
R [ ] ===
| --- C few uF
| |
/// ///
Use fixed size font
Input a fixed voltage square wave pulse
This will give a big peak and when C charges drop to a lower limited current
Works with transistors too.
It ought to work. The classic "capacitor in series" pick and hold,
(more-or-less mentioned by the Original Poster and endorsed by Piglet),
connects directly to the solenoid. Another alternative is a capacitor
parallel to a solenoid. A summary of both classic circuits appears at:
<https://www.geeplus.com/pick-and-hold-drive-circuits/>
A different solenoid vendor favors newer PWM methods. Their 555 circuit
is my personal favorite:
<https://www.theleeco.com/support-resources/engineering-tools/electrical-engineering/drive-circuits/>
A 1988 patent application is more elaborate:
<https://patents.google.com/patent/US4890188A/en>
The interesting thing about the patent is that it doesn't distinctly
identify U7 as a 555. Instead it uses "monostable" nomenclature,
perhaps for legal reasons?
For what it's worth, here's Bob Pease's topical take:
<https://www.electronicdesign.com/technologies/analog/article/21798400/whats-all-this-solenoid-driver-stuff-anyhow>
No doubt these are all clever circuits, but they're all for solenoids rated for continuous duty. Solenoids rated for momentary duty will burn up at continuous currents required for "hold in." If they were AC types, it
would be an entirely different story because many times the hold in is
around 10%. But that's not the case for DC types. Power is not an issue for momentary types because the activation is so brief, and the application usually limits the duty substantially.
These games and their solenoids pre-date modern protection technology.
In this day and time, it's cheap and easy to embed a PTC onto/into the solenoid to protect it from destruction. Then there's nothing the game
can do by way of fault or abuse to damage the solenoid, and conversely,
the protection will not interfere with the specified performance of the game. The protection has to be tailored to the solenoid. As you said,
some are momentary, and others are continuous operations. But they're
not interchangeable. Some of them get quite pricey and complicated, the
dual coil ones.
Are your solenoids Bally 27-1300? These come in at 14.1 ohms and intended for28VDC system. Part code means 1300 turns 27ga enamel wire. And "A Bally 27-1300 coil can sustain continuous 28VDC power for only 3 to 5 seconds before irreversi
1.The Real-Time Heat Calculation To find out how quickly the coil heats up, wecalculate the energy dissipated as heat (P = V?ý / R):\(P=\frac{28\text{\ V}^{2
2. The 3 to 5 Second Window (Thermal Degradation)Pinball coils are wound withClass 130 (B) or Class 155 (F) polyurethane/polyamide magnet wire insulation. Th
3. The 10 to 15 Second Window (Catastrophic Melting)Once the insulation fails,the physical geometry of the coil causes a runaway chain reaction: The Short-Ci
Repair Community Verification. This reality is well-documented across repair archives like the Pinrepair Guides and community forums such as Pinside. Technici
Based on this info, the appropriate Bourns PTC FOR THIS COIL is the MF-R030, which, according to datasheet, trips in 1 second timeframe, well away from a dama
Most of this is AI, except for their PTC part selection, where it failed to put two and two together.
These games and their solenoids pre-date modern protection technology.ÿ In this
day and time, it's cheap and easy to embed a PTC onto/into the solenoid to
protect it from destruction.
Then there's nothing the game can do by way of
fault or abuse to damage the solenoid, and conversely, the protection will not
interfere with the specified performance of the game. The protection has to be
tailored to the solenoid. As you said, some are momentary, and others are continuous operations. But they're not interchangeable. Some of them get quite
pricey and complicated, the dual coil ones.
On 2026-07-17 3:30 p.m., someone wrote:Are you, perhaps, going too far? Belts and braces?
These games and their solenoids pre-date modern protection technology. In >> this day and time, it's cheap and easy to embed a PTC onto/into the solenoid
to protect it from destruction. Then there's nothing the game can do by way >> of fault or abuse to damage the solenoid, and conversely, the protection will
not interfere with the specified performance of the game. The protection has
to be tailored to the solenoid. As you said, some are momentary, and others >> are continuous operations. But they're not interchangeable. Some of them get
quite pricey and complicated, the dual coil ones.
This board is not for technicians so they can upgrade the rest of the game, it
is for folks who want to repair a game they own with a minimum of fuss (because
they are NOT technicians) and to make it as reliable as is reasonable.
On 7/17/2026 3:30 PM, someone wrote:
These games and their solenoids pre-date modern protection
technology.ÿ In this day and time, it's cheap and easy to embed a PTC
onto/into the solenoid to
Cheap is a relative term.ÿ Anything that you do "per solenoid" has to be repeated for all solenoids.ÿ And, has to be present ON the solenoid as
you want the driver to be identical circuits.
protect it from destruction.
Then you have different flavors of solenoids.ÿ And, have to ensure the
device is *in* the solenoid -- not just dangling off one of the terminals. (otherwise, it risks physical damage or "removal" when someone eventually discovers that the protection device has failed and will just bypass it
to avoid having to purchase a replacement!)
Then there's nothing the game can do by way of fault or abuse to
damage the solenoid, and conversely, the protection will not interfere
with the specified performance of the game. The protection has to be
tailored to the solenoid. As you said, some are momentary, and others
are continuous operations. But they're not interchangeable. Some of
them get quite pricey and complicated, the dual coil ones.
That's why this is done in software.ÿ You can effectively code the duty cycle
based on the SOA of each particular solenoid (load) in each specific application -- coil XYZ in one use may see different operating conditions than in some other use.
There have been numerous different approaches to this, in the industry,
over the years.ÿ All have consequences (cost/price, reliability, serviceability, performance, etc.)
Consider the premise:ÿ the CPU has "lost its mind" AND the circuitry that
is intended to guard against that has failed.ÿ What if the bridge that produces the unregulated supply fails?ÿ (hey, we're EXPECTING failures
so why not imagine and protect against ALL of them?)
The problems with things like PTCs are:
- they can silently be activated countless times in a short period
- they have a finite lifetime
- they can fail
- they represent an additional manufacturing step & cost
etc.ÿ This assuming there are no "bugs" in the system that
the protection device is countering!
And, most importantly, they do nothing to address (or even indicate)
the underlying problem!
One advantage of nonreseting devices is that it brings the failure to
the attention of someone who can *possibly* take action to address it.
I use a *lot* of hammer drivers in my current design:
- to open/close skylights
- to open/close HVAC vents
- to control irrigation solenoids
- to control domestic water sources
- to isolate the system from the municipal water supply
- to backflush the water softener
- to unlock doors
- to control high current contactors
etc.ÿ I.e., to perform actions that would typically require
mechanical action from a human user.
I use "pulse on" and "pulse off" interfaces as they avoid static
(stuck at) failures in the controls.ÿ They are also considerably
easier to handle, in software, as you can "address" a single
device at a time (instead of mapping N of them -- 8 -- into
a single access and then having to wrap all such access in
atomic operations -- which is what inevitably happens when
hardware-types design interfaces without understanding software).
If the processor "goes south", then *it* should be reset to
bring it to a known/safe state.ÿ The field should also be
powered down as you have no idea what state it may be in.
AND, SOMETHING MUST BE MADE AWARE OF THIS *FAILURE*!
In my case, the PSE is signalled when the reset occurs
and *it* decides when (if!) to release the node from
the reset state.
If it notices a pattern in such events, it can opt not to
provide power to the PD to ensure it is rendered inoerable
(just like a human can unplug a device that is repeatedly
"blowing a circuit breaker")
And, having done these things, can alert a user as to the reasons
for its actions.
I am pretty sure John doesn't have an upstream "agent" that
can perform these tasks automatically.ÿ *BUT*, he can involve the
user to ensure a potential problem doesn't persist and morph
into a more serious condition (can something catch fire?)
On 2026-07-20 12:52 a.m., Don Y wrote:
On 7/17/2026 3:30 PM, someone wrote:
These games and their solenoids pre-date modern protection technology.ÿ In >>> this day and time, it's cheap and easy to embed a PTC onto/into the solenoid to
Cheap is a relative term.ÿ Anything that you do "per solenoid" has to be
repeated for all solenoids.ÿ And, has to be present ON the solenoid as
you want the driver to be identical circuits.
protect it from destruction.
Then you have different flavors of solenoids.ÿ And, have to ensure the
device is *in* the solenoid -- not just dangling off one of the terminals. >> (otherwise, it risks physical damage or "removal" when someone eventually
discovers that the protection device has failed and will just bypass it
to avoid having to purchase a replacement!)
No way am I going to be asking my customers to modify their games, that would
not be possible in most cases. The protection must be on the single MPU board
which has all the electronics.
The solenoids are powered from the control transistors which source the 24VDC
to the coil, the other end of the solenoids goes to common/ground. This is not
changeable. Not at all practical to redesign the game itself.
Then there's nothing the game can do by way of fault or abuse to damage the
solenoid, and conversely, the protection will not interfere with the
specified performance of the game. The protection has to be tailored to the
solenoid. As you said, some are momentary, and others are continuous
operations. But they're not interchangeable. Some of them get quite pricey >>> and complicated, the dual coil ones.
The only continuous duty coils are the flippers and they are always active and
have two windings and End Of Stroke switches so rarely present a problem. A non-issue here.
I use "pulse on" and "pulse off" interfaces as they avoid static
(stuck at) failures in the controls.ÿ They are also considerably
easier to handle, in software, as you can "address" a single
device at a time (instead of mapping N of them -- 8 -- into
a single access and then having to wrap all such access in
atomic operations -- which is what inevitably happens when
hardware-types design interfaces without understanding software).
I am not redesigning the original circuit, rather I'm just trying to make it more resistant to failure. Also all of the controlled coils are only fired momentarily, none of them are supposed to be left on at all.
If the processor "goes south", then *it* should be reset to
bring it to a known/safe state.ÿ The field should also be
powered down as you have no idea what state it may be in.
Hence the Watchdog Reset circuit.
Remember to verify that any device that you use doesn't get upset ifAND, SOMETHING MUST BE MADE AWARE OF THIS *FAILURE*!
In my case, the PSE is signalled when the reset occurs
and *it* decides when (if!) to release the node from
the reset state.
If it notices a pattern in such events, it can opt not to
provide power to the PD to ensure it is rendered inoerable
(just like a human can unplug a device that is repeatedly
"blowing a circuit breaker")
And, having done these things, can alert a user as to the reasons
for its actions.
I am pretty sure John doesn't have an upstream "agent" that
can perform these tasks automatically.ÿ *BUT*, he can involve the
user to ensure a potential problem doesn't persist and morph
into a more serious condition (can something catch fire?)
Risk of fire is extremely low, as long as the solenoid circuit breaker works as
it should! There may be smoke however from the coil as it fails...
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 496008:12:56 |
| Calls: | 178 |
| Files: | 605 |
| D/L today: |
7 files (18,398K bytes) |
| Messages: | 70,090 |