4 ms·

Reliability now isn't done with the same methods as it was then. Back then, the good stuff might have been good because the motor was big. The modern good stu

Reliability now isn't done with the same methods as it was then. Back then, the good stuff might have been good because the motor was big. The modern good stuff probably has a brushless motor that can prevent stalls. It doesn't matter if it's big or small, the computer won't let it overheat, so they can make it smaller to save money that they can spend on whatever part is the actual failure mode. The trouble is finding manufacturers that actually do that, rather than just using a tiny motor with no computer and plastic gears with no torque sensing. If you design things with old fashioned methods, you need to use old fashioned heavy parts. Nylon gears in contact with ozone, and switches and connectors of all kinds seem to be the problem on everything I've seen. Which is why I always say I would gladly use 10k lines of code to save one moving part or one switch.

mikepurvis 4y ago
100% agree, but I think the issue here comes with a typical phased design process: - Mechanical: "Here's the physical specs, no need to account for A, B, or C, as it's been handled in software" - Electrical: "Here are the physical constraints and electrical spec. No need to account for X, Y, or Z, as it's being handled in software." - Firmware: "You need to handle A, B, C, X, Y, and Z, but if you run out of time or don't have the budget to make up a test rig for validating all those cases are handled correctly, no worries we'll just ship it anyway."
- eternityforest 4y ago
  The other issue I see is when mechanical and electrical don't actually give firmware the data or control they need. You'll see stuff like a lack of battery level monitoring, or relays without current sensing. I'm not sure why we don't do things the other way, have firmware people present at every step. Some things can't be fixed later. If mechanical puts a weak link gear designed to fail before the motor, firmware might not have enough margin to not wear it out with auto-stop.
  - bumby 4y ago
    Completely anecdotal, but my experience was that a large amount is attributable to systems engineers and project managers not having adequate software background. Invariably, this leads to software rigor being deprioritized or with just little oversight. After all "it's just software"
bumby 4y ago
>I would gladly use 10k lines of code to save one moving part or one switch This creates a whole new reliability problem. Software reliability is notorious for its interface failures and there can be many more of those modes (where hardware typically has a few wear-out style failures). I think about my relatively high-end TV that seems to always struggle with software updates without any glitches. It seems like we've just been lulled into accepting software glitches as the price of having software control everything. Luckily, most of the software is not safety critical. I think this is one of the dangers of relying on software to close reliability gaps. Yes, you can change it quickly and cheaply and it's versatile, but it's often very hard to identify all the failure modes.
- eternityforest 4y ago
  True embedded software is a lot different. Smart TVs are desktop or phone class computers, and even then, the glitches are usually "A power cycle fixes it" or "One feature that wouldn't exist at all without software stops working" type of thing. For non safety critical stuff it's much better to crash every week than to wear out in 5 years.
  - bumby 4y ago
    >glitches are usually "A power cycle fixes it" Maybe I'm becoming a curmudgeon or maybe it's my bias as a former reliability engineer, but the fact that we've normalized this drives me crazy. Imagine your frustration if your car needed to be "power cycled" on a regular basis just to keep it moving forward, yet we've become accustomed to that in our day-to-day interactions with electronics. It's the bane of my existence that I have to continuously power cycle a device to do something seemingly simply like change a tv streaming service or scan a document. Interface failures are rampant.
    - lloeki 4y ago
      > your car needed to be "power cycled" on a regular basis just to keep it moving forward you'd be surprised how often watchdogs get their GIGO conditions triggered and things perform a cleanup reboot while you drive
mschuster91 4y ago
> The trouble is finding manufacturers that actually do that, rather than just using a tiny motor with no computer and plastic gears with no torque sensing. If you design things with old fashioned methods, you need to use old fashioned heavy parts. Oh yeah. Like Surefeed smart cat feeders. They don't use end reed or contact switches to control the lid motor - they use current sensing on the motor and stop it when the current surges due to reaching the end position. The problem is, they also use cheap-ass plastic gears on an apparently pretty strong motor... my old Surefeed from five years ago is still going strong, but the newer revision (which is, admittedly, easier to clean) failed after not even a year because the motor had shred the gears and could no longer detect if the lid was fully closed or opened, making noise for so long that the cat refused to use it. Fucking hell, these things cost 150€+ apiece. Two contact switches and wiring would have cost them less than ten cents. Now they have to pay for the cost of handling the warranty claim... but I'd rather like to have a well-designed product in the first place. (Oh, and it doesn't like rechargeable C cell batteries either, because they apparently saved the dollar that would have given them a boost voltage regulator, so you're stuck buying disposable alkaline batteries)
- eternityforest 4y ago
  One of my general rules is not to buy anything that uses disposable batteries, unless battery life is measured in years. Not only does NiMh always seem to be a hassle, it usually seems like rechargable-based devices are more up to date in general. They probably wouldn't even need a reed switch, just a wad of foam for some buffering plus a more sensitive stop algorithm. Or better yet, don't give the motor enough current to shred gears even at full stall.
  - mschuster91 4y ago
    Meh, I have grown to dislike devices with integrated batteries. For whatever the fuck reason, I seem to burn through batteries... like eight or so phone batteries, original Samsung at that, an Apple MBP2015, various gadgets, all gone to swelling, and often enough an utter PITA to replace. No, no bad chargers either - Anker and original chargers that came with the devices only.

mikepurvis 4y ago

100% agree, but I think the issue here comes with a typical phased design process: - Mechanical: "Here's the physical specs, no need to account for A, B, or C, as it's been handled in software" - Electrical: "Here are the physical constraints and electrical spec. No need to account for X, Y, or Z, as it's being handled in software." - Firmware: "You need to handle A, B, C, X, Y, and Z, but if you run out of time or don't have the budget to make up a test rig for validating all those cases are handled correctly, no worries we'll just ship it anyway."

eternityforest 4y ago
The other issue I see is when mechanical and electrical don't actually give firmware the data or control they need. You'll see stuff like a lack of battery level monitoring, or relays without current sensing. I'm not sure why we don't do things the other way, have firmware people present at every step. Some things can't be fixed later. If mechanical puts a weak link gear designed to fail before the motor, firmware might not have enough margin to not wear it out with auto-stop.
- bumby 4y ago
  Completely anecdotal, but my experience was that a large amount is attributable to systems engineers and project managers not having adequate software background. Invariably, this leads to software rigor being deprioritized or with just little oversight. After all "it's just software"

bumby 4y ago

>I would gladly use 10k lines of code to save one moving part or one switch This creates a whole new reliability problem. Software reliability is notorious for its interface failures and there can be many more of those modes (where hardware typically has a few wear-out style failures). I think about my relatively high-end TV that seems to always struggle with software updates without any glitches. It seems like we've just been lulled into accepting software glitches as the price of having software control everything. Luckily, most of the software is not safety critical. I think this is one of the dangers of relying on software to close reliability gaps. Yes, you can change it quickly and cheaply and it's versatile, but it's often very hard to identify all the failure modes.

eternityforest 4y ago
True embedded software is a lot different. Smart TVs are desktop or phone class computers, and even then, the glitches are usually "A power cycle fixes it" or "One feature that wouldn't exist at all without software stops working" type of thing. For non safety critical stuff it's much better to crash every week than to wear out in 5 years.
- bumby 4y ago
  >glitches are usually "A power cycle fixes it" Maybe I'm becoming a curmudgeon or maybe it's my bias as a former reliability engineer, but the fact that we've normalized this drives me crazy. Imagine your frustration if your car needed to be "power cycled" on a regular basis just to keep it moving forward, yet we've become accustomed to that in our day-to-day interactions with electronics. It's the bane of my existence that I have to continuously power cycle a device to do something seemingly simply like change a tv streaming service or scan a document. Interface failures are rampant.
  - lloeki 4y ago
    > your car needed to be "power cycled" on a regular basis just to keep it moving forward you'd be surprised how often watchdogs get their GIGO conditions triggered and things perform a cleanup reboot while you drive

mschuster91 4y ago

> The trouble is finding manufacturers that actually do that, rather than just using a tiny motor with no computer and plastic gears with no torque sensing. If you design things with old fashioned methods, you need to use old fashioned heavy parts. Oh yeah. Like Surefeed smart cat feeders. They don't use end reed or contact switches to control the lid motor - they use current sensing on the motor and stop it when the current surges due to reaching the end position. The problem is, they also use cheap-ass plastic gears on an apparently pretty strong motor... my old Surefeed from five years ago is still going strong, but the newer revision (which is, admittedly, easier to clean) failed after not even a year because the motor had shred the gears and could no longer detect if the lid was fully closed or opened, making noise for so long that the cat refused to use it. Fucking hell, these things cost 150€+ apiece. Two contact switches and wiring would have cost them less than ten cents. Now they have to pay for the cost of handling the warranty claim... but I'd rather like to have a well-designed product in the first place. (Oh, and it doesn't like rechargeable C cell batteries either, because they apparently saved the dollar that would have given them a boost voltage regulator, so you're stuck buying disposable alkaline batteries)

eternityforest 4y ago
One of my general rules is not to buy anything that uses disposable batteries, unless battery life is measured in years. Not only does NiMh always seem to be a hassle, it usually seems like rechargable-based devices are more up to date in general. They probably wouldn't even need a reed switch, just a wad of foam for some buffering plus a more sensitive stop algorithm. Or better yet, don't give the motor enough current to shred gears even at full stall.
- mschuster91 4y ago
  Meh, I have grown to dislike devices with integrated batteries. For whatever the fuck reason, I seem to burn through batteries... like eight or so phone batteries, original Samsung at that, an Apple MBP2015, various gadgets, all gone to swelling, and often enough an utter PITA to replace. No, no bad chargers either - Anker and original chargers that came with the devices only.