Troubleshooting Industrial Networks
A layered method, symptom tables for serial, Modbus and Ethernet faults, diagnostics and a commissioning checklist.
On this page
- A method that works
- Troubleshooting by layer
- Serial and Modbus RTU faults
- Modbus problems that are not the wiring
- Ethernet and IP faults
- EtherNet/IP, PROFINET, OPC UA and MQTT faults
- Reading diagnostic counters
- What noise looks like
- Worked case studies
- Commissioning and acceptance checklist
- Documentation and baselines
- FAQ
A method that works
Communication faults feel mysterious because nothing visibly moves: there is no smoke, no noise, only a device that does not answer. The cure is a method, because a network is a stack of layers and the fault is always at one of them. Work from the bottom up, prove each layer before the next, change one thing at a time, and write down what you did.
- 1. Define the symptom precisely. Which device, which link, since when, what changed? Does it fail completely, intermittently, or only under load?
- 2. Look before you touch. Link lights, device fault LEDs, controller status and the diagnostic buffer, the alarm list. Record them before you clear anything.
- 3. Check the physical layer. Power, cable, connectors, polarity, termination, shield, port speed and duplex.
- 4. Check the addressing. Address, mask and gateway (Ethernet); station address and baud settings (serial); device name (PROFINET).
- 5. Prove the device on its own. Connect a PC with a master or protocol tool and talk to it directly. If it works, the device and the wiring are good and the fault is in the controller’s settings or program; if it does not, the fault is below.
- 6. Look at the traffic. A sniffer, port counters or a scope shows what really happens: are requests sent, are replies returned, are there errors?
- 7. Check the program and the configuration. Timeouts, retries, register map, scaling, connection status, mapping.
- 8. Fix, test, and record. Verify the cure by repeating the original test; note the cause and the fix in the maintenance log.
Troubleshooting by layer
| Layer | The question | The quick test |
|---|---|---|
| Physical | Is there a signal, of the right size, with the right polarity? | Link LED; meter (idle voltage, termination resistance); cable tester; scope |
| Data link | Are frames arriving intact, from the right address? | Switch port error counters; serial sniffer showing CRC and parity errors; duplicate MAC check |
| Network | Can the two devices reach each other? | ping, arp -a, subnet and gateway check |
| Transport | Is the port open and the connection established? | Port test, firewall log, Wireshark handshake |
| Application | Is the request valid, and is the reply what the program expects? | Protocol tool, decoded packets, register map |
| Program | Does the controller use the data correctly? | Watch table, connection status bits, timeouts, scan time |
Serial and Modbus RTU faults
| Symptom | Likely causes | First check |
|---|---|---|
| No bytes at all | Cable open, wrong port, master not polling, A/B not connected, the device not powered | A meter on the line during a poll; the PC loopback test; the master’s status |
| Request seen, no response | Wrong slave address, baud rate or parity; A/B swapped; slave off; the slave ignoring a frame with a bad CRC | Compare settings; swap A and B; try another address; connect the slave alone to a PC |
| Garbage characters | Baud rate, data bits or parity mismatch; wrong voltage level (TTL on an RS-232 port) | Set the PC to match and scan the baud rates; check the adapter type |
| Works for a while, then stops | Ground loop, noise from a drive, loose terminal, a connector that heats and expands | Trend errors; check shield bonding and routing; wiggle the cable and watch |
| Works with a short cable, not a long one | Missing termination or bias; too high a baud rate; a stub or a star | Terminate both ends, bias once, lower the baud rate, remove stubs |
| One device fails, others work | Wrong address, long stub, bad connector, faulty transceiver, a termination switch left on at a middle device | Test it alone with a PC; check its terminator and address switches |
| Everything stops when one device is connected | That device’s driver stuck on, the same address as another, two masters | Disconnect devices one at a time until it recovers |
| Random CRC errors | Noise, reflections, bad grounding | Scope for ringing and spikes; separate from drive cables; use shielded pair; add isolation |
| Values wrong but communication fine | Address off by one, scaling, word order, signed against unsigned | Compare to the device display; try the neighboring register |
| PLC shows a fault, PC works | PLC port settings or program, a timeout too short, wrong protocol selected | Compare the PLC port settings with those that worked on the PC |
| Works at 9 600 baud, fails at 38 400 | Cable too long or the wrong type; a slow adapter or a slow slave turnaround | Run at the lower speed, or improve the cable and terminators |
Worked example: how far off can the baud rate be?
- A serial receiver finds the start bit, then samples each following bit in the middle of its time. Over a character of 10 bits the sample point drifts by the baud-rate error times the number of bits; if it drifts by half a bit by the stop bit, the sample is wrong. Half a bit over 9.5 bits is about 5.3 percent, so the total mismatch between the two ends must stay under about 5 percent (in practice keep it under 2 to 3 percent).
- A receiver set to 19 200 baud reading a sender at 9 600 baud sees each bit as half as long: the sender’s single bits look like two bits. Typical symptom: characters arrive shifted, doubled or as framing errors. The ratio is 2 to 1: a clue that it is a baud-rate and not a parity fault.
- A parity mismatch shows the same bytes but with parity errors; an 8-bit against 7-bit mismatch shows the high bit stuck or missing.
Modbus problems that are not the wiring
| Symptom | Cause | Fix |
|---|---|---|
| Exception 02 on a read | Register does not exist: off by one, wrong table, wrong start address | Check the manual’s address base; try 40001 as 0 and as 1 |
| Exception 01 | Function not supported by that device or register | Use 03 for holding registers, 04 for input registers |
| Exception 03 | The quantity is too large or the value is out of range | Read fewer registers per request; check the allowed range |
| A float shows 0 or 1E+38 | Word or byte order wrong | Swap the registers; check with a known value |
| A number goes to 65 535 instead of −1 | Signed against unsigned | Read as INT16 |
| A value is 10 times too big or small | Scale factor not applied | Divide by the device scale |
| Occasional timeout on a slow device | Timeout shorter than the device’s worst reply time | Raise the timeout; reduce the poll rate |
| A write does nothing | Register is read-only, the device is in local control, or write protect is on | Check the mode and the register access in the manual |
| A write works but reverts | The program writes the old value every scan | Write only on change |
| Through a gateway nothing answers | Unit ID not equal to the slave address; serial settings in the gateway differ | Check the gateway’s mapping |
Ethernet and IP faults
| Symptom | Likely cause | Test and fix |
|---|---|---|
| No link light | Cable, port off, speed or duplex mismatch, no power | Another cable; another port; set both ends to auto |
| Link, but ping fails | Wrong subnet, duplicate IP, wrong VLAN, firewall | ipconfig and mask; arp -a; VLAN on the port; try from the same switch |
| Ping works, software cannot connect | Wrong protocol port, firewall, wrong driver or node number, PUT/GET off | Port test; check the protocol settings |
| Ping works for a while, then drops | Duplicate IP, a loose connector, an overloaded switch, a spanning-tree change | Continuous ping while moving the cable; switch log; arp for two MACs |
| Device found by one PC but not another | Different subnet or VLAN, a laptop with several adapters, a firewall on the PC | Compare IP settings; disable other adapters |
| Errors only at 100 Mbit/s or 1 Gbit/s | A damaged pair; a cable too long or the wrong category | Certify the cable; replace |
| Network slow; many devices drop | A broadcast storm from a loop, a faulty device flooding the network, multicast flooding | Switch counters; unplug segments; enable spanning tree, storm control, IGMP snooping |
| Intermittent faults after a power cut | DHCP or BOOTP addresses changed, switches boot slower than the controller | Use static addresses; adjust start-up delays |
| Works on the bench, not on the machine | Noise, grounding, cable routing, a different switch | Reroute cable; check shield bonding; test with a short cable |
EtherNet/IP, PROFINET, OPC UA and MQTT faults
| Network | Symptom | Cause and fix |
|---|---|---|
| EtherNet/IP | Module shows a yellow triangle or “connection failure” | Wrong IP, wrong EDS or electronic keying mismatch, wrong assembly sizes, RPI too fast; read the module fault code |
| EtherNet/IP | I/O drops now and then | RPI too short for the network or CPU, multicast flooding, a poor cable; check connection counters |
| PROFINET | Device not found; BF or SF LED on | Name mismatch; DCP blocked; wrong topology (a neighbor check); reassign the name |
| PROFINET | Device fault after replacing a unit | The new device has no name; assign it, or use a controller with automatic name assignment by topology |
| OPC UA | BadSecurityChecksFailed, BadCertificateUntrusted | Trust the client’s certificate in the server; check dates |
| OPC UA | Bad quality values | The source is offline or the user lacks rights; read the status code |
| MQTT | Client keeps reconnecting | Two clients with the same client ID; wrong credentials; keep-alive shorter than the network latency |
| MQTT | Subscriber gets nothing | Topic spelling or case; wildcard; ACL |
Reading diagnostic counters
Switches, drives and PLCs keep counters of what has happened on each port. A single glance at a managed switch often shows where the trouble is. Read the counters, clear them, wait, and read them again: it is the change that matters, not the old total.
| Counter | Meaning | What a rising count suggests |
|---|---|---|
| CRC / FCS errors | Frames received with a failed check | A bad cable, connector or noise on that link; a duplex mismatch |
| Alignment errors, runts, fragments | Damaged or truncated frames | Collisions (duplex mismatch), bad cable or a faulty port |
| Giants, oversize | Frames larger than allowed | A VLAN tag or jumbo frame mismatch |
| Late collisions | Collisions after the first 64 bytes | Duplex mismatch, a cable too long, a hub |
| Input drops, discards, overruns | The port had no buffer space | Overload: too much traffic or a broadcast storm |
| Output drops | The switch dropped frames to send | An uplink too slow for the traffic |
| Broadcast and multicast counts | Frames to everyone or to a group | A very high number means a storm or unfiltered multicast |
| Link flaps | The link went down and up | A loose connector, a failing cable, a powered-down device |
| Spanning-tree topology changes | The loop-protection protocol reacted | A port flapping, a device added or removed |
| Serial frame, parity, overrun errors (in a PLC or drive) | Characters failed the checks | Baud or parity mismatch; noise; a master that sends too fast |
| Modbus slave: bus message count, CRC error count, exception count (function 8) | The slave’s own tally | The error count rising while the master is fine means noise at the slave |
Worked example: is that error rate serious?
- A switch port has received 1 000 000 packets and counted 120 CRC errors: 0.012 percent, or 1 in 8 333.
- On a healthy cable the CRC error count stays at zero for months; anything that rises steadily is a fault. At this rate, a device that sends 1 000 frames a second loses about 0.1 per second, which TCP hides by retransmission but real-time protocols (EtherNet/IP I/O, PROFINET RT) show as dropped updates.
- A ping run of 100 packets with 97 replies is 3 percent loss: a healthy link loses none. Run it for a longer time and move the cable to find the cause.
- The rule: zero errors is the target; a few after a cable has been plugged in are normal, but they must stop rising.
What noise looks like
| What the scope shows | Cause | Cure |
|---|---|---|
| Overshoot and ringing after each edge | A missing terminator, a long stub, a star | Terminate both ends; remove or shorten stubs |
| Slow, rounded edges | Too much capacitance: a long cable or many nodes at too high a speed | Lower the baud rate; use a better cable; add a repeater |
| Spikes between and on the bits | Noise from a drive or a contactor | Reroute; improve the shield bonding; add isolation and ferrites |
| Signal sits at a mid level when idle | No bias | Add bias at one point |
| Low amplitude | Too many terminators, a driver weak or loaded, a long cable | Remove extra terminators; check the driver; repeater |
| Signal with an offset that moves | A ground potential difference | Bond the panels or isolate |
| Overlapping signals, doubled amplitude | Two devices transmitting at once: two masters or a driver stuck on | Remove the second master; find the stuck driver |
Worked case studies
Case 1: ten meters, one dead, and the whole line slows down
- Symptom: a Modbus RTU line of ten meters at 9 600 baud (8E1) normally refreshes about every half second; since Tuesday the data is nearly twice as old and a stale-data alarm fires.
- Normal cycle: one transaction takes 50.8 ms (request 8 + response 25 characters, two gaps, 5 ms for the slave), so ten take 508 ms.
- One slave has died. The master sends its request, waits the timeout of 100 ms, and retries 3 times: 4 × (9.2 ms request + 100 ms) = 437 ms for that one device.
- New cycle: 9 × 50.8 + 437 = 894 ms: the line is 1.8 times slower because of one dead device.
- Fix: repair or replace the dead meter, and change the program to skip a failed slave for several cycles (retry it every 10 to 30 seconds) and to raise an alarm for that device, so that one failure does not slow the others.
Case 2: the HMI that drops out
- Symptom: an HMI at 192.168.10.20 loses its PLC every few minutes. Ping to the PLC works between the dropouts.
- Check:
arp -aon the laptop shows two different MAC addresses seen for 192.168.10.20 over a few minutes: another device has the same address. - Cause: a laptop of a service engineer was set to 192.168.10.20 and sometimes connected to the machine switch.
- Fix: change the laptop address, keep an address list, and keep the DHCP range and the static range apart. Enable port security if it keeps happening.
Case 3: the replaced drive that will not join
- Symptom: after replacing a drive on a PROFINET network, the controller shows the device as missing and the drive’s BF LED flashes.
- Check: the new drive has no device name (or the factory default). The controller finds devices by name.
- Fix: assign the project’s device name with the engineering tool or PRONETA, power-cycle the drive, and the controller assigns the IP address at start-up. In future, enable name assignment by topology (neighbor detection) so that a replacement gets its name automatically.
Case 4: errors that follow the production schedule
- Symptom: RS-485 CRC errors appear only when a conveyor drive runs at high speed.
- Check: a scope on the pair shows spikes in step with the drive’s switching. The communication cable runs beside the motor cable for 8 m in the same tray.
- Fix: move the communication cable to a separate tray at least 200 mm away, bond the motor-cable shield at both ends, add isolation at the master. The errors stop.
- Lesson: intermittent communication faults correlate with something else in the plant; look for what changes when the fault appears.
Commissioning and acceptance checklist
| Step | Check | Record |
|---|---|---|
| 1. Cables | Every cable tested (continuity, certification where required); terminators and shields checked | Test report |
| 2. Addresses | Every IP, station address and device name set and unique | Address list |
| 3. Links | Link lights on; speed and duplex correct; no errors on ports after an hour | Counter screenshots |
| 4. Each device | Reached from the controller; the data correct against the device display | I/O or register check list |
| 5. Failure behavior | Unplug each device: the alarm appears and the machine goes to the planned state; plug in: it recovers without help | Test log |
| 6. Redundancy | Break a ring link: recovery time within the limit; restore | Recovery time |
| 7. Load | The busiest moment of the machine: cycle times and counters acceptable | Cycle time, load figures |
| 8. Security | Unused ports closed; passwords changed; firewall rules checked | Security checklist |
| 9. Backups | Controller, HMI, drives, switches and firewalls saved | Backup list |
| 10. Handover | As-built diagrams, address list, parameters and procedures delivered; staff briefed | Signed handover |
Documentation and baselines
A fault is much easier to find when you know what normal looked like. When the system is working, record a baseline: the cycle time of each network, the load on each uplink, the error counters, a screenshot of the device list, a packet capture of a normal minute, and the voltage and resistance readings on the serial buses. Store them with the drawings.
| Document | Contents |
|---|---|
| Network diagram | Switches, links, speeds, VLANs, rings, firewalls |
| Address list | IP, mask, gateway, MAC, name, unit ID, protocol and port, owner |
| Serial settings table | Baud rate, data bits, parity, stop bits, station address, register-map reference |
| Register maps and tag lists | What each register or tag is, its type, scale and unit |
| Device files | EDS, GSD, ESI and IODD files and firmware versions |
| Switch and firewall configurations | Exported files with the date |
| Baseline measurements | Counters, loads, capture files, scope screenshots |
| Fault log | Date, symptom, cause, fix, who |
Related
- Industrial Communication: the overview of this guide.
- Sniffers, Analyzers and Serial Tools: the tools used in this method.
- Serial Communication: RS-232, RS-422 and RS-485, Modbus RTU, ASCII and TCP and Industrial Ethernet: EtherNet/IP, PROFINET and EtherCAT: the detail behind each fault.
- Cabling, Grounding and Noise: cable tests and noise.
- PLC Troubleshooting, Safety and Documentation: the controller side of fault finding.
- Modbus Frame and CRC Calculator.
FAQ
Where do I start when a device does not answer?
Check the link lights and power, then prove the device with a PC and a protocol tool. If the PC works, the fault is in the controller’s settings or program; if not, work down through addressing, cabling and the device itself.
How do I tell a wiring fault from a settings fault?
Wiring faults give no activity or random errors; settings mismatches give consistent garbage (baud) or a consistent silence (address). A loopback test and a meter reading separate them in a few minutes.
Why does the problem come and go?
Intermittent faults are usually physical (a loose connector, noise from a drive, a ground difference) or a duplicate address. Look for what else changes at the same time and log the counters.
Is it safe to plug a laptop into a running network?
Only with permission and care. A laptop with a wrong IP can cause a duplicate address, and a sniffer must never transmit. Use an isolated adapter, read only, and follow the plant’s rules.
What tools should a technician carry?
A multimeter, a cable tester, a USB-RS485 and a USB-RS232 adapter, a laptop with a terminal, a Modbus tool and Wireshark, loopback plugs, spare patch cords and terminators, and the address list.
References
- IEC 61918, Industrial communication networks: Installation of communication networks in industrial premises; IEC 61784-5 (installation profiles).
- PROFIBUS & PROFINET International, PROFINET Commissioning Guideline and PROFIBUS Commissioning Guideline.
- ODVA, EtherNet/IP Network Troubleshooting notes; Rockwell Automation, Troubleshooting EtherNet/IP Networks.
- Modbus Organization, MODBUS over Serial Line Specification and Implementation Guide V1.02 (diagnostic functions and counters).
- Wireshark Foundation, Wireshark User’s Guide.
Last reviewed: October 2026. Speeds, lengths, node counts and menu names are typical: confirm against the specification and the manufacturer’s documentation for the devices you use.