S7-300/400 Counter Retentivity: Fix OB10 Daily Reset Value Loss

Problem Overview

On Siemens SIMATIC S7-300 and S7-400 controllers, an OB10 time-of-day interrupt is commonly used to reset production counters at a fixed clock time (for example, 00:00, 06:00, or shift handover). The interrupt fires reliably, but engineers frequently observe a secondary failure mode: after an uncontrolled stop–start cycle (power loss, STOP–RUN toggle, MRES reset, or firmware download), only some of the counters retain their last value. The rest fall back to zero. In a typical installation this presents as 70–90 % of the 98 counters in the user DB keeping their values, while a smaller subset loses them on every restart.

The root cause is almost never the OB10 logic itself; the daily reset continues to operate. The real defect is that the counter storage locations are sitting in memory areas the CPU is configured to treat as non-retentive. As soon as the CPU performs a cold restart, the non-retentive image is overwritten with the initial values declared in the data block, and the counters that were written into a retentive sub-range survive. This article documents how to identify the affected area, configure retentivity in STEP 7 V5.x HW Config and in TIA Portal device properties, and verify the result on a live CPU.

Root Cause: Why Some Counters Reset and Others Do Not

The S7-300/400 CPU distinguishes three power-up classes defined in the Siemens operating system manual:

If a counter is implemented as a DB variable of type INT or DINT that is incremented by an IEC counter function block (CTU, CTUD), the value lives in the load memory image of the DB. Whether that image is copied back into work memory on restart depends entirely on the retentivity setting in the CPU's hardware configuration. Counters implemented with the older S_CU / S_CD / S_CUD instructions sit in the system memory area of counters (C0…C255) and follow the global retentivity bit mask in HW Config, which is applied uniformly to the whole C area. The two implementation styles therefore respond differently to the same restart class.

When a mix of IEC-counter-DB tags and legacy S counters are present, the asymmetry is the source of the user's observation. The IEC counters whose DB word is inside the retentive range keep their count; the ones outside that range fall back to the initial value declared in the DB. The legacy S counters outside the retentive C range fall back to zero, regardless of DB placement.

S7-300/400 Memory Model and Retentivity Ranges

Every S7-300/400 CPU allows the engineer to declare retentive memory ranges in three categories:

1. Memory bits (M area) — bit, byte, word, and double-word markers.
2. Timers (T area) — applies to legacy S5 timers (S_PULSE, S_PEXT, etc.).
3. Counters (C area) — applies to legacy S5 counters (S_CU, S_CD, S_CUD).

For S7-300 CPUs the retentive range is configured per byte count (for example, MB0…MB15 retentive = 16 bytes of M area). For S7-400 CPUs, individual bit, byte, word, and double-word markers can be marked retentive with finer granularity. The exact maximum retentive count for a given CPU is published in the device manual; for example:

The official S7-300 CPU 31x manual documents these limits in section 4.5 (" retentive and non-retentive memory areas"). For IEC counter blocks whose internal CV (current value) lives in a DB, the retentive flag on the DB word in the offline DB declaration does not, by itself, control cold-restart behaviour. The DB itself must be marked non-retain in its attributes, and only the byte range selected under "Retentive memory areas" of the CPU is restored. To retain a value inside a DB, the simplest model is to copy the value to a retentive M area and back on warm restart, or to make the entire DB retentive by including the DB in the CPU's "Retentive DB" list (S7-400 only, in the object properties of the CPU under "Retentive Memory").

Configuring Retentivity in STEP 7 V5.x HW Config

For an S7-300 with 98 counter tags in a single shared DB, follow this procedure:

1. Open SIMATIC Manager > HW Config and double-click the CPU icon (e.g. CPU 315-2 DP / 6ES7315-2AH14-0AB0).
2. Switch to the "Retentive Memory" tab in the CPU properties dialog.
3. Set Number of memory bytes starting at MB0 to the byte count required. Each IEC counter increment can be packed as 4 bytes (DINT) or 2 bytes (INT); 98 counters at 4 bytes = 392 bytes. If the total exceeds the CPU maximum, the field displays a red value. In that case split the counter DB into a retentive part (most recent shift) and a non-retentive part (live count) and accept that the live-count part restarts from its initial value — which is correct for daily-reset counters anyway.
4. Set Number of S5 counters starting at C0 to cover the legacy S counter range in use (e.g. 0–63 if you have 64 S_CU instances).
5. Set Number of S5 timers starting at T0 only if any S5 timers are used; for OB10-driven resets it is usually 0.
6. Click OK, then Save and Compile (Station > Save and Compile).
7. Download the hardware configuration to the CPU. The CPU will report STOP briefly while the new system data is written to the MMC.

For an S7-400, the same dialog offers an additional "Retentive data blocks" list. Add the counter DB by DB number here if you want its entire image to be reloaded on warm restart.

Configuring Retentivity in TIA Portal

For S7-300/S7-400 projects migrated to TIA Portal V15 or later:

1. In the project tree, expand PLC_1 > Device configuration and double-click the CPU.
2. In the device view, click the Properties tab in the inspector window.
3. Navigate to General > Retentive memory (S7-300) or Retentive memory areas (S7-400).
4. For S7-300: enter the number of retentive Memory bytes, Counters, and Timers as decimal values.
5. For S7-400: tick the checkboxes for the individual MB / MW / MD / C / T ranges to mark them retentive. The dialog updates the totals at the bottom.
6. For IEC counter blocks (CTU, CTUD) whose CV lives in a DB: open the DB properties and ensure the "Retain" attribute is enabled, and the DB is listed under "Retentive data blocks" in the CPU properties (S7-400 only). On S7-300 the entire DB image is treated as non-retentive; only the M area carries across a cold restart.
7. Compile the hardware (Project tree > PLC_1 > Compile > Hardware and Software (rebuild all)) and download to the CPU.

OB10 Time-of-Day Interrupt Setup

OB10 is the time-of-day interrupt organization block. It runs once when the configured time is reached, then waits for the next configured interval. The configuration parameters live in the CPU's Time-of-Day Interrupts tab.

A minimal OB10 implementation that resets 98 INT counters stored in DB100 at offsets 0.0 through 194.0 looks like this in STL:

ORGANIZATION_BLOCK OB10
TITLE = "Daily counter reset"
VERSION : 0.1
  VAR_TEMP
    i : INT;
  END_VAR
BEGIN
  FOR i := 0 TO 97 DO
    "DB_Counter".C[i] := 0;
  END_FOR;
  // optional: stamp the shift tag
  "DB_Counter".LastReset := DT_DATE_AND_TIME;
END_ORGANIZATION_BLOCK

And in structured text (SCL) for TIA Portal:

FOR #i := 0 TO 97 DO
  "DB_Counter".C[#i] := 0;
END_FOR;
"DB_Counter".LastReset := DT_AND_TOD();

The reset itself is not the problem. The reset writes zero to a memory location that should still be retentive, so the next cold restart correctly reads the last zeroed value back. The asymmetry arises only when the increment logic writes to a non-retentive tag and the daily-reset logic writes to a retentive tag, or vice versa. Consistency is the goal.

Counter Implementation Patterns

Three patterns are in common use, each with a different retention behaviour:

For the scenario in the original question — 98 counters in a single FC, all in one DB — the third pattern is the simplest. Define a UDT UDT_Counter with Current : DINT; LastReset : DATE_AND_TIME; DailyPeak : DINT, instantiate it 98 times in a global DB, and reserve a matching byte range in the M area as a shadow buffer. On STOP→RUN transition, copy the shadow back into the DB; on OB10, zero the DB and write the shadow to zero as well.

Alternative Daily-Reset Strategies

If the S7-300's 16-byte retentive limit is too tight for 98 × 4-byte counters, consider:

1. Move the historical counters to a separate S7-300 CPU with larger retentive capacity, or upgrade to a CPU 319-3 PN/DP (2 KB retentive markers).
2. Use a retentive recipe DB on an S7-400 — DBs on S7-400 can be marked fully retentive in the CPU's "Retentive DBs" list.
3. Persist to MMC and reload on OB100/OB102. On OB100 (warm restart) read the last value from a recipe-style DB. This works on S7-300 with firmware V2.0 and higher. Use SFB 81 RD_DPARA or direct load-memory reads via SFC 83 READ_OB (S7-400) to bring a snapshot back into work memory on cold restart.
4. Shift to a TIA Portal S7-1500. The S7-1500's data block retentive mechanism is per-tag: each RETENT attribute on a DB tag is honoured across cold restart, with up to 8 MB of total retentive data on a CPU 1515-2 PN, for example. This is the most direct modern fix.

The fourth option is the most common engineering decision today because it removes the entire class of "some retentive, some not" bugs and replaces them with a per-tag flag that is hard to mis-configure. Reference the SIMATIC S7-1500 CPU 1515-2 PN manual for the retentive limits and the S7-1500 system manual for migration steps.

Verification and Commissioning

After the retentive range is configured, verify with this checklist before handing the system back to operations:

1. In STEP 7, open the CPU properties and confirm the retentive byte count and counter count. Read back from the online CPU: PLC > Module Information > Retentive Memory.
2. Increment a test counter manually with a VAT table (DB_Counter.C[0] := 12345).
3. Stop the CPU with the mode selector. Wait 5 seconds. Switch back to RUN.
4. Read the counter again. The expected value is 12345. If the value is 0, the DB is not in a retentive area or the OB10 has fired during the test (rare but possible if a time-of-day boundary falls inside the test window). Disable OB10 (uncheck "Active") before the test if you want a clean signal.
5. Repeat for a counter at the end of the DB (DB_Counter.C[97]) to confirm the entire byte range is covered.
6. Force a power-cycle of the cabinet (open the MCB feeding the 24 V DC PSU is not enough — you need a CPU power loss). Confirm that the values still come back.
7. For a full audit, trigger a MRES reset. This clears the load memory too and is the worst case. The values will NOT survive MRES. Document this in the operator manual so it is not interpreted as a bug.

Troubleshooting Matrix

Best Practices for Daily-Reset Counter Banks

• Use a UDT for the counter record and instantiate it in a single DB. Versioning the UDT is easier than versioning 98 separately declared tags.
• Stamp the last reset time as DATE_AND_TIME (8 bytes) inside the same UDT. This makes "is today's count correct?" self-diagnosing on the HMI.
• Centralise the reset in OB10 and have no other code write to the same DB byte range. Mixing cyclic and time-of-day writes is the most common cause of "values change at unexpected times".
• Document the retentive boundaries in the project comments near the DB declaration. A future maintainer should not have to open HW Config to find out why counter 73 is special.
• Use the S7 diagnostic buffer (event ID 4300 series for retentive memory changes, 0x4301 for STOP→RUN transitions) to confirm retentivity changes during commissioning.
• Do not place production counters in the same DB as setpoints and recipes. A recipe download will rewrite the entire DB with the offline project values, wiping the live counters. Split counters into their own DB.

FAQ