BLOG
Rack PSU Shutdown: Why Does Standby Power Stay On After 12V Turns Off?
QUICK LINKS
Quick answer: Standby power can stay on after 12V turns off because the main-output control and standby control serve different functions. On the PA350R, PS_ON can disable the main rail while standby remains available under its enabled condition.
The PA350R-212A-R front-end supply has a 12V main output and default 5V standby output. That arrangement can keep supported management functions powered when the high-power system is off. A glowing controller or an accessible management interface is therefore not automatically evidence of an incomplete shutdown.
The diagnostic task is to establish what kind of shutdown was requested and which rails were intended to remain available. This article concerns normal control states; an unexpected protection trip or a retained main-rail latch needs separate fault-recovery analysis.
Define whether shutdown means main-off or all rails unavailable
The PA350R source document separates the main and standby outputs. In system language, “off” may mean that the application’s main power is disabled while management remains active. In a service procedure it may require removal of every relevant energy source. Those meanings must not be mixed. A software shutdown message does not establish an electrically de-energized assembly.
A system that intentionally retains standby may still detect commands, preserve management state or report faults, depending on its design. Do not assume every platform uses all of those functions or that every controller is powered from the same standby rail. Verify the actual power tree. The visible behavior should be judged against the platform’s intended state, not against an expectation that every indicator becomes dark.
The main and standby architecture guide covers the rail roles. Here, define the desired endpoint for the specific event: main output disabled, management available, or a service isolation condition. This classification makes the remaining signal evidence interpretable and prevents a normal standby state from being recorded as a hardware defect.
| Requested state | Expected question |
|---|---|
| Main output disabled | Should standby and management remain available? |
| Management retained | Is the observed controller behavior intended? |
| Service isolation | Has the approved procedure addressed every relevant energy source? |
Why This Matters
- The word “off” can describe a functional state without describing electrical isolation.
- A retained management rail may be intentional and still require normal service precautions.
What OEMs Should Do Now
- Name the intended shutdown endpoint in the test case and operating instructions.
- Confirm the platform power tree and approved isolation procedure independently of software state.
FEATURED PRODUCTS
PA350R-212A-R
- Output Power - 350W
- Output Volt - 12V
- Features - This rack-mount power supply accepts AC line input voltage from 100Vac to 240Vac or DC voltage from 180Vdc to 300Vdc,provides 350 watts of 12Vdc main and 5Vdc standby power. This high power density power supply features a fully digital design, supports the PMBus communication protocol, and is equipped with short circuit, overcurrent, over-voltage, and over-temperature protection.
Read PS_ON and PS_KILL as different controls
For PA350R, the PS_ON description states that low-to-high turns off 12V and high-to-low turns on 12V and clears fault. The PS_KILL description states that high-to-low enables standby, while low-to-high turns off both standby and 12V. These functions explain why changing the main enable need not remove standby. Do not transfer the same names and polarities to another model without its source.
The source’s high and low thresholds are logic interpretation values, not a complete electrical interface specification. They do not establish permitted drive voltage, pull-up arrangements or connector behavior. Use the supported platform controls and approved interface documentation. Do not manually force a signal or bridge an interlock to test a hypothesis about normal shutdown.
Distinguish the command issued by firmware from the state observed at the supported diagnostic interface. If the system requests main-off and the rail turns off while standby remains enabled, the observation may match the intended sequence. If the observed state disagrees with the command, record both and investigate the interface or platform logic before concluding that the supply ignored the request.
| Control transition described by the source | Listed effect |
|---|---|
| PS_ON low → high | 12V off |
| PS_ON high → low | 12V on and fault clear described |
| PS_KILL high → low | Standby on |
| PS_KILL low → high | Standby and 12V off |
Why This Matters
- Main-output control and standby control can intentionally produce different rail states.
- A control-name assumption can turn a normal sequence into an apparent fault.
What OEMs Should Do Now
- Compare the requested operation with the model-specific signal definitions.
- Record command and observed state separately through the supported system interface.
Use event order to verify a normal main-rail shutdown
Capture the main-off request, the supported control observation, PW_OK behavior and the fall of 12V using a consistent time reference. Standby and input-valid evidence provide context. A final screen showing standby present and PW_OK low is not enough to establish whether the event was deliberate, delayed or fault initiated. The sequence identifies which explanation is plausible.
The PA350R source gives separate timing entries for PS_ON-related power-good and output transitions. Use the exact event definitions in the current agreed specification rather than assigning one universal shutdown timer. A telemetry polling interval may be slower than the physical transition, so label polled timestamps and discrete capture separately. Do not interpret a delayed log update as an electrical delay without corroborating evidence.
Retain at least one successful intended shutdown as a reference. Compare an unexpected event against the same markers and configuration. If the main rail falls before the command or a fault is reported first, the event should move into fault diagnosis rather than remaining categorized as normal shutdown. The category should follow the evidence, not the operator’s initial description.
Why This Matters
- A normal endpoint and a fault endpoint can look alike after the transition has finished.
- Timing interpretation depends on the capture method and defined event markers.
What OEMs Should Do Now
- Save one time-aligned normal main-off sequence with standby observed.
- Compare unexpected sequences against the same markers and preserve any earlier fault evidence.
Do not confuse retained standby with fault recovery
Standby remaining on through a commanded main-off event is different from standby disappearing and later returning after protection. The first question concerns control states; the second concerns rail-specific fault behavior. Separate them in the issue record. A controller that stayed alive continuously provides different evidence from a controller that rebooted when its supply recovered.
The PA350R protection entries distinguish latching main faults from auto-recovering standby faults. That can explain a recovery asymmetry, but it does not need to be invoked for every intentional PS_ON shutdown. Check the command history and supported fault record before choosing that explanation. Avoid clearing status simply because the endpoint looks unusual to someone expecting every rail to turn off.
Consider downstream paths as well. An observed voltage at a controller or connector is not automatically proof that it comes from the expected rail; a platform can have other supplies or retained energy. Determine the approved measurement boundary and power tree. Do not disconnect or modify a live assembly just to test a speculative backfeed explanation; follow the platform’s service method.
Why This Matters
- Continuous standby and recovered standby describe different event histories.
- Fault analysis is weakened when an intentional command is omitted from the record.
What OEMs Should Do Now
- State whether standby stayed available continuously or returned after an interruption.
- Preserve control and fault history before deciding whether recovery analysis is needed.
How Phihong supports shutdown-state verification
For a PA350R-212A-R review, provide the intended operating state, unit revision, supported PS_ON/PS_KILL observations, input-valid and power-good history, and both rail observations. Include the platform power tree or an approved simplified view when it is relevant. The useful question is whether the observed sequence matches the intended main-off state, not merely why an LED remains lit.
Confirm the exact standby option and system implementation. The source describes default 5V standby and optional adjustment features; do not assume every unit or platform uses the same option. A public feature listing does not define the installed configuration, electrical interface or service isolation procedure. Resolve those details before turning a shutdown check into an automated acceptance rule.
Use the rack power architecture guide to place the sequence in context and retain the agreed definition with the platform validation record. If the event instead begins with an unexpected protection condition, route it to a separate fault investigation. Keeping normal shutdown and fault recovery distinct makes both procedures clearer and reduces unnecessary resets.
Why This Matters
- A defined endpoint allows the same shutdown test to be interpreted consistently across teams.
- Installed standby options and platform wiring control the observed behavior.
What OEMs Should Do Now
- Ask Phihong to confirm the model-specific control interpretation and configured standby option.
- Document normal main-off behavior separately from fault recovery and service isolation.
Useful Links: PA350R-212A-R product details · PA350R-212A-R technical datasheet
Related Links: Rack PSU diagnostic workflow · PMBus address conflicts · AC_OK versus PW_OK · Main and standby power roles · Rack PSU architecture · Management telemetry basics
Frequently Asked Questions
Does standby staying on mean shutdown failed?
Not necessarily. It may be the intended main-off state. Compare the actual sequence with the platform requirement and the model-specific control definitions.
Do PS_ON and PS_KILL do the same thing?
No. In the PA350R source, PS_ON controls the 12V main output, while PS_KILL has a separate role that includes standby and main-output shutdown.
Can I treat software shutdown as electrical isolation?
No. Use the approved service procedure to establish the required isolation state. Standby, other system sources or retained energy may remain after a functional shutdown.
How do I distinguish normal standby from recovered standby?
Capture the event history. Determine whether standby remained available continuously or disappeared and returned, then correlate that with control commands and supported fault records.
What should the review packet contain?
The intended state, exact model/revision, control observations, AC_OK/PW_OK sequence and main/standby observations, all tied to the same module and time reference.
