Deutsch   English   Français   Italiano  
<uvm7f5$pvu$1@nnrp.usenet.blueworldhosting.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!nnrp.usenet.blueworldhosting.com!.POSTED!not-for-mail
From: "Edward Rawde" <invalid@invalid.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Re:Predictive failures
Date: Tue, 16 Apr 2024 12:02:43 -0400
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Lines: 65
Message-ID: <uvm7f5$pvu$1@nnrp.usenet.blueworldhosting.com>
References: <uvjn74$d54b$1@dont-email.me> <uvjobr$dfi2$1@dont-email.me> <uvkn71$ngqi$2@dont-email.me> <uvkrig$30nb$1@nnrp.usenet.blueworldhosting.com> <uvl2gr$phap$2@dont-email.me>
Injection-Date: Tue, 16 Apr 2024 16:02:46 -0000 (UTC)
Injection-Info: nnrp.usenet.blueworldhosting.com;
	logging-data="26622"; mail-complaints-to="usenet@blueworldhosting.com"
Cancel-Lock: sha1:ZbMqD0ouNfNDVX2FnvBobgQwUlg= sha256:dBrgvS08QW88ActFWkcl/9samqGKQo2iYZT4BcHJtxo=
	sha1:07hfmMiPbCAcIE49+rjDHqges4c= sha256:RNPP+O5SeVn+XgcgAkcwPrON2mq3m7EgYdh2YWgNCJg=
X-RFC2646: Format=Flowed; Response
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MSMail-Priority: Normal
Bytes: 3750

"Don Y" <blockedofcourse@foo.invalid> wrote in message 
news:uvl2gr$phap$2@dont-email.me...
> On 4/15/2024 8:33 PM, Edward Rawde wrote:
>
> [Shouldn't that be Edwar D rawdE?]

I don't mind how you pronounce it.

>
>
> Again, the goal is to be an EARLY warning, not an "Oh, Shit!  Kill the 
> power!!"
>
> As such, software is invaluable as designing PREDICTIVE hardware is
> harder than designing predictive software (algorithms).

Two comparators can make a window detector which will tell you whether some 
parameter is in a specified range.
And it doesn't need monthly updates because software is never finished.

>
> You don't want to tell the user "The battery in your smoke detector
> is NOW dead (leaving you vulnerable)" but, rather, "The battery in
> your smoke detector WILL cease to be able to provide the power necessary
> for the smoke detector to provide the level of protection that you
> desire."
>
> And, the WAY that you inform the user has to be "productive/useful".
> A smoke detector beeping every minute is likely to find itself unplugged,
> leading to exactly the situation that the alert was trying to avoid!

Reminds me of a tenant who just removed the battery to stop the annoying 
beeping.
Better to inform the individual who can get the replacement done when the 
tenant isn't even home.

>
>
> I'm not looking for speculation.  I'm looking for folks who have DONE
> such things (designing to speculation is more expensive than just letting
> the devices fail when they need to fail!)

Well I don't recall putting anything much into a design which could predict 
remaining life.
The only exceptions, also drawing from other replies in this thread, might 
be be temperature sensing,
voltage sensing, current sensing, air flow sensing, noise sensing, iron in 
oil sensing,
and any other kind of sensing which might provide information on parameters 
outside or getting close to outside expected range.
Give that to some software which also knows how long the equipment has been 
in use, how often
it has been used, what the temperature and humidity was, how long it's been 
since the oil was changed,
and you might be able to give the operator useful information about when to 
schedule specific maintenance.
But don't give the software too much control. I don't want to be told that I 
can't use the equipment because an oil change was required 5 minutes ago and 
it hasn't been done yet.

>
>
....