Modbus RTU and Modbus TCP use the same function codes and the same register model — only the transport differs. RTU runs over RS-485 serial: a frame carries a slave address, function code, data and a 16-bit CRC, with frames separated by a 3.5-character silent interval. TCP runs over Ethernet on port 502: the CRC is dropped because TCP already guarantees integrity, and a 7-byte MBAP header (transaction ID, protocol ID, length, unit ID) is added in front. RTU is one master, up to 247 slaves, one transaction at a time on a shared line. TCP allows multiple simultaneous clients and multiple outstanding requests, at the cost of needing Ethernet infrastructure.
- The application layer is identical — a function code 3 read of holding registers means the same thing on both.
- The most common integration bug is not wiring, it is addressing: documentation numbered 40001 upward maps to protocol address 0.
- RTU needs matching baud rate, data bits, parity and stop bits on every node; a parity mismatch produces silence, not an error message.
- Modbus has no native security. On a plant network, segment it — never expose port 502 to an untrusted network.
One Protocol, Two Transports
Modbus is unusual among industrial protocols in how little there is to it. A client asks a server for some registers or coils; the server answers with the values or with an exception code. That request/response model, and the register model behind it, has not changed since 1979, which is precisely why almost every energy meter, VFD, temperature controller and gateway on the market speaks it.
What changed is the wire underneath. Modbus RTU is the original serial form, in practice almost always RS-485 two-wire multidrop. Modbus TCP wraps the same message in a TCP/IP packet. A device that supports both behaves identically at the application level — the register map in its manual is the same map regardless of which port you connect to.
This is worth internalising early, because it means learning Modbus once covers both. Time spent understanding function codes and register addressing pays off on every device; time spent on transport specifics only matters at commissioning.
Frame Structure: CRC vs MBAP Header
| Element | Modbus RTU | Modbus TCP |
|---|---|---|
| Frame start | Silence of at least 3.5 character times | TCP segment boundary; no timing rule |
| Address field | 1 byte slave address (1–247, 0 = broadcast) | 1 byte unit ID inside the MBAP header |
| Function code | 1 byte | 1 byte (identical) |
| Data | Variable | Variable (identical) |
| Error check | 16-bit CRC appended | None — TCP checksums handle it |
| Extra header | None | 7-byte MBAP: transaction ID (2), protocol ID (2, always 0), length (2), unit ID (1) |
| Concurrency | One transaction at a time on the line | Multiple outstanding requests, matched by transaction ID |
| Typical port | Serial COM / RS-485 module | TCP 502 |
The transaction ID in the MBAP header is the quietly important addition. Because TCP lets a client issue several requests before the first reply arrives, each response carries back the transaction ID of the request it answers. On RTU there is nothing to match — the line is strictly one question, one answer, and the master must wait.
The unit ID field exists for gateways. A Modbus TCP to RTU gateway uses the unit ID to decide which serial slave a request is destined for, which is how an Ethernet client reaches thirty serial meters through one IP address. For a device that speaks TCP natively, the unit ID is usually ignored, though many devices expect 1 or 255 and some reject anything else.
Practise Modbus integration on real equipment
Connect PLCs, drives and energy meters over RS-485 and Ethernet, then diagnose real faults — Pune classroom or live online.
Function Codes You Will Actually Use
The specification lists over twenty function codes. Eight cover nearly all industrial work.
| Code | Name | Acts on | Typical use |
|---|---|---|---|
| 01 | Read Coils | Read/write bits | Reading output states — relay status, drive run command bits |
| 02 | Read Discrete Inputs | Read-only bits | Digital input status from a remote I/O block |
| 03 | Read Holding Registers | Read/write 16-bit words | By far the most used — setpoints, measured values, drive parameters |
| 04 | Read Input Registers | Read-only 16-bit words | Measured values on devices that separate read-only data |
| 05 | Write Single Coil | One bit | Start/stop commands |
| 06 | Write Single Register | One word | Writing a single setpoint such as a speed reference |
| 15 | Write Multiple Coils | Multiple bits | Setting a block of outputs in one transaction |
| 16 | Write Multiple Registers | Multiple words | Writing a recipe or a multi-word command block atomically |
When a server cannot fulfil a request it returns an exception response: the function code with its high bit set, plus an exception code. 01 means illegal function, 02 illegal data address, 03 illegal data value, 04 server device failure. Exception 02 is the one you will meet most, and it almost always means the addressing is off rather than the device being faulty.
Register Addressing and the Off-by-One Trap
More Modbus commissioning hours are lost here than anywhere else. Device manuals traditionally use a five- or six-digit numbering convention that is not what goes on the wire.
| Data type | Documentation numbering | Protocol address sent | Function codes |
|---|---|---|---|
| Coils | 00001–09999 | 0000–270E | 01, 05, 15 |
| Discrete inputs | 10001–19999 | 0000–270E | 02 |
| Input registers | 30001–39999 | 0000–270E | 04 |
| Holding registers | 40001–49999 | 0000–270E | 03, 06, 16 |
Holding register 40001 in a manual is protocol address 0. Register 40108 is protocol address 107. The leading digit indicates the data type and the rest is a one-based index, while the wire carries a zero-based index with the type implied by the function code.
Complicating this, some manufacturers document the protocol address directly, some document both, and some print "register 108" without saying which convention they mean. The practical rule when a read returns exception 02 or plainly wrong data: try the address one lower, and try it as a raw zero-based value. One of the two nearly always works, and it costs thirty seconds against an afternoon of speculation.
RS-485 Wiring, Termination and Timing
RTU adds a physical layer that TCP does not have, and its rules are unforgiving.
| Aspect | Requirement | What happens if ignored |
|---|---|---|
| Topology | Daisy chain, short stubs only | Star wiring creates reflections; works at low baud, fails intermittently at high baud |
| Termination | 120 Ω at both physical ends only | Missing termination causes CRC errors; extra termination overloads the drivers |
| Bias resistors | Fail-safe bias at one point on the segment | Idle line floats and receivers see random noise as start bits |
| Common reference | Signal common wired alongside A/B, shield grounded at one end | Ground potential differences between panels destroy transceivers |
| Serial settings | Identical baud, data bits, parity and stop bits on every node | Complete silence — a parity mismatch produces no reply and no error |
| Inter-frame gap | Silence of 3.5 character times between frames | Frames merge and are discarded as invalid |
| Response timeout | Typically 300 ms to 1 s in the master | Too short and slow devices are marked failed; too long and one dead node stalls the poll cycle |
A/B polarity deserves its own note: manufacturers disagree on labelling, and swapping the two wires is the most common RS-485 fault. It causes no damage, so when a new device stays silent and the settings are verified, swap A and B before doing anything else.
On Modbus TCP none of this applies, replaced by ordinary Ethernet concerns — correct subnet, no duplicate IP, and a firewall that permits port 502. The trade-off is real: RTU needs care with cable and settings but runs on two wires over a kilometre; TCP needs switches and addressing discipline but scales effortlessly and lets several clients read the same device at once.
Data Types, Byte Order and 32-Bit Values
Modbus registers are 16 bits, and the specification says nothing about how to represent anything larger. Devices therefore split 32-bit floats and integers across two consecutive registers — and disagree about the order.
| Convention | Register order | Byte order within register | Common in |
|---|---|---|---|
| Big-endian | High word first | High byte first | Most Modbus devices; the specification's own convention for register contents |
| Little-endian word swap | Low word first | High byte first | Many energy meters and PC-based masters |
| Byte swap | High word first | Low byte first | Some gateways and older devices |
The reliable way to identify which one a device uses is to read a value you can independently verify. Ask a meter for a voltage you can measure with a multimeter: if the reading comes back as a plausible 415.2, the order is right; if it comes back as an implausible number, swap the words and read again. Guessing from the manual alone is slower than a single empirical test.
Signed values, scaling factors and implied decimal points are similarly device-specific. A temperature controller commonly returns 2453 meaning 245.3 °C, with the scaling documented rather than transmitted. Always confirm the scaling on a known value before trusting archived data — a scaling error propagates silently into every report built from that tag.
Troubleshooting Table
| Symptom | RTU cause | TCP cause |
|---|---|---|
| No response at all | A/B swapped, wrong slave address, parity or baud mismatch, no bias | Wrong IP, firewall blocking port 502, device not listening |
| Exception code 02 | Wrong register address — try one lower, and try zero-based | |
| Exception code 03 | Value out of the device's permitted range, or too many registers requested in one read | |
| Intermittent CRC errors | Missing or duplicated termination, star wiring, EMC from drive cables | Not applicable — TCP retransmits transparently |
| Values wildly wrong but stable | Word or byte order mismatch on a 32-bit value, or an undocumented scaling factor | |
| Works alone, fails with all devices connected | Duplicate slave address, or too many nodes for the line without a repeater | Duplicate IP address on the network |
| Slow or stuttering updates | Poll cycle too long for the node count; one timing-out device stalls the rest | Too many separate small reads instead of one block read |
Step-by-Step Lab: Read a Device's Registers Both Ways
Hands-on- Any Modbus slave device with a published register map — an energy meter, a VFD with a Modbus option, or a temperature controller.
- A USB-to-RS485 converter for the RTU part, plus a free Modbus master utility on a laptop.
- For the TCP part: a Modbus TCP device or a Modbus TCP-to-RTU gateway on the same subnet as your laptop.
- Estimated time: 40 minutes.
Record the device settings before touching anything
From the device's own keypad or display, write down its slave address, baud rate, parity, stop bits, and — for TCP — its IP address and unit ID. Do not assume the manual's defaults are what is actually set.
Read one known value over RTU
Wire A, B and common. Configure the master utility with the recorded settings and issue a function code 03 read of a single register that holds something you can verify independently — a voltage, a temperature, a frequency.
Prove the off-by-one to yourself
Deliberately request the address one higher than the correct one, then one lower. Note what each returns.
Read a 32-bit value and determine the word order
Find a float or 32-bit integer in the register map — energy totals and power values usually are. Read both registers, combine them one way, then the other.
Repeat the same read over TCP
Connect to the device or gateway on port 502 and issue the identical function code 03 read with the same register address and unit ID.
Break the RTU line and watch the failure mode
With RTU polling continuously, swap A and B, then restore them. Then change the master's parity while leaving the device unchanged.
You have understood Modbus if you can explain why the same function code 03 request works unchanged over both transports, why a documented register 40108 goes on the wire as address 107, and why a parity mismatch produces silence rather than an error. From here, the natural next step is polling the device from a PLC or a Python script and archiving the values to SQL Server for reporting.
Frequently asked questions
What is the actual difference between Modbus RTU and Modbus TCP?
Only the transport. RTU sends the message over RS-485 serial with a 16-bit CRC and relies on a 3.5-character silent gap to mark frame boundaries. TCP sends the same message over Ethernet on port 502, drops the CRC because TCP already ensures integrity, and prefixes a 7-byte MBAP header. Function codes, register addresses and data are identical.
Why does register 40001 in the manual not work as address 40001?
The 4xxxx numbering is a documentation convention where the leading 4 means "holding register" and the remainder is a one-based index. On the wire, the function code carries the data type and the address is zero-based, so 40001 becomes address 0 and 40108 becomes address 107.
How many devices can I put on one Modbus RTU line?
The protocol allows slave addresses 1 to 247. The physical RS-485 layer typically supports 32 standard-load nodes per segment before a repeater is needed. In practice, poll cycle time limits you first — every additional device lengthens the time between updates for all of them.
My 32-bit values read as nonsense numbers. What is wrong?
The word or byte order almost certainly differs from what your master assumes. Modbus registers are 16 bits and the specification does not define how larger values are split, so read a value you can verify independently, try both word orders, and document which one the device uses.
What does exception code 02 mean?
Illegal data address — the device does not have a register at the address requested. It usually means an off-by-one from the 4xxxx numbering convention, or a request that extends past the end of a valid register block. Try the address one lower before suspecting the device.
Is Modbus TCP secure enough for a plant network?
No. Modbus has no authentication and no encryption in either form — any client that can reach port 502 can read and write registers. Keep it on a segmented control network behind a firewall, and never expose port 502 to an untrusted network or the internet.