Why GX and GY bits do not stay retentive after power loss

Why do GX and GY bits clear after a power loss?

On a DL06 the default retentive V-memory range is V400 to V37777. The GX and GY control words sit outside it at V40000 to V40177 and V40200 to V40377. A power-up restores only the retained range, so every G bit comes back cleared.

The DL06 user manual's CPU chapter, Chapter 3, covers this under "Setting Retentive Memory Ranges". It states that the CPU provides certain retentive ranges by default, sized for many common programs. Retentive locations are the ones the CPU restores at power-up; everything else starts from zero. Other platforms build the same idea into dedicated devices. A retentive timer holds its accumulated time through an outage and resumes from it, and how a retentive timer recovers after a power loss walks through one platform's version of that behavior.

The G-bit blocks sit outside the retained area. A pushbutton writes the G bit during the shift. The bit does its job scan after scan. The first power cut, even one lasting 2 seconds, erases it. Nothing about the pushbutton or the panel is at fault; the destination address simply has no retention behind it.

What symptoms tell you the G bits are not retentive?

Three symptoms point the same way: selections that hold through a controlled stop but clear after an outage, a machine that idles until the panel boots and re-sends a pushbutton value, and a machine that will not restart at all after a panel or cable failure.

• Selections hold through a controlled stop and clear after a power cut. This points to state stored outside the retained range.
• The machine idles after power returns until the panel finishes booting, sometimes 30 seconds or more on a slow panel. This points to a startup sequence that waits for an HMI write to rebuild its state.
• A failed panel or a broken cable leaves the machine unable to start. This points to the panel being the only place the state lives.
• Numeric values fail the same way: a setpoint that returns to zero after a power loss sits in memory the CPU does not retain. The mechanism behind that case is covered in why an HMI setpoint resets to zero after a power loss.

Can the retentive range be extended over V40000 to V40377?

The programming software accepts the entry. On a DL06 set up this way, the CPU loaded the factory default straight back after the download. The extended range never existed inside the controller to begin with.

The CPU chapter documents how retentive ranges are set, and the editor takes an entry covering the whole G-bit block. The decisive step is the readback. After the download, read the retentive configuration back out of the CPU and compare it with the entry. On the DL06 configured this way the CPU read back the factory default, and the extended range was gone.

An editor screen is a request; the readback after the download is the confirmation. Five minutes of readback in the office prevents a startup surprise on the floor, where the same failure shows up as lost selections after the first real outage. Apply the same sequence to any range edit on any controller family: enter, download, read back, then trust.

Does mirroring GX and GY into retentive V-memory work?

The mirror trick holds only what the last completed scan saved. Copy VGX and VGY into retained words at the end of the scan, and copy them back at startup. A power cut after an operator's newest change still loses that change, even when the copy runs every 50 milliseconds.

The copy runs on every scan and its cost grows with the number of words mirrored. The method stays practical for a handful of words, say 16 words or fewer, and not for a whole control block. Decide it by data-loss tolerance. If the machine can absorb losing the changes made after the last copy, the mirror is a workable temporary measure, and a rung comment should record that limit for whoever reads the program next. If the restart depends on the selection, the mirror is the wrong tool and the state belongs in C bits.

What is the fix for selections that must survive a power cut?

Move every selection that must survive an outage into retentive C bits. Repoint the panel pushbuttons to write those C bits. Let the controller own the state, so the machine restarts from the PLC whether the panel is up, down or unplugged.

Retentive C bits are the CPU's own retained state, restored at power-up with the rest of the retained ranges. A selection written to one survives outages, panel failures and cable breaks alike. The conversion is mechanical:

1. List each GX and GY bit that holds a persistent selection or machine mode.
2. Assign a retentive C bit to each one. Keep momentary commands, acknowledges and jog pulses on ordinary non-retentive bits; retention is for selections, not for pulses.
3. Repoint the logic rungs and the panel pushbutton objects to the C bits.
4. Download and read the retentive configuration back from the CPU.

After the move the panel is a command and display device. A pushbutton writes the C bit while communications are up. A panel that loses communications, reboots or fails outright leaves the state untouched, because the state lives in the CPU. How a given pushbutton object behaves through a communications interruption is configured behavior, so test it on the real pair; what an HMI communication timeout does to held outputs covers the same interruption from the outputs' side.

How do you keep startup independent of the HMI panel?

Write the startup rung so the PLC recalls its mode from the retained C bits on the first scan. The panel may have booted, may still be starting, or may be disconnected; the rung does not care. Let the panel display that state once its communications return.

The PLC then reaches its restart decision before the panel says anything. That covers the two cases that break panel-dependent designs: the CPU is already running while the panel is still booting, and the panel has failed outright. The panel comes up in its own time, connects, and displays the C-bit state it finds. From then on the pushbuttons work normally.

Check the panel side in both directions. While running, a pushbutton write must change the C bit. Across a reboot or a communications loss, the panel must come back displaying what the CPU holds. Its return must not overwrite a mode someone set at the machine while it was down, so a panel power-cycle belongs in the acceptance test.

One safety rule sits outside all of this: a retained mode is a memory value, not a permission to run. The startup logic recalls the selection and still gates every output behind the permissives and interlocks that gate a normal start. Any operator confirmation the procedure requires stays in the rungs.

Example: what does the move to retentive C bits look like?

A packaging machine keeps three operator selections in the GX block: run mode, infeed selection and print enable. After a 10 second power blink all three clear, and the machine sits waiting for the panel to boot.

The restart requirement is strict: the machine resumes the exact selections on the first scan, with no wait for the panel. The fix moves all three selections to three retentive C bits, repoints the panel pushbuttons to write those bits, and recalls them in the startup rung before any output rung. Three selections give 2 x 2 x 2, or 8 on and off combinations, too many to cycle through individually. The acceptance test uses two representative states: all three on, and the mixed state of auto on, infeed off, print on.

The test then runs like this. With the machine in a controlled stop, set a state from the panel. Open the machine's disconnect for 10 seconds to force a full CPU restart, close it again, and read the three C bits back. Each state gets 3 power cycles, plus 1 cycle with the panel powered down entirely: 7 cycles and 21 bit readings, 3 bits across 7 cycles, every reading matching what was set. The machine resumes on the first scan each time with no panel write. The old GX words stay unused, and the three selections now live inside the retained range V400 to V37777.

How do you test retention before returning the machine to production?

Load the change, read the configuration back from the CPU, and power-cycle the machine with the panel dark. A normal stop and start and a panel reboot both pass even when retention is broken.

1. Download the change and read the retentive range configuration back from the CPU. It must read the factory default range plus any change you intended. An extended G-bit range that comes back anyway means the state belongs in C bits, not in that range.
2. Set the representative states from the panel and confirm the C bits track the pushbuttons in normal running.
3. Power-cycle the machine with the panel dark: controlled stop, open the disconnect, wait 10 seconds, restore, and confirm the C bits and the resume sequence. Communications errors right after a restore usually trace to the power-up sequence, which PLC COM timeout after power-up: check supply and boot order walks through.
4. Repeat 1 cycle with the panel completely disconnected, so the CPU shows it reaches its restart decision alone.
5. Bring the panel back and confirm it displays the C-bit state it finds, and that its return changes nothing on its own.
6. Confirm the permissives and interlocks still gate the outputs after the restart, then release the machine to production.

Recommendation: On a DL06-class machine whose restart must not wait for a panel, put every persistent selection in retentive C bits and repoint the panel pushbuttons at them. The GX and GY blocks at V40000 to V40177 and V40200 to V40377 sit outside the retained range, and an extended range reverts at download. Keep the mirror-copy rungs only as a temporary measure where losing the last scan's changes is acceptable. After every download, read the retentive configuration back from the CPU, and power-cycle once for 10 seconds with the panel dark before the machine runs production again.

Questions