Fixing S7-1500 TCON Error 8602 and 80C6 SQL Database Connection

Problem Details: TCON Error 8602 / 80C6 During S7-1500 SQL Server Connection

When using the Siemens "SQL" example project in TIA Portal to establish communication between a SIMATIC S7-1500 CPU and a Microsoft SQL Server, the application may fail on the first TCON call with the following status indicators on the tempLSqlStatus structure:

• Status word 8602 (decimal) in the tempLSqlStatus instance.
• SubfunctionStatus 80C6 (hex) reported in the diagnostic buffer / online watch table.
• State number 3 stuck in the SQL state machine.

After a follow-up attempt (e.g., adding firewall rules for TCP), the subfunctionStatus may change to 80CE while the high-level error 8602 remains. The PLC never reaches the connected state and the SQL request block (LSql_SqlBlock) does not transition past State 3.

The root cause is not the SQL Server error 8602 documented in the Microsoft SQL Server 8000–8999 event catalog (which describes a query processor interface access failure). The decimal 8602 in the Siemens example originates from the TCON instruction, not from Microsoft SQL Server. The relevant Siemens error numbers are the TCON subfunction codes 80C6 and 80CE, which are part of the standard TCP connection error set documented in the S7-1500 communication system manuals.

Root Cause Analysis: Why TCON Returns 80C6 / 80CE

The TIA Portal documentation for the TCON instruction states that an IP address of 0.0.0.0 on the local PROFINET interface is an invalid configuration and prevents the connection from being established. When the local IP is 0.0.0.0, the TCON call cannot bind to a network interface, and the CPU reports the failure as the TCON subfunctionStatus 80C6 ("connection partner cannot be reached") because no route is available to the remote SQL Server endpoint.

Other independent root causes that produce the same 80C6/80CE signature include:

1. Misconfigured local PROFINET IP address on the CPU (subnet mask mismatch, duplicate IP on the network, or default 0.0.0.0 after a factory reset).
2. SQL Server not listening on the expected TCP port. By default, SQL Server listens on dynamic ports if the TCP/IP protocol is enabled but a static port is not configured. The Siemens example targets port 1433; if the server is bound to a different port, TCON reports a connection error.
3. Windows Firewall blocking inbound TCP/1433 on the SQL Server host, or an upstream network firewall (corporate, cloud NSG, host-based).
4. TCP/ODBC driver mismatch on the Windows side – only the ODBC Driver 17 for SQL Server (or 18) is supported by the current Siemens SQL example. Older Native Client drivers are not compatible with the TLS handshake the example performs.
5. Version incompatibility: the SQL example project is built for TIA Portal V16. Opening it in V15.1 may compile but will produce runtime errors in TCON because the internal data block structure for the connection description changed in V16.

TCON SubfunctionStatus Reference for S7-1500

The TCON instruction populates the DONE, BUSY, ERROR, and STATUS outputs. The STATUS value can be split into two hex ranges: the high byte (event class) and the low byte (event number). For S7-1500 CPUs (firmware ≥ V2.0), the relevant connection-related values are:

These values are documented in the S7-1500 S7-1500/S7-1200 Communication Function Manuals, see the SIMATIC S7-1500 Communication Function Manual entry ID 109768413 on the Siemens Industry Online Support portal.

Prerequisites for a Working S7-1500 → SQL Server Link

Before commissioning the SQL example project, confirm the following items are in place. Each prerequisite addresses one of the failure modes listed in the root cause section.

• TIA Portal V16 or later with the "SIMATIC S7-1500" HSP installed. TIA V15.1 is not supported – the connection description DB layout changed in V16.
• S7-1500 CPU with firmware ≥ V2.5 (CPU 1511, 1513, 1515, 1516, 1517, 1518) to support the Open User Communication OPC UA-capable TCON instruction variant used in the example. Older firmware does not support all TLS features.
• SQL Server 2016 or later (Express, Standard, or Enterprise) running on a Windows host reachable from the PLC PROFINET interface.
• SQL Server TCP/IP protocol enabled, listening on a static port 1433 (not a dynamic port – see the msphpsql issue 576 on dynamic-port troubleshooting for the same root cause pattern).
• ODBC Driver 17 or 18 for SQL Server installed on the Windows host. Driver 13 and the older SQL Server Native Client are not compatible.
• Windows Firewall inbound rule allowing TCP/1433 from the PLC's PROFINET subnet.
• Static IP address on the PLC PROFINET interface – not 0.0.0.0, not DHCP-pending.

Step-by-Step Resolution Procedure

1. Verify the PLC PROFINET IP address. In TIA Portal, expand Device Configuration → PROFINET interface [X1] → Ethernet addresses. The IPv4 address must be a valid host address inside the same subnet as the SQL Server. A value of 0.0.0.0 is the primary cause of TCON 80C6 in a fresh project. Save and re-download hardware configuration to the CPU.
2. Ping the SQL Server from a PC on the same subnet as the PLC to confirm the network path is alive. If the ping fails, fix routing, VLAN, or switch port assignment first – TCON will not succeed if IP connectivity is broken.
3. Open SQL Server Configuration Manager on the Windows host: SQL Server Network Configuration → Protocols for MSSQLSERVER → TCP/IP → Properties → IP Addresses → IPAll. Set TCP Port = 1433, clear TCP Dynamic Ports, and restart the MSSQLSERVER service. Confirm with netstat -ano | findstr :1433 that the PID listening is sqlservr.exe.
4. Install ODBC Driver 17 for SQL Server on the host. Verify in ODBC Data Sources (64-bit) → Drivers that "ODBC Driver 17 for SQL Server" is listed. A missing or wrong driver produces a TCON 80CE because the SQL Server rejects the TLS handshake.
5. Create a Windows firewall inbound rule: New Rule → Port → TCP → 1433 → Allow → Profile: Domain + Private → Name: "SQL Server from PLC". Do not enable on Public profile. Repeat for UDP/1434 only if you use the SQL Browser service.
6. Configure the SQL Server authentication mode. The Siemens example uses SQL Server authentication (user sa or a dedicated login). Right-click the server in SSMS → Properties → Security → SQL Server and Windows Authentication mode → restart the service.
7. Open the SQL example project in TIA Portal V16. Do not downgrade to V15.1 – the TCON_CFG data block layout changed. If you need to migrate to a newer V17/V18 project, use Project → Migrate rather than a manual copy.
8. Update the connection DB constants. In the LSql_Connection DB, set remoteIPAddress to the SQL Server's IPv4, remotePort to 1433, and localTSAP to a unique value not used by any other connection on the CPU (default 10.00 works on a single-connection project).
9. Recompile and download the entire S7-1500 station. Reset the CPU to RUN. Watch the tempLSqlStatus tags in real time. The state machine should now progress past State 3 within two scan cycles.
10. Run a test SELECT from the HMI or watch table calling LSql_SqlBlock. A successful read populates tempSqlResult and the state returns to 0 (idle).

Verification Checklist

Workarounds When TIA Version Downgrade Is Required

If the production line uses TIA V15.1 and the SQL example was provided in V16, do not attempt to open the V16 project directly. Instead, recreate the data structures manually:

1. Create a new V15.1 project with the same S7-1500 station.
2. Add a new TCON call referencing a fresh TCON_CFG DB. Use the V15.1-compatible connection description layout (8-byte local TSAP, 8-byte remote TSAP, IP 4 bytes, no extended TLS fields).
3. Reuse the LSql_SqlBlock FB and LSql_Connection DB from the V16 example, but adjust the id of the TCON reference to match the new V15.1 connection ID.
4. Test with a non-encrypted SELECT first. If the V15.1 build of TCON rejects the TLS parameters, fall back to plain TCP and let the Windows side handle encryption at the ODBC layer.

Diagnostic Data to Capture Before Contacting Siemens Support

If the 80C6/80CE persists after the steps above, gather the following before opening a support request on the Siemens Industry Online Support portal:

• S7-1500 CPU order number (e.g. 6ES7513-1AL02-0AB0) and firmware version (read from the online diagnostics or the module label).
• Full TIA version (Help → About) including installed HSPs.
• SQL Server build number (SELECT @@VERSION) and authentication mode.
• Wireshark capture on the SQL Server NIC during a failed TCON attempt – filter tcp.port == 1433. Look for SYN with no SYN-ACK, or SYN → SYN-ACK → RST (which is the 80CE pattern).
• Screenshot of the tempLSqlStatus structure with all member values (status, subfunctionStatus, state, errorCounter).
• Output of Get-NetFirewallRule -Enabled True -Direction Inbound | Format-Table Name, Profile.

Troubleshooting Matrix: Symptom → Cause → Action

Common Field Errors and Lessons Learned

During commissioning, three configuration mistakes account for the majority of TCON 80C6/80CE reports against the Siemens SQL example project:

1. SQL Server left on a dynamic port. The default installation of SQL Server Express enables TCP/IP but assigns port 0 (dynamic) until a static port is configured. A Wireshark capture of a failed connection shows SYN going to sqlhost:49672 (or similar ephemeral port) even though the Siemens project is configured for 1433. Set a static port in SQL Server Configuration Manager and restart the service.
2. ODBC Native Client 11 installed, not ODBC Driver 17. Windows ships with older SQL drivers. The Siemens example's TLS 1.2 handshake requires the new driver. Uninstall Native Client 11 and install msodbcsql17.msi from the Microsoft download center.
3. Project opened in TIA V15.1 by mistake. A colleague's V15.1 installation opens a V16 example without complaint but silently changes the connection DB layout. TCON 80CE then appears on the first call. Migrate the project formally with Project → Migrate rather than opening a foreign version.

Safety and Operational Notes

The S7-1500 Open User Communication stack is a non-real-time extension. Do not place TCON retries inside a fast OB1 cycle without rate limiting – a network outage will saturate the CPU's communication resources and can stall process I/O. Siemens recommends placing the SQL request in a cyclic OB with a minimum 100 ms period and using the BUSY output to gate the next request.

For safety-integrated applications (SIL 2/3), route SQL data exchange through a non-safety CPU and apply data validation on the safety side. The standard SQL example project is not certified for safety functions.