Re-program an S7-1200 with a New Hardware Configuration: Full Recovery, Communication, and RUN-State Guide

This procedure covers the complete recovery of a SIMATIC S7-1200 CPU whose IP address was wiped during a factory reset, whose project no longer matches the physical module layout, and whose CPU refuses to enter RUN. It applies to firmware V4.x CPUs (CPU 1211C, 1212C, 1214C, 1215C, 1217C) and to TIA Portal V15.1 through V18. All references below come from the official S7-1200 Programmable Controller System Manual (entry ID 36932465) and the TIA Portal online help: Resetting to factory settings.

1. Problem Scope and Typical Failure Chain

When an S7-1200 has been programmed once and is later reused with a different module lineup, three independent faults usually appear in sequence:

1. Layer 2 — IP loss: A manual "Reset to factory settings" (MRES via TIA Portal or mode selector) wipes the IP address, subnet mask, and PROFINET device name. The CPU keeps its MAC address but is no longer reachable at the previous IPv4.
2. Layer 3 — Discovery failure: TIA Portal "Online > Accessible devices" returns no nodes even after the user manually enters the previously used IP. The CPU still responds to DCP/PN-DCP identification frames, so PROFINET tools can still see it.
3. Layer 4 — Configuration mismatch: After the user re-uses a different project, the CPU refuses RUN, and the SM DIAG LED begins to blink because the configured topology does not match the plugged-in modules.

Each layer has to be cleared in order. Skipping Layer 2 (e.g. trying to download a project before the CPU is reachable) produces the "CPU will not go to RUN" symptom with alternating RUN/STOP LED activity.

2. Prerequisites

3. Physical and Electrical Inspection

Before any software step, confirm that the CPU is alive and that the network is wired correctly.

1. Apply 24 V DC to terminals 1L+ and 1M. The CPU's RUN/STOP LED must react (even if it only glows solid orange). No LED at all means the power section or the fuse on the SB 1223/DO board is open.
2. Insert the Ethernet patch cable into the CPU PROFINET port. The port's green Link LED must come up within 3 s. A yellow/green pair without activity indicates the CPU is on a different subnet or the cable is broken.
3. Note the order of the plugged-in modules from left (CPU side) to right. Each module has a slot label engraved on the front: CPU, SM1, SM2, ... SM8. The first SM plugged next to the CPU occupies slot 1, the next slot 2, and so on.
4. Compare the engraved catalog numbers (e.g. 6ES7 221-1BF32-0XB0) to the project's device configuration. Mismatched MLFBs are the single most common cause of "CPU will not enter RUN".

4. Step 1 — Configure the PG/PC IP Address

Set the engineering station to a static IPv4 inside the same subnet as the CPU's next address. The S7-1200 PROFINET interface defaults to 0.0.0.0 after a factory reset, so any well-formed address in 192.168.0.0/24 is acceptable as long as the host portion is not .0 or .255.

1. Open Control Panel > Network and Sharing Center > Change adapter settings.
2. Right-click the wired Ethernet adapter (typically "Realtek PCIe GBE Family Controller" or "Intel I210") and select Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4) → Properties.
4. Choose Use the following IP address and enter:
   

   Field	Value
   IP address	192.168.0.254
   Subnet mask	255.255.255.0
   Default gateway	(leave blank for direct connection)

5. Click OK and close all dialogs. Verify with ipconfig /all in an elevated command prompt.

5. Step 2 — Discover the CPU with PRONETA

PRONETA reads the CPU's MAC address through the standard PROFINET DCP protocol, even when the CPU has no IP. The TIA Portal "Online > Accessible devices" search can fail to return anything if Windows firewall blocks the UDP ports used by PN-DCP (ports 34964/UDP for DCP).

1. Download PRONETA from the Siemens support site (search for entry ID 67460624, free of charge).
2. Start PRONETA and click Network Analysis. The CPU should appear within 5–10 s with status "No IP address".
3. Switch to the IO Test tab, right-click the CPU, and choose Set IP address > Static. Assign 192.168.0.1 with subnet mask 255.255.255.0 and router 0.0.0.0.
4. Assign a PROFINET device name, e.g. s71200. The name is mandatory if the CPU is part of a PROFINET IO system with a controller; for a stand-alone CPU it is still recommended for clarity.
5. Click Apply and wait for the green status confirmation. The CPU's Link LED will blink briefly while the assignment is written to flash.

Alternative discovery tools: Siemens Primary Setup Tool (PST), the command-line pnio_diag (part of the SIMATIC NET toolbox), and the free TIA Selection Tool. All of them speak the same DCP protocol, so if PRONETA cannot find the CPU, none of the others will — the issue is the physical layer, not the application.

6. Step 3 — Verify Reachability from TIA Portal

1. Open the project in TIA Portal that contains the new configuration.
2. In the project tree, expand Online access and locate the wired Ethernet adapter.
3. Double-click Update accessible devices. The CPU should now appear with its assigned IP 192.168.0.1 and its PROFINET device name.
4. If the CPU still does not appear, verify with a raw ping:
   ping 192.168.0.1 -n 4
   A reply confirms Layer 3 is up. A "Destination host unreachable" reply points to a subnet mismatch.
5. If the ping succeeds but TIA Portal reports "no devices", close all firewalls temporarily: netsh advfirewall set allprofiles state off (re-enable with on after the session).

7. Step 4 — Download the New Hardware Configuration

1. In the project tree, right-click the CPU and select Download to device > Hardware and software (only changes).
   Why "only changes"? A full download also rewrites the program blocks and the data blocks, which can wipe retained tags. Use the variant "Hardware configuration" if you only want to update the topology.
2. TIA Portal shows a "Select target device" dialog. The CPU's IP should already be filled in. Confirm by clicking Flash LED; the CPU's RUN/STOP and ERROR LEDs will blink for a few seconds, proving the route is correct.
3. Follow the download dialog. When prompted, choose Stop all and Reset only if the existing program must be replaced. To preserve retentive data, choose Stop all and skip the reset.
4. After the download, TIA Portal offers to Go online. Click Go online and observe the diagnostic buffer.

8. Step 5 — Decode the RUN/STOP LED Pattern

The user reports orange–green–orange–green then back to orange. The table below maps every RUN/STOP and ERROR pattern documented in the S7-1200 system manual.

The reported "orange–green–orange–green and then back to orange" pattern matches the blinking green/orange row combined with a hardware configuration error: the CPU tries to enter RUN, fails to start its I/O, and falls back to STOP. The flash sequence repeats every 2 s.

9. Step 6 — Decode the I/O Module DIAG LED

The user reports the DIAG LED on the SM blinking green continuously. For the SM 1221, SM 1222, SM 1223, SM 1231, SM 1232, SM 1234, and SM 1278 families, the DIAG LED has three states documented in the system manual:

Continuous flashing green on the SM means at least one channel is raising a diagnostic interrupt. The most common causes are:

• Wire break on a 4–20 mA analog input (SM 1231 / SM 1234): the input is enabled but the transducer is not connected or the loop is open. Disable unused channels in the device configuration to suppress the diagnostic.
• 24 V missing on the load supply (SM 1223 DO): the SM has 24 V logic but no 24 V on 2L+/3L+, so the outputs flag "load voltage missing".
• Overrange on a thermocouple (SM 1231 TC): open thermocouple junction triggers a wire-break event.
• Channel-level configuration error: a digital input configured as HSC (high-speed counter) without a valid wiring assignment raises "type 3" diagnostics.

To clear the LED, fix the channel or disable the unused channel in TIA Portal → device configuration → properties → inputs/outputs → diagnostics, then redownload the hardware configuration.

10. Step 7 — Read the Diagnostic Buffer

1. In TIA Portal, mark the CPU in the project tree.
2. Select Online > Online & diagnostics > Diagnostics buffer.
3. Read the most recent event first. Common entries seen after a topology mismatch:
   0xE002 — "Parameter assignment error". The CPU could not download parameters to an SM. Click the entry to see the slot number and the cause byte.
   0xE001 — "Module removed/inserted". Reported by an SM that lost IO data.
   0x4380 — "Channel-level diagnostic". Wire break or overrange on a specific channel.
4. Right-click the relevant entry and select Open in the project to jump directly to the offending module.

11. Verification Checklist

12. Troubleshooting Matrix

13. How to Avoid the Problem Next Time

• Always upload the existing project to TIA Portal before any reset. The "Upload device as new station" action captures the current hardware configuration, symbols, and DB contents.
• Use the mode selector's MRES position only as a last resort. The recommended factory reset path is TIA Portal → Online & diagnostics > Reset to factory settings, which keeps the IP intact unless explicitly cleared.
• Keep a separate "template project" with the correct topology. Compare the new project's HWCN against the template before download.
• Document the IP plan. A simple .txt in the project folder listing CPU, HMI, PG, and any switched subnet avoids the 192.168.0.1 collision that brought the PG and the CPU onto the same address in the first place.

14. Quick-Reference LED Tables

14.1 CPU Status LEDs

14.2 SM Status LEDs (SM 1221 / 1222 / 1223 / 1231 / 1232 / 1234 / 1278)

15. Diagnostic Event ID Cheat Sheet

16. Frequently Asked Questions