Communication Troubleshooting: Modbus and PLC Networks

Communication troubleshooting starts by separating an observation from its possible causes. A controller reporting lost I/O, an HMI displaying an old number and a Modbus client returning an exception are different observations. They need different next checks. Replacing a drive or restarting a switch before recording the evidence can make the original condition harder to investigate.

This guide develops a repeatable approach to EtherNet/IP, PROFIBUS and Modbus problems. The addressing and register examples are fictional, read-only learning exercises with declared assumptions. They do not represent a customer incident, a validated plant configuration or a native packet-capture feature of our software. For a broader course route, compare industrial networking training in South Africa.

Start with the symptom, scope and last known good state

Write the actual diagnostic message, equipment identifier and observation time before deciding what failed. Record the software that produced the message and whether its clock is synchronised with the controller or switch. A screenshot saying “offline” without a device name or timestamp has limited value when several systems reconnect at different times.

Establish the scope. Is one value wrong while other values from the same device update? Is one remote station absent while neighbouring stations remain available? Are several unrelated applications reporting losses through a shared path? These questions help identify a useful comparison. They do not prove that the common component is faulty: a shared power source, configuration change or observer can also explain apparently related failures.

Preserve available controller diagnostics, driver logs, switch counters and the current configuration before disruptive changes. There is no universal rule requiring application logs to be read last. A precise configuration rejection may be more informative than starting with a cable replacement. Equally, an obviously damaged connector deserves appropriate physical inspection without an elaborate protocol investigation first.

Use a simple evidence record:

The wider PLC troubleshooting method connects communication evidence with program state, command signals and feedback. Keep those observations separate: the fact that a command reached a controller does not prove that a field device acted on it.

02

Separate physical links, Ethernet paths and application data

A physical link indicator describes a limited interface condition. It does not certify every conductor, the complete route, the correct destination or the meaning of a returned value. Record link transitions and error counters over an identified interval. A cumulative counter of 100 errors without a starting value or duration cannot tell you whether errors are occurring now.

For Ethernet, document the actual ports and logical path as well as the cable drawing. VLAN membership concerns the Ethernet broadcast domain; an IPv4 address and subnet mask concern network-layer addressing. A TCP connection and an application response are further observations. Treating all of these as “layer two” hides the distinction you are trying to diagnose.

Two devices plugged into the same physical switch need not share the same VLAN. Two interfaces with addresses from the same numerical subnet need not have a usable Ethernet path between them. Conversely, hosts in different subnets may communicate through an intended router and permitted services. Successful communication depends on the configured path, not the visual similarity of address labels.

Do not solve an addressing puzzle by casually joining management and control networks. Compare the intended architecture, interface configuration and routing table with the observed path. An isolated training network can use a deliberately simple arrangement; a production change needs the site's normal engineering and change process.

Worked IPv4 subnet example: why the mask matters

Assume a small fictional Ethernet lab with ordinary connected IPv4 routes, no proxy ARP, no unusual host routes and no address translation. Host A is 192.168.10.20/24. Host B is 192.168.10.200/24. The /24 mask is 255.255.255.0, so both addresses belong to network 192.168.10.0/24. Under those assumptions each host treats the other as local.

Now change only B's mask to /25, or 255.255.255.128. A still treats B as local. B belongs to 192.168.10.128/25, while A's address lies in the lower half of that original /24. B therefore treats A as outside its connected subnet. The two endpoints now make different local-versus-remote decisions.

These are address calculations, not connectivity test results. A “Yes” still requires the intended link and permitted communication. A “No” means an appropriate route would be needed under the lab assumptions. It does not mean that changing a mask is automatically the correct repair. The original addressing plan decides which configuration is intended.

The host routing distinction is described in RFC 1122, section 3.3.1. For your worksheet, record both masks, both interfaces and the actual selected route. Looking at only the first three address numbers misses the asymmetric case above.

03

Wireshark ARP filters and the limits of packet visibility

For an authorised capture, first establish where it was taken and which traffic could reach that interface. Promiscuous mode cannot make a switch send unrelated unicast traffic to an ordinary laptop port. A properly configured mirror port or suitable capture arrangement may be required. See Wireshark's Ethernet capture guidance.

For IPv4 ARP frames concerning a lab device at 192.168.10.20, this Wireshark display filter checks sender or target protocol addresses:

arp.src.proto_ipv4 == 192.168.10.20 or arp.dst.proto_ipv4 == 192.168.10.20

These fields are documented in the Wireshark ARP display-filter reference. Display-filter syntax is separate from capture-filter syntax. Do not substitute arp and ip.addr == ...: an ordinary ARP frame does not contain the IPv4 header that the ip.addr field examines.

Suppose the saved lab capture contains three ARP observations. At 10:00:00, sender address .20 is associated with MAC ending 01. At 10:00:05, sender address .20 is associated with MAC ending 02. At 10:00:06, a request asks about .20. The filter includes all three, because it checks both sender and target fields. A sender-only filter would omit the request if its sender address were another host.

The two sender MAC values justify investigating address ownership. They do not, by themselves, establish a malicious device or prove why an application stopped. Compare the inventory, redundancy arrangement, proxy behaviour, recent replacements and capture location. Keep the original frames so another engineer can inspect the interpretation.

Likewise, seeing no requested packet in a capture is meaningful only within that capture's coverage. A management-interface capture may miss control-interface traffic. Overlapping address ranges on a multi-interface machine warrant checking interface selection and routes; the address text alone does not prove that packets were stolen across isolated networks.

Modbus troubleshooting: timeout, exception or wrong value?

Classify the result before editing a register number. A timeout means the client did not receive an acceptable response within its configured wait. An exception is a protocol response reporting an unsuccessful request. A normal response containing an unexpected value requires checking the requested object and its interpretation. These outcomes are not interchangeable.

The Modbus application protocol specification, sections 6.3 and 7, defines function 03 for holding-register reads, zero-based PDU addresses, quantities of 1–125 registers and exception responses. Each returned register contains two bytes, high byte first. A device's documented map determines which addresses it implements and what their contents mean.

For this exercise, define a fictional server with only four readable holding registers, at offsets 0 through 3. There are no other implemented addresses. The two first registers form an unsigned 32-bit value with the high word first; the other two are independent unsigned 16-bit values. This layout is our declared worksheet, not a drive manufacturer's map.

Read offset 0 with quantity 2. The request PDU and normal response PDU are:

Request:  03 00 00 00 02
Response: 03 04 12 34 56 78

The response's 04 is the byte count: two registers produce four data bytes. These are PDUs only. They omit the Modbus TCP header or serial address and CRC; they are not complete frames to paste into a serial transmitter.

In our declared high-word-first interpretation, 0x1234 × 65536 + 0x5678 equals 305,419,896. Swapping the two complete words produces 0x56781234, or 1,450,709,556. Both use exactly the same received register values. This difference is a decoding decision, not evidence of a damaged Ethernet cable.

Changing the starting offset is a different mistake. Reading offset 1 with quantity 2 returns 5678 and 0064. You have now selected different registers, so changing word order cannot recover the original pair. Also distinguish unsigned integers from signed integers and floating-point encodings; a 32-bit container does not specify its data type.

Some manuals label the first holding register 40001; some client interfaces ask for a zero-based offset and others use a displayed reference convention. Record the tool's convention before entering a number. The important evidence is the actual requested PDU address and function, not whether two screens show identical labels.

04

Check register boundaries with explicit expected results

Using only the four-register fictional map, predict each read before running a matching lab implementation. A starting address can exist while the complete requested span extends beyond the map.

This provides a useful diagnosis for our opening example: the smaller read succeeds because offset 3 exists, while the two-register span does not. We have reproduced a map boundary condition. That conclusion applies to the declared server, not to every real device returning an exception.

For Modbus RTU, also record the serial format, station address, interface type and relevant device instructions. For Modbus TCP through a gateway, record both the IP endpoint and the downstream mapping. A responsive gateway does not prove that the intended serial instrument supplied the data. The Modbus specifications library separates the application specification, serial-line guide and TCP messaging guide, which answer different questions.

EtherNet/IP connection faults and data mapping

Capture the controller's actual connection fault code and description. Compare the installed device identity and firmware with the engineering configuration. Then consult the matching device manual for its connection type, supported data layout and configuration requirements. Avoid copying assembly numbers or byte counts from a different drive because its name looks similar.

A rejected connection and an established connection with misunderstood data need different evidence. In the first case, examine the reported configuration or connection error. In the second, trace the documented field offset, type, scale and quality into the consuming tag. A green status icon cannot demonstrate the correctness of every engineering value.

Rockwell's 5094 connection-view documentation identifies device-dependent RPI ranges and defaults, exposes connection fault details and notes that online RPI changes close and reopen the connection. Those details are specific to the documented profile; there is no universal “set every device to 20 ms” repair.

For a fictional comparison, record configuration A, its error text and the observed data. Create configuration B by changing one justified field in an isolated lab, then repeat the same observations. If the connection becomes established, separately verify a known data value. This prevents a successful connection test from being mistaken for a complete application test.

Do not equate the requested packet interval with a universal disconnection timeout. Read the device and controller connection behaviour. Where communication loss affects a process, the required response and recovery sequence also belong in the application design and assessment.

05

PROFIBUS diagnostics: identify the segment before changing termination

Start with the actual transmission technology and topology. An RS-485 PROFIBUS DP segment and a PROFIBUS PA installation using MBP are not interchangeable wiring exercises. Record station addresses, segment boundaries, repeaters or couplers, the configured device description and the master's diagnostic information.

For the RS-485 connector arrangement described in PI's PROFIBUS assembly guideline, termination belongs at the two segment ends, not at every intermediate station. The guideline also identifies a supply pin used for functions such as bus termination. Check the actual connector and device requirements, including what happens when an end station loses power.

Draw a fictional segment as End A — Station B — Station C — End D. On that declared single segment, the endpoint locations are A and D. Adding a repeater would change the segment drawing and require considering the resulting segments separately. The highest station address is not necessarily a physical endpoint: address numbers and cable positions are different records.

An analyser observation should be retained with its measurement location, settings and operating condition. Do not label every degraded waveform as proof of a missing terminator. Compare the observed pattern with the installation and instrument guidance, then test a specific hypothesis through the authorised maintenance process. The PI installation guideline collection separates design, assembly and commissioning material for that reason.

Build a useful simulator and course portfolio

Use Modbus learning and simulation resources for the available educational scope. The reviewed drive-status exercise maps supplied Boolean status inputs to lamps and a logical permissive. It should not be presented as proof that you captured real RTU frames, measured RS-485 waveforms or configured an EtherNet/IP adapter.

Keep the packet worksheet in this guide as a separate exercise unless your chosen lab explicitly implements that map. For software behaviour, test PLC programs against explicit expected results. Record inputs, expected outputs, actual outputs and the limitation of each test.

A useful portfolio contains the five subnet comparisons, the seven register-boundary predictions, the two 32-bit interpretations and one evidence-led investigation. Add an explanation of what would falsify your preferred hypothesis. For example, an exception from the intended server weakens a blanket claim that no application communication is possible, but it does not validate every request.

Connect this work with HMI tag binding and data quality, then study OPC UA nodes and subscriptions if that is the actual path into your supervisory system. Avoid treating OPC UA, EtherNet/IP and Modbus as different names for the same connection.

06

Questions South African learners and course buyers should ask

Which industrial communication course should I take first?

Start with the equipment and task you need to support. A learner maintaining Siemens distributed I/O may need a different practical lab from someone integrating a Modbus energy meter. Ask a Johannesburg, Durban, Cape Town or online provider for the actual protocols, controller models, software access and individual troubleshooting exercises. The city name does not establish the technical depth of a course.

Can I learn PLC network fault finding without buying hardware?

You can practise subnet calculations, register maps, value decoding and evidence records without owning a production controller. Software exercises can also develop program testing skills. Physical-layer diagnosis requires suitable equipment, instruction and measurement practice. Ask which course outcomes are demonstrated virtually and which involve an actual network bench.

Why does my PLC respond to ping but the HMI still show bad data?

A ping response is narrower evidence than a successful application transaction with correct tag mapping and acceptable quality. Compare the HMI's configured endpoint, driver diagnostic, requested object and current data status. Follow the particular protocol's evidence instead of treating reachability as proof of the whole chain.

How do I compare Modbus RTU, PROFIBUS and EtherNet/IP training?

Request a sample assessment for each advertised protocol. Look for declared configurations, diagnostic observations, controlled changes and a written explanation of the result. A course that merely names several protocols is difficult to compare with one that requires you to distinguish a timeout, a configuration rejection and a decoding error. Use those concrete outcomes to choose the next learning step.