Another reason to hate "soft touch" power switches

[soldar]

I still have an old CRT TV that after a power outage turns on with audio volume at whatever level it was set. I once came back from a long trip and the neighbors were surprised to hear I had been gone because the TV had been blasting away for days. Now I remember to turn the volume down if I am leaving for more than a few days.

I have mentioned in another thread that I have a big multimeter that has the only switch in the back, like computers, where it is unreachable with the instrument mounted in rack or shelves. I put an inline switch in the power cord. Which is still a pain.

[exe]

Huh, my micsig oscilloscope turns on when I... turn off the bench (the scope has internal battery). It does so with a delay and it cannot be powered off before it finishes booting. It also does it inconsistently, like in 50% of the time. Just unplugging the oscilloscope from the power brick doesn't do anything, but unpluging the brick from mains triggers power on. So, every time I do something with a scope I have to think what power state it will be in the end. I ended up using it from battery only. Horrible design...

[rsjsouza]

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.

No question there. But the discussion has been about storing user preferences, front panel setups, etc. to nonvolatile memory.

The discussion has been about what the soft button ADDs to your system. My point is they add more predictability to a system that can benefit from still having available power to guarantee extra reliability during critical operations by means of a controlled shutdown. It could also improve bootstrap performance by keeping the system in some sort of suspended or sleep mode state. Just picture a high end oscilloscope with a HLOS and it becomes much more difficult to move away from the soft switch. It is not impossible if you are rolling your own OS or use one of the expensive real-time HLOS around (VxWorks, QNX, etc), but much more difficult if you have a commercial HLOS running on the machine. Again, the soft switch can bring an added value if one desires a commercial HLOS on such equipment. 

Specific to the user preferences, etc., small amounts of data like these can be written to flash directly in an unbuffered operation. Even still, the internal RTOS or HLOS may need to queue this operation before it has time to properly finish this operation. Being carefully planned, the most critical operations before a powerdown (the ones that can potentially corrupt the system) must be tied to a NMI to avoid interrupt priority queuing, but perhaps other less critical operations (such as user settings or preferences) may or may not be fully completed before the power is completely lost - manifesting themselves as operations not saved at the next power up (a nuisance). Now, queue a power loss in the shape of a user-operated clunking switch, which happens orders of magnitude more often than an actual power loss: the probability of the nuisance errors happening is magnified.

Is it impossible to make a system completely bullet proof? No, and I mentioned my experience in my previous post, but the limitations there are a tradeoff that I am willing to have. 

(...) 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.

Depending on the complexity of the system, that may not be the case. Just picture a high end oscilloscope with a HLOS and it becomes much more difficult to move away from the soft switch. It is not impossible if you are rolling your own OS or use one of the expensive real-time HLOS around (VxWorks, QNX, etc), but much more difficult if you have a commercial HLOS running on the machine. Again, it is a tradeoff between added functionality and implementation details.

I agree this is shameful. However, it doesn't detract from where it matters the most: when the power supply is actually turned on.

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.

??!?? Really ??!!?? 

Each to its own... To me a power supply in the OFF state is almost completely irrelevant as it does not fulfill its main function, which is to power stuff around. At power off, the only function it does is to look good in my bench and impress my technically inclined friends. For that, I don't think I can fault it either - it looks really good! 

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. 

I didn't say it isn't. See above. But to me a clunking switch is not a "core feature" but a small detail in the overall system. Again, each to its own.

[Mr. Scram]

The discussion has been about what the soft button ADDs to your system. My point is they add more predictability to a system that can benefit from still having available power to guarantee extra reliability during critical operations by means of a controlled shutdown. It could also improve bootstrap performance by keeping the system in some sort of suspended or sleep mode state. Just picture a high end oscilloscope with a HLOS and it becomes much more difficult to move away from the soft switch. It is not impossible if you are rolling your own OS or use one of the expensive real-time HLOS around (VxWorks, QNX, etc), but much more difficult if you have a commercial HLOS running on the machine. Again, the soft switch can bring an added value if one desires a commercial HLOS on such equipment. 

Specific to the user preferences, etc., small amounts of data like these can be written to flash directly in an unbuffered operation. Even still, the internal RTOS or HLOS may need to queue this operation before it has time to properly finish this operation. Being carefully planned, the most critical operations before a powerdown (the ones that can potentially corrupt the system) must be tied to a NMI to avoid interrupt priority queuing, but perhaps other less critical operations (such as user settings or preferences) may or may not be fully completed before the power is completely lost - manifesting themselves as operations not saved at the next power up (a nuisance). Now, queue a power loss in the shape of a user-operated clunking switch, which happens orders of magnitude more often than an actual power loss: the probability of the nuisance errors happening is magnified.

Is it impossible to make a system completely bullet proof? No, and I mentioned my experience in my previous post, but the limitations there are a tradeoff that I am willing to have. 

Depending on the complexity of the system, that may not be the case. Just picture a high end oscilloscope with a HLOS and it becomes much more difficult to move away from the soft switch. It is not impossible if you are rolling your own OS or use one of the expensive real-time HLOS around (VxWorks, QNX, etc), but much more difficult if you have a commercial HLOS running on the machine. Again, it is a tradeoff between added functionality and implementation details.

??!?? Really ??!!?? 

Each to its own... To me a power supply in the OFF state is almost completely irrelevant as it does not fulfill its main function, which is to power stuff around. At power off, the only function it does is to look good in my bench and impress my technically inclined friends. For that, I don't think I can fault it either - it looks really good! 

I didn't say it isn't. See above. But to me a clunking switch is not a "core feature" but a small detail in the overall system. Again, each to its own.

The ability to turn off equipment so that it's not consuming power, heating up the room, wearing out the equipment itself and not a potential fire hazard is definitely a core feature. It's the baseline of what can be reasonably expected. Can you imagine not being able to turn off your car?

[exe]

Same here on off-"feature". Most my T&M equipment used less than 1% of the time, except lab power supplies and my laptop.

I cut mains off when I don't use my lab, I don't want my house to be burned by a malfunctioning device (I have about twenty devices plugged in the lab, some of them second-hand and old).

[Richard Crowley]

When I was managing the E-test lab (on-wafer evaluation of test-dice during process development) we had a problem with mains power interruptions for a period. The hits were pretty short so that most equipment would keep running, although after scrambling the operation. 

After many very valuable test wafers were ruined, I got a bunch of power contactors and installed one in each equipment rack.  So that power for the rack was provided through the contactor, but it would drop-out with any power interruption.  At the local surplus store, I found some nice green N.O. "START" buttons, and red N.C. "STOP" buttons. and built them into a nice 1RU panel at the top of each rack.

That gave us the opportunity to go around to each automated test station and re-start it properly vs. letting the zombie equipment to go on a rampage.

[SiliconWizard]

Well as for me, again I don't really mind those soft power buttons. As long as they are implemented correctly (which granted is not always the case).

Granted, but my question is: What value do they ADD that justifies their complexity, cost,

Well, as for the "value", I think we already covered that. Additionally, they add a more "modern" look and feel. You are of course entitled to personally find those values are of no value to you.

As I said earlier though, I think you're mistaken in thinking they add complexity and cost. In many cases, in modern equipment, I'd say they are pretty cheap to add, and that they are actually much simpler overall than having to deal with proper handling of sudden power-on and power-off, not just for the graceful shutdown cases, but also any time a specific power supply sequencing is required, and other reasons. Anything that is less expensive/or more flexible to deal with in software than purely in hardware.

Depending on the implementation, upon soft shutdown, they can do as little as putting the whole instrument in a "sleep" mode (thus not necessarily shutting down the main power supplies but merely shutting down everything that was already meant to be enabled/disabled by software and then put the display(s) and CPU(s) to sleep as well. They can additionally partially shut the main power supplies down (usually only partially). This last thing doesn't cost anything much either these days. Many DC/DC power modules used in those instruments already contain control signals to shut the PS down (as with computer PSUs), so the cost is practically nothing.

and the added downside of often being implemented INcorrectly?

Well, this is a good point. But a "hard" power switch can be implemented incorrectly in many ways as well due to reasons exposed before...
Again, I think most manufacturers will favor this solution for several reasons, but the main one being that everything that depends more on software than hardware is considered much more flexible and much easier to fix if there are bugs, so in that respect, that's more of a comfortable option for the manufacturer than for the user.

I personally don't mind much, but I think there should be some sense of proportion when designing a lab instrument. Whereas I expect a modern scope to be much like a dedicated computer, thus I expect it to function much like one (except I still expect it to boot faster than a typical computer!), for a simple lab power supply, I would find that silly.

Now when a manufacturer has a whole range of instruments, that still makes sense to use a common OS, for instance, and common subsystems in all of them when possible. So again what's a benefit for the manufacturer is not necessarily a direct benefit for the users.

[IDEngineer]

...they are actually much simpler overall than having to deal with proper handling of sudden power-on and power-off, not just for the graceful shutdown cases, but also any time a specific power supply sequencing is required, and other reasons. Anything that is less expensive/or more flexible to deal with in software than purely in hardware.

Here's how it pencils out:

1) Some devices don't care about power loss. There is no timing requirement to losing power, regardless of reason. They need take no special action to handle loss of power.

2) The remaining devices do care about power loss, and must design to accommodate it, again regardless of reason (intentional or unintentional).

Device type (1) can use either type of power switch because it literally doesn't matter. Device type (2) MUST handle power loss because it can occur for lots of reasons unrelated to the power switch - and once it must handle unexpected power loss, it can automatically handle a hard switch because that is no different from a power company event.

The moment someone suggests there is a "middle ground", where a soft switch is needed because the OS "needs to do something special when power is lost", we're right back at #2 above: What happens when power is lost at the wall? The device can either accommodate that (in which case it's type 1) or it can't (in which case it's type 2), and in both cases a properly designed instrument does not require a soft switch.

That leaves one middle ground: An IMproperly designed instrument that expects power to "play nice" 100% of the time, where they assume power is never lost unexpectedly, and so the "Engineers" on that project leave a gaping hole that causes inconvenience (or worse) when power is nevertheless lost without warning. I would consider such a "middle ground" to be a broken design because a properly designed instrument should anticipate, and gracefully handle, predictable events like power loss. And those that do immediately put themselves into type 2 above, where a hard switch works as well as a soft one.

Anything that is less expensive/or more flexible to deal with in software than purely in hardware.

That's precisely the point: Graceful handling of power loss IS a software event. It is software which is notified that power has been lost, and reacts by saving important non-volatile information. Yes, there's a hardware cost for the AC-loss detection circuitry but that's vanishingly small in any modern instrument's BOM budget, and once that's in place you get exactly what you described: "less expensive/or more flexible to deal with in software", to the extent that if it's later realized that some important piece of data wasn't being preserved that can be corrected with a firmware update.

Bottom line: Power loss either matters or it doesn't. If it does, you have to handle the unexpected loss of power anyway. And once you've done that, a soft switch doesn't add anything (the OS is already getting notified of power loss, so there's no additional information conveyed by actuating a soft switch).

[Dundarave]

Back in the day, one had to “gracefully” shut down gear so that cached data would be written out to slower permanent storage, i.e. hard drives, etc.  Caching, and thus the need to be careful about blowing away the cache before it get written, is essentially a hack to mitigate read/write wait times.

Given that almost everything is now solid-state and the data speeds are so fast, what kind of test gear would still require such a process?  If a scope can save giga-samples per second in real time, surely it can save your trace color selection in the time between “Ok” and when the power goes out...

[rrinker]

 I do not like leaving ANYTHING on when I am not there - so everything on my bench is plugged in to a power strip that has a nice handy remote on/off hard switch with a pilot light, which I have mounted up under the corner next to where my socket is for wrist straps.
 For my basement/model train room, I have all the wall outlets where everything plugs in to controlled by a central switch to shut off the whole thing when I am not there.
 About the only thing I leave running 24/7 is my main desktop computer and my server, and even those get shut down when I am away for any extended period of time like I am now (no worries, I posted about being away on another forum and someone mentioned security. Well, I have two of the most evil, vicious guard Pugs ever known, plus my house is not empty just because I happen to be gone).

(the Pugs are so vicious they might trip you in attempting to be the first to get scratches and treats even if you are a complete stranger)

[ratatax]

Soft power on may be a way to save cost and make engineering easier even if it needs some additional components to switch the mains.
For the product I design I looked for big clunky mains switches, they are costly and a nightmare to integrate into a product, you have to attach them in some way usually it's not easy if they are not panel mount, the button cap is also a hassle since no switch have a standard plug, you'll have to mold your own or rely on the manufacturer's ones which usually provide very poor choices (shapes, colours). You also have to bring the mains close to the front panel with cables, or use a complicated lever system.

In terms of mechanical engineering, a simple press button like the others on the front panel is so much easier, and of course it has all the benefits you mentionned like saving data before shutting down etc.

If it's well implemented I don't see the problem, a well designed circuit should draw only a few milliamps