Don, you seem to get very emotional about this stuff. Relax a little
and lets just discuss a few things.
Sorry, I'm actually *not* "emotional" about it. Rather, trying to
infuse my sense of priority and commitment to various aspects of
the discussion, goals, etc. Old-school, "New England" personality.
(Workplace debates have always been "passionate" -- for want of
a better word. But, never "emotional". They are *ideas* fighting,
not *people*. "If two of us agree, then one of us is UNNECESSARY!")
My point is that the failure you are describing is *very* unlikely. Push
buttons most often fail open or intermittent rather than shorted,
especially a quality outdoor button as you would surely be using.
Again, you're making assumptions. What *I* would use isn't the
issue. What would *you* use if you were a DIYer building something
like this (from published schematics)? What would a manufacturer
intent on trimming pennies from teh design try to smuggle into
the process?
E.g., I'm currently looking at using a pneumatic switch, here
with the intent of "burying" the mechanism safely and having only
a "tube" to expose to the user. I doubt a manufacturer would
go to those extremes.
Buttons can also fail because of the environment they are in.
Getting "gummed up" because tree sap dripped on them. Or,
ice formed inside the switch or along the path that the
mechanical actuator follows.
If *I* am supplying the switch, then *I* can make an assessment as
to the likely failure modes of *that* switch. And, play the
"expected value" game of offsetting the cost of the "more reliable"
switch against the cost of detecting a failure.
If I *don't* have control over the parts used, means by which they
are assembled, etc. then I have to expect that "CAN'T HAPPEN"
*will*, in fact, happen!
That is my point. You are making a big deal out of one failure mode
while there are many others, much more likely, which result in the same
problem that you can do nothing about. There is little utility to
focusing on this one failure mode rather than looking at the system and
considering what are the mostly likely failures and dealing with those.
How do you decide which failures are "most likely" when you can't
control what components are actually used and how well they are
assembled? I've never had a solenoid fail. Neither the actual
solenoid(s) nor the wiring to them. But, I take great effort when
making connections, waterproofing them, routing the cables, *digging*
in the yard (to avoid hitting any buried cables), etc.
OTOH, I've been called on by friends and neighbors to service varous
bits of kit around their homes and found multiple splices in a
single cable ("cut out the old component, tie in the new -- but
don't bother to remove the old *splice*... just treat it as part
of the *wire*!").
I've found 110V electric outlets wired with 220V across them (i.e.,
the neutral connector wired to the other "hot leg"). Earth grounds
tied to live "travelers". 110V devices on 220V services. None
of which are *expected* to "happen" -- yet, do!
Yeah, like someone is going to give you any sort of quote over the phone
based on the diagnostic of a home built controller. That's not the way
service people work normally.
It's not intended to be "home built". As I've said (here and in
other recent threads), I have no desire to be in the manufacturing
business. Yet, would enjoy if these designs found a home *with*
some manufacturer. So that folks who can't or don't want to
recreate these designs can still avail themselves of them -- for
a price. If the development has been done for you (as a manufacturer),
all you have to do is decide if you can make money at some particular
price point *with* that design.
[OTOH, if you enjoy playing with electronics, know how to solder,
would like to tinker with the code *in* such a device, then you
shouldn't be BLOCKED from doing so because a vendor won't
expose the device's innards to you!]
My garage door opener didn't come with an inbuilt ability to "talk"
to anything. It could *listen* to *it's* remote. But, the only way
to tell if the door was open, closed, jammed, etc. was to walk out to
the garage and *look*.
If you, as a manufacturer, could implement a similar opener design
replacing the ~900MHz remote with, for example, a BT remote
(possibly paired with your cell phone so the cost of the
actual transmitter was eliminated) *AND* add the capability of
allowing that remote to *query* the state of the door & opener,
would you do so if all you had to do was deal with tooling charges?
I.e., now the designs are no longer "home built".
Still, I don't get your point. Why can't you detect details of the
failure? I'm talking about what is ultimately useful to the user,
knowing that he plants are getting water. In fact, he wouldn't know
that unless you also included a flow meter of some sort in case someone
shuts off the faucet handle, etc. So if you aren't doing that, you
really are just pretending to include a useful self diagnostic capability.
You can monitor flow *out* of the valve and still not know
that the plants are actually getting water! A pipe downstream
from the valve can fail (as happened to next door neighbor).
The emitters for a plant can clog and restrict the flow of water
(esp true for drip systems -- you might not be able to detect
this until *all* the emitters for a particular plant have clogged)
I.e., a high resolution flow meter is your best bet (assuming
you know -- or can learn -- what the nominal water consumption
rates are for your zones). This is the approach I have been
pursuing as it also gives you other useful information (e.g.,
"I am not calling for any water, anywhere. Why do I detect
water flowing? Has some pipe broken somewhere??")
[It's still possible for certain types of failures to escape
detection -- if they resemble nominal usage patterns -- like
a broken pipe on a nominally high flow zone]
You can try to make the "at risk" side as dumb as possible, but that may
be difficult to make flexible so it will work with different resistance
Actually, it isn't hard if you can "measure" current consumption
(or, resistance, etc. -- duality). And, you don't have to *know*
what the nominal coil's characteristics are. Just that they are
in a certain range. You then *learn* what each condition "looks
like" (to your electronics/software). (you don't even care if your
"measurement units" correspond to any of the SI units!)
So, if you replace a solenoid (or valve -- and fail to "rescue"
the old solenoid from the old valve) with an identical/similar
one, the system sees little or no change. As long as the change
isn't enough to make the bare solenoid look like some other
detectable condition, all is well.
The first time someone presses the button, the results that the
controller sees may be slightly different than previous -- due
to the different solenoid. So, you now learn that "new normal".
If you make a significant change to a solenoid (e.g., a valve
from a different manufacturer; replacing a 3/4" valve with a
1" valve; moving the control signal to another "circuit", etc.)
then you need to *tell* the system to notice the changes.
Otherwise, risk it misinterpretting what it sees.
In reality, you would publish a "how to replace a solenoid/valve"
guide. It would enumerate the steps to perform -- one of which
would be to tell the controller "relearn" (relearn *everything*,
not just a specific valve -- that would be requiring more
information from the user than the system would need. It can
figure out which solenoids have been replaced -- *if* they are
"different enough").
This capability also lets you notice more failure conditions.
And, adjust how you report those as well as how you continue
to operate while they persist.
coils, etc. A single smart controller watching all the solenoids could
be made very simple and cheap so that it would be inexpensive to replace
if damaged. Of course you can add protection circuitry which will
increase the cost somewhat.
When was the last time you heard of someone replacing their $39
irrigation controller because it "broke"? Or, $139 controller?
So, you're advocating a *feature* whereby YOUR controller can be
readily replaced? :>
I don't know so much about using linear optos, but why bother? You
still have a failure mode, the opto.
Repeat that with: "You still have a failure mode: the drive
transistor; the field wire connector; the forward-going opto;
the voltage/current sensor; the PSU; etc." :> The goal isn't
to make things that *can't* fail but, rather, that are *resistant*
to casual failures. And, are able to report as many conditions
as possible that affect the performance of the device in question.
We had a lightning strike in the back yard at a place I lived
many years ago. *Toasted* the "electronic" telephone and
"magnetized" the TV. But, nothing (aside from the phone)
in the house "broke".
Why not just put a small,
inexpensive controller on the "live" side and live with the small added
Because that sort of device is more fragile than some discretes,
etc. And, you don't *need* that, there. OTOH, you *do* need
the hammer drivers over there!
cost? We are talking less than $5 for an MCU and the circuitry. BTW,
remember you need to power this circuit no matter what it is. I suppose
you can power this from the 24 V which I assume is AC.
Much easier to just put an MCU on the "live" side and be done with it.
*Any* circuit you put on the "live" side will be susceptible to the
transients from lightning, even passives, even relays! It just depends
on the strength of the jolt. A simple MCU circuit can have some
protection added for the smaller jolts. Keep it inexpensive and
consider it an expendable for the few times you have high voltages
coming in.
Why expose it if you don't have to? Protect things that are less
flimsy and that *must* exist on that exposed side. Even if you can
price a product so taht you can afford to replace a fair number of
them "under warranty", you don't leave your customers with a good
feeling about your product if they have to be INCONVENIENCED to
replace it!
Yes, actually. Much of the info you give is not directly relevant. Such
as much of what I just snipped.
Ah, silly boy. :> Here's just a *short* bulleted list.
As you suggest, I should *omit* putting all this in context. So,
try hard to forget EVERYTHING about that which has been discussed
in this thread. Ask yourself *honestly* how many items for which
you *crave* justification (it's a spec, I shouldn't have to
justify anything, right? :> ) And, how willing you would be
to even *think* about a problem presented in such a way?
- wired connection(s)
- drive a load of < ~20VA, < 36V, < 1A
- detect an input signal presented via "volt free" contacts
- both simultaneously
- tolerate deployment in temps of -40F - 140F, RH 0-100%
(though the "sense" and "drive" end can exist in RH 0-80, 0-100F)
- not "break" if subjected to conditions beyond these
- operate as a two wire circuit
- operate alongside other (31?), similar circuits with a "common"
- detect a missing load
- detect a shorted load
- detect a short to any "alongside" circuit
- detect an open in any "alongside" circuit
- detect inputs as short as 0.2 sec (i.e., < 5Hz)
- detect indefinite inputs (i.e., > DC)
- survive "nearby" lightning strikes
- "minimize" RFI
- "immune" to RFI/EMI
- 20 yr product life
- low cost (e.g., $2-3 per pin)
- minimize attack surface presented to a potential adversary
- use components and technologies available to tinkerers (cost, low qty)
- use components and technologies available to vendors (not "by hand")
- use components that will be available for product lifetime (or equiv)
- electrically efficient (e.g., 80-90+%)
Of course, you can improve on these -- they are just minimums)
If written as a *real* spec, this would occupy many pages further
clarifying each issue (to answer the questions that the reader would
invariably have and to put each requirement into context -- so
he understood *why* each was necessary)
That is great if you are really trying for the ultimate solution. But
I'm looking for the *right* solution -- for *today*. Someone can
revisit this in the future when MCUs with 100V pin drivers are
available. Or, when mixed mode customs are available at the
corner grocery store.
"Right" doesn't mean "expedient". I've already *got* something
that works -- it just doesn't deal with everything I want to do
(as well as the other applications to which I would like to apply it)
E.g., I use speech as a primary modality for interacting with
the system. I'm not going to waste my time trying to design
the best speech synthesizer. I don't have expertise, there.
So, I'll make a box into which that component fits. And, put
a nominal implementation in place that works -- the *right*
solution for today. Someone can replace this, later, with
better technology (perhaps even proprietary technology -- in
the case of a vendor opting to commercialize it!)
most of us want a practical solution without spending an excessive
amount of time "optimizing" it.
Because you figure you can revisit it, later. I don't know how
old you are or what your opinions of your "future life" include.
*I* don't want to revisit things, anymore. I want to make my
*best* stab at these things (there are a *lot* of them on my
list) and move on. Omitting something that is fairly obvious
is just plain embarassing...
I have *21* designs that I need to complete. I would much prefer
leveraging work done on one to eliminate some *other*. And,
to increase the quantity of individual designs that I will
have to fabricate. I'd love to prune this number down to 4-6.
But, will be happy if I can hit 6-8. By the time I'm done, I
figure I will have dropped ~10K of recurring dollars into this.
It's unlikely I'm going to save another $100 beating it with a
stick!
[If someone wants to commercialize any of these, they can always
elide the components that are not required for a particular
*instance* of a design -- instead of relying on differential
stuffing as I will]
I want to move past "building infrastructure" to developing better
algorithms to *use* that infrastructure. Where, by far, the majority
of the effort and challenge will lie! It might be fun to *build*
a race car; but FAR MORE exciting to actually RACE it! :>
In fact, I once read a paper on how
optimization is a *bad* idea most of the time. Things should be
optimized when optimization is required, but otherwise it is best to
avoid. Your coil concerns is a perfect example. The design could be
optimized to provide lots of noise immunity by assuming some reasonable
range of the expected coil resistance. But if you use a different coil,
that optimization gets in the way of the circuit working.
Likewise, if you want to optimize the design to have no active
components on the "live" side of the isolation barrier, then you will
have a design with little flexibility for design issues you find a
month, six months or some longer time down the road.
I've already quantified those "issues". As I said, I don't plan to
revisit this. I want to come up with a design that I can produce
"a few of", publish and then move onto other aspects of the project.
If someone else figures out how to use some technique or device
that comes on the market next year to do this better, then *he*
can undertake that task -- with my blessing! :>
There is no real need to catch a "quick" button. I would expect to
press such a button for a "long" time, possibly until the water started
to flow. This is an easy issue to deal with by directions to the user.
Our clothes dryer requires the power button to be depressed for a
full second. The washer (same manufacturer -- "sister" product)
responds instantaneously. It annoys the hell out of *both* of us!
Why should we have to hold the button IN for so long? It's already
recessed so it's not like someone is going to bump into it! And, if
such a time is required, then why doesn't the same argument apply to
the *other* product sitting beside it?? Same manufacturer. Possibly
same developers, code base, etc.
You're also thinking only about it "as a button" (because I only
described a "button" application). I can use the same hardware
interface to talk to the anemometer and/or rain sensor on the roof.
Both emit very *brief* pulses. Should I design, layout and
fabricate *another* circuit that is largely similar -- but with
different constraints?
{Again, I didn't mention this in my post as it just would complicate
the discussion. It is, however, reflected in the bulleted list
I presented above -- as a simple, unqualified "requirement")
Where did you pull 15 seconds from... no, wait, I don't want to know!
If you have to drop the solenoid to examine the button, then you
would want to keep the polling interval relatively long -- so the
water isn't "pulsing" through the pipes (which can become audible).
BTW, I have found that gas pumps do exactly this. If you press the
octane select button quickly, it is not seen by the pump. You have to
press it like you are working a mechanical device, not a quick jab. This
is not unusual on ruggedized equipment.
[Having been involved with gas pumps in the past... :> ]
This is often a consequence of a slow polling loop -- the button is
just not *examined* very frequently. Some implementations treat
the "pump" (what the user interacts with) as a "terminal" of sorts.
The switch closure is *reported* to a control algorithm elsewhere.
Which, in turn, responds with commands to turn on lamps, engage the
pump, etc.
And, some switch debounce algorithms are sloppy -- they report the
switch only *after* it has been "seen" for some number of observations
(instead of reporting it on the *first* observation and just absorbing
any bounce thereafter). If this happens before the event is reported
to the "controller", then the response is even more slugish!
[I've got a paper I wrote on hardware and software debouncing
techniques here, somewhere]
If you think this just saves a few resistors, you don't understand your
own design. Each of those resistors have to be sensed and the sensing
circuitry has to be protected from spikes. Having just *one* sense
element may be the biggest cost saving you can come up with here.
I was being facetious. But, in fact, it doesn't save much.
Recall, you have to be able to drive multiple solenoids at
the same time. You don't want a failure in one to cause
the others to be unusable. So, you want to treat each
output/input as a separate circuit. With its own current
limiter, isolated *control*, etc.
Once you put a current limiter/source in the equation, you've
already got a handle on the "sense resistor" -- *in* the
current limiter!
As I've said, give me credit for having thought about these
things *before* posting my question!