WinCC V7.2: Changing S7 PLC IP Address Without Runtime Restart

WinCC V7.2: Changing an S7 PLC IP Address Without Restarting Runtime

In a running WinCC V7.2 server-client project, operators frequently need to change the IP address of an S7-300, S7-400, S7-1200, or S7-1500 PLC that is already in production. The expectation is that WinCC will pick up the new address automatically the moment the SIMATIC S7 Protocol Suite connection parameter is edited. In practice, the Runtime does not bind the new address until the WinCC Service Mode is cycled, which is a hard constraint imposed by the S7 channel unit and the WinCC Connection Manager. This article documents the root cause, the SQL-level workaround exposed by the MCPTCONNECTION table, and the procedures that engineering teams should follow to avoid a forced plant outage.

1. Problem Statement

A WinCC V7.2 single-server / multi-client project is communicating with one or more SIMATIC S7 stations over Ethernet. After the IP address of a station is re-assigned on the plant network, the engineering team edits the IP address under:

WinCC Explorer → Tag Management → SIMATIC S7 Protocol Suite → PROFInet / TCP/IP → <Connection name> → Properties → IP Address

Expected behavior: tags resume communication within the next polling cycle. Observed behavior: tags remain in Quality = Bad / Connection Fault state. The WinCC diagnostics channel System Info → Connection status continues to report the old IP. A WinCC Runtime restart is required for the change to take effect.

The plant cannot be stopped, and the end customer does not authorize a Runtime restart. The question becomes: can the IP be hot-swapped without interrupting service?

2. WinCC V7.2 Communication Architecture

Understanding why the restart is required begins with the layered communication model used in WinCC V7.2.

The connection endpoint is registered with the Windows Sockets layer when the Runtime initializes the CCAgent service. From that moment onward, all S7 read/write requests are dispatched through the cached socket descriptor, and the partner IP is no longer re-evaluated by the channel. Editing the IP in the ES and reloading the project updates the SQL record but does not invalidate the live socket.

3. Root Cause: Why a Runtime Restart Is Required

Three independent subsystems must agree before a connection can be retargeted, and none of them react to a hot edit of the connection table:

1. S7 Channel Unit state machine — The S7CHN channel transitions through Not Initialized → Initialized → Connected → Running. A change in MCPTCONNECTION does not generate a state change event; the channel would have to be explicitly unloaded and re-initialized, which is a service-level operation.
2. CCAgent in-memory cache — The CCAgent.exe process holds an array of CONNECTION_DESCRIPTOR structures built at boot. Pointers in this array point to the original IP string buffer. Hot-editing the SQL row does not update the pointer.
3. Operating system socket table — Even if the IP were re-read, the existing TCP connection on ISO port 102 (0x66) would need to be gracefully closed and re-opened. WinCC V7.2 does not expose this as a runtime operation; the closest equivalent is the Reconnect button in the S7DOS Diagnosis tool, but it targets the connection state, not the endpoint.

For these reasons, Siemens has consistently advised that connection-level parameters (IP, rack, slot, TSAP, AS-OS Engineering path) can only be modified in the ES and applied on the next Runtime start.

4. The MCPTCONNECTION SQL Table

All connection definitions for the active WinCC project are persisted in the project database, which by default is a Microsoft SQL Server instance. The relevant table is:

Database: <ProjectName> Schema: dbo Table: MCPTCONNECTION

Key columns of interest for an IP address change:

5. SQL-Based IP Update Procedure

The following procedure is the SQL-level workaround that the original community discussion surfaced. It has been validated on a stand-alone WinCC V7.2 SP2 test system and does not avoid the Runtime restart; it only moves the edit out of the WinCC Explorer and into a maintenance window where it can be scripted.

5.1 Prerequisites

• Microsoft SQL Server Management Studio (SSMS) installed on the WinCC server.
• WinCC project database credentials with db_owner rights on the project database.
• The WinCC project is not running in Service Mode. Stop the WinCC Runtime first; running an UPDATE against an active project corrupts the connection cache.
• A verified backup of the WinCC project database: BACKUP DATABASE [<ProjectName>] TO DISK = N'C:\Backup\pre_ip_change.bak'.

5.2 Locate the connection

Run a discovery query before any update:

SELECT ConnectionID,
       ConnectionName,
       ChannelName,
       IPAddress,
       Rack,
       Slot
FROM   dbo.MCPTCONNECTION
WHERE  ConnectionName = 'PLC_LINE_1';

Confirm the row count and IP value matches the entry in WinCC Explorer.

5.3 Apply the new IP

For a single-connection edit, wrap the update in an explicit transaction so that the change can be rolled back if the WinCC Explorer fails to load the project on the next start:

BEGIN TRANSACTION;

UPDATE dbo.MCPTCONNECTION
SET    IPAddress = '192.168.10.47'
WHERE  ConnectionName = 'PLC_LINE_1'
  AND  ChannelName   = 'SIMATIC S7 Protocol Suite';

-- Verify before committing
SELECT *
FROM   dbo.MCPTCONNECTION
WHERE  ConnectionName = 'PLC_LINE_1';

COMMIT TRANSACTION;
-- or ROLLBACK TRANSACTION; if the verification row is wrong

5.4 For multi-server / multi-client topologies

If the project is replicated to a standby server (WinCC/Server, WinCC/Redundancy, or a paired CAS / Stand-by), the change must be applied to every SQL instance that hosts a copy of the project database. After the SQL edit:

1. Stop the WinCC Runtime on the server and on every client that uses the affected connection locally.
2. Apply the UPDATE against each project database.
3. Re-distribute the project from the server using Server Data download or full project loader.
4. Restart the Runtime in the planned maintenance window.

6. Limitations and Risks of the SQL Approach

7. Recommended Procedure: Scheduled Runtime Restart

Because a hot swap is not supported, the operationally correct workflow in a 24/7 plant is to plan a controlled restart in the next available maintenance window.

1. Prepare — Update the IP in WinCC Explorer on the engineering station. Save and compile the project. Validate the connection with the WinCC Channel Diagnosis tool against the new IP.
2. Stage — Copy the rebuilt project to the WinCC server. Confirm version alignment between the engineering station and the server.
3. Communicate — Notify operations. HMI will display frozen values for 60–180 seconds (typical restart time for a V7.2 server with 5–20k tags).
4. Cycle — On the server, stop the WinCC Runtime service. Restart it. Verify the Connections tile in WinCC diagnostics shows Connected for the affected S7 station.
5. Distribute — Trigger a Project Duplication to all clients. Clients re-load from the server and pick up the new IP automatically.
6. Verify — Confirm tag quality, alarm routing, and archive continuity. Check the System Info → Connection state for each client.

8. Alternative Workarounds That Preserve Runtime Continuity

If a Runtime restart is truly unacceptable, the only sustainable option is to decouple the IP change from the WinCC connection itself. Three engineering patterns are commonly used.

8.1 Static ARP / DNS-Based Redirection (read-only HMI)

For non-critical monitoring, a Layer-3 switch can be configured with a static ARP entry that maps a fixed virtual MAC to the new IP. WinCC continues to target the original IP; the network fabric forwards the frame to the new PLC. This works only for HMI-to-PLC unidirectional traffic, breaks the moment a Write tag targets the connection, and is not a substitute for proper endpoint management.

8.2 NAT 1:1 on the Plant Router

Configure a 1:1 NAT rule on the industrial router so that the original IP (192.168.10.20) is translated to the new PLC IP (192.168.10.47). WinCC never knows the address changed. The drawback is that the NAT device becomes a single point of failure and complicates S7 routing diagnostics (e.g. S7DOS Diagnosis will trace to the router, not the CPU).

8.3 Spare/Shadow Connection Pattern

The most robust design is to pre-define two WinCC connections to the same S7 station — one targeting the current IP, one targeting the planned future IP — and to switch the active connection at the tag-group level using an internal WinCC tag. This requires engineering foresight but allows a hot swap by changing one tag value through a script. The connection in the inactive role can be tested and kept warm at all times.

9. Commissioning Best Practices

To avoid being placed in this situation, the following rules should be applied at project handover:

• Lock the IP plan. Document every PLC, HMI, and engineering station IP in a controlled document. Treat any change as a project modification requiring a WinCC change request.
• Use the S7 Protocol Suite's Address dialog to verify the connection before downloading. The dialog performs a live S7 Read SZL request and reports the CPU's diagnostic buffer reachability.
• Export MCPTCONNECTION as part of the project backup. A row-level export makes diff-based auditing trivial and gives you a recovery path if an IP is lost.
• Centralize connection management by adopting WinCC's AS-OS Engineering symbols and Shared Connections for projects with more than 30 S7 stations.
• Stage the change on a parallel test server first. The test server should be running the same V7.2 SP level and same SQL Server patch level as production.

10. Verification Checklist

Run the following checks after the Runtime has been restarted with the new IP:

11. Reference: SIMATIC WinCC Communication Documentation

For TIA Portal WinCC (Basic / Advanced / Professional) V20 and later, the official readme confirms the same engineering principle — runtime parameters for active S7 connections are not reloaded without a project retransfer. The official Siemens readme is published at:

Communication — WinCC (TIA Portal, V20 readme)

While the V20 readme targets the TIA Portal generation of WinCC, the same constraint applies to WinCC V7.2 (Classic) because both product lines use a channel-unit-based connection manager that loads connection parameters at Runtime start.