Network problems become manageable when you troubleshoot from physical condition upward through configuration and application.
SURVIVAL RULE: Start with power, cable, connector, and link before software.
Start at the physical layer
Communication faults feel abstract, so technicians often jump into IP settings or PLC configuration. Begin with power, connector seating, cable damage, link LEDs, switch-port state, and physical route. A device with no power cannot communicate, and a damaged cable cannot be repaired by software.
If one remote I/O station drops out after a washdown, inspect the field connector and power before changing controller network settings. Moisture at one connector is more likely than a plant-wide protocol problem.
Field habit: Ask: Is the device powered? Does the port have link? Does the fault follow a cable or port?
Common trap: Do not restart every switch or controller as a first diagnostic step; that erases evidence and can create a bigger outage.
Addressing errors have patterns
Duplicate IP addresses, wrong subnet settings, wrong device names, replaced devices with default addresses, and incorrect topology can produce predictable failures. Determine whether the device is completely missing, intermittently disconnecting, or communicating with the wrong identity.
A replacement Ethernet device may power up and show link but remain unavailable because its configured address or name was not restored. Two devices with the same address may work unpredictably as network tables change.
Field habit: Record the original device identity before replacement and follow the approved commissioning procedure.
Common trap: Do not guess an unused address on a production network.
Quick check
What should be true at this point in the sequence?
What evidence can prove or eliminate this section of the system?
What changed recently or only under the failing condition?
Use diagnostics to localize scope
Controller diagnostics, managed switches, device web pages, and network tools can show whether a fault affects one node, one port, one segment, or many devices. Scope is one of the strongest clues. If several devices behind one switch disappear together, the shared infrastructure deserves attention.
If only one axis drive faults communication but neighbors on the same switch remain stable, local cable, connector, device power, or device health is more likely than the uplink.
Field habit: Draw a quick topology and mark healthy versus failed nodes.
Common trap: Do not confuse correlation with cause; a red network LED still requires a physical or configuration explanation.
Intermittent communication requires timestamps
Network dropouts often last seconds and recover before you reach the cabinet. Capture exact timestamps from HMI alarms, controller logs, switch events, and operator reports. Then compare those times with power events, machine motion, cable flexing, and other faults.
A cable inside a robot dress pack may lose link only at one arm position. The network log gives the time; the machine position provides the physical cause.
Field habit: Synchronize clocks where practical and preserve logs before rebooting devices.
Common trap: Do not dismiss a recovered network fault as ‘just a glitch.’ Repeated glitches usually have a repeatable condition.
Quick check
What should be true at this point in the sequence?
What evidence can prove or eliminate this section of the system?
What changed recently or only under the failing condition?
Field Exercise
Sketch the network path from a controller to one remote device, including every switch or connector you can identify.