TIA Portal Error -109 ServiceNotConnected S7-1500 VPN Download

Problem Overview

When downloading project changes to a remote SIMATIC S7-1500 station (CPU 1515F-2PN, FW 2.8.3) through a customer VPN tunnel using TIA Portal V16 Update 5, the engineering station successfully pings the PLC and can establish an online connection, but the download process aborts after a few seconds. The TIA Portal event log reports one or more of the following messages:

• Communications error (error code -102): ServiceDisconnected
• Communications error (error code -109): ServiceNotConnected
• Internal system error, please contact SIMATIC customer service

When -102 / -109 fire together, the TIA Portal online session terminates and the user must rebuild the PG/PC interface assignment. Because the customer IT team has already confirmed that TCP port 102 is permitted on the VPN, the root cause is almost always below the IP layer: a physical or lower-layer data-fault on the PROFINET segment that the duplicate, "twin" machine does not exhibit.

Affected Environment

Protocol Stack Used by TIA Portal Downloads

Understanding why error -109 surfaces only after the online session is established requires the protocol layers involved in a download:

1. Ethernet (IEEE 802.3) — physical link, auto-negotiation of speed/duplex.
2. IP / TCP — TCP port 102 is the registered port for ISO Transport Service on top of TCP, used by S7 communication and the S7CommPlus derivative used by TIA Portal.
3. ISO Transport (RFC 1006 / ISO 8073) — connection-oriented, TPDU-based session.
4. S7Comm / S7CommPlus — Siemens application-layer protocol for PG functions (read, write, download, online).
5. TIA Portal download manager — streams blocks, rewrites, and triggers CPU run-mode transitions.

Each transition phase requires multiple keep-alive PDUs. When error -109 (ServiceNotConnected) is returned, the S7CommPlus layer has not received the expected connect response from the CPU within the timeout window. When error -102 (ServiceDisconnected) follows, the S7CommPlus session that was open is torn down by the CPU, which is the typical reaction to repeated malformed or incomplete PDUs caused by corrupted frames reaching the controller.

Root Cause Analysis

The combination of working ping, working online connection, and a download that fails after partial data transfer almost always traces to a layer-1 / layer-2 fault on the path between the PLC's PN/IE_2 port and the VPN gateway or first managed switch. The twin-machine comparison is the strongest diagnostic evidence: identical project, identical TIA Portal version, identical VPN policy, but a different physical PROFINET segment. Common causes encountered in the field:

1. Damaged or marginal PROFINET cable (most frequent)

PROFINET specification (IEC 61784-2 / IEC 61918) requires Cat 5e or better UTP/STP, 100 Ω differential impedance, and a maximum segment length of 100 m. A cable that is partially crushed, has a defective RJ45 latch, or shows increased insertion loss passes ping (ICMP uses very small packets) but drops the much larger S7CommPlus download PDUs. Siemens PROFINET installation guidelines require cable testing per PROFINET Cabling and Interconnection Technology (Siemens document 6ZB5530-1AE0-0BA0).

2. Duplex / auto-negotiation mismatch

If the PLC port is set to a fixed 100 Mbps full-duplex and the partner switch port has fallen back to half-duplex or 10 Mbps after auto-negotiation, the link stays up but late collisions corrupt frames. TIA Portal's download is the first IP traffic that exercises the link at sustained bandwidth, which is why ping and small reads succeed while bulk downloads fail.

3. EMI / ground potential difference

VFD-bearing machinery, welding cells, or ungrounded shielding can raise the noise floor on a PROFINET segment sufficiently to corrupt a multi-megabyte transfer even though the link is "up". This is the second most common cause when the two machines have different routing and one runs near a drive cabinet.

4. Switch port error-disable or rate limiting

Many managed switches have storm-control, BPDU-guard recovery, or MAC-limit features. A noisy neighbor device on the same switch can cause the PLC's port to be temporarily error-disabled or rate-limited.

5. Windows 10 VPN behavior (less likely once ping works)

Microsoft documented a regression in Windows 10 version 1903 (May 2019 Update) where certain IPSec VPN tunnels dropped long-lived TCP sessions; subsequent builds (1909, 2004) carry the fix KB4503293. If the engineering PC is still on 1903, confirm it has been patched. TIA Portal's download session is long-lived and TCP/102 is exactly the kind of session that the original 1903 bug disrupts.

6. CPU firmware defect (rare, last-resort check)

FW 2.8.3 on the 1515F-2PN has no published TIA Portal V16 download defect, but firmware 2.8.x requires TIA Portal V16 SP1 or later for online token handling. The matching V16 Update 5 is the correct combination; if the engineering station has a side-loaded older V16 base install, a clean re-install of V16.0.5 resolves edge cases.

Step-by-Step Diagnostic Procedure

Follow this sequence in order. Do not skip steps; each one is designed to localize the fault to a single network segment.

Step 1 — Verify the Twin-Machine Hypothesis

1. In TIA Portal Online → Accessible nodes, scan the VPN-side subnet and confirm the PLC is reachable.
2. Open Project tree → Devices → PLC_1 → Online & Diagnostics and read the diagnostic buffer. Look for entry "Communication error" or "Connection interrupted".
3. Compare the diagnostic buffer of the working twin. If the working machine has no communication entries, the fault is on the failing machine's path.

Step 2 — Inspect PROFINET Port LEDs on the CPU

On the CPU 1515F-2PN the X2 port has two LEDs per channel: Link (green) and Activity (yellow). According to the S7-1200 / S7-1500 system manual and the PROFINET IO status and error displays reference, the following patterns indicate link health:

Step 3 — Read the CPU's PROFINET Diagnostics

1. In TIA Portal, open Online & Diagnostics → PROFINET interface → Port statistics.
2. Note the counters Discarded frames, CRC errors, and Late collisions.
3. Reset the counters, run a single download attempt, then read again. Any non-zero increment of CRC errors or Discarded frames is definitive proof of a physical-layer problem.

Step 4 — Cable Continuity Test

Use a cable certifier (Fluke DSX, Softing WireXpert, or even a simple continuity tester) to validate the run from the PLC's X2 to the customer switch. The acceptable limits per IEC 61918 are:

• Wire map: all four pairs correctly terminated to T-568B (or T-568A on the customer standard).
• Insertion loss: ≤ 22 dB at 100 MHz over 100 m.
• Return loss: ≥ 10 dB.
• Delay skew: ≤ 50 ns across all four pairs.

Pin failures, kinks, or cable ties pulled too tight are the most common marginal-cable causes. Replace the patch cord first; it is the cheapest component.

Step 5 — Force Speed/Duplex on the PLC and Partner

1. On the CPU: Device configuration → PROFINET interface → X2 → Port properties. Set Transmission rate / duplex to 100 Mbps full-duplex, automatic negotiation disabled.
2. On the partner switch: mirror the same setting on the PLC's port. Disable auto-negotiation and pin the port to 100/FULL.
3. Repeat the download and watch the CRC counters in Step 3.

Step 6 — Eliminate VPN Path Variability

1. From the engineering PC, run ping -t -l 1400 <PLC_IP> for 60 seconds. Zero packet loss is required for a TIA Portal download to be reliable.
2. Run Test-NetConnection -Port 102 -ComputerName <PLC_IP> in PowerShell to confirm TCP/102 is open and that the underlying TCP RTT is below 200 ms. RTT above 500 ms will frequently time out the S7CommPlus connect PDU during a download.
3. If the VPN introduces high RTT, set the TIA Portal PG/PC interface MTU down to 1300 (TIA Portal does not expose this directly; the workaround is to enable VPN fragmentation).

Step 7 — Validate the S7CommPlus Session

Open a Wireshark capture on the engineering PC filtered to tcp.port == 102 && ip.addr == <PLC_IP>. Look for the ISO Transport CR (Connection Request) followed by CC (Connection Confirm) PDUs. If the CC arrives but TIA Portal still reports -109, capture the next TPKT payload and verify it is an S7CommPlus S7_COMMS_SETUP request. Missing or malformed SETUP responses indicate CPU firmware, not the network.

Solution Procedure (Field-Confirmed)

1. Replace the PROFINET patch cable between the CPU 1515F-2PN X2 and the customer switch with a known-good Cat 5e (or Cat 6A) shielded patch cord terminated to T-568B. Use a cord with an over-molded boot and a locking tab protector.
2. Re-seat the RJ45 on the switch side and the PLC side. Listen for the latch click.
3. Verify both Link LEDs are solid green and the Activity LED flickers when the PC pings the PLC.
4. Open TIA Portal V16.0.5, change the PG/PC interface to the same PN/IE adapter, set the target IP, and perform a full project download.
5. Watch the TIA Portal progress bar reach 100% without a -102 / -109 entry in the event log.

Verification Checklist

• ping -t -l 1400 <PLC_IP> → 0% loss for 60 s.
• CPU PROFINET port statistics → 0 CRC, 0 discards, 0 late collisions over a 5-minute window.
• TIA Portal: Download to device completes with green progress bar and no entries in the Info / Diagnostics tab.
• CPU diagnostic buffer: no new Communication error entries.
• Wireshark: no retransmissions, no duplicate ACKs, no TCP RST for the S7 session.

Error Code Cross-Reference

Preventive Measures

• Spec PROFINET-certified cable assemblies only (Siemens 6XV1840 series or equivalent). Avoid generic Cat 5e patch cords in panels.
• Install RJ45 connectors with industrial strain relief (M12 D-coded or Siemens FastConnect).
• Document every PN segment with a cable test certificate; keep the cert on file with the project archive.
• Maintain the engineering host on the latest Windows 10 cumulative update to avoid the 1903 VPN regression.
• Keep TIA Portal on the same Update level across all engineering seats; mismatched Update levels frequently produce -102 / -109 because of S7CommPlus version negotiation differences.
• For F-CPU 1515F, pair TIA Portal V16.0.5 with FW 2.8.3 or FW 2.9.x; do not cross-paired older FW < 2.6.

Related Siemens References

• S7-1200 / S7-1500 system manual — error messages (STEP 7 V14.0 entry ID)
• PROFINET IO — status and error displays

FAQ