Resolving WinCC 7.2 to S7-1200 Disconnect on Firmware 4.x

Symptom: a SIMATIC WinCC V7.2 SP9 station with SIMATIC Net V8.2 SP1 reports Disconnect on every S7-1200/1500 connection even though the same project successfully talks to S7-300 CPUs over the same network. The S7-1200 responds on TCP and ISO, but WinCC tears the S7 connection down on the first SZL request. This article explains why the SIMATIC S7-1200, S7-1500 Channel DLL closes the handle and lists the supported workarounds, verified against the SIMATIC PC station, the CPU 1215C (6ES7215-1HG40-0XB0) and current TIA Portal security settings.

1. Problem Description

A production cell is supervised by a WinCC V7.2 station (Update 9, hotfix level current) running on Windows with SIMATIC Net V8.2 SP1. The SCADA server holds four connections to ET 200S and S7-300 stations, all in status OK, plus one connection to a new S7-1200 station that is permanently Disconnect. The S7-1200 is a CPU 1215C DC/DC/DC with order number 6ES7215-1HG40-0XB0, firmware V4.1.

The S7-1200 and S7-300 share the same PROFINET subnet. ping to the S7-1200 succeeds from the SCADA computer. TIA Portal V13 SP1 on a separate engineering laptop can Go online with the S7-1200 without errors. The WinCC PC station in STEP 7 / SIMATIC Net contains an IE General module (with the correct IP and subnet) and an Application module that is set to SIMATIC Net PC software V8.1 SP2. The XDB/Station Configuration Editor is consistent, the Station Manager icon is green, and the S7ONLINE access point is bound to the right Ethernet adapter.

Runtime evidence:

• WinCC Connection status: Disconnect for the S7-1200 connection, OK for the S7-300 connections.
• Tag values for the S7-1200 do not appear in Graphics Designer.
• Wireshark capture shows the three-way TCP handshake, an ISO TPDU connection, and a short S7 Setup Communication exchange. The CPU 1215C replies with a positive S7 ACK; the WinCC station then sends a FIN/ACK and does not retry.
• Channel log C:\Program Files (x86)\Siemens\WinCC\Diagnose\CCS7PlusChannel_01.LOG contains only the start banners, no error or warning text.

2. Root Cause — S7-1200 Firmware 4.x SZL Subset

During the S7 connection setup the WinCC channel issues a series of Read SZL (System State List) requests to identify the CPU, the available SFB/SFC set, protection level and module status. The channel uses the SZL response to build its internal representation of the partner and to decide which S7 services (PUT/GET, BSEND/BRCV, program alarm routing, time sync) can be opened. The S7-300 answers the full set that the V7.2 channel expects, and the connection succeeds.

Firmware 4.x on the S7-1200 (and the original S7-1500 firmware) implements a different SZL surface. The CPU responds to the Setup Communication request and to most SZLs, but it does not return every SZL ID that the WinCC V7.2 channel was compiled to consume. The channel checks each required SZL against its own allow-list; if a single mandatory SZL is missing, the channel closes the S7 transport connection immediately. The TCP and ISO layers survive, which is why the S7 connection appears to come up and then die within milliseconds.

The two firmware generations differ as follows:

This is a known limitation, not a project bug. The WinCC V7.2 release notes for the SIMATIC S7-1200, S7-1500 Channel were qualified against S7-1200 firmware V2.x. When Siemens validated WinCC V7.3 (entry ID 101908495) the channel was re-qualified for the FW 4 generation of S7-1200 and the original S7-1500 firmware.

2.1 Why the S7-300 keeps working

The S7-300 returns the full set of SZLs the WinCC V7.2 channel expects (CPU type, signal modules, communication status, OB/ZG objects, protection level). The channel therefore completes the Setup Communication handshake and opens the user-data S7 connections. The S7-1200 and S7-1500 implement only a subset; for the S7-1500 that subset was extended across firmware updates, but FW 4.x of the S7-1200 still does not return every SZL the V7.2 channel requires.

2.2 Why the S7-1200 still answers TIA Portal

TIA Portal V13 SP1 uses the Online & Diagnostics path, which negotiates a different S7 protection and SZL set. It only needs the few SZLs that identify the module and the run-time status; it does not require the full V7.2 channel surface. Go online succeeds, but the S7-1200 channel DLL is not exercised.

3. Diagnostic Procedure

Before applying any workaround, capture objective evidence. The combination of network trace and channel trace distinguishes the SZL mismatch from a configuration mistake such as a wrong rack/slot, missing PUT/GET permission, or mismatched TSAP.

3.1 Step 1 — Verify the S7 connection parameters in WinCC

1. Open WinCC Explorer and select Tag Management > SIMATIC S7-1200, S7-1500 Channel > S7-1200 connection.
2. Confirm IP Address, Rack = 0, Slot = 1, and Connection type = S7-1200.
3. If you are attempting the firmware 4.x workaround of selecting S7-1500 as the connection type, note the slot rules: the original S7-1500 expects Rack 0 / Slot 0 (or 1) and a different connection resource range. The WinCC V7.2 driver may still negotiate, but the SZL subset will be evaluated against the S7-1500 path. For a CPU 1215C V4.1 the success rate of this trick is low; treat it as a last resort before the OPC workaround.

3.2 Step 2 — Verify the protection / PUT/GET setting on the PLC

In TIA Portal, open the device configuration of the CPU 1215C and select Properties > Protection & Security > Connection mechanisms. The following two settings are mandatory for a WinCC station that uses the SIMATIC S7-1200, S7-1500 Channel:

• Permit access with PUT/GET from remote partner must be enabled. The default is disabled on firmware 4.x. Without this flag the S7 server blocks all read/write PDUs from any partner that does not present a configured S7 connection, and WinCC drops to Disconnect even if the Setup Communication succeeds.
• Only allow secure PG/PC and HMI communication is a TIA Portal V17+ option. When enabled, every S7 partner must present a valid TLS certificate. The V7.2 channel DLL does not implement this secure path; it can only talk to the PLC when secure communication is disabled or when the legacy PUT/GET path is explicitly allowed. See the TIA Portal V21 reference Communication with S7-1500 and S7-1200 (WinCC Unified RT) for the rules that govern certificate management on newer firmware; the same access-control philosophy applies to WinCC V7.2 even though it cannot use the certificate path.

3.3 Step 3 — Capture a Wireshark trace

1. Start Wireshark on the SCADA computer with capture filter host <PLC IP> and tcp port 102.
2. Start WinCC Runtime and wait one minute.
3. Stop the capture and filter for s7comm or tcp.port==102.
4. Decode the first S7 Communication Setup PDU. The relevant fields are Max AmQ calling, Max AmQ called, and the parameter block. A normal V7.2 → S7-300 exchange is followed by a positive S7 Communication Setup response, then the channel opens one or more user-data S7 connections.
5. For the V7.2 → S7-1200 V4.1 case, the response is also positive, but no user-data S7 connection is opened. The SCADA station sends FIN, ACK within a few hundred milliseconds. That timing is the SZL check: the channel reads the response, compares it against its compiled-in SZL list, decides the FW 4.x SZL surface is incomplete, and closes the transport.

3.4 Step 4 — Capture the channel log

1. Open WinCC Explorer > Computer > Properties > Graphics Runtime > Channel Diagnosis and enable all trace flags. The default trace mask is c4000000; this is the value visible in the symptom log (| TraceFlags : c4000000).
2. Restart the WinCC Runtime. The log CCS7PlusChannel_01.LOG is rolled with three files of about 1.4 MB each (| LogFileCount : 3, | LogFileSize : 1400000).
3. After one minute, inspect the log. If the only entries are the INFO Log starting banners, the channel did not reach a code path that emits a diagnostic; this is consistent with the SZL mismatch.
4. If the log instead contains WARN or ERROR entries, post them to Siemens support. The relevant error codes are 0xE0FE0001 (no partner reachable), 0xE0FE0002 (S7 partner rejected), and 0xE0FE000A (CPU rejected SZL). Note that for the SZL mismatch the channel will typically close the connection before the diagnostic subsystem is notified, so a clean log is expected.

3.5 Step 5 — Check the SIMATIC Net PC station

1. Open the Station Configuration Editor and verify the components: index 1 = IE General (or the PROFINET interface of the SCADA computer), index 2 = Application with version SIMATIC Net PC software V8.1 SP2 (or matching the installed SIMATIC Net).
2. Open Set PG/PC Interface and confirm the access point S7ONLINE points to PC Internal (local) or to the IE General entry, not to a virtual interface.
3. Restart the SIMATIC Net Configuration Service and the S7DOS service.

4. Solution A — Upgrade the SCADA to WinCC V7.3 or Later

This is the only officially supported path for the S7-1200 firmware 4.x and the S7-1500 firmware 2.x. Siemens entry ID 101908495 ("WinCC V7.3 – SIMATIC S7-1200, S7-1500 Channel") qualifies the V7.3 channel DLL against:

• S7-1200 firmware V4.x with absolute addressing
• S7-1200 / S7-1500 / ET 200SP with symbolic addressing (exported from TIA Portal, imported via the WinCC Configuration Studio)
• Cyclic tag read
• Chronological reporting of program alarms
• Loading of AS messages (S7-1500 only)
• Password protection
• Time synchronization

Steps:

1. Plan a WinCC V7.3 (or current V7.5) upgrade for the SCADA. This is a major migration: project must be opened in the new WinCC Explorer, all channel connections re-compiled, the SIMATIC Net PC software upgraded to a version that matches the WinCC release (typically SIMATIC Net V8.3 SP1 or later for V7.3, V8.4+ for V7.4 / V7.5).
2. In TIA Portal V13 SP1 (or matching the CPU firmware), re-export the absolute tag list. The export is via Project > Export to Text File with the Generate S7 tag list for WinCC option.
3. In WinCC Configuration Studio, Tag Management > SIMATIC S7-1200, S7-1500 Channel > Import the text file. WinCC will create the data blocks and the connection under the existing channel unit.
4. If the project relies on AS messages (program alarms) from the S7-1200, note that V7.3 supports only loading of AS messages from the S7-1500, not the S7-1200.
5. Verify by starting Runtime and confirming the connection state moves from Disconnect to OK and the tag values appear.

5. Solution B — Front the S7-1200 with the SIMATIC Net OPC Server

This is the workaround that Siemens technical support recommends when a WinCC V7.2 upgrade is not on the project schedule. The SIMATIC Net OPC server is part of the same PC software suite; it reads the same SZL surface as the S7-1200/1500 channel DLL but tolerates the S7-1200/1500 response set. WinCC V7.2 then connects to the OPC server through its built-in OPC DA Client channel rather than the S7-1200 channel.

5.1 Architecture

1. SIMATIC Net OPC server (component of SIMATIC Net V8.2 SP1) runs as a Windows service on the SCADA computer. It uses the existing Application module of the PC station to talk to the S7-1200 over ISO-on-TCP.
2. WinCC V7.2 starts the OPC DA client channel. The OPC DA client reads tag values from the local OPC server, which in turn polls the S7-1200.
3. The S7-300 connections stay on the SIMATIC S7-1200, S7-1500 Channel; only the S7-1200 connection is moved to OPC.

5.2 Configuration

1. In Station Configuration Editor, confirm that the OPC server entry exists in the PC station (added automatically by SIMATIC Net V8.2 SP1). Index 3 is typically the OPC server.
2. Open SIMATIC NET OPC Server > S7-1200 and create a new connection. Enter the CPU 1215C IP address, Rack 0, Slot 1. Save and download the configuration.
3. Open OPC Scout V10 (installed with SIMATIC Net) and add the items. The item path follows S7:[S7-1200]DB1,BYTE0 or the symbolic name if the S7-1200 DB is configured as non-optimized and accessible attributes are set.
4. In WinCC Explorer, add a new channel OPC DA Client. Create a new connection to OPCServer.WinCC (or the SIMATIC Net server name visible in DCOM config).
5. Add tags that mirror the OPC items. For each WinCC tag, set the item name to the OPC Scout path.
6. Verify the S7-1200 PUT/GET flag is still enabled on the PLC (Section 3.2). The OPC server uses the same protection mechanism as the channel DLL.

5.3 Pros and cons of the OPC workaround

6. Solution C — Re-target the S7-1200 Channel at the S7-1500 Connection Type

The S7-1200 firmware 4.x SZL surface is closer to the original S7-1500 firmware than to the S7-1200 firmware 2.x. In some projects, switching the WinCC connection type from S7-1200 to S7-1500 yields a successful Setup Communication. The success rate depends on which SZLs the firmware returns and on the specific V7.2 service pack (Update 9 to Update 17 had different DLL builds).

To try this workaround:

1. Open the WinCC connection properties and set Connection type to S7-1500.
2. Set Rack = 0 and Slot = 0 (the S7-1500 default). For an S7-1200, Slot 0 is the CPU slot; Slot 1 is also accepted.
3. Save, start Runtime, and watch the connection state for one minute.
4. If the state moves to OK, the channel has accepted the SZL set. If the state is still Disconnect, revert to Solution A or B.

7. Solution D — Downgrade the PLC to a Compatible Firmware

Only possible when the project allows it. The CPU 1215C 6ES7215-1HG40-0XB0 supports firmware V2.x through V4.x, with V2.x being the last generation that the WinCC V7.2 channel was tested against. To downgrade:

1. Open TIA Portal V13 SP1 (or the matching TIA Portal version for the target firmware).
2. Open the device configuration and select Online > Accessible devices > Firmware update.
3. Select the target firmware (V2.2.3 is the last V2.x recommended for new deployments).
4. Confirm the downgrade. The PLC will reset, the project will be retained, and the SZL surface returns to the V2.x set.

8. Verification

Independent of the chosen path, the verification steps are the same.

8.1 Connection state

1. Start WinCC Runtime.
2. Open Tools > Channel Diagnosis and confirm the S7-1200 connection is in status OK.
3. Confirm the S7-300 connections remain in status OK (the OPC workaround should not affect them).

8.2 Tag read

1. In Graphics Designer, open a screen that displays a tag from the S7-1200.
2. Force the tag value from TIA Portal (Monitor & Modify) and confirm the value appears in the WinCC screen within the configured update cycle (default 1 s for the SIMATIC S7-1200, S7-1500 Channel; 250 ms for OPC).
3. Write a value from the WinCC screen to the S7-1200 and confirm it is observed in TIA Portal Monitor & Modify.

8.3 Channel log

1. Stop Runtime and open CCS7PlusChannel_*.LOG.
2. Confirm the only entries are INFO Log starting. No WARN or ERROR entries should be present.
3. If the OPC path is used, also inspect OPC DA Client log files for stale items and timeouts.

8.4 Network trace

1. Start a fresh Wireshark capture.
2. Confirm a user-data S7 connection is opened by WinCC (or by the OPC server) and that cyclic S7 read PDUs follow the connection setup.
3. No retransmissions, no TCP RST, no FIN/ACK within the first second of the connection.

9. Field-Proven Caveats and Common Follow-On Issues

• PC station mismatch after SIMATIC Net upgrade. If SIMATIC Net is upgraded independently of WinCC, the Application module in the PC station keeps its old version. Open the Station Configuration Editor, edit the Application module, and re-select the installed PC software version. This is a common cause of the Station Manager icon turns yellow symptom.
• TSAP duplication. When the S7-1200 and an S7-300 share the same PROFINET subnet and the S7-300 was the first station configured, the PC station may bind the S7-1200 connection to the same TSAP as the S7-300. The CPU rejects the second Setup Communication. Always check the TSAPs in the PC station .xdb file.
• Firewall blocking ISO-on-TCP (port 102). The Windows firewall on the SCADA computer is on by default in current builds of Windows. Allow %WINDIR%\System32\s7oiehsx64.exe and the SIMATIC Net services through the firewall, otherwise the TCP handshake completes but the ISO TPDU is silently dropped.
• Optimized block access on the S7-1200. If the DBs in the S7-1200 are configured as Optimized, the OPC server and the WinCC channel can only read by symbolic name. For absolute addressing the DB must be Non-optimized and the Accessible from HMI/OPC UA attribute must be true.
• Secure PG/PC communication (TIA V17+). When the TIA Portal V17+ Only allow secure PG/PC and HMI communication option is enabled, the WinCC V7.2 channel DLL cannot establish a connection at all. The connection is rejected before SZL exchange. Disable the secure mode for legacy SCADA connections, or migrate the SCADA to a current WinCC version that supports the certificate path described in the TIA Portal V21 reference on Communication with S7-1500 and S7-1200 (WinCC Unified RT).
• Routing through a PN/PN coupler. When the S7-1200 sits on a sub-network behind an IE/PN Link or a PN/PN coupler, the SIMATIC Net PC station must include the routing path. The S7-1200 channel DLL does not auto-discover the router; the PC station must be edited in STEP 7 / TIA Portal to include the S7 subnet of the S7-1200.

10. Decision Matrix

11. Frequently Asked Questions