Configuring Selective Retentive Memory on S7-300 in TIA Portal

1. Problem Overview

The S7-300 CPU family (including the CPU 313C, order number 6ES7 313-5BF03-0AB0) does not support the granular, per-symbol retentive memory model introduced with the S7-1500 generation. In the CPU properties dialog of TIA Portal (or legacy STEP 7), retentivity is configured as a single contiguous range: Number of retentive memory bytes starting with MB0. The user can only specify how many bytes from the start of the bit-memory (M) area survive power OFF, STOP→RUN, and unbuffered RESTART — there is no way to flag individual words such as MW16, MW22, MD54, or MD200 as retentive while leaving MW0…MW14 non-retentive.

This limitation causes three field problems:

1. Marking the entire range MB0…MB203 as retentive consumes backup capacity on the MMC and risks retaining intermediate scratch values that should be initialised on every restart.
2. WinCC 7.3 HMI tags bound directly to MW/MD addresses lose their last value when the CPU is switched off, which corrupts operator faceplates and recipe views.
3. Code becomes non-portable: when the same logic is migrated to an S7-1500 the retentive attribute is lost unless a separate download is performed, creating a maintenance hazard.

The recommended solution is to replace the volatile MW/MD operands with a global Data Block (DB) whose instance-DB area is flagged with the RETAIN attribute. Each individual tag inside the DB inherits the retentive behaviour, regardless of its address, while all other flags remain volatile. The same pattern is documented in the Siemens functional description of S7-1500 CPUs under Retentive memory areas (S7-1500); the principle (DB-scoped retain) is identical on the S7-300 and S7-400 lines.

2. Why S7-300 Retentive Memory Is Range-Based

The S7-300 architecture separates the retentive configuration of three operand areas:

Hardware Configuration → CPU 313C → Properties → Retentive Memory exposes the three numeric spin boxes. There is no symbolic selector: if you want MW200 retained, you must also retain everything from MW0 to MW199. The CPU firmware stores the configured length in the system data block SDB 0 and applies it to the warm-restart OB (OB100) and to the backup/restore procedure triggered by the MMC.

3. Prerequisites

• Siemens STEP 7 / TIA Portal V13 SP1 (Update 9 minimum) — older V13 without SP fails to upload the SDB into a project that contains optimised blocks.
• CPU 313C, 6ES7 313-5BF03-0AB0, firmware V3.3 or later (earlier V3.0/V3.1 are functionally identical for retain but lack some diagnostic OBs).
• MMC of at least 64 KB; the retentive DB will be downloaded as part of the active program.
• Source project compiled without errors — DB retain cannot be set on blocks that contain unresolved symbols or mixed instance / global declarations.
• WinCC Explorer 7.3 (or WinCC flexible 2008 SP5) with an active HMI connection of type S7ONLINE pointing at the same MPI/Profibus subnet.

4. The Data Block RETAIN Method — Concept

DB-based retain works on every S7-300/400/1500 CPU because the retain flag is stored in the DB header (attribute byte in the block interface, S7-matic ATTR_RET bit). When the CPU performs a power-OFF/power-ON sequence, the load image of every RETAIN DB is preserved by the operating system; volatile DBs are zeroed. The mechanism is independent of the bit-memory retentive range, so it does not consume any of the configured MB backup budget.

Three structural rules must be observed:

1. The DB must be a global DB (DB type = Shared DB). Instance DBs attached to FBs inherit the retain setting of the FB interface; this is harder to audit.
2. The DB must be non-optimised on S7-300 (TIA Portal option “Accessible from S7-300/400”). The S7-300 firmware does not understand the optimised-block container introduced with S7-1500.
3. Absolute addressing in the program must change from MW16 to DB_RETAIN.DBW16 (or fully symbolic "dbRetain".SetpointRPM). The original MW16 becomes a scratch flag and is no longer retained.

5. Step-by-Step — Create the Retentive Data Block

1. In the project tree, right-click Program blocks → Add new block → Data block (DB).
2. Name the DB DB_Retain (number 100 is conventional; avoid 0–5 which are reserved for system and SFB/SFC instance work areas).
3. Open the DB properties: uncheck “Optimised block access”, leave “Instance of a…” unchecked (Shared DB), and tick “Set” (RETAIN) under Attributes. The block interface should now show the green RETAIN indicator on every declared tag.
4. Declare the tags that previously lived in M-memory, e.g.:

   STRUCT
       SetpointRPM   : INT;       // formerly MW16  (WORD aligned to MW16)
       AuxTimer      : WORD;      // formerly MW22
       RecipeIndex   : WORD;      // formerly MW28
       Position_mm   : DINT;      // formerly MD54  (DINT, 4 bytes)
       CycleCounter  : DWORD;     // formerly MD112
       Totaliser     : LREAL;     // formerly MD200 (use 8 bytes for REAL/LREAL)
   END_STRUCT

5. Confirm the declaration is free of overlap. The S7-300 compiler aligns tags on a WORD boundary; the offsets above will land at DBW16, DBW22, DBW28, DBD54, DBD112 and DBD200 — matching the original M-addresses one-to-one, which simplifies the search-and-replace step in the program.
6. Compile the block (Ctrl+B) and verify in the inspector that the “Retain” column reads SET for every tag.

6. Step-by-Step — Migrate the User Program

1. Open Project → Cross-references and filter for MW16, MW22, MW28, MD54, MD112, MD200. Record every call site in OB1, OB35, OB100, FCs and FBs.
2. For each occurrence, perform Replace → Operand with the corresponding DB operand:

   Old operand	New operand (absolute)	New operand (symbolic)
   MW 16	DB100.DBW 16	"dbRetain".SetpointRPM
   MW 22	DB100.DBW 22	"dbRetain".AuxTimer
   MW 28	DB100.DBW 28	"dbRetain".RecipeIndex
   MD 54	DB100.DBD 54	"dbRetain".Position_mm
   MD 112	DB100.DBD 112	"dbRetain".CycleCounter
   MD 200	DB100.DBD 200	"dbRetain".Totaliser

3. Because the offsets are preserved, the conversion can be scripted with a Replace in project regular expression. TIA Portal V13 supports a limited regex flavour; use plain text replacement for each pattern.
4. Re-run Compile → Software (rebuild all blocks). The compiler will flag any tag that conflicts with the DB interface (e.g. an indirect read that previously pointed inside the M area but now lands in undefined DB offset space).
5. Open the Watch table and add both the old MW/MD addresses and the new DB tags side by side; verify that writes to the new symbols mirror into the watch window.

7. Step-by-Step — Update the WinCC 7.3 HMI Tags

WinCC 7.3 cannot read DBx.DBW tags directly through the OPC channel of a third-party PLC; it goes through the S7ONLINE / SIMATIC S7 PROTOCOL SUITE. Two integration paths are commonly used:

7.1 SIMATIC S7 Protocol Suite — direct DB tag

1. In WinCC Explorer open Tag Management → SIMATIC S7 Protocol Suite → MPI (or PROFIBUS) → New Tag.
2. Set Data area = DB, DB number = 100, Offset = the absolute byte offset of the desired tag (16, 22, 28, 54, 112, 200).
3. For MD200 (DWORD / LREAL) select the appropriate data length: 4 bytes for DWORD, 8 bytes for LREAL. WinCC will treat the LREAL as a 64-bit float.
4. Assign the new tag to every HMI element that previously referenced the M flag. The HMI faceplate should now read the retained value after a CPU power cycle.

7.2 Symbolic HMI tag through TIA Portal integration

1. In the TIA Portal HMI project, navigate to HMI tags → Show HMI tags of the S7 connection. TIA Portal V13 will surface the DB tags as selectable symbolic names.
2. Drag dbRetain.SetpointRPM onto the HMI tag list; the connection editor resolves DB100.DBW16 automatically.
3. Download the HMI station; WinCC Runtime will read/write the symbolic address through the same MPI/Profibus.

8. Verification & Commissioning Procedure

1. Download the project (hardware + software) to the CPU 313C. Accept the prompt to delete all blocks; the SDB must be re-generated with the new DB structure.
2. Switch the CPU to RUN. Open a watch table containing DB100.DBW16, DB100.DBW22, DB100.DBW28, DB100.DBD54, DB100.DBD112 and DB100.DBD200. Write distinctive values: 16#1234, 16#5678, 16#9ABC, 1234567, 9876543 and 3.14159E+0.
3. Force a power OFF / power ON at the 24 V supply (or trigger an MRES). Allow at least 30 s for the MMC remanence to elapse before re-energising.
4. Re-open the same watch table. All six values must reappear unchanged. The volatile M flags (e.g. MW0) must be 0.
5. Trigger a STOP → RUN transition via the mode selector. The DB tags must remain unchanged. A RUN → STOP transition is also valid; STOP clears only the PAE/PAA, not the retentive DB.
6. On the HMI faceplate, navigate to the screens bound to the migrated tags and confirm the values match the watch table.
7. Archive the verification log — most plant quality systems require a screenshot of the watch table before and after the power cycle.

9. Alternative Methods and When to Use Them

If the application must withstand MMC removal (operator swaps the card while the line is down), combine the DB-retain method with a Recipe function: the in-RAM retain is the first line of defence, and a periodic save to the MMC via SFC 213 (WR_REC) or WinCC recipe view is the second. Remember that DB retain alone does not survive a card pull — only the MMC-resident recipe does.

10. Memory Architecture — Why the DB Outlives the M-Byte

The CPU 313C has three physical memories, all of which contribute to retentivity:

When the configured MB retentive range is N bytes, the operating system allocates an N-byte buffer in the system memory and refreshes it on every STOP/RESTART. The DB retain, in contrast, lives in the work memory and is restored from the load image during the start-up phase. The two mechanisms are independent: a project that marks MB0…MB31 as retentive and DB100 as RETAIN uses 32 bytes of system memory for the first range plus the full DB footprint in work memory for the second.

11. Troubleshooting Matrix

12. Frequently Asked Questions