What Happens When a PLC Misses a Packet?

In industrial automation, Programmable Logic Controllers (PLCs) are the central processing units for calculations that require precise, error-free data transfer to support determinism. A packet not received during the data transmission of process variables is considered a serious nondeterministic event. This has consequences beyond an incident and extends through a technological chain of effects on scan cycles, control, and networks. These consequences are dependent on protocol, programming, and processes, and hence require in-depth knowledge.

Detection Mechanisms & Root Causes

A PLC finds missing data via mechanisms integrated into its communication stack and application logic. Industrial networks built on standard Ethernet, such as EtherNet/IP or Profinet, have integrated sequence numbering, timestamping, or heartbeat signals into their frame structure. The PLC looks for these integrated signals, and a missing sequence or the expiry of the periodic “heartbeat” packet triggers the missing packet detection algorithm. Sophisticated PLCs employ producer/consumer or publisher/subscriber architectures, with connection-status flags integrated into data tags that flip on communication failures.

Causes of a PLC missing a packet can be very complex. One key factor in a network that causes a PLC to miss a packet is network congestion, which is even more common when real-time PLC and information technology data are carried simultaneously over shared network infrastructure. Another possibility for a PLC missing a packet of data is a switch buffer overflow during peak network activity, in a scenario where a network switch is used. Another reason could be hardware problems, such as EMI at the physical layer of a network and corrosion of network connectors. Another possibility is resource bottlenecks in a PLC, with its CPU taking longer to process network interruptions due to heavy workload in a real-time network environment.

Protocol-Determined Response Frameworks

The reaction to this in a PLC is primarily determined by the transport protocol and the industry-standard application-layer rules.

In TCP-based protocols, such as Modbus TCP, a connection-oriented conversation is established between the PLC and the receiving device. In a connection-oriented protocol, reliability is guaranteed via ACK and retransmits. The TCP stack detects the loss (missing sequence data) and retransmits after a timeout. The packet will be resent when a timeout occurs. The process will be nondeterministic, and its latency will be higher. In a PLC control loop, the process will exceed the scan time, causing a process watchdog error, or the PLC will continue processing outdated information.

With UDP-style and “real-time” communications (such as Profinet RT and possibly some EtherNet/IP cyclic transfers), a different model applies. These are optimized for speed and predictability, though reliability is optional. For a missed UDP packet, no retransmission occurs on the transport layer. There has to be an instantaneous response from the PLC at the application layer. This typically occurs through data substitution. Thus, a “hold-last-state” strategy occurs when the PLC freezes the related variable in its last known good condition. A safe default value, already preconfigured by the user, replaces the lost data. Also, the PLC increments internal debug counters. Again, this gives a silent record of the occurrence that can be evaluated post-event. High-speed “real-time” networks, such as Profinet IRT or EtherCAT systems, counter this phenomenon. These use time-switching to eliminate contention in their networks.

Direct Impact on PLC Scan Cycle and Logic Fidelity

The PLC scan cycle, a continually repeating process of reading input values, applying logic, and writing to outputs, is directly impacted. The PLC recognizes a missing packet and, to continue processing, must resolve the missing information.

In the case of discrete/digital signals, the effect can be dramatic. Think about the case where the registration sensor signals the presence of the part, but it is missed. In this case, the input image table is not updated, which affects the ladder logic program that validates the registration sensor. This program relies on the previous cycle’s data, causing the activation of the diverter arm to be mistimed and potentially damaging the product or causing jams. Programmers counter this problem for critical signals using hardware interrupts or direct read instructions that don’t normally allow an input image table to be updated.

For analog process variables, the issue is with control algorithms. In a PID loop that depends on a network temperature value, it will compute its output based on incorrect information. If a PLC has a hold-last-state, there may be incorrect integration within a PID due to a constant value of a static error. “Bad value” status propagation represents more advanced function block capabilities to pause or switch a PID to manual control. This requires programming. The PLC also spends scan time running communication fault routines. These routines set the alarm bits, record events, and can trigger shutdown events in the process under control. This processing overhead, though required, marginally increases the scan time, which could impact other tasks running under the PLC.

System-Wide Cascading & Diagnostic Implications

A lost packet is seldom an isolated event on the PLC. It can cause system instability by triggering responses on the PLC.

Cascade Effects on the Network

Attempts to retransmit messages (in TCP networking) and the burst transmissions of diagnostic messages sent by the PLC will increase the overall network load. If it were a congestion loss that occurred initially, this would worsen the situation and cause other packets to be lost. The overall situation will cause the PLCs to lose sessions with the I/O clusters, forcing a restart.

Distributed Coordination Failure

In multi-PLC systems where coordinated motions are performed, a lost synchronization packet may cause a loss of synchronization across entire sections of a machine. One PLC may shut down while another keeps running, and if the system isn’t set up for coordinated shutdown logic, safety interlocks, or torque monitoring, mechanical collisions can occur. This may be resolved only through human interaction.

Corruption of Supervisory System Data

Data requested for operations from the supervisory system (e.g., SCADA or MES) or from the data historian will be invalid or stale. The consequences of supervisory system data corruption may range from invalid production information to erroneous decisions. The “bad data” can travel well beyond the immediate cell.

As for diagnostics, the tools available today are quite elaborate. Web-enabled PLCs likely include pages showing packet error counts, connection status, and a graphical representation of cycle times. The critical parameters that could trigger alarms through SNMP traps, notifying network administrators, include non-zero values of “discarded packets” or “CRC errors” on switch ports carrying signals from PLCs. High, continuous values may indicate problems such as noise or duplex mismatches, while occasional high values may indicate cable tension or electrical noise.

Mitigation through Design and Programming

There is resilience designed against packet loss, achieved through layered defenses.

Network Infrastructure Design

The most important protection is network or physical segmentation. Having a separate switch fabric dedicated solely to PLC real-time I/O communication is most desirable. However, if network convergence is required, very tight Quality of Service (QoS) requirements must assure priority of PLC protocol traffic. Network switches should be designed with large buffer capacities and port-based traffic shaping to assure proper protection of PLC data streams. Redundant network configurations, such as ring networks (MRP networks) or double paths (such as PRP networks), assure physical path redundancy, allowing PLC communication even if only one network cable is operational.

Protocol and Hardware Selection

Deterministic protocols suited to the application must be chosen. In applications with high-speed motion, protocols that include a scheduling function (Profinet IRT, EtherCAT) should be chosen. In applications that are less time-critical, the diagnostic function becomes essential, and protocols with that function, such as EtherNet/IP with explicit messaging, may meet the application requirement.

Hardware selection

Hardware for media redundancy should ideally include PLCs and I/Os with dual, independent Ethernet ports to ensure seamless media redundancy.

Defensive PLC Programming

The software within the PLC is the last line of defense. Robust programs include the following:

• Heartbeat: Using timer instructions to track the toggling of a bit received remotely. A timeout causes a controlled fault.
• Data Validation: Validate an analog value signal on plausibility and rate of change before using it within control logic.
• Graceful Degradation Logic: Coding alternative, safer control logic that is enabled when a communication fault is detected. E.g., the drive control, which is performed via the network, reverts to the local speed setpoint if the command packet stream is lost.
• Staggered Reconnection: After a failure, it must be ensured that all devices reconnect at the same time to a network that has just recovered and that could thus become flooded by reconnecting devices.

In this method, PLC packet loss serves as a stress test of the control system’s robustness. The process triggers a series of subsequent criteria—a replacement of data values, a distortion of decision logic, and a possible negative impact on a network. The impact’s magnitude depends on a physical process’ latency sensitivity and a control system’s design. In this case, it means a technology challenge is not to make the network ideal, which is unrealistic, but to design a PLC’s environment to cope with, react to, and recover from packet loss in a predictable and safe way. That’s what a contemporary PLC’s reliability means.

Final Thoughts

No industrial network is perfect, and good control systems assume that. The difference between a resilient system and a fragile one comes down to how packet loss is handled across the PLC, network, and the program itself. If you’re evaluating PLCs, industrial switches, or redundant network hardware and want to design it for resilience, we can help you choose components that fit your application and its risks. Get in touch with our team, and we can help strengthen your industrial network with parts from leading brands. If your faulty PLCs are causing you trouble, no problem! Send it in to be repaired or replaced by our group of skilled technicians. If you would like to learn more about industrial networks, we have a blog comparing the Stratix 5900 to industrial routers here.