S7-300 CPU Migration 315-2AG10 to 315-2EH14: Fixing Drift

1. Problem Overview: Upgrading a SIMATIC S7-300 CPU 315-2DP to 315-2PN/DP

Replacing a SIMATIC S7-300 CPU 6ES7315-2AG10-0AB0 with a 6ES7315-2EH14-0AB0 on a running machine is not a one-to-one, plug-and-play hardware swap. The two CPUs differ in firmware generation, work memory, on-board interface set (MPI/DP only versus PROFINET + DP), instruction-execution speed, and the default STEP 7 / TIA Portal project structure that surrounds them.

Field reports consistently show that loading a backup from the old CPU onto the new CPU and pressing "RUN" results in a CPU that is in RUN without diagnostic buffer entries and without compiler errors, yet the machine sequence either runs too fast, misses steps, or executes a different branch of the same logic. Operator-side parameter changes (delays, RPM setpoints) made through the HMI temporarily mask the problem, but the change does not survive a cold restart and does not transfer to a sister machine with identical hardware.

2. CPU Variant Comparison

Although both catalog numbers begin with 6ES7315-2, the two devices are not interchangeable at the project level.

The 10x cycle-time reduction reported in the field is the single most common cause of "the sequence runs but it is wrong" symptoms. Anything in the original program that depends on OB1 wall-clock time — software timing relays, TON/TOF accumulators, manual cycle counters, indexing operations — will execute ten times faster on the new CPU unless the program itself is reorganized or the timer base is changed.

3. Root Cause Analysis: Why the Backup "Loads" but the Sequence Stops Working

Loading a serial backup (.s7p or .zip) from a 315-2DP into a 315-2PN/DP deposits the blocks but does not rebuild the hardware configuration, the PROFIBUS/PROFINET topology, or the CPU properties dialog. The four mechanisms that produce silent sequence drift on a backup-restored 315-2EH14 are:

1. Hardware configuration missing or wrong: Without a matching HW Config in the loaded project, the new CPU defaults to its module rack, but rack 0 may not match the physical rack. Distributed I/O (ET200S, ET200M) may not be assigned to the DP or PN master system, producing implicit I/O-not-updated behavior with no SF LED if the slots are simply inactive.
2. Cycle-time compression: A 10x faster OB1 means every software timing element in the program expires 10x faster. Mechanical sequencing that relied on ~150 ms to settle now runs at ~15 ms — the cylinder has not finished extending before the next rung is evaluated.
3. Clock memory bits not enabled: The default in a freshly created CPU 315-2PN/DP project has clock memory disabled. Any logic that referenced clock bits (e.g., M10.0 = 10 Hz, M10.1 = 5 Hz) becomes a static 0, breaking periodic latches and blinkers.
4. OB10 / OB35 / OB40 parameters not carried over: Time-of-day interrupt OB10, cyclic interrupt OB35 (default 100 ms), and hardware interrupt OB40 must be present in the new project with the same phase offset and period. If the new project does not contain these OBs, the cyclic interrupt logic simply never runs.

The 315-2PN/DP does not produce a diagnostic-buffer entry for any of these conditions because they are not faults — they are design-time configuration drift. The CPU happily runs whatever the project tells it to run.

4. Cycle-Time Compression (20 ms → 2 ms) and What It Breaks

The original CPU 315-2AG10 was measured at approximately 20 ms OB1 cycle time on the loaded machine. The 315-2EH14 measured approximately 2 ms on the same machine code. Three classes of code are immediately affected:

5. STEP 7 V5 / TIA Portal Migration Procedure

The accepted sequence when stepping across the 2AG10 → 2EH14 boundary inside the SIMATIC S7-300 family is to rebuild the project rather than transplant the backup. The procedure below is the one that produces a stable, reproducible migration across all five sister machines in the field scenario described.

5.1 Prerequisites

• STEP 7 V5.5 + SPx (or current TIA Portal) installed, including the HSP (Hardware Support Package) covering the 315-2EH14 with the matching firmware version installed on the device.
• Online backup (.s7p / .zip) of the source CPU 315-2AG10 read with PG online functions or uploaded via the memory card.
• Full topology diagram: rack layout, slot assignment, PROFIBUS-DP node addresses, ET200 station numbers, HMI connection parameters.
• If the new CPU will use PROFINET: GSD file for every PROFINET device on the network, plus the IO controller / IO device naming plan.

5.2 Step-by-Step Project Rebuild

1. Create a new STEP 7 project. Insert a SIMATIC 300 station, then drag the CPU 315-2PN/DP from the hardware catalog (order number 6ES7 315-2EH14-0AB0) onto slot 2. This creates a fresh HW Config that matches the new CPU's firmware capabilities.
2. Replicate the rack layout. Insert power supply, IM (if any), and signal modules in the same slots as the physical machine. Verify the I/O address ranges match the program. Where the original project assigned IW0 to slot 4, the new project must do the same.
3. Open CPU properties and re-apply every checkbox from the old CPU. Specifically check (and re-enter) the following items, which are the ones that bit-roast across a CPU swap:
   • Cyclic interrupts — OB35 period (default 100 ms; was it 50 ms or 200 ms on the old machine?) and phase offset.
   • Time-of-day interrupts — OB10 start date/time, execution (once / every minute / hourly / daily / weekly / monthly / annually), and any subsequent OB10..OB17 if multiple schedules were used.
   • Hardware interrupts — OB40..OB47 assignments, if I/O modules were set to trigger hardware interrupts.
   • Clock memory — enable and select a byte address (commonly MB0 or MB10). Without this, every clock-bit reference collapses to 0.
   • Startup characteristics — OB100 / OB101 / OB102 presence and warm/cold restart behavior. Confirm whether the original project used a restart OB at all.
   • Diagnostics / process interrupts — match the OB82 / OB83 / OB85 / OB86 / OB122 enable bits. The new CPU defaults may differ.
   • Protection — password level, write/read protection. If the new project does not match the source, the HMI may lose write access.
4. Re-assign DP and PN networks in NetPro. The 315-2EH14 has a DP master on IF1 (MPI/DP) and a PROFINET interface on IF2. Recreate the subnet, assign the CPU as the IO controller on the PROFINET subnet, drag in every distributed station, and assign device names. The PROFINET device name must match the topology exactly — a missing or renamed device shows up as an "IO device failure" only after the first restart.
5. Import the program blocks. From the old CPU backup, copy OB1, all FBs, FCs, DBs, SFBs, SFCs, UDTs, and the symbol table into the new project. Do not rely on a serial restore; do a structured import via PLC → Upload Station to PG if the new CPU is online, or via the blocks container in SIMATIC Manager.
6. Run Check Block Consistency (Tools → Check Block Consistency → Compile All). Resolve every reported access error. Access errors on the 315-2EH14 that did not occur on the 315-2AG10 typically mean the block was compiled against a system data snapshot that has now been rebuilt.
7. Download the hardware configuration to the new CPU first, wait for the CPU to return RUN, and only then download the blocks. Downloading blocks before HW Config can leave the CPU in STOP with SF if the block references an I/O address that does not yet exist in the new hardware.
8. Watch the diagnostic buffer online immediately after the first download: PLC → Diagnostic/Setting → Diagnostic Buffer. Any OB-not-loaded, I/O access error, or rack/OB configuration mismatch appears here.

6. NetPro and PROFINET Configuration for the 315-2EH14

The most visible project-level difference between the two CPUs is the addition of a PROFINET interface. Even if the migration is intentionally DP-only, the PROFINET interface is still active and must be addressed in NetPro.

6.1 Decision matrix

6.2 PROFINET device naming

Every IO device on the PROFINET subnet must receive its device name from the IO controller. The naming step is the one that most often trips an otherwise clean migration:

1. Open PLC → Ethernet → Edit Ethernet Node in SIMATIC Manager (or Online → Accessible Devices in TIA Portal).
2. Browse the PROFINET subnet, identify each IO device by MAC address or port, and assign the same device name as the original topology.
3. Verify each device's IP address matches the topology. PROFINET device-name mismatches surface as SF on the device and BF on the CPU.
4. If the project uses PROFINET device replacement without exchangeable medium, confirm the same role is assigned in the IO controller properties.

7. OB10, OB35, and Clock Memory Parameter Carry-Over

These three CPU properties are the highest-impact silent defaults that disappear across the migration. A focused checklist keeps the rebuild predictable.

8. HMI Integration and Operator-Visible Parameter Drift

The original symptom — "changing delay and RPM on the HMI makes the new CPU behave" — is a strong signal that the HMI tags point at the correct process image but the program logic was tuned against the 20 ms OB1 cycle. After the migration, the operator panel can compensate within a narrow band, but the underlying timing structure is still 10x faster than the original.

8.1 HMI project check

1. Confirm the HMI project connection points to the new CPU's IP address (PROFINET) or PROFIBUS node address (DP).
2. Re-confirm the symbol / tag connection — if the HMI uses absolute addresses and the rebuild shifted the symbol base, operator-entered values can land in a different DB or in a different byte of the same DB.
3. Where the original project wrote to retentive data blocks, confirm the RETAIN attribute is still set on the new CPU's DB properties. Otherwise, every cold restart wipes operator-tuned values back to defaults.

9. Replicating the Fix Across Sister Machines (Palletiser Case)

field reports includes five near-identical machines, with the second (a palletiser) failing to come up cleanly even after the first machine was made to run. Two causes explain this:

1. The first machine was patched in place rather than rebuilt. Operator HMI tuning compensated for the timing drift and was never documented. When the second machine was commissioned, the rebuilt project ran the timing-correct code but the palletiser sequence relied on values the first machine's HMI had overwritten.
2. The palletiser's I/O assignment differs from the first machine. Even if mechanical layout is identical, the slot-to-address mapping may differ (a DI module on slot 5 versus slot 6, or a different PROFIBUS node address on an ET200S). The HW Config rebuild must be done per machine from the actual as-built drawing, not copied from the first machine's project.

Field-proven recipe for fleet rollout:

1. Build the master project from one validated source backup, with HW Config rebuilt from the as-built drawing of the first machine.
2. Confirm the first machine runs end-of-cycle without HMI tuning.
3. Save the master project as read-only baseline. Every subsequent machine gets a copy of this baseline plus a per-machine slot/topology file.
4. For each sister machine, rebuild only the HW Config and NetPro against its own as-built drawing. Do not copy the first machine's block container without re-checking block consistency.

10. Verification Procedure

After the rebuild and download, run the following checks. Every item must pass before the machine is returned to production.

1. Diagnostic buffer: PLC → Diagnostic Buffer. There should be no entries for OB-not-loaded, rack failure, or I/O access error after a STOP/RUN cycle.
2. Module status: PLC → Module Information for every slot. I/O must show OK, not "not available" or "fault".
3. Cycle time: online → PLC → Operating Mode → Scan Cycle Time. Record the new OB1 minimum, maximum, and current cycle. Confirm the maximum is bounded by the deterministic design (typically < 50 ms for mechanical sequencing).
4. Cyclic interrupt: confirm OB35 is loaded and runs. Place a counter in OB35 and watch it increment online.
5. Clock memory: confirm the configured clock byte increments. Force-watch a single bit with the online monitor and confirm it toggles at the configured frequency.
6. PROFINET / PROFIBUS status: no SF on the CPU, no BF on either port, all configured IO devices show "OK" in the topology view.
7. End-to-end sequence test: run a full mechanical cycle and time each step against the as-built timing sheet. Do not accept HMI-tuned values as proof.
8. Cold restart: power cycle the CPU, confirm OB100 (if loaded) runs, confirm retentive DBs preserve values, and confirm the sequence comes up in the same state it was in before the power cycle.

11. Forward Path: S7-300 to S7-1500 Migration Note

The same migration methodology — do not transplant, rebuild against the new firmware — applies when the next step is from the 315-2EH14 to an S7-1500 CPU (for example 6ES7515-2AM02-0AB0 or current equivalent). Siemens publishes a generation-change guide that consolidates the differences in OB organization, symbol/PLC data-type handling, and PROFINET device-name conventions between the two families.

• Reference: Siemens Migration Guide: SIMATIC S7-300/S7-400 to SIMATIC S7-1500
• Reference: TIA Portal Migration Options — Overview

For the S7-1500 target, the OB model is reorganized (OB1 is replaced by a cyclic program in a different OB block, time-of-day and cyclic interrupts change names and default periods), and bit memory timing semantics move toward IEC timers. Plan for at least one re-validation cycle on a representative machine before rolling the migration out across a fleet.

12. Diagnostic and Troubleshooting Matrix