Resolving TSEND_C Status 7002 on Siemens S7-1200 PLC

TSEND_C remains at 7002, while BUSY, DONE, and ERROR appear inactive. The decisive test is not the client display or a watched output bit; it is whether TCP payload bytes leave the S7-1200 and whether those bytes match the client application's required message syntax.

Connection Role and Data Path

Separate transport connectivity from application acceptance. TCP provides a byte stream between two endpoints. A successful connection can carry a message that the receiving application subsequently ignores because its parser rejects the content.

Receiving data through TRCV_C proves that a receive path works, but it does not by itself prove that the client accepts the PLC's transmitted format. If transmit and receive use independent connections, verify each connection separately. The PC application must accept the PLC's connection role, local and partner addressing, and selected port arrangement.

Check 1: Expect the intended PLC-to-PC TCP connection to be established at the moment the send request is issued. If separate connections are configured, expect both endpoints to appear independently in the PC's connection diagnostics.

Controlled Send Request

REQ is the command input for the send operation. Commission it with a deliberate false-to-true transition rather than leaving it continuously asserted. Keep CONT true when the application requires the connection to remain established, as in the reported configuration.

1. Force REQ false and confirm that no send request is pending.
2. Place one known test message in the send buffer.
3. Drive REQ true for a controlled request event.
4. Return REQ false before initiating the next test.
5. Do not overwrite the buffer while the transaction is being evaluated.

The test buffer should reside in memory that no other logic writes. Overlapping absolute addresses, reused temporary storage, or another network modifying the same bytes can make the transmitted payload differ from the text displayed during offline inspection.

Check 2: Expect exactly one intentional send request for one prepared buffer. Expect the buffer bytes to remain unchanged from the request event through completion of the diagnostic capture.

Transient Output Capture

DONE and ERROR can be too brief to diagnose reliably from an online display. A monitor refreshed more slowly than the PLC scan can miss a one-scan indication. Setting a memory bit directly from an output also fails if later logic writes that bit or if the capture expression does not latch the event.

Create separate diagnostic latches for the block outputs. The latches are application diagnostics; do not write back to DONE, ERROR, or other instruction outputs.

DoneSeen  := DoneSeen  OR DONE;
ErrorSeen := ErrorSeen OR ERROR;
BusySeen  := BusySeen  OR BUSY;

Reset these latches before each controlled trial. Record STATUS at the same time as an output transition, because a continuously watched value may show only the state present after the short event has passed. Interpret 7002 using the status table for the installed instruction version, but do not treat it as proof that the client accepted the message.

Check 3: Expect the diagnostic latches to retain any brief DONE, ERROR, or BUSY indication until manually reset. If none sets, continue with a packet capture instead of concluding that no transmission occurred.

Wire-Level Transmission Test

A network trace between the PLC and PC separates transport behavior from application behavior. In the resolved case, traffic analysis showed that the PLC was transmitting the string even though the client software displayed nothing. The apparent send failure was therefore downstream of TSEND_C.

1. Start a packet capture on the PC interface carrying the PLC connection.
2. Filter the view to the PLC and PC endpoint addresses and the configured TCP port.
3. Clear the diagnostic latches and issue one controlled REQ event.
4. Locate the corresponding PLC-to-PC TCP payload.
5. Compare the captured bytes with the prepared send buffer, including any nonprinting bytes.

If no PLC-to-PC payload appears, return to connection state, endpoint configuration, request generation, and buffer addressing. If payload appears, the send path is operating; move to application framing and syntax.

Check 4: Expect one PLC-to-PC payload containing the intended test bytes. An acknowledgment proves TCP delivery to the peer stack, while recognition by the client must be checked separately.

Client Message Syntax

The term message syntax here means the exact byte structure the PC application parses. A TCP receiver may accept bytes at the socket and still discard them at the application layer because a field, delimiter, terminator, character representation, or declared length is wrong.

Compare the captured payload against the client protocol definition byte for byte. Do not rely solely on a text window: it can hide control characters, padding, and terminators. Check the following items in order:

1. Confirm that the first byte begins where the client expects the message to begin.
2. Compare every fixed character and field separator with the client's documented syntax.
3. Check whether numeric fields use the required text or binary representation.
4. Verify any message terminator and include it in the transmitted length when the protocol requires it.
5. Remove unintended trailing bytes left from an older or longer buffer value.

The software revision used for diagnosis also matters. An earlier client version displayed any received string, including malformed strings, while the later version did not recognize the incorrect syntax. A display difference must not be mistaken for a transport failure.

Check 5: Expect the captured payload length and every byte to match one client-defined valid message. Expect the client to process that message rather than merely maintain the TCP connection.

End-to-End Commissioning Verification

Avoid changing from TSEND_C to separate TCON and TSEND blocks before locating the failing layer. That substitution produced 80C4 during testing and introduced a second connection problem without resolving the original malformed-string fault.

1. Reset the event latches and clear the client result display.
2. Load a known-valid message into the PLC buffer.
3. Issue one false-to-true REQ event while CONT remains true.
4. Confirm the outgoing payload in the packet capture.
5. Confirm that the captured bytes equal the known-valid message.
6. Confirm that the PC application recognizes and acts on the message.
7. Repeat with a second valid message to rule out a stale display or cached value.

Check 6: Expect two distinct PLC-to-PC payloads, two byte-for-byte valid messages, no latched ERROR, and two corresponding client application results.

Frequently Asked Questions