WinCC V17 S7-1200 Connection Limit: SOFTNET IE S7 Troubleshooting

Problem Statement and Observed Symptoms

A WinCC Professional V17 Runtime (RT) installation on Windows Server 2019 Standard is configured to supervise 34 SIMATIC S7-1214C controllers distributed across a production cell. Each controller drives a local machine and is also paired with a SIMATIC KTP700 Basic panel running a WinCC Comfort project. A single WinCC RT Server polls data from all 34 PLCs through the SIMATIC S7-1200, S7-1500 Channel and forwards the values to 4 WinCC RT Clients on the same LAN.

The engineering team observes the following symptoms:

• 34 S7-1214C controllers are pingable from the WinCC Server and respond to ARP requests, confirming Layer 3 reachability.
• WinCC RT initializes 21 active S7 connections and 13 connections remain in Disconnected or Establishing connection state indefinitely.
• Disconnected connections do not recover after manual restart of the WinCC Runtime; only a server reboot temporarily restores the full set before the count degrades again to 21.
• The Automation License Manager (ALM) shows the SOFTNET-S7 Powerpack license key as assigned to the WinCC Server, but the assignment flips to Not assigned every 30 to 60 seconds and then back to Assigned, a clear indicator of license churn.
• Channel Diagnostics in WinCC Explorer shows the dropped connections with internal channel driver errors. The status field cycles through Disconnected, Establishing connection, and Connection failed on the 13 affected channels.
• The Fast Acknowledge option has been disabled in the channel configuration, and the connection timeout has been raised to 100 s, but the symptom persists.

The available license portfolio is:

• Industrial Ethernet SOFTNET-S7 Lean (max 1 S7 connection)
• Industrial Ethernet SOFTNET-S7 Basic (max 8 S7 connections)
• SOFTNET-S7 Powerpack (upgrade from Basic to Full, max 64 S7 connections)

On paper the license chain should permit up to 64 simultaneous S7 connections, which is more than the 34 required. The symptom of 21 connected PLCs is the typical signature of a WinCC Runtime that is intermittently falling back to the Basic tier (8 connections) plus residual administrative slots, while the remainder of the available TCP socket pool is blocked by half-open connections to the 13 unreachable PLCs.

License Architecture: What the SOFTNET Key Actually Authorizes

SOFTNET-S7 is a per-station license family. The available variants and the maximum number of S7 communication connections they authorize are listed below. All counts are maximum concurrent S7 connections, not the number of PLCs that can be polled. A single S7 connection can read multiple PLCs only if the PLCs are accessible through a routing path, not through independent TCP sessions.

Per Siemens Knowledge Base article 21914909, the License Key Industrial Ethernet SOFTNET-S7 Basis (Basic) is the minimum required for SIMATIC S7 communication from a PC station. The Powerpack license is a delta upgrade that converts the Basic tier to the Full tier. The Powerpack does not stack; it is a one-way upgrade of an already-present Basic license. If the Basic key is missing, stolen, expired, or fails the ALM signature check, the Powerpack cannot assert itself and WinCC falls back to the Basic 8-connection limit.

The relationship between the license tier and the actual number of PLCs that can be connected is multiplicative: each S7 connection opens one ISO-on-TCP (RFC1006) port pair (TCP source 1024-65535, destination port 102 on the PLC) and consumes one connection resource on the CPU. The connection count limit in the license is therefore the absolute ceiling for that WinCC station.

Confirm the current license state at the engineering station using ALM. Open ALM, switch to the Active License Keys view, and verify that all three keys (Lean, Basic, Powerpack) show a green check mark in the Valid column and an Assigned to entry of the WinCC Server's hostname:

1. Start > Automation License Manager (or C:\Program Files\Siemens\Automation\ALM\ALM.exe).
2. Right-click the WinCC Server in the Computer pane and select Connect Target Computer if the server is remote.
3. Inspect the Active License Keys tab. Note the time of the first refresh.
4. Press F5 every 10 seconds for 2 minutes. If the Powerpack key toggles between Valid and Not valid, you have license churn.

S7-1200 CPU Connection Resource Architecture

The S7-1214C has a finite connection resource pool, partitioned by the firmware version. The relevant limits for the S7-1214C DC/DC/DC (6ES7214-1AG40-0XB0) and its AC/DC/RLY and DC/DC/RLY variants are summarized in the table below. The same connection resource can be used for PG (programming), OP (HMI panel), and S7 (PUT/GET or S7 communication), but each active role consumes one resource.

For an S7-1214C with one KTP700 Basic (1 OP connection) and one WinCC S7 connection (1 S7 connection), the consumed resource count is 2 of 16. This is well within budget for any single PLC and is not the cause of the 21-of-34 plateau.

However, an important sub-case must be verified on every PLC in the project. If Permit access with PUT/GET communication from remote partner is enabled in the S7-1214C properties (TIA Portal > CPU Properties > Protection & Security > Connection mechanisms), each WinCC S7 connection uses the S7 communication path and may consume an additional S7 connection resource depending on the data block size. WinCC with the standard S7-1200/1500 channel uses S7 communication as the primary path; if PUT/GET is the only access method, each connection can balloon to two resource slots. Check this in the TIA project for every CPU:

1. Open the S7-1200 project in TIA Portal.
2. Select the CPU in the project tree.
3. Open Properties > Protection & Security > Connection mechanisms.
4. Confirm that Permit access with PUT/GET communication from remote partner is set to Permit if WinCC is using the S7-1200/1500 channel in classic mode.
5. For S7 communication (BSEND/BRCV) used by the channel, the option must also be enabled.

For the broader S7-1200 family and the specific S7-1214C part numbers, refer to the SIMATIC S7-1200 Programmable Controller System Manual on the Siemens support portal.

Windows Communication Stack Constraints (Server vs Desktop)

Windows desktop SKUs (Windows 10, Windows 11) limit the number of half-open TCP connections and the simultaneous outbound TCP socket pool used by the S7 channel DLL. The exact limits depend on the edition; empirical measurements show that 16 to 24 concurrent S7 connections is the practical ceiling on a Windows 10 Pro installation. Windows Server editions (2016, 2019, 2022) raise this ceiling to 64 or higher and are the only supported runtime environment for a 34-PLC WinCC Professional project. The choice of Windows Server 2019 Standard is correct and is not the limiting factor on its own.

Verify the connection limit is not a Windows issue by inspecting the TCP table and the half-open connection count from an elevated PowerShell prompt on the WinCC Server:

This returns the number of established ISO-on-TCP connections targeting port 102 (the standard S7 port). The expected value with 21 PLCs is 21. If the count is significantly lower than the WinCC connection count, the difference is held in SynSent or FinWait states:

The expected breakdown is roughly: 21 Established, 13 TimeWait (released), and a small number in SynSent. If the TimeWait pool exceeds the dynamic range of ephemeral ports, the server will silently drop new SYNs. The default dynamic port range is 49152-65535 (16,384 ports) and is rarely the bottleneck for 34 connections, but the TimeWait timeout of 4 minutes can clog the table if connections cycle frequently. Inspect the current TimeWait pool size and tune the registry if necessary:

netsh int ipv4 show dynamicport tcp
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v TcpTimedWaitDelay /t REG_DWORD /d 30 /f

The second command reduces the TimeWait delay from the default 240 seconds (4 minutes) to 30 seconds, accelerating the recycling of ephemeral ports. Apply this only on Windows Server SKUs that explicitly support it; the change is hot-reloaded within 60 seconds.

Root Cause: Powerpack License Churn and the 21-Connection Plateau

The 21-of-34 symptom with a license of Basic + Powerpack on Windows Server 2019 is the fingerprint of license churn. When the Automation License Manager (ALM) cannot confirm the validity of the Powerpack key, the WinCC Runtime engine falls back to the Basic 8-connection limit. WinCC does not abort the in-flight connections; instead, it freezes new connection attempts and parks the unresolved ones in a pending state.

The number 21 is not a hard-coded constant in WinCC. It is the emergent value of the following combination on the observed hardware:

• Basic 8 connections (the lower-tier limit that the runtime drops to when Powerpack is invalid).
• 12-13 stale TCP connections in TimeWait (from the previous Powerpack-valid cycle).
• 1 license-check handshake socket held by ALM.

The sum lands in the 20-22 range, which matches the observed 21. The Powerpack license churn therefore manifests as a plateau that scales with the TCP table state, not with the actual S7-1214C capability.

Common causes of Powerpack license churn:

1. License server time skew. The WinCC Server and the ALM host (which may be the same machine) must have a time difference of less than 5 minutes for license assignment to be valid. Windows Server 2019 with a misconfigured time source will invalidate the license every cycle. Validate with w32tm /query /status and force resync with w32tm /resync /force.
2. ALM service restart. The ALM Service Host (almservicehost.exe) is a Windows service that brokers license keys. If the service is restarted (manually, by a Windows update, or by a service crash), all assigned Powerpack keys are released and re-validated. During the re-validation, the runtime drops to Basic. Change the service startup type to Automatic (Delayed Start) with a 60-second delay to avoid start-up race conditions.
3. License container on a removable or network drive. The .ALI license file or the License Key USB stick must remain continuously accessible. A brief network blip releases the Powerpack. Move the license to a local fixed disk and verify the path with almservicehost -status.
4. Co-termination with VMware or Hyper-V snapshots. Restoring a VM snapshot rewinds the license state to a previous checkpoint, which may have been a no-Powerpack state. Disable automatic snapshots on the WinCC Server VM.
5. Two competing ALM instances. If both the local ALM and a network ALM are running, they can fight over the assignment. Stop the redundant ALM and keep only the local instance on the WinCC Server.

The fix is to make the Powerpack assignment sticky. Confirm each of the five items above in the order listed. The full resolution procedure is provided later in this article.

Stabilizing the Automation License Manager Service

The ALM service (almservicehost.exe) is the broker that holds license keys on behalf of running processes. By default, the service is installed with the Manual startup type and is started only when the first process requests a license. This is fragile for a 24/7 SCADA server because the service is also stopped when the last licensed process exits, and it can fail to start cleanly if a previous Runtime instance has not released the license properly.

Apply the following hardening to the ALM service on the WinCC Server:

1. Open services.msc and locate the service named Siemens Automation License Manager Service or SIMATIC ALM Service Host.
2. Set Startup Type to Automatic (Delayed Start).
3. Set the Delayed Start value to 60 seconds to avoid start-up race conditions with the WinCC Runtime service.
4. On the Recovery tab, set First failure, Second failure, and Subsequent failures to Restart the Service with a 1-minute restart delay.
5. Click Apply, then restart the service to validate the new behavior.

After the change, monitor the service for 24 hours. The service should remain in the Running state and should not log any unexpected stops in the Windows Event Viewer under Windows Logs > System with source Service Control Manager. If the service is still stopping unexpectedly, check the ALM installation log at C:\ProgramData\Siemens\Automation\ALM\log\almservicehost.log.

Channel Diagnostics Procedure in WinCC Explorer

WinCC Professional includes a Channel Diagnostics tool that shows the live state of every connection in the runtime project. Open the tool from the WinCC Explorer menu or by pressing the keyboard shortcut configured in the project properties. The Channel Diagnostics window has three relevant tabs:

1. Connection Status: shows the current state of every S7 connection (Established, Connecting, Disconnected, Broken). The Channel column gives the channel name, and the Connection column gives the connection name as defined in the project.
2. Statistics: counts the connection events since runtime start: successful cycles, failed cycles, timeouts, and rejections. The S7-Connection Refused counter is the most informative for license-related drops.
3. Trace: a real-time log of the channel driver. Set the trace level to Verbose to capture every ISO-on-TCP frame.

To narrow the 13 affected connections, sort the Connection Status table by state. The Disconnected entries can be exported to a CSV file with the Export button. The exported file contains the connection name, the last error code, and the timestamp. Common error codes for license-related drops include:

• 0x80072EE7: connection timeout. The server did not respond to ARConnectionRequest within the configured timeout.
• 0xE0FF8001: channel driver initialization failed; typically a license check failure.
• 0xE0FF8019: maximum number of connections reached for the active license tier.

For the SOFTNET license, the relevant Siemens KB is 21914909. For general TIA Portal V20 licensing, see Licensing STEP 7 and WinCC.

Configuration Parameters and Their Effect on Connection Count

The S7-1200/1500 channel in WinCC Professional exposes several parameters that affect the connection-counting behavior. The most relevant are listed below.

Disabling Fast Acknowledge is a hard requirement for WinCC Runtime with more than 16 S7 connections on a single channel. The WinCC Channel Diagnostics manual states that Fast Acknowledge reduces the connection-state check overhead but caps the effective connection count at 16. With Fast Acknowledge disabled, the driver uses a state machine that scales to 64 connections at the cost of higher CPU utilization on the WinCC Server.

For a 34-PLC project, the recommended channel configuration is:

Fast Acknowledge = 0
Connection Timeout = 30 s
Reconnection Attempts = 5
Reconnection Wait Time = 15 s
Send/Receive Timeout = 10 s
Cycle Time = 2 s

Step-by-Step Resolution Procedure

Follow the procedure in this exact order. Skipping a step is the most common reason for the 21-of-34 plateau to persist.

1. Stabilize the ALM Powerpack. Open ALM, locate the Powerpack key, and confirm the Valid indicator is steady green. If it flickers, fix the time skew first, then the network path to the license container, then the ALM service startup type (set to Automatic Delayed Start with a 60-second delay).
2. Reboot the WinCC Server. A full cold reboot forces all TimeWait sockets to clear and re-establishes the license assignment.
3. Verify the channel configuration. In WinCC Explorer, open the S7-1200/1500 channel properties and confirm Fast Acknowledge is disabled, the connection timeout is at least 30 s, and the maximum connection count is set to 64 (or License maximum).
4. Activate the project. Use WinCC Explorer > Computer > Activate to load the corrected configuration into the runtime. Do not start Runtime from the simulation mode.
5. Observe the connection count. In Channel Diagnostics, watch the connection status for 5 minutes. The count should rise monotonically from 0 to 34 within 2 minutes and remain stable. If it plateaus at 21 again, return to step 1 and re-stabilize the Powerpack.
6. Check the WinCC Server's CPU and memory utilization. The Runtime can fail to spawn new connection threads if the system is under CPU pressure. Confirm RAM greater than 8 GB free and CPU below 60 % at idle before activating Runtime.
7. Confirm the S7-1214C firmware is consistent. Mixed firmware versions across the 34 PLCs can cause connection negotiation failures. Update all PLCs to the same firmware (V4.4 or V4.5 as of 2024) using the TIA Portal Update Firmware wizard.
8. Add a redundant WinCC Server as a long-term safety measure. Two servers with a 50/50 connection split will load-balance the TCP socket pool and isolate the impact of any single license churn event.

Symptom-to-Root-Cause Matrix

Use the following matrix to triage the connection symptom on any WinCC Professional project. The matrix is based on the most common failure modes observed in production SCADA systems with the S7-1200/1500 channel.

Alternative Architectures for 32+ PLC SCADA Systems

If the Powerpack license continues to churn after all fixes above, consider a different communication architecture. The three viable alternatives are:

1. OPC UA with the SIMATIC S7-1500 OPC UA Server. Each S7-1214C with firmware V4.4+ exposes an OPC UA server. A single WinCC instance can subscribe to 34 OPC UA endpoints without the S7-1200/1500 channel license. The OPC UA approach trades the S7-channel license cost for an OPC UA license (Siemens 6GK1704-1UA00-4AE0 for V17) and a different client configuration in WinCC. The OPC UA channel scales beyond 64 endpoints per server and is the recommended path for 100+ PLC projects.
2. Modbus TCP with the S7-1200 Modbus server. The S7-1214C can be configured as a Modbus TCP server (TIA Portal MB_SERVER instruction block) on port 502. The WinCC Modbus TCP/IP channel does not require a SOFTNET license, but the per-tag tag count is more limited than the S7 channel. This option is the most cost-effective for high-tag-counts at low polling rates.
3. Distributed WinCC RT Servers. Split the 34 PLCs across two WinCC RT Servers (17 + 17) and aggregate the data at the WinCC Client level. Each server holds its own SOFTNET license. This is the most resilient architecture and isolates license problems to a single server. The two servers can be configured in redundant mode (WinCC Redundancy option) for hot-standby failover.

For 64+ PLC projects, the OPC UA path scales best because the S7-channel license is hard-bounded at 64 connections per station. A second OPC UA client station (running on the same or a different machine) doubles the capacity to 128 PLCs. For 500+ PLC projects, deploy a dedicated WinCC Process Historian and use the WinCC DataBridge option to consolidate tag data from multiple servers.

Verification and Acceptance Test

After the resolution procedure, run the following acceptance test before signing off the project. Document the results in the commissioning log.

1. Connectivity test: confirm 34 of 34 PLCs are in the Established state in Channel Diagnostics. Capture a screenshot of the Connection Status table and store it in the project archive.
2. Sustained operation test: leave Runtime running for 72 hours. Log the connection count every 6 hours. The count must remain at 34 of 34 with zero drops. The S7-Connection Refused counter in the Statistics tab must remain at 0.
3. License stability test: leave ALM open in the foreground and watch the Powerpack key for 24 hours. The Valid indicator must remain steady green for the full duration.
4. Failure-recovery test: disconnect the network cable from PLC #17 for 30 seconds and reconnect it. The connection must re-establish within 60 seconds and the system must continue to report 34 of 34 connected.
5. CPU utilization test: with Runtime running, monitor the WinCC Server CPU and memory for 1 hour. CPU should remain below 70 % and memory utilization below 80 %.
6. Client performance test: with all 4 WinCC Clients connected, force a screen change on each client every 5 seconds for 30 minutes. The Server CPU should not exceed 85 % during the load test.
7. Restart-resilience test: restart the WinCC Runtime service 5 times in a row with 60-second intervals. After the final restart, confirm that 34 of 34 PLCs reconnect within 2 minutes and the ALM Powerpack key remains valid.

Frequently Asked Questions