Troubleshooting S7-1200 TCON TSEND Failures Across Mixed Firmware

Overview of the Mixed-Firmware S7-1200 Communication Failure

A recurring field failure on SIMATIC S7-1200 networks involves Open User Communication blocks (TCON, TSEND, TRCV, TDSCON) that stop establishing a connection when a CPU with newer firmware is mixed into a fleet of CPUs that all carry older firmware. The symptom reported by maintenance engineers is consistent: the original network of four S7-1214C CPUs on firmware V1.1 communicates fine, but the moment a replacement main PLC on firmware V4.1 is dropped into the same topology, TCON returns a connection error and the data exchange halts. The block programming on paper looks identical, yet the partner never finishes the TCP handshake.

This article dissects the root cause, the TIA Portal project-handling consequences, and the exact recovery procedure that lets you bring the mixed-firmware network back online without rewriting the application. It also covers the related issue of installing TIA Portal V10.5 on a Windows 7 laptop and the impossibility of uploading a V10.5 project from a later STEP 7 / TIA Portal version.

TIA Portal V10.5 Installation Constraints and OS Compatibility

TIA Portal V10.5 was the first commercially released TIA Portal release supporting the S7-200 migration path into the unified engineering framework. Its OS support matrix is rigid and is the source of the second cluster of field tickets encountered together with this firmware-mismatch fault.

If a laptop currently runs Windows 7, the official path is to upgrade to TIA Portal V11 SP2 or later. TIA V10.5 cannot be coerced to install on Windows 7 because the installer checks the OS family string and the .NET runtime (3.5 SP1, 32-bit only) prerequisites. A virtual machine running Windows XP Mode is technically workable but is no longer covered by Siemens support and is not recommended for production engineering stations.

Why V10.5 Projects Cannot Be Uploaded from TIA V11 SP1 or Later

Two distinct operations are regularly confused in service tickets: project upload from the PLC to TIA Portal, and project migration between TIA Portal versions. The V10.5 question almost always refers to project upload, which behaves as follows:

• Upload from PLC to TIA Portal: pulls program blocks, data blocks, and configuration from the connected CPU back to the engineering station. It is supported only if the project on the engineering station has been created in a TIA Portal version equal to or newer than the version used to write the program in the first place. The PLC stores only the compiled binary; the offline project documentation, comments, and symbol table are not in the CPU.
• Project migration: a TIA Portal V10.5 archive can be opened and migrated forward in V11 SP1 or later using Project → Migrate project. The forward direction (V10.5 → V11) works; the reverse (V11 → V10.5) does not, because TIA Portal versions are not symmetric and there is no backwards migration path.

The original field statement — "TIA V10.5 cannot be uploaded" — is technically correct: from a V11 SP1 (or newer) engineering station, you cannot upload a project back into the V10.5 project tree, because V10.5 cannot read the V11 project container format. If you still have the V10.5 SP2 source project on disk, open it on a Windows XP / Vista station; otherwise the only recovery option is to recreate the offline project from scratch in the newer TIA Portal version.

S7-1200 Open User Communication: TCON, TSEND, TRCV, TDSCON Architecture

Open User Communication on the S7-1200 is implemented through four cooperating blocks, each of which carries its own internal version number that is bound to the CPU firmware:

• TCON — establishes and maintains the TCP/UDP connection. Owns the local connection ID, remote IP/port, and active/passive role.
• TSEND — transmits N bytes from a data area over an existing connection.
• TRCV — receives N bytes (LEN mode) or a delimiter-terminated frame (ADH mode) over an existing connection.
• TDSCON — establishes a connection to a Siemens partner supporting the S7 connection protocol (used for routing across subnets and for some S7 routing scenarios).

The blocks are stored in the CPU firmware as library FB/FC instances with internal version fields. TIA Portal records the version of each instance dragged into a project. When the project is compiled and downloaded to a CPU with the same or newer firmware, the matching firmware-resident block version is used. When downloaded to a CPU with older firmware, the older block version is used, and the interface (IN/OUT parameter list) of that older block is honored.

If two CPUs in the same application project carry different firmware revisions, TIA Portal compiles the block calls against the firmware of the target CPU, but the project's offline representation of the block (the type, the version, the help text) follows the firmware version selected at compile time. This is the source of the visible mismatch where the same logical program shows TCON "V4.0" on the new main PLC and a different block stamp on the older partner PLC.

Root Cause: Instruction Version Mismatch Between Firmware V1.1 and V4.1

When the original four S7-1214C fleet was programmed, the TIA Portal device selected for each CPU was firmware V1.1. The compiled offline TCON / TSEND / TRCV blocks therefore carry the V1.1 instruction family. When the new main PLC is selected at firmware V4.1, the same offline program is recompiled against the V4.1 instruction library, which is a different FB type with a different interface signature. The two programs diverge in three places that matter at runtime:

1. Interface signature drift. The V4.x TCON introduces additional IN/OUT parameters (e.g., extended connection diagnostics, RCVTIME / MSGLIFE fields re-ordered, additional status word layout) that the V1.x partner CPU cannot resolve. If the main PLC builds the connection-establishment request using a V4.x-shaped parameter set, the V1.x partner either rejects the request or the runtime within the partner firmware misinterprets the byte stream.
2. Connection-ID namespace collision. V1.x firmware reserved a smaller connection-ID space and tagged connection IDs differently. A connection ID that is unique on V4.1 can collide with a built-in reserved slot on V1.1, producing a TCON error STATUS word value 0x0001 (connection in use / parameter error) or 0x8085 (connection ID already in use) on either side.
3. Keep-alive / timeout semantics. V4.x Open User Communication exposes finer keep-alive knobs and reorders the meaning of TCON's idle/keep-alive fields. The default values compiled by TIA Portal V13+ for V4.x are tighter than what V1.x expects, so the V1.x partner treats the connection as failed before the V4.1 main has finished opening the socket.

The maintenance symptom reported on the floor — "the new V4.1 main PLC shows TCON V4.0, the partner V1.1 PLC does not establish the connection" — is the user-visible fingerprint of this triple drift. It is not a "bug" in the firmware; it is the documented consequence of compiling the same logical program against two different instruction libraries.

TSEND/TRCV/TCON Instruction Version Mapping Table

The following table captures the official instruction version transitions documented in the S7-1200 system manual for Open User Communication. Always cross-check with the Siemens Industry Online Support entry for your specific firmware and TIA Portal combination.

Note that the version number printed on the block in TIA Portal follows the firmware that was selected when the project was last compiled, not the firmware currently flashing on the connected CPU. Re-compile the project after any device change to refresh the version stamp.

Diagnostic Procedure for Mixed-Firmware TCON Networks

Run this sequence before changing any firmware. Each step produces a piece of evidence that points at the instruction-version drift or rules it out.

1. Capture the firmware stamp on every CPU. In TIA Portal, go to Online → Accessible nodes, browse to each S7-1214C, and read Online → Diagnostics → Device Information. Record Order number, Firmware, and Hardware version. Build a small table on paper or in a spreadsheet.
2. Capture the compiled block version on every CPU. Open the program block (TCON, TSEND, TRCV) in each CPU project, switch to Properties → Information, and record the block version stamped on the offline block. If TIA Portal is connected online, the online block also carries a version; record both.
3. Read the TCON STATUS word. With the program running, force the TCON instance's DONE / ERROR / STATUS outputs to a watch table and capture the STATUS hex value on a failing cycle. Common values seen on this failure mode:
   • 0x0001 — parameter error (interface signature mismatch suspect).
   • 0x8085 — connection ID already in use (namespace collision suspect).
   • 0x80A1 — partner refused connection or partner unreachable.
   • 0x80C4 — temporary communication error, often keep-alive / timeout.
4. Compare TIA Portal compile history. Open Project tree → PLC_1 → Device configuration, switch the device between firmware V1.1 and V4.1, recompile, and observe whether the TCON block's IN/OUT pins change shape. A shape change is the smoking gun for instruction-version drift.
5. Capture the offline project comments. Open the V4.1 main PLC's offline TCON instance and check whether the comments and symbol table entries differ from the V1.1 partner project. If TIA Portal shows "No documentation loaded" on the block, the offline project on the engineering station does not match what is running on the CPU — this means a backup program is wrong.

Resolution Path: Aligning Firmware or Migrating Projects

You have three viable paths. Pick by weighing downtime tolerance, hardware availability, and long-term fleet strategy.

Step-by-Step Recovery Procedure

This procedure executes Path A (firmware alignment upward) because it is the long-term sustainable answer. Substitute the equivalent steps if you choose Path B or C.

1. Back up every CPU's offline project. In TIA Portal use Project → Archive on each project before any change. Store the .zap archive in version-controlled storage with the date stamp in the file name.
2. Identify the highest firmware supported by your TIA Portal version. The device catalog in TIA Portal V13 SP1 carries V4.1; V14 SP1 carries V4.2; V15 carries V4.4 (depending on the HSP set installed). The latest HSP for V15 is HSP for S7-1200 published by Siemens.
3. Update the engineering station's TIA Portal. If your station is still on V10.5 / V11 SP1, install at minimum TIA Portal V13 SP1 Update 9 or V14 SP1 Update 7 to obtain V4.1 / V4.2 device catalog coverage. Windows 7 SP1 64-bit is the minimum OS for these versions.
4. Install the S7-1200 firmware update package. Use SIMATIC Automation Tool or the S7-1200 Online → Firmware update wizard. The firmware file (.upd) is matched to the order number (for example 6ES7214-1AG40-0XB0 for CPU 1214C DC/DC/DC firmware V4.x). Verify the order number before flashing.
5. Flash each partner CPU. Connect to each S7-1214C in turn, perform the firmware update, and confirm the new firmware revision on the device-information screen. Repeat for all four CPUs so the fleet is uniform.
6. Recompile the project against the new firmware. In the offline project, change the device to the new firmware revision and recompile. The TCON / TSEND / TRCV blocks automatically pick up the V4.0 family. Download the project to each CPU.
7. Bring up the network. Power-cycle the CPUs in the order main first, then partners. Watch the TCON DONE / ERROR bits and confirm STATUS returns 0x0000 on the active connection.
8. Capture the working binary as the new baseline. Read the project back from the CPU and save the archive with a clear name. This becomes the new master for any future PLC swap.

Verification Checklist

• All four CPUs report the same firmware revision on Online → Device Information.
• TCON DONE = 1 and STATUS = 0x0000 on the main PLC's watch table.
• TRCV on each partner shows NDR = 1 within the expected polling period and RCVD_LEN matches the TSEND LEN value.
• The diagnostic buffer of each CPU contains no entry tagged with Event ID 0x0190 (TCP connection aborted) or 0x0188 (connection establishment failed).
• The TIA Portal project compiles clean against the new firmware with no warnings related to "block version" or "instruction version".
• The offline archive matches the connected online project on a fresh upload test.

Field-Proven Caveats and Safety Notes

FAQ