A computer connects to a PLC and the link light stays on, yet reading parameters occasionally pauses. A moment later it resumes, apparently without losing data. The device may not be processing slowly: TCP may be filling a gap. TCP is a transport mechanism used by many supervisory computers, gateways and controllers. It works to deliver a stream of bytes in order. This guide follows those bytes without mathematical derivations: who keeps the records, who waits, and why eventually receiving the data can still affect a production cycle.
1. The network carries data; the endpoints retransmit it
The supervisory computer passes data to its TCP implementation, then through its network interface and industrial switches to the PLC. A switch normally forwards Ethernet frames using Ethernet addresses. It does not acknowledge every byte on behalf of that TCP connection. The communication endpoints retain transmission records, process acknowledgments and decide when to retransmit. If a gateway terminates a connection and starts another, analyze the two connections separately rather than treating the whole route as one undivided channel.
Think of TCP as a continuous manuscript with numbered positions. Transport can divide it into packages of different sizes, but the recipient should ultimately obtain the contents in the right order. This analogy explains numbering and gap repair only. TCP does not understand the manuscript: it cannot tell whether the bytes represent a temperature, a parameter file or a start command. The application must decide whether that information is valid.
2. Sequence and acknowledgment numbers count bytes, not packages
For an easy example, an established connection sends three data segments containing bytes 1001–1100, 1101–1200 and 1201–1300. These numbers are illustrative; real connections do not have a fixed initial sequence number. SEQ identifies the starting sequence number of the data in a segment. ACK identifies the next byte the receiver expects in the continuous stream. After the first segment arrives, an acknowledgment can point to 1101, confirming the preceding continuous contents.
If the second segment is missing but the third arrives, the receiver can typically buffer the later data while its cumulative acknowledgment stays at 1101. Seeing byte 1300 is different from having all the bytes in between. The acknowledgment can advance once the gap is filled. An ACK is not a packet number, so counting rows in a capture cannot by itself show how much application content is missing.
3. Duplicate acknowledgments and a timer offer different clues
A sender retains data that has not yet been acknowledged. If later data keeps arriving, the receiver may repeatedly report the same acknowledgment number, indicating a gap ahead. In a classic fast retransmit example, three duplicate ACKs trigger retransmission of the missing segment. Modern implementations can also use other loss detection methods. Devices do not all follow one simplified timing diagram exactly.
If there is little traffic, there may not be enough later data to produce those repeated acknowledgments. A retransmission timer may then provide the recovery mechanism. RTO, the retransmission timeout, is the waiting period for acknowledgment. The endpoint considers round-trip delay and its variation rather than using one fixed value for every connection. If the timer expires without the required acknowledgment, it retransmits data; repeated absence of feedback generally lengthens the wait. No particular millisecond value here is a promise about a FCTEL product.
4. Repaired data can still cause a visible pause
Retransmission takes time. A receiver may wait for a gap to be filled before delivering subsequent continuous bytes to its application. Data that has reached a network interface does not necessarily update the display immediately. This is one possible consequence of the transport mechanism. A lit link indicator does not mean application updates are always on time, and one pause does not identify a particular switch port as the cause.
TCP also controls how much data is sent at once according to network conditions. Loss may be treated as a congestion signal, causing the sender to reduce its sending activity. This happens in the endpoint protocol; it does not mean the negotiated port speed has automatically fallen. A connection can temporarily deliver less useful data while the physical link still reports Gigabit speed. Reliable delivery attempts to repair missing data, but does not provide a fixed industrial control deadline.
5. A TCP acknowledgment is not a task completion notice
A TCP ACK confirms the corresponding bytes at the peer TCP receiver. It does not prove that the PLC application has approved a parameter, written it to its destination or completed a motor action. The application protocol often provides its own response, exception code or completion status. Record transport acknowledgment, protocol response and equipment result separately rather than merging their timestamps into one success message.
When overlapping bytes are retransmitted on the same connection, TCP uses sequence numbers to recognize duplicates and normally does not deliver them as new stream contents. An application that times out and sends a command again is creating another application request. TCP cannot decide that two requests mean the same thing. After reconnecting, check request identifiers, execution status and duplicate request rules defined by the application protocol. Repeating action commands indefinitely is not a sound completion strategy.
6. Troubleshoot both directions and correlate application timing
Record the pause time, endpoints, protocol, amount of data and operation. Then examine port error and discard counters, connection logs and captures at both ends. Sending the same byte range again is a useful clue. Also check whether ACKs advance, whether data is reordered, and whether the advertised receive window becomes small or zero. The window describes how much data the receive buffer can accept; it is different from whether a cable is connected.
A capture tool marks a retransmission by interpreting the packets it observed. It has not directly measured a failed component. An overloaded mirror port, capture loss or a late capture start can mislead the analysis. Network interface offloading can also change how segmentation appears in a host capture. Compare records from both sides to distinguish missing outbound data, missing return acknowledgments and packets that the capture simply failed to observe.
If frame check errors rise at the same time, inspect connectors, cabling, shielding and interference. If discards increase with traffic bursts, investigate competing egress traffic and buffering. If only large transfers through routers or tunnels fail, investigate path size limits too. Change one condition at a time and retain before-and-after evidence. Increasing the application timeout alone can hide the symptom without removing transport delays.
Return traffic matters: data may have arrived while its acknowledgment was lost on the way back. Without that acknowledgment, the sender may retransmit and the receiver recognizes the repeated bytes. A repeated transmission therefore does not prove that the first data never reached its destination. Draw outbound and return paths separately and compare receiver records. Otherwise, replacing the cable beside the sender may overlook the actual return path. Test both directions rather than using a single one-way transfer to represent the connection.
7. Verify correct contents and timely, usable results
FCTEL managed industrial switch documentation is a starting point for checking interfaces and management functions. Confirm which counters and logs the actual model, manual and firmware provide. This article describes general TCP behavior. It does not claim that a switch handles TCP for the endpoints or that another vendor’s protocol implementation represents the performance of a particular FCTEL device.
After recovery, verify file or parameter contents, then observe response distributions and exceptions during continuous operation. For action requests, check completion status and repeated-command behavior as well. Use the application deadlines agreed for the site, distinguishing an isolated pause, progressive deterioration and a genuine disconnect. Remember three points: TCP repairs byte gaps, repairs take time, and receiving data must be checked separately from completing a task.
A maintenance report should name the symptom and evidence: which byte ranges repeated during which period, whether application responses were delayed, and whether port counters changed. Simply writing network problem is not enough. Specific records help network, equipment and software teams analyze the same event instead of each declaring its own device healthy. If capture clocks differ, establish their time relationship before combining two unrelated events into a supposed cause.
Technical references: RFC 9293: TCP sequences and acknowledgments; RFC 6298: retransmission timers; RFC 5681: classic fast retransmit and congestion control; Wireshark: TCP analysis; Wireshark: offloading and capture interpretation. Related resources: Technical Articles and FCTEL managed industrial switch documentation (Chinese). Original AI-assisted illustrations show generic principles, not product measurements.
