S7-1200 TSEND_C and TRCV_C Connection Limits: Resource Rules

Overview of S7-1200 Open User Communication Resources

Every SIMATIC S7-1200 CPU exposes a fixed pool of communication resources through its integrated PROFINET interface. These resources are consumed by active connections only, not by blocks that are merely compiled into the project. The TSEND_C/TRCV_C compact blocks and the discrete TSEND/TRCV/TCON/TDISCON blocks from the SIMATIC S7-1200 Programmable Controller instruction set share the same underlying resource pool. The compiler in TIA Portal performs static syntax and type checking on every block instance, but it does not perform an availability check against the runtime resource count of the target CPU. As a result, projects that exceed the runtime connection count of the CPU compile cleanly and download without error. The constraint is exposed only at runtime, when the TCON instruction tries to establish a connection for which no resource remains.

This behavior is a frequent source of confusion in multi-CPU architectures in which one master S7-1200 must talk to many peers using TSEND_C/TRCV_C. Compiling a project with ten CPU instances, twenty peer connections, or even thirty peer connections does not produce a TIA Portal warning, but the first run-time call to TCON that would push the active count above the CPU maximum returns an error code on the instance DB status word.

Why TIA Portal Compiles Past the Connection Limit

The TIA Portal compiler resolves the following for each instruction instance:

• Block version compatibility against the selected CPU firmware.
• Data type conformance on input and output pins.
• Instance DB allocation in the load memory.
• Multi-instance parenting and naming.

It does not pre-reserve connection resources, because connection establishment is performed by the TCON instruction at runtime, not at compile time. The official Siemens answer entry Which devices can the S7-1200 communicate with over the integrated PROFINET interface, and which protocols are supported? lists per-protocol maximums per CPU and is the canonical reference for the published limits. Any divergence between the published limit and the number of block instances in the project is therefore by design, not a bug.

Practical implication: a successful compile of a project with more TSEND_C/TRCV_C pairs than the CPU's connection limit means only that the program is syntactically valid. It does not guarantee that every connection will come up. The first TCON that exceeds the available resources returns status code 16#80A3 in the instance DB, and the connection remains in DISCONNECTED state.

Per-CPU Connection Resource Limits

Connection counts vary by CPU model and firmware version. The values below are drawn from the device manuals listed in the Siemens Industry Online Support and are the most commonly cited figures for the standard S7-1200 line. Always verify against the specific S7-1200 Programmable Controller manual for the exact order number (MLFB) and firmware you are commissioning.

The 16-connection ceiling applies to the integrated PROFINET interface only. Adding a CM 1243-1 (communications processor for S7-1200) introduces a second PROFINET interface with its own resource pool, doubling the usable connection count for applications that need it.

TSEND_C and TRCV_C vs TSEND, TRCV, and TCON

The two block families serve different design philosophies. Pick deliberately:

The 8192-byte payload ceiling applies to both families. The TIA Portal instruction reference TSEND_C and TRCV_C — Send and receive data using Ethernet and the corresponding TCON/TDISCON/TSEND/TRCV reference TCON, TDISCON, TSEND, and TRCV — TCP communication instructions specify this limit. Both instruction groups run on top of the same connection resource pool, so the 16-connection ceiling applies regardless of which block family you choose.

Where the two families diverge is in resource acquisition behavior. TSEND_C internally calls TCON the first time the REQ edge is seen and keeps the connection alive until the CONT pin drops. The discrete TSEND/TRCV family leaves TCON entirely under programmer control, which is the only realistic way to multiplex many peers across a small connection pool.

Active vs Configured: Where Resources Actually Live

A connection resource is allocated at the moment TCON transitions from IDLE to CONNECTING. It remains allocated until TDISCON is executed or until the partner drops the link and the local T_DISCONNECT timeout expires. The compiler sees a project with N instances of TSEND_C/TRCV_C and treats every instance as potentially active. The runtime, however, only consumes a slot in the resource table for instances whose TCON has actually fired.

This decoupling is what produces the apparent contradiction observed by integrators: a project with 30 TSEND_C instances compiles cleanly, but only 16 of them (on a stock S7-1200) can ever coexist as active connections. The compiler cannot know which 16 will be active, because that is a function of the program's sequential call order and the dynamics of the network.

TCON Error Codes and Runtime Diagnostics

When TCON cannot allocate a resource, the instance DB STATUS word returns a code from the standard TCON error set. The codes you will most often encounter during connection-limit work are:

Code 16#80A3 is the unambiguous signal that the S7-1200 has run out of connection resources. Treat it as a planning failure and reduce the simultaneous active count, not as a transient fault. Codes 16#80C4 and 16#80C5 can also indicate resource pressure but are retry-friendly.

Connection Resource Planning Methodology

Plan before you program. The following procedure gives a defensible upper bound on simultaneous connections for a master S7-1200:

1. Identify the published total connections figure for the exact CPU MLFB and firmware from the Siemens device manual.
2. Subtract the number of permanent connections required for HMI panels, the web server, and any PG/PC online access. A typical HMI panel uses one connection; a TP700 Comfort uses one; the web server counts as one user-defined connection. PG online access is transient but should be reserved.
3. Subtract any S7 connections reserved for PUT/GET or BSEND/BRCV with peer S7-300/400/1500 controllers.
4. The remaining budget is what is available for TSEND_C/TRCV_C active pairs.
5. Validate by counting TSEND_C instances whose REQ edge will fire simultaneously at the worst-case execution point in the OB1 cycle.
6. If the worst-case count exceeds the budget, switch to discrete TCON/TDISCON and implement a pool/queue.

For the seven-CPU architecture in the original integrator scenario (one master S7-1200 + six peers), the master needs six simultaneous active connections, plus at least one for HMI, plus one for web server, leaving 8 connections in reserve. This is well within the 16-connection limit of any current S7-1200 CPU. The same architecture scaled to twelve peers would exhaust the master CPU's resource pool and force a multiplexer design or a CM 1243-1 add-on.

Sequential vs Simultaneous Communication Strategies

The connection limit forces a design choice when the peer count exceeds the budget. The two practical strategies are:

The sequential strategy is the simplest and is what the S7-1200 was designed for. A polling cycle that talks to one peer per OB1 sweep, holds the connection for a single burst, and disconnects before moving on consumes exactly one connection slot regardless of how many peers exist. This is the only sustainable architecture on a stock S7-1200 once the peer count exceeds 14 (after subtracting HMI and web).

Verifying the Active Connection Count at Runtime

Never trust the compile count. Trust only what the CPU reports. The S7-1200 exposes the live connection table through the following channels:

1. Online & Diagnostics → Diagnostics → Communication. The TIA Portal online view lists every active connection with its ID, protocol, partner IP, partner port, and state.
2. Watch table on the instance DBs. Monitor the DONE, BUSY, ERROR, and STATUS tags of every TSEND_C instance.
3. Web server diagnostic pages. With the standard web server enabled, navigate to Diagnostics → Connection overview for a browser-based view of all active connections.
4. SNMP. The integrated PROFINET interface exposes connection-related MIB variables to network management.

A simple verification snippet in ladder logic increments a counter on every successful TCON and decrements on TDISCON, giving a live view of the current pool occupancy. With this counter in place, exceeding the budget becomes visible the first time it happens.

Field-Proven Configuration Example

The following ST excerpt sketches a multiplexer for a master S7-1200 that needs to talk to 24 peers but has only 14 connection slots after HMI and web. It uses a ring index to advance through the peer table and explicitly disconnects before reconnecting.

// Ring index through 24 peers
IF Scan_Enable THEN
    IF NOT ConnectionActive THEN
        // Disconnect prior peer (if any) before requesting the next
        TDISCON_DB(REQ := TRUE, ID := ActiveID);
        ActiveID := PeerTable[RingIdx].ConnectionID;
        TCON_DB(REQ := TRUE,
                ID := ActiveID,
                CONNECT := PeerTable[RingIdx].ConnectParam);
        ConnectionActive := TRUE;
    ELSE
        // Burst data while connected
        TSEND_DB(REQ := SendTrigger,
                 ID := ActiveID,
                 LEN := SendLen,
                 DATA := SendBuffer);
        TRCV_DB(EN_R := TRUE,
                ID := ActiveID,
                LEN := RecvMaxLen,
                DATA := RecvBuffer);
        IF CycleTimeElapsed THEN
            TDISCON_DB(REQ := TRUE, ID := ActiveID);
            ConnectionActive := FALSE;
            RingIdx := RingIdx + 1;
            IF RingIdx > 24 THEN RingIdx := 1; END_IF;
        END_IF;
    END_IF;
END_IF;

This pattern uses exactly one connection slot regardless of peer count. It scales linearly in scan time, not in connection count. Place the cycle on a cyclic OB (e.g., OB30) or in OB1 with a rate limiter if the polling interval must be tight.

Common Pitfalls and Field Caveats

• Assuming compile success means runtime success. The compiler never validates the connection budget. Plan and verify at runtime.
• Forgetting the HMI and web server. A TP700 Comfort and an active web session consume two of the sixteen slots. This is the most common reason a six-peer architecture mysteriously fails on the bench.
• TSEND_C hidden CONT pin. Once TSEND_C has connected, it stays connected until CONT is dropped. There is no graceful way to multiplex TSEND_C across many peers. Use the discrete family for multiplexing.
• Partner CPU's own limit. Each peer S7-1200 also has a 16-connection budget. A star architecture with 16 peers each holding one connection back to the master consumes 17 connections on the master (1 per peer plus 1 active master) and one on each peer (16 total). Verify both ends.
• Watchdog and T_DISCONNECT. If a partner goes offline without a clean TCP FIN, the local slot is held until the T_DISCONNECT timeout expires (default typically a few seconds). During this window, the slot is unusable.
• PG online access. A TIA Portal going online opens a connection. If the PG is left online during a connection-limit test, it consumes one slot and skews the count.
• CM 1243-1 misattribution. Connections on the CM 1243-1's PROFINET interface do not count against the integrated interface's budget. They are a separate pool.
• Web server users. Multiple browser users on the standard web server each consume a connection slot.

Documentation and Standards References

For authoritative figures, work from the following Siemens-published documents:

• Which devices can the S7-1200 communicate with over the integrated PROFINET interface, and which protocols are supported? — the canonical answer for per-protocol limits and partner compatibility.
• TSEND_C and TRCV_C — Send and receive data using Ethernet — instruction reference, payload limits, and pin semantics.
• TCON, TDISCON, TSEND, and TRCV — TCP communication instructions — discrete-block family reference.
• TCON, TDISCON, TSEND, and TRCV (TCP communication instructions) — alternate Siemens entry on the same family.