Learn Modbus: why a 1979 protocol still runs

Modbus is a question and answer protocol: one device asks, another answers with plain numbers, and nothing in the message says what those numbers mean. That single property explains both sides of Modbus: why a protocol from 1979 still sits in the energy meter you opened this morning, and why it sometimes hands you nonsense. After this lesson you can look at an installation and say who asks, who answers, and what you still have to look up.

What happens when a gateway reads a meter?

Nothing more than this: one short question out, one short answer back. A gateway wants three values from an energy meter at server address 1, so its question carries four things.

The meter answers with the same function code, a byte count and three 16 bit numbers. That is 8 bytes out and 11 bytes back:

Question: 01 03 00 6B 00 03 74 17
Answer:   01 03 06 02 2B 00 00 00 64 05 7A

No need to decode those bytes yet, the Modbus RTU frame byte by byte does that later. What counts is what comes back: 555, 0 and 100, without a unit, without a decimal point and without a name. Only this device's register map turns them into something:

Modbus is an application layer protocol at level 7 of the OSI model, and this exchange is all it does. The reference page what Modbus is covers the wider picture.

Why a protocol from 1979 still runs everywhere

Because it is small enough to fit anywhere and open enough to copy. Modicon, today Schneider Electric, put Modbus on the market in 1979 and handed it to the Modbus Organization in April 2004, a step the organization itself calls a commitment to openness. The application protocol document has been public ever since, currently as version V1.1b3, dated 26 April 2012.

The frugality shows in the numbers. A Modbus PDU never exceeds 253 bytes, a limit inherited from the first serial implementation, and the read request above fits into eight bytes on RS485 including its error check. A device that has to handle no more than that needs neither a strong processor nor a negotiation to open a connection. That is why it keeps turning up on almost every inverter, energy meter and heat pump controller.

Who asks, who answers, and how to tell them apart

The device that starts the conversation is the client, everything that waits is a server. In practice the client is your gateway, PLC, SCADA system, energy management system or a Home Assistant instance talking Modbus, and the servers are the meters, inverters, sensors, drives and I/O modules. You recognise them by behaviour: whatever starts talking on its own is the client, and a bus should hold exactly one.

You will still meet the older names in datasheets and configuration screens. The serial line specification ties them together literally: on Modbus serial line the client role is provided by the master of the bus and the slave nodes act as servers. The Modbus Organization replaced the terminology on 9 July 2020, but field names did not follow. A screen asking for a slave ID under a Modbus master setting is talking about exactly what this course calls a client and a server address.

What a register is, and what it is not

A register is 16 bits, and that is the whole definition. No unit, no data type, no scaling, no name. In the answer above, 555 is just 555. Whether it means 55.5 A, 555 W or half a serial number is a decision the manufacturer wrote down in a datasheet.

The standard defines four data blocks, allows up to 65536 items in each, sets out how you address them and whether you may write them, and stops. It states that the pre-mapping between the Modbus data model and the device application is totally vendor device specific. So one register number can legitimately mean three things on three brands.

This is why no tool can discover on its own what a device holds, and why a manufacturer register map is half the job rather than optional paperwork. How a Modbus register map is built is the reference page, and the lesson on reading a Modbus datasheet makes it routine.

RTU and TCP: same question, different envelope

The question in the middle is identical, only the packaging differs. That middle part is the PDU (protocol data unit): function code plus data, at most 253 bytes. Modbus RTU adds one address byte in front and two CRC bytes behind, giving a message of at most 256 bytes. Modbus TCP wraps that same PDU in a 7 byte MBAP header and drops the CRC completely, because Ethernet and TCP already do that check, giving at most 260 bytes on port 502.

The same read request therefore looks like this: 01 03 00 6B 00 03 74 17 on RS485, eight bytes, and 00 01 00 00 00 06 FF 03 00 6B 00 03 on TCP, twelve bytes. Both carry the same PDU, 03 00 6B 00 03.

That is the entire difference at protocol level. Chapter 2 covers RTU, chapter 3 covers TCP, and choosing between Modbus RTU and Modbus TCP weighs them up.

The twelve words you need for the rest of the course

These twelve terms come back in every later lesson, and they appear in exactly this form in datasheets.

Two of these twelve mislead: server address and unit id look interchangeable and are not, and the datasheet number differs by one from the address on the wire. That is exactly the subject of the next lesson, on Modbus addressing from 40001 to the wire.

How to use this course

The course holds 21 lessons in four chapters: fundamentals, Modbus RTU, Modbus TCP and advanced topics. Work through them in order if you are starting from scratch, or jump straight to the lesson that matches the problem on your desk. Every lesson repeats in two sentences what it needs from earlier ones, so nothing is a locked door. Each one ends with four questions so you can check whether the concept stuck.

Common mistakes

Reading a value as if it came with a unit. You poll a register, see 555, and write down 555 A. The message carried a 16 bit number and nothing else. The step size, the decimal point and the unit live in the datasheet, so a value you cannot trace back to a datasheet line is a value you have not read yet.

Treating "the device supports Modbus" as an answer. Modbus RTU and Modbus TCP are two different physical worlds. A device with only RS485 terminals does not join your network with a patch cable, and a device with only an Ethernet port does not join your RS485 daisy chain. Ask which of the two before you order anything.

Assuming master and slave mean something other than client and server. They are the same two roles under older names, replaced by the Modbus Organization on 9 July 2020. Configuration screens still say Modbus master and slave ID, and treating those as a third concept is how people end up putting two clients on one bus.

Try it yourself

No software to install in this lesson. The exercise is the inventory a technician makes on day one of a project, and it works just as well at a desk.

1. 1

   Pick a device you actually deal with

   An energy meter, a solar inverter, a heat pump or an EV charger. Something you have installed or will install.

2. 2

   Find the Modbus documentation on the manufacturer site

   Look for a register map, a Modbus protocol manual or a communication appendix, not a forum post. Note the document version, because register maps change between firmware generations.

3. 3

   Answer five questions in writing

   Does it speak RTU or TCP, what is the factory address, what baud rate ships from the factory, are the registers numbered in the 40001 style or from 0, and does the document say anything at all about byte or word order.

4. 4

   Fill in this card for your device

   Copy the five lines below and complete them. Every blank you cannot fill is a question for the supplier, not a guess for later.

5. 5

   Note where you searched when a question stays open

   Write down the page number or the search term. That is the real deliverable of this exercise: you now know exactly what to ask.

Device:      ______________________  firmware/doc version: __________
Transport:   RTU over RS485   /   Modbus TCP
Address:     server address ____     or unit id ____
Numbering:   datasheet numbers from 1 (40001 style)   /   addresses from 0
Word order:  ______________________  (or: not documented)

No device at hand? Use the public protocol documentation of the Eastron SDM630 and answer the same five questions for that meter. As a check: it speaks Modbus RTU over RS485, the address range runs from 1 to 247 with 1 as the factory setting, the measurements sit in input registers that you read with FC04, and the document states that the most significant register comes first.

Expected result: five answers on paper, and the realisation that a datasheet almost never covers all five.

Summary

• Modbus is a request and response protocol at OSI level 7: a client asks, a server answers on its own address, and never starts a conversation by itself.
• A register is 16 bits with no unit and no data type, so the manufacturer register map is the only place that says what it holds, not the protocol.
• Client and server are the current names for the roles that screens still call master and slave, replaced by the Modbus Organization on 9 July 2020.
• Modbus RTU and Modbus TCP carry the same PDU of at most 253 bytes and differ only in the envelope: 256 bytes with an address byte and a CRC, 260 bytes with a 7 byte MBAP header.
• Before you read a device you want five things: transport, address, baud rate, address notation and word order.