Electronics > Projects, Designs, and Technical Stuff
Another reason to hate "soft touch" power switches
IDEngineer:
--- Quote from: rsjsouza on July 19, 2019, 02:20:59 am ---the main reason I can see is to be quick enough to have application data be written to the non-volatile media before the power is off. The reason the data is in RAM is most probably due to running performance - in the world of ultra fast SSDs, RAM is still the absolute performance king.
--- End quote ---
No question there. But the discussion has been about storing user preferences, front panel setups, etc. to nonvolatile memory. Not storing megabytes of captured, digitized data. The former would be measured in hundreds of bytes, not megabytes, and you can easily write that amount of data to EEPROM or flash in the time it takes for the rails to taper off. So unless the argument is "We're preserving all of your captured image data", there's simply no reason that an AC power loss detection circuit that drives a hardware interrupt can't do double duty and protect against both unplugged line cords and turned-off hard switches.
--- Quote ---I don't think the soft switch is an issue per se, especially in the light of the benefits it can bring to cater to complex OSes and therefore better featured and better performing equipment.
--- End quote ---
See above. The "better features" and "better performance" would have to be megabytes of data, or else the argument doesn't hold. And that begs the question: How do they deliver these "betters" when AC is unexpectedly lost? Think flipped switch, electrical company glitch, tripped-over cord, etc. Do they just write that off, sorry for you dear user, tough luck?
(True story: I was working on a very early Linux system years ago when something rolled off the back of the table and of all the places it could have fallen, it fell right on the switch on the power strip. Trashed the hard drive partition so badly I had to reinstall the OS. That's when I started taping across power strip switches with duct tape. You just never know when AC will fail you, which is why a properly designed piece of expensive T&M equipment should protect against at least the loss of basic volatile data. I don't expect megabytes to be magically preserved, but loss of AC is just too much of a risk to ignore. And once you've solved that problem, a hard switch is precisely zero different and can enjoy the same benefits.)
vk6zgo:
Of course, if you run your gear 24/7 in "awake" mode, you may be presented with the opposite problem, where your SMPS "start up" circuit has failed.
Only when you have a mains failure, do you notice this.------great fun being stuck with several devices which won't turn back on.
Even more off topic, but a good story, so being an O.F., I will tell you anyway:-
Back in the day, I was tasked to lead a team automating a TV Transmitter site which used Tx which had never been designed for such service.
With a lot of workarounds, cut & try, etc, we got together a system which was effectively "a Tech in a box", using a Programmable Logic Controller & a whole raft of electromechanical interfaces.
This, when it received the right signal from the Studio (the presence or absense of vertical syncs) would, in turn, switch on the tube filaments, wait 5 minutes, then apply the HT.
At closedown, it would perform the opposite procedure.(it also did a lot of other stuff)
All good, but if there was a power loss, then the emergency power plant (EPP) took over, we needed to "truncate" the procedure to get back on air as quickly as possible.
To do this, we needed an input to the PLC to indicate the loss of power.(It could detect this itself, but didn't provide it as an input).
This site used -24v fed aound the building to do various things, & this was normally provided by a Mains operated power supply.
In a power failure, the 24 volt EPP starting battery would take over via some "steering diodes".
We blithely connected our PLC input to the "unprotected" side of the diodes, so that Mains loss should cause the loss of -24v, & trigger the fast TX restart
Several "simulations" of a Mains fail worked OK, so the system was put into service.
The first weekend, I was callef out for a transmitter failure.
I was presented with the spectacle of both sound transmitters up ok, but both vision Tx with HT on & no filaments.( needless to say, this is an undesirable condition).
It turned put that the large electrolytics on the supply kept the DC voltage applied to the PLC input up long enough for the normal startup procedure to occur, but without the initial "fils on" step.
This was quickly "bodged up" by bulding an unfiltered DC supply in a handy plastic box, plugging it into the nearest power point with a "don't turn off!" sign attached, pending the provision of a better alternative.
The only relevance this has to the thread is that it is incredibly easy to set up a system where the unintended consequences are so weird, that they are overlooked.
We assumed that the worst case result of this input not working being the controller just reverting to its normal start up sequence, rather than what actually happened.
All the other functions worked perfectly.
Mr. Scram:
--- Quote from: rsjsouza on July 18, 2019, 09:15:15 pm ---I agree this is shameful. However, it doesn't detract from where it matters the most: when the power supply is actually turned on.
There were several EEVBloggers that sent their units back to Keysight for a recall (myself included) and the exchanged units presented the same behaviour.
--- End quote ---
Unless you're running a factory where equipment is up 24/7, I'd argue the off state is as relevant as the on state. Even if you're not looking at it while the device is in it. I can't confirm or deny this is intended behaviour, as I don't own one of these power supplies.
Mr. Scram:
--- Quote from: tautech on July 18, 2019, 10:06:47 pm ---They ADD the ability to have a powerful OS that permits incorporation of complex features into an instrument and that OS needs be shut down gracefully to retain settings.
Most that have soft key power buttons also have the feature to set what happens after a power failure as has already been pointed out to you.
Apparently you had changed from default power behavior so no wonder your DSO restarted after a power failure.
--- End quote ---
That's just fixing one problem with another. Build a more robust OS or hardware and you'll never have to fix the problem of things going corrupt with a power failure in the first place. We already established that power failures do occur without mains switches, so not having an OS robust enough to survive an outage is already shoddy engineering.
Mr. Scram:
--- Quote from: rsjsouza on July 19, 2019, 02:20:59 am ---I don't think it is lazy engineering - the main reason I can see is to be quick enough to have application data be written to the non-volatile media before the power is off. The reason the data is in RAM is most probably due to running performance - in the world of ultra fast SSDs, RAM is still the absolute performance king.
This is also not a cost cutting scenario, as the highest-end oscilloscopes are Windows or other HLOS based, as well as the vast number of PCs of all price points in existence today without a clunking switch.
The systems I saw running embedded Linux that did not have issues with a clunking switch were running entirely from RAM - simpler systems that still took a while to boot to load from flash to RAM (more than one minute).
I don't think the soft switch is an issue per se, especially in the light of the benefits it can bring to cater to complex OSes and therefore better featured and better performing equipment. Besides, if designed properly the power consumption is very minimal and with decent isolation (using latching relays, for example).
--- End quote ---
Implementing complex OSs with a hard switch is a doable engineering problem. Implementing soft switches with the associated downsides like power consumption and apparently costs seem to be lazy engineering. It's strange people are content to give up core features when they're offset with some shiny gimmicks. It can do everything except for things equipment did 50 years ago. :palm:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version