PLC run hours reset at power loss: keep them in a counter

Why the hours disappear

The PLC keeps its data registers in SRAM, and SRAM holds its contents only while something powers it. Through an outage these CPUs keep alive only the range the manufacturer designates retentive, and on this family that ride comes from a capacitor good for about one hour without the optional battery. Timer data registers sit outside the protected range: the address picker lists each device type, the timer data type is the nonretentive one with an initial value of 0, and the power-cycle check below confirms it on your own panel. For the vocabulary: a retentive device keeps its value with power off, a nonretentive one does not, and what input and output retentive mean on an HMI panel unpacks the terms.

Two events write 0 into a nonretentive register, and only one is the outage you are chasing. The first is power removal. The second is a program download, because the project file excludes retentive values by default and the download writes fresh zeros. The second one surprises people after the first fix is already in, so the rebuild below handles both.

What each symptom points to

Each failure pattern here has one likely owner. Find yours before editing the program.

• Hours return as 0 after every power cut, everything else on the screen fine. The device holding the hours is nonretentive. Open the address picker and record which device holds each accumulated value before you change anything.
• The meter reads wrong or blank after a display restart, while the PLC register still shows the hours. That is a tag, cable or display configuration fault, and no memory change will fix it.
• Hours clear right after someone presses a reset button. Trace the bit from the button to the reset input, one bit per meter, such as the C2, C3 and C5 bits in a three-meter program. A bit left on, or a rung that reads the wrong state as a reset request, wipes a healthy count.
• Hours survive a short outage but not a weekend. The capacitor's window ran out. Longer rides need a battery-backed CPU variant, not more program work.
• Hours vanish after a program download rather than after an outage. The software's project option for retentive values is off. Turning it on is part of the rebuild below.

A setpoint or stored value in the panel that also returns to zero after the same outage belongs to the same family of faults; the panel-side case is worked through in why an HMI setpoint resets to zero after a power loss.

Separate a display fault from a memory fault

Two power tests answer the question, and they are not interchangeable.

1. Write down the hours in the timer data register and on the meter, with power on.
2. Restart the display only. If the raw register still reads the hours, the memory is intact and the fault is in the tag, the communications or the display configuration.
3. Remove power from the PLC for longer than the capacitor's retention window, repower, and read the raw register again in the programming software. A value of 0 confirms nonretentive storage.
4. Leave the PLC powered and touch nothing for a minute. A register that moves toward 0 on its own has an active reset condition, usually a reset bit whose power-up state or polarity is wrong.

Watch the raw register in the programming software each time, not the meter on the screen. A display restart alone tells you nothing about what the PLC kept; only the PLC power cycle tests memory.

Move the hours into a retentive counter

Counters in this family hold their accumulated value through a power cut, which is why the timer-plus-counter pair is the standard run hour meter here. The timer watches the run status and pulses once per hour of running, each pulse increments the counter, and the counter's accumulated register is the number the meter displays. The pulse timer can stay in a TD register, because a cut mid-hour costs at most that hour's pulse, one count per outage at worst.

1. Pick a counter for each meter and note its accumulated register address in the address picker.
2. Add a self-resetting timer on the run status contact, preset to one hour. Its done pulse increments the counter and restarts the timer.
3. Repoint the meter tag from the timer data register to the counter's accumulated register. The display side, scaling and the numeric object, is already laid out in show motor run hours on an HMI from a PLC counter; this page is only about keeping the value alive.
4. Move each reset pushbutton bit, such as the C2, C3 and C5 bits, onto its counter's reset input, so a service reset clears its own meter and nothing else.
5. Turn on the software option that saves retentive values with the project, under Setup, then Software Setup. It ships off, and with it off the next download writes zeros back into the counters.
6. Repeat for the remaining meters so motor hours and unit hours stay independent.

Some PLC families ship a timer instruction whose accumulated time is already retentive; where one exists it replaces the counter pair, and one family's wiring from that instruction to an hours display is shown in how a retentive timer instruction drives a runtime hours display.

Rebuild the alarm and the resets

The alarm logic keeps its shape; only its input moves. A greater-than-or-equal contact between the counter's accumulated register and the maintenance threshold energizes a coil, the same coil the display watches to raise the alarm screen. The comparison holds true from the moment the count reaches the threshold until a reset clears the counter, so the alarm screen stays up until maintenance closes the job.

Give the reset a paper trail: the hours at service time belong in the log before the button clears them. The rung pattern for that is in save the previous count before a PLC counter reset. Check two things on every reset rung: the button clears only its own meter, and no alarm rung writes to the reset input, or the alarm destroys its own record the moment it fires.

Example: a 3,000 hour filter alarm

An air handler blower runs 8 hours a day, and the equipment schedule calls for bearing service at 3,000 run hours. That 3,000 is this example's assumption; your own number comes from the service schedule for the equipment.

At 8 hours a day the counter reaches 3,000 in 3,000 ÷ 8 = 375 days, about 12 months. On a two-shift schedule at 16 hours a day the same threshold arrives after 3,000 ÷ 16 = 187.5 days, about 6 months, which is why the threshold belongs in run hours and not in months. The count of 3,000 sits well inside a plain integer register, whose signed 16-bit limit is 32,767. Minute resolution instead of hour resolution scales the threshold to 3,000 × 60 = 180,000 counts, which overflows that 16-bit limit, so minute pulses need the wider register type the picker offers.

Four weekend shutdowns in a season show what the change buys. A timer data register holding the hours directly restarts from 0 at each shutdown and throws the season away. The counter loses at most the pulse in progress at each shutdown, up to 4 counts across the four outages, and the meter reads the same on Monday morning as it did on Friday evening.

Prove it with a power cycle

The proof is a power cycle through the disconnect the building actually uses, with the PLC, its power supply and the display dropping out together, and the counter read before and after. A bench supply on the controller alone skips the display and the field wiring. Expect the count to return exactly; a count that returns short by one means the outage landed inside a pulse hour, the design's expected cost.

One safety note: cycle power only with the driven equipment locked out, because a repowered controller can start a blower or a pump with nobody expecting it. Watching a retentive value across a controlled power removal is standard discipline across controller families; one write-up of the method is in why retentive values need a controlled power-cycle test.

If maintenance also wants outage history and trends, that data belongs outside the panel, because the panel's trend memory faces the same power events; archiving trend data outside the panel after a power cycle covers the external route.

The decision

Recommendation: accumulate run hours in a retentive counter fed by an hour pulse, compare the accumulated register against the service interval with a greater-than-or-equal contact, reset the counter only from the maintenance pushbuttons, and turn on the project option that saves retentive values. That covers the ordinary case, where the count exists to schedule service and losing one count per outage is harmless. Reach for a battery-backed CPU variant only when outages longer than the capacitor's window are routine. If the hours vanish only after a program download, the fix is the project option under Setup, then Software Setup, with no hardware change. If the raw register holds its value but the meter lies, the fault is in the tag, the cable or the display configuration, and the PLC program stays as it is.

Questions