PLC retentive memory so pumps restart after a power loss

Why do the pumps need restarting after a brief outage?

The pumps lose their state because the run request lives in memory that clears at power-up. An ordinary output coil follows its rung on every scan, and a control relay outside the retentive range resets to off within milliseconds of the CPU restarting. A small PLC re-evaluates every rung within a few milliseconds of power returning, so the decision about each pump is made again almost immediately. If the request is an ordinary control relay driven by a touchscreen toggle, that relay powers up at 0. The OUT rung driving the Y output sees a false rung and holds the starter off, and the panel reboots into its project displaying zeros. Restarting everything by hand is the only path left.

Because the whole boiler room sits behind a transfer switch, the CPU itself loses power for the transfer seconds, so this reset happens at every blink. The ladder program survives the cycle in the CPU's permanent storage; it is the data bits that reset, and the setpoints or mode bits the panel wrote elsewhere reset with them. The article on why an HMI setpoint resets to zero after a power loss covers that side of the same outage.

What does each symptom after power-up point to?

Match the symptom to the layer that lost its state: the request bit, the output rung, or the retention window. Each one fails in a pattern you can read from the screen, the output status, and how long the power was out.

• Every pump needs a screen restart after every transfer, even a 5-second one: the request bit is outside the retentive range, or a panel toggle drives the Y output directly through an OUT coil.
• One pump returns on its own and the others wait: mixed addresses. The returning pump's request sits in the retentive range and the others do not, so check each address one pump at a time.
• A pump starts with nobody touching anything: a request or an output is latched with no live conditions in the output rung. Add the stop, fault and permissive contacts before the coil.
• The screen shows a pump running but the starter is off: the request survived, a permissive is open, and the rung is correctly withholding the output. Find the open contact.
• Pumps come back after a short transfer but not after an overnight shutdown: the CPU's capacitor-backed retention drained past its window. That case belongs to the operator, by design.

Which bit should hold the pump run request?

Hold one run request per pump in a control relay inside the PLC's retentive range, a C1000-style address on this family, and write it with SET and RST so it stays on after the rung that set it goes false. Three pumps means three request bits, plus one auto/manual bit per pump if the mode should survive the cycle too: six retentive bits in total. On a DL06, the CPU specifications and operation chapter of the user manual lists the retentive ranges the CPU carries by default, so check that table before assigning addresses.

Split the latch into separate rungs. The operator's start command SETs the request, and the stop command, a pump fault, and the startup policy each RST it in its own branch. Keeping the set path and the reset paths apart is the standard way to write a readable latch, and it gives every way to stop the pump a visible home in the program.

Does SET/RST alone carry the request through a power cycle?

No. SET and RST hold a bit against scan logic but they do not make memory retentive. A latch set in an ordinary address still powers up cleared, so the address has to sit inside the range the CPU keeps alive through a reset. The two changes answer two different questions. SET and RST answer the scan question: the bit holds after the momentary rung that set it goes false. Retention answers the power question: the bit holds through a CPU reset.

Converting an OUT coil to SET/RST without moving the address changes nothing after a power cycle, because the bit is still 0 at the first scan and the output rung built on it stays false. The same ordinary-versus-retentive divide governs every other memory type on the CPU; why GX and GY bits do not stay retentive after power loss is the same problem in a different addressing scheme. For this PLC family, the walkthrough of DL06 retentive memory loss after a power outage follows one request bit through the full cycle.

How long does retentive memory survive with the power off?

A capacitor-backed CPU keeps retentive memory only for the limited time its manual prints. The CPU specifications chapter states that a super capacitor retains the values through a power loss but for a bounded period, so design the startup logic for the case where that memory has drained. The decision does not have to wait on that figure. Split the policy by outage length: a generator transfer is a few seconds of dead CPU, comfortably inside the window a support capacitor is designed to cover, so retained requests may restore on their own. A planned shutdown, or any outage of unknown length, is a different case: treat the memory as possibly drained and require an operator start for every pump.

A compact UPS on the PLC's control power is worth adding anyway. Sized for the transfer seconds, it takes the CPU out of short events entirely, and the ladder still decides safely when an outage outlasts the battery.

What must the ladder check before the output turns back on?

Treat the retained request as permission to consider running, and let the output turn on only when the rung's live conditions are true: no stop command, no pump fault, the boiler permissive made, and the selector in a mode that allows a start. Keep the Y output on an ordinary OUT coil so the rung re-evaluates every scan. A permissive that opens while the pump is running stops the pump exactly as it did before the change.

A rung for pump 1 reads: C1000 contact, AND NOT stop command, AND NOT pump fault, AND boiler permissive, AND auto mode selected, coil out to Y0. The stop command, a fault, and the startup policy RST the request in their own rungs, so a pump that was stopped or tripped stays off even though its request bit is the retentive one. Before you allow automatic restart at all, get the policy approved by the person responsible for the boilers: a pump that starts unattended, or feedwater that stays off through an outage, is a low-water risk on a steam boiler. For the conditions worth carrying in a restart rung, the notes on configuring startup permissives for pumps and compressors are a practical checklist.

Scenario: three feedwater pumps through an 8-second outage?

With the requests in the retentive range, the two pumps that were running come back on the first scan after the CPU restarts, the stopped pump stays off, and the operator touches the screen zero times; with ordinary coils, all three pumps need three touches. Set the example up with real numbers: three boilers, one feedwater pump each, requests assigned to C1000, C1001 and C1002, outputs to Y0, Y1 and Y2. The standby generator starts and the transfer switch closes 8 seconds after the utility drops. The CPU re-evaluates the program within a few milliseconds of power returning. Before the outage, pumps 1 and 2 are running and pump 3 is stopped.

The arithmetic at the first scan: 3 request bits retained, of which 2 are set and 1 is clear, so 2 outputs re-energize and 1 stays off, and the count of touchscreen touches is 0. The 8-second dead time sits inside the capacitor's window, so retention carries both set bits. Run the same outage on the original program and the count is 3 requests cleared, 3 outputs off, 3 restarts by hand. Same hardware, same outage; the only change is which range holds the bits and how the coil is written.

How do you change the program and test it without risking the boilers?

Test one pump at a time with its starter locked out, cut control power to the PLC for 10 seconds, and compare the request bit and the output before and after; do not interrupt power to an operating boiler system without the approval of the person responsible for it.

1. Back up the running project, and record for each pump the request bit, the output address, and every contact in the output rung.
2. Move the three request bits, and the three auto/manual bits if you keep them, into addresses inside the retentive range listed in the CPU specifications chapter.
3. Split the latch: the operator's start command SETs the request; the stop command, a pump fault, and the after-long-outage rule RST it, each in its own rung branch.
4. Drive Y0, Y1 and Y2 from the request contacts through ordinary OUT rungs carrying the stop, fault and boiler permissive contacts.
5. Add the long-outage rule from the next section: a request that powers up cleared stays cleared until an operator starts that pump.
6. Bench-check one pump: command it on from the screen, cut PLC control power for 10 seconds, restore, and confirm C1000 returns set and Y0 follows only with every permissive true.
7. Repeat per pump, then run the live transfer test under the approved commissioning procedure, with the boiler operator present.

When should a pump wait for an operator after power returns?

Keep three cases on operator restart: after a planned shutdown, after any outage long enough that the retention window is in doubt, and for any pump that was stopped or faulted before the outage; automatic restoration is for a brief transfer that caught a healthy, permitted pump mid-run. The retention memory is its own discriminator, so the ladder can sort the two cases without knowing the outage length: a request that survives the cycle was inside the capacitor's window, so that pump may restore; a request that powers up cleared tells you the window was exceeded or a reset path ran, and every pump in that state waits for an operator. Use the CPU's first-scan flag to run the startup sweep that leaves every command bit in a defined state; initializing PLC bits to a safe state after a long power outage shows the pattern.

Recommendation: Put each pump's run request in a retentive control relay written with SET and RST, drive the Y output from that request through an ordinary rung carrying the stop, fault and boiler permissives, restore running pumps automatically across a generator transfer measured in seconds, and require a fresh operator start after a planned shutdown or any outage that leaves the request bits cleared.

For the three-pump boiler room in the scenario, the decision lands as: two running pumps return on the first scan, the stopped pump stays stopped, and nobody walks to the touchscreen unless the outage was long enough to drain retention.

Questions