TIA Portal: Download S7-300 DB Changes in RUN Mode Without Stop

Problem Definition: TIA Portal Forces a PLC Stop for Datablock Downloads

Engineers commissioning S7-300 systems with TIA Portal V12 Update 3 (and adjacent V11/V13 versions) report a recurring and operationally serious symptom: any small modification to a global or instance data block (DB) that TIA Portal detects as a delta triggers the "Stop CPU and download to target device" prompt, even when the actual on-plc change is harmless. A typical field scenario: an engineer opens the online snapshot of a DB, edits a few constant values to bring the offline and online states back into alignment, recompiles, and TIA Portal still insists on a CPU stop before it will write the block back.

This is unacceptable on plants with continuous processes, life-safety interlocks, or any process where an unplanned stop costs product, energy, or regulatory standing. The engineer needs a deterministic procedure to differentiate a benign DB change (variable name, comment, initial value of an unused tag) from a structural change (new tag, deleted tag, changed data type, shifted offset) and apply the matching download strategy.

Root Cause: Structural vs. Non-Structural Block Changes

The CPU compares the offline block timestamp and structural signature against what is loaded in RAM. If the structural signature differs, the firmware interpreter cannot reconcile the existing code in OB/FB/FC against a new DB layout, because absolute addresses, fragment sizes, and pointer offsets embedded in the compiled code all depend on the original DB definition. The CPU therefore demands a stop so the work memory can be re-initialised consistently.

TIA Portal classifies every change into one of three categories, each with a different download consequence:

Change class	Example	Typical TIA reaction on S7-300/400

Non-structural / cosmetic Renaming a tag, changing a comment, changing the initial value of a tag that is never referenced, modifying the default value of a CONST Often avoidable - see Selective Download List below Structural but compatible Appending a NEW tag at the END of a DB; existing tags keep their absolute offset Stop required on S7-300/400; supported on S7-1500 Structural and incompatible Inserting a tag in the middle, deleting a tag, changing a data type, reordering, modifying ARRAY bounds, changing LENGTH Stop required on every S7 family, including S7-1500

The crucial engineering observation is that the PLC never references symbolic names - it only resolves the absolute byte offset at compile time. Therefore a name change is invisible to the CPU even though TIA Portal flags it as a delta. This property is the foundation of every workaround described below.

CPU Family Behaviour: S7-300/400 vs. S7-1500 in TIA Portal

The download-in-RUN behaviour is fundamentally different across the Siemens S7 families. Engineers who maintain mixed fleets must understand the asymmetry before planning a hot-fix workflow.

Capability	S7-300 (CPU 31x)	S7-400 (CPU 41x)	S7-1500 (CPU 15xx)
Download code blocks (OB/FB/FC) in RUN	Supported (single block)	Supported (single block)	Supported (whole program)
Download a DB with only a renamed tag	Possible via deselect	Possible via deselect	Supported automatically
Append new tag at the END of a DB in RUN	Not supported	Limited / not supported	Supported (TIA V12+)
Change initial value of existing tag in RUN	Stop required if downloaded as block	Stop required	Supported in RUN
Optimised block access	Not available	Not available	Available - symbolic only
Hardware configuration change in RUN	Stop required	Stop required	Limited CiR (Configuration in RUN)

The official Siemens FAQ 76278125 - Which blocks can be loaded in RUN with S7-1500? documents the S7-1500 capabilities and is the primary reference for engineers migrating to that platform. There is no equivalent full-RUN-DB-edit capability for S7-300/400 - the workarounds below compensate for that limitation.

Datablock Change Categories and Run-Mode Compatibility

Before clicking "Download", classify the modification using this decision flow:

1. Hardware configuration change? (New module, removed module, parameter reassignment) - STOP is mandatory. Plan a controlled process pause.
2. Code change in OB / FB / FC? Code-block changes can normally be downloaded in RUN on S7-300/400 with no process interruption - TIA Portal handles this transparently.
3. DB change - is the size or tag order affected? Yes = STOP required (on S7-300/400). Apply the Reserve-Variable Pattern.
4. DB change - only a name, comment, or unused initial value? Apply the Selective Download List technique below.
5. DB change - only a runtime value of an existing tag? Skip the download. Use the watch table or HMI to overwrite the value online. Use a VAT or the HMI to write directly to the running PLC.

Hardware Configuration Changes That Always Require a Stop

The following modifications cannot be downloaded in RUN on any S7-300/400. Engineers must schedule a controlled process interruption:

• Adding, removing, or slot-shifting any module on the central rack or on a PROFIBUS-DP / PROFINET-IO slave.
• Changing the IP address or device name of a PROFINET device (PROFINET IO controller re-parameterisation).
• Modifying the PROFIBUS-DP slave address, baud rate, or bus topology.
• Changing the CPU's own IP address, MPI/DP interface configuration, or subnet assignment.
• Adding or removing a CP module, FM module, or point-to-point configuration.

For the TP1200 Comfort HMI connected via PROFINET, changing the HMI's IP, name, or PROFINET device assignment also forces an HMI restart but does not require the CPU to stop. The TP1200 panel will momentarily blank while the project reloads - design operator screens with this in mind.

Workaround 1: Selective Download List to Skip Non-Critical DBs

The most common TIA Portal stop trigger is a benign DB modification that the tool nonetheless flags as a delta. The CPU does not need the change; only TIA Portal believes it does. The fix is to deselect the block from the download dialog.

Procedure (CPU 315-2PN/DP, TIA V12-V16):

1. In the project tree, right-click the CPU -> "Download to device -> Software (all blocks)".
2. In the "Download preview" dialog, locate the DB row that TIA Portal has flagged for download.
3. Uncheck the checkbox for that specific DB. Other blocks remain selected.
4. Confirm with "Download". TIA Portal writes only the selected blocks.
5. Re-open the DB online and verify that the value, comment, or name change is - in fact - irrelevant at runtime.

For frequent use, enable "Show all blocks" in the download dialog so newly created blocks are visible, and uncheck "Consistent download" if you intend to deselect individual blocks.

Workaround 2: Reserve-Variable Pattern for In-Run DB Expansion

This technique is the only documented method for adding new variables to a running DB on S7-300/400 without a stop. It exploits the same property exploited by Workaround 1: the CPU only cares about the byte-level layout, not the symbolic name.

Procedure:

1. During initial development, add a "tail" of placeholder tags to every DB you expect to extend later. Use names like reserve01 ... reserve20, each of type INT (2 bytes), DINT (4 bytes), or REAL (4 bytes) as appropriate.
2. Reserve 40-80 bytes per DB minimum, depending on anticipated growth. The DB will be slightly larger than functionally required, which is the trade-off.
3. Compile and download the original DB in RUN mode (this is the only download that requires a stop, performed at commissioning when the process can tolerate it).
4. Later, when you need a new variable, rename a reserve tag (e.g. reserve03 -> iNewSetpoint) in the offline DB.
5. Modify the code in OB/FB/FC to reference the renamed tag.
6. Download only the modified code blocks in RUN. Deselect the DB from the download list. The new symbol is in fact the same byte offset as reserve03, so the CPU continues to operate correctly.

The reserve-variable pattern is documented in Siemens training material and is widely used in pharmaceutical, water-treatment, and steel-rolling applications where unplanned stops are unacceptable. It is also the recommended approach in the Siemens FAQ referenced above for S7-1500 projects where engineers still want to keep the offline/online view self-consistent.

Workaround 3: Optimised vs. Non-Optimised Block Access

Optimised block access is a TIA Portal V12+ feature that exists on S7-1200 and S7-1500 only. On S7-300/400, only standard (non-optimised) access exists. This is significant because:

• Optimised DBs store tags by symbol only; the offset is not stable, which means renaming or reordering tags is a structural change requiring STOP even on S7-1500 in some cases.
• Non-optimised (standard) DBs store tags at fixed offsets, which is what enables the rename-without-restart trick on S7-300/400.

If you are migrating a project that was created in STEP 7 V5.5 and converting it to TIA Portal, the resulting DBs are non-optimised by default. Verify in DB properties -> Attributes that "Optimised block access" is unchecked. If you inadvertently enable it on a converted project, the size cannot grow in RUN even with the reserve-variable technique - because optimised DBs have no fixed offsets.

Access mode	Available on	Symbol stability	RUN-mode growth
Optimised	S7-1200 / S7-1500	Tags may move in memory	Yes (S7-1500 only)
Standard (non-optimised)	S7-300 / S7-400 / S7-1500	Tags at fixed offsets	Reserve-variable pattern works

HMI Project (TP1200 Comfort) Considerations During Live Downloads

The TP1200 Comfort panel is typically integrated in the same TIA Portal project as the CPU 315-2PN/DP. Several HMI-side actions trigger an HMI restart or even a CPU stop request:

• HMI project recompile + download: The TP1200 restarts its runtime, the screen blanks for 10-30 seconds, and the CPU continues running. No process impact if the PLC tag interface is unchanged.
• PLC tag database change: If you add, rename, or change the data type of a PLC tag that the HMI references, TIA Portal must update both the CPU DB layout and the HMI tag list. This often cascades to a CPU stop request.
• HMI connection change: Changing the HMI's PROFINET connection, IP address, or device name requires an HMI restart but does not require the CPU to stop.

Verification Procedure After a Live Download

After every in-RUN download, verify both the offline-online consistency and the runtime behaviour before declaring the change complete.

1. Open the project tree -> CPU -> "Online & Diagnostics". Confirm the operating mode is RUN (no SF or BF LED illuminated).
2. Open each modified DB online (right-click -> "Monitor & force"). Confirm the byte-level layout matches the offline DB by comparing the absolute offsets. Any drift indicates a structural change was unintentionally downloaded.
3. Use a Watch Table (VAT) to read the values of the affected tags. Force a known value and observe that the program logic reacts as expected.
4. For renamed reserve variables, place a cross-reference on the new symbolic name and confirm the only references are the new code paths - no stale references to reserveNN remain.
5. Check the CPU diagnostic buffer (Online & Diagnostics -> Diagnostic buffer) for any stop events, OB85 / OB121 / OB122 events, or I/O access errors triggered by the download. A clean diagnostic buffer is the strongest verification.
6. Trigger a controlled test of every interlocks and alarms that touch the modified tags. Do not rely on monitoring alone.

Cross-Platform Note: Other Vendors (B&R X20CP1484 Comparison)

Engineers maintaining multi-vendor fleets often ask whether Siemens' run-mode restrictions are unique. They are not - every major PLC vendor enforces some version of the same structural-consistency rule, though with different surface behaviour. For example, on B&R X20 system CPUs such as the X20CP1484, downloading a modified project that exceeds the controller's available work memory raises diagnostic event 4071 - "Not enough memory" (logged in the logger with timestamps and a forced stop indication) and requires the engineer to either reduce project size, re-evaluate the task class configuration, or re-partition the runtime. The behaviour is documented in B&R's help system and the X20CP1484 user manual. The lesson is the same: treat the PLC's work memory as a fixed-resource envelope and plan changes against that envelope rather than against TIA Portal's convenience features.

Field-Proven Engineering Checklist

Step	Action	RUN-mode outcome
1	Classify change (HW / code / DB-structural / DB-cosmetic / runtime value)	Determines the correct path
2	For DB-cosmetic, deselect the DB from the download list	No stop
3	For DB-structural growth, use reserve variables	No stop on future growth
4	For runtime value changes, write via Watch Table or HMI	No stop, no download
5	For code changes, download only the modified OB/FB/FC	No stop on S7-300/400
6	For hardware configuration, schedule controlled stop	Stop required
7	Verify diagnostic buffer and cross-references	Confirm clean state