The line trips, the HMI throws a red comms banner, and the controller shows a module fault. Everybody's first instinct is to swap a switch or re-pull a cable. Nine times out of ten that's the wrong first move, because the network already wrote down what happened and nobody read it. This is my field method for chasing comms dropouts across the mix of protocols you actually find on a floor, EtherNet/IP, Modbus TCP, PROFINET, PROFIBUS, DeviceNet, starting with the checks that cost nothing and keep you out of an energized panel until you have a reason to open one.
I write this vendor-neutral on purpose. I see it across manufacturing lines and organics and digester sites alike, on jobs where the network was built by one integrator, the drives by another, and the field devices got added over five years by three different hands. That handoff is where the ghosts live. A quick definition: EtherNet/IP is the CIP-over-Ethernet protocol Allen-Bradley/Rockwell and others use, and it isn't the same thing as generic office Ethernet even though it rides the same copper and fiber.
Read the evidence before you touch anything
The single habit that separates a twenty-minute fix from a two-shift outage is reading the controller's comms fault bits and the managed switch's port statistics before you swap any hardware. The network keeps counters, and those counters are your black box recorder. On the controller, pull the module fault codes and connection status for each I/O and device connection; on a Rockwell ControlLogix that's the module properties Connection tab and the controller fault log, on a Siemens S7 it's the diagnostic buffer, and get the timestamp of the fault, not just that it faulted.
Nine times out of ten, swapping a switch or re-pulling a cable is the wrong first move, because the network already wrote down what happened and nobody read it.
On the managed switch, pull per-port statistics: CRC and alignment errors climbing on one port point at a physical or noise problem on that run, in/out errors and collisions matter too (collisions on a full-duplex link mean a duplex mismatch), and link flap count with its last-flap timestamp tells you exactly where to look, a port that's flapped four hundred times since Monday is telling you something. Line up the controller fault timestamp against the switch flap timestamp against the drive event log; when the logs agree on a time, you've found your segment before touching a screwdriver. Write the counters down with the time you read them, then read them again later, because a counter is only useful as a rate: five hundred CRC errors becoming nine hundred in ten minutes while the mixer VFD ran means everything.
What has to wait for hands-on work
Everything above is read-only from an operator terminal or a laptop on a mirror port, so do that work first. Once the trail leads to reseating a connector or ringing out a cable, the hazard changes: panels carry 120/240/480VAC and arc flash is real, so follow your site's electrical safety program, correct PPE, and a verified zero-energy state with LOTO. A VFD holds a charged DC bus after power-down, so wait the stated discharge time and verify it's below the safe threshold before you touch bus terminals, and any pump, mixer, or fan on the far end of that I/O drop needs to be at verified zero energy too, because a comms fault that unexpectedly re-establishes can command a start. If any part of the network passes through a biogas or digester area or any permit-required confined space, none of the pop-the-cover-and-reseat-it advice applies without the full permit process first.
Start at the physical layer. It's the highest-probability, lowest-cost place to look
Follow the specific run that faulted end to end, the patch cable at the switch, the field cable through the raceway, the connector at the device, because the field cable takes the abuse: crushed in a tray, pinched by a panel door, baked against a hot pipe. RJ45 in a control panel is a liability, the latch breaks and the crimp backs out, which is why field devices mostly use M12 instead; a loose M12 ring, finger-snug rather than properly torqued, is the single most common intermittent I find on packaging and process skids. Watch two limits people blow past: bend radius (kinking a cable tighter than roughly four times its outside diameter wrecks the impedance) and run length (copper Ethernet is a 100-meter channel limit, patch cords included; I've seen 140-meter runs that "worked" until summer heat pushed the margin over the edge). A run that shares a raceway with power or lives next to big drives is a candidate for fiber, since glass is immune to the noise in the next section. And in a harsh plant, check for green or white powder on contacts or water beaded inside a connector boot; a connector that ohms out fine on a dry morning can fault every afternoon.
Electrical noise and grounding get blamed last and cause the most maddening intermittents
A VFD switches its output at high frequency to synthesize the motor waveform, and that switching radiates and couples onto anything running parallel and close, including your data cable. The tell is error counters that climb only when a specific drive runs, specifically loaded or ramping; idle plant, clean counters, start the big drive, CRC errors march. Fix it in order. Separation first: get data cable out of the same tray as drive output cabling, a common rule of thumb is 8 to 12 inches on parallel runs, crossing at 90 degrees where they must meet. Shield grounding second, and the scheme depends on the protocol: high-speed industrial Ethernet and PROFIBUS are normally bonded at both ends with a full circumferential connection to chassis, while DeviceNet grounds the drain at a single point, and the trap is a ground-potential difference between two bonded ends driving current down the shield on a long inter-building run. Drive-side hygiene third, proper shielded VFD cable bonded 360 degrees at both ends, line reactors where specified, a solid drive ground; a drive noisy on the network is often grounded poorly at the motor. Change one thing at a time and re-read the counters after each, or you'll never know which one mattered.
The switch itself, and two faults that get misdiagnosed constantly
An unmanaged switch is a black box on a plant network, a place faults go to hide, which is the whole argument for managed switches: they give you the port counters this method depends on. Auto-negotiation and duplex mismatch is one of the most common and most misdiagnosed faults there is. If one end auto-negotiates and the other is forced to a fixed speed and duplex, auto-neg fails to detect duplex and defaults to half, and now you've got full-duplex on one end and half on the other. It works fine at low traffic and falls apart under load with late collisions and CRC errors that look exactly like a bad cable. The rule is simple: either both ends auto or both ends hard-set identically, never mixed, and the switch port stats will show you the negotiated speed and duplex on each side.
Many plant networks also run a redundant ring, DLR on EtherNet/IP or MRP on PROFINET, meant to heal in milliseconds when one link breaks, but a ring broken in two places can't heal, and one that healed silently around a real fault leaves you one break from an outage with no warning; check the ring status object, because a "working" plant on a broken ring is a time bomb. EtherNet/IP also delivers its I/O data as multicast by default, so without IGMP snooping enabled on the managed switches, a busy network can flood multicast to every port and saturate links and CPUs, causing timeouts across unrelated devices. If a whole segment drops connections intermittently and no single cable is the culprit, check IGMP snooping and the querier before anything else.
Once physical, noise, and switch are clean, look at the protocol configuration
EtherNet/IP declares a connection timeout after a multiple of the RPI, the requested packet interval, passes with no packet, commonly four times RPI, so an RPI set too aggressively for the network and CPU load produces connection timeouts under load even though nothing's actually broken; loosening a too-tight RPI often clears load-related timeouts. Modbus TCP faults are usually address or timing, the classic off-by-one between 0-based and 1-based registers, or a master's timeout shorter than a loaded slave actually takes to answer. PROFINET rides Ethernet plus device naming, so a duplicated or missing device name after a swap drops that device, and the diagnostic buffer names the offending station. PROFIBUS is an RS-485 multidrop bus terminated at exactly both physical ends and nowhere else, every station on a unique address and the same baud; one wrong address or bad terminator can take down the whole segment. DeviceNet is CAN-based with the same discipline, every node at the same baud and exactly two 120-ohm terminating resistors at the trunk ends.
Isolate by segment, and always correlate with load
When the logs point at a region but not a device, bisect it: disconnect half the devices, or open a managed switch's ports in groups, and see if the fault clears, then halve again. On a ring, open it deliberately at a known point to force traffic one way and localize the problem. Re-read counters at each split; you're converging on the one run or node that's dirty with data instead of a box of spare parts. And always test under real load, since bench-testing a suspect run in a quiet plant proves nothing if the fault only appears with a drive running and the line at full rate. If the dropout won't reproduce on demand no matter how you poke at it, the capture method looks more like the fault that only happens on Tuesdays than a straight port-counter read, and it's worth reading both together.
Comms dropouts are where an independent second look earns its keep, because these faults usually live in the seam between vendors, the drive integrator's cable tray crossing the network integrator's data run, with field devices added later by a third crew. Each vendor's gear checks out fine on its own bench. The fault is in the handoff, and the record, counters, timestamps, one change at a time, is what finally pins it.
The printable field version of this guide, with the full symptom-to-cause reference table across all five protocols, is free in the resources library. If your network keeps dropping and nobody can agree whose problem it is, get in touch, send me the port-error counts, and we'll trace it together.