The short answer
How to Diagnose Read and Write Communications
To diagnose read and write communications, first capture what is actually being sent and what comes back, from the driver diagnostics or a protocol analyzer, then classify: no link means the port or the cable; no answer means the address, the device, or the path; an answer with an error means the message or the register map; and a write that succeeds with no effect means the device overwrote or ignored it. Read the exception or status code, which names the refusal; reproduce the same request with a test tool on a laptop and compare byte for byte; then fix the one thing the evidence points at and retest before touching anything else.
Key points
- Capture the request and the response before theorizing; the bytes settle most arguments.
- Classify: no link, no answer, rejected exchange, or accepted with no effect.
- The exception or status code is the diagnosis; log it in a tag.
- A test tool that reproduces the controller request separates the network from the message.
- Change one thing, retest, and record what fixed it.
What you need
- The driver diagnostics on the controller or SCADA, and a protocol test tool on a laptop
- A protocol analyzer or port mirror for Ethernet; a serial tap or a converter with diagnostic indicators for RS-485
- The device register map for the installed model and firmware
- The network schedule with addresses, ports, unit identifiers, and serial settings
- A meter for serial signal levels and cable continuity
Procedure
- 1
Scope the failure
Reads only, writes only, or both; one device or all on the port; constant or intermittent; since when and what changed.
- 2
Check the link
Port status on the controller and the switch, link lights, serial activity indicators. No link: cable, port settings, converter, termination. Stop here if the link is down.
- 3
Capture
Enable the driver diagnostics or mirror the port and capture one failing exchange: the request bytes and the response, or the absence of one within the timeout.
- 4
Classify
No response: address, device, path, or timeout too short. Exception response: read the code. Good response with wrong data: the map or the interpretation. Write acknowledged but ineffective: the device logic or mode.
- 5
Read the code
Modbus exceptions 01 to 06, DNP3 internal indications, EtherNet/IP general status, OPC UA status codes; each names the refusal in the protocol specification and the device manual.
- 6
Reproduce with a tool
Send the same request from a laptop tool. If the tool succeeds, compare its request with the controller request byte by byte: function code, address, count, unit identifier, data type. If the tool fails the same way, the device or the path is the problem.
- 7
Test the path
Ping and a port test for Ethernet; signal levels and termination for serial; a gateway or firewall in between examined for drops.
- 8
Fix one thing
The address, the function code, the data type, the timeout, the device mode, the firewall rule, or the cable, whichever the evidence named. Retest with the capture running.
- 9
Record
The cause and the fix in the site record, and the error code tag left in place so the next failure is logged.
| Evidence | Points at | Fix |
|---|---|---|
| Timeout on every message | Address, device off, path, or a driver with the wrong port | Verify the address and unit identifier; ping; check the device |
| Timeout on writes only | A firewall or gateway dropping writes, or a device that does not answer writes | The security policy; the device write configuration |
| Exception 01 | Function code not supported | Use the function the device supports |
| Exception 02 | Register not valid or not writable | The map and the offset convention |
| Exception 03 | Data value or count invalid | Data type, word count, range |
| Good response, wrong values | Offset, table, word order, type, scale | Read raw registers and match to the device display |
| Write acknowledged, value reverts | Device logic writes the register or a local mode | Find the owner of the register |
| Intermittent timeouts | Marginal link, noise, timeout too short, a duplicate address, a slow device | Retry statistics, cable, timeout from measured response |
Frequently asked questions
- The device works with the laptop tool and not with the controller.
- The two requests differ. Compare function code, starting address, register count, unit identifier, and data type; the controller driver often defaults to a multiple-register write or a zero-based address that the device does not accept.
- Reads work and writes return exception 02.
- The write targets a register that is read-only, does not exist, or sits in a different table than the read. The manual names the writable registers; the write address is corrected.
- Everything worked until the firewall was installed.
- The firewall is dropping the traffic, and possibly by design. Read the firewall log, confirm with the security owner what should cross, and write the rule for that traffic only.
- How do I capture serial traffic?
- A serial tap or a converter with a monitoring port between the controller and the bus, feeding a laptop with a serial analyzer; or the driver diagnostics on the controller if it offers a byte-level view. A meter on the bus shows signal presence and levels but not content.
Related topics
- Read Works but Write FailsPolling a device returns good data and writing a setpoint does nothing or returns an exception: a write-protected device, a read-only register, the wrong function code, a wrong address or type, logic that overwrites the value, a security rule, or a local mode.
- Wrong Register DataThe poll succeeds and the numbers are nonsense: an offset by one, the wrong table, swapped words in a 32-bit value, a float read as an integer, signed read as unsigned, a scale factor not applied, a stale gateway value, or the wrong unit answering.
- Device Times OutA polled device that answers late or not at all: how to read the driver counters, tell a dead device from a slow one, and find the timeout setting, the bus loading, the radio latency, the duplicate address, or the device that is simply too busy to answer.
- Communication FailuresWhat to read when a controller stops talking to a device, another controller, or SCADA: port and connection status, message error codes, timeouts and retries, addressing, limits, and the order of checks that separates controller, cable, device, and network.
- How to Configure a Modbus ConnectionSet up a Modbus RTU or TCP link between a controller and a device: get the register map, match the physical and protocol settings, build the reads and writes, handle data types and the addressing offset, and verify with a protocol tool before trusting a value.
- Serial CommunicationsRS-232, RS-422, and RS-485 in practice: which is which, cable and distance, termination, biasing, the common reference wire everyone leaves off, and the settings that have to match at both ends.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.