Modbus TCP Explained by Doing: Read a Register in 10 Minutes (Video)

Modbus TCP is a client asking a server for numbered 16-bit registers over TCP port 502. The quickest way to understand it is to do it: start a free Modbus server simulator, read holding register 40001 with a free client, write a value and read it back. With the two command-line tools below it takes about ten minutes, and the off-by-one addressing that confuses everyone becomes obvious.

Checked 1 October 2026. Tool licences and trial terms come from the publishers' own pages, listed under Sources.

In this lesson by iipd Global, an S7-1200 is programmed as a Modbus TCP server with the MB_SERVER block in TIA Portal and read from a PC with ModScan, a Modbus scanner. It is one of the lessons in our free Industrial Communication course, in the module on Modbus TCP on the S7-1200. Do the ten-minute exercise below first, without a PLC, and the video will make complete sense.

This post is the hands-on companion to our Modbus tutorial, which covers RTU, ASCII, RS-485 wiring and the full theory. Here we only do one thing: read a register.

The ten-minute exercise

What you need

Two free command-line programs from proconX: diagslave, a Modbus slave (server) simulator, and modpoll, a Modbus master (client). Both are free to use and redistribute, and both run on Windows and Linux, including a Raspberry Pi. Unzip them into one folder and open a terminal there.

Start a server

Run diagslave -m tcp -p 5020. That starts a Modbus TCP server on port 5020. Modbus TCP's registered port is 502, and diagslave and modpoll both default to it, but ports below 1024 need administrator rights on Linux, so a high port keeps the exercise simple. Leave this window open.

Read a register

In a second terminal, run modpoll -m tcp -p 5020 -r 1 -c 1 -1 127.0.0.1. In plain words: TCP, port 5020, start at reference 1, read one value, poll once, at this address. modpoll's default data type is holding registers with function code 3, so this reads register 40001. On a fresh simulator it returns 0.

Write, then read back

Run modpoll -m tcp -p 5020 -r 1 127.0.0.1 1234. Putting a value after the address makes modpoll write it. Run the read command again and register 1 now holds 1234. You have just done the whole of Modbus TCP that most projects use: a client reads and writes numbered registers on a server.

Now see the offset

Add -0 to the read command and change -r 1 to -r 0. modpoll's help says -0 makes the first reference 0, PDU addressing, instead of 1. You get the same 1234, because "reference 1" and "address 0" are the same register. That is the whole off-by-one problem in one line.

What actually crossed the network

Here is the read request for register 40001, captured byte for byte from a test client on 1 October 2026:

The first seven bytes are the MBAP header, which the Modbus TCP implementation guide defines: a transaction ID the server copies into its reply, a protocol ID that is always 0 for Modbus, a length counting the bytes that follow, and a one-byte unit ID. The unit ID replaces the serial slave address and matters mainly when a gateway passes requests on to RS-485 devices behind it.

The last five bytes are the PDU, the same on serial and TCP: function code 03, start address 0000 and quantity 0001. The specification is explicit that in the PDU registers are addressed from 0, so registers numbered 1 to 16 are addressed as 0 to 15. The reply carries the function code, a byte count and two bytes per register, high byte first: 1234 comes back as 04 D2.

A Modbus TCP frame has no CRC. TCP already checks the data, which is one of the main differences from Modbus RTU.

The function codes you will use

One request with function code 3 or 4 can read up to 125 registers. If a device answers with an exception instead of data, the code tells you why: 01 is an unsupported function, 02 an illegal data address (usually the off-by-one or a register that does not exist), 03 an illegal value, 04 a device failure.

From simulator to a real S7-1200

The video does the same exercise with a PLC as the server. MB_SERVER is the S7-1200's Modbus TCP server instruction. It listens on port 502 by default, needs a connection ID that is unique for each MB_SERVER or MB_CLIENT instance, and maps Modbus areas onto PLC memory like this:

The important parameter is MB_HOLD_REG. It points at a data block or memory area, and register 40001 is its first word, 40002 the second word, and so on. So with a 10-word holding register DB, a value you write into the DB's fifth word appears at 40005, which a client set to zero-based addressing calls address 4.

Run the same modpoll read against the PLC's IP address on port 502 and you should see the DB's values. If you do not:

• Ping the PLC first. No ping, no Modbus.
• Check the port and unit ID your tool is sending.
• Try the read one register lower or higher. If that works, it was the offset.
• Check MB_SERVER's STATUS output. The S7-1200 system manual lists what each status code means.

Other free tools

• QModMaster: a free graphical Modbus master for Windows and Linux under the LGPL, with a bus monitor that shows raw frames. Good if you prefer a window to a terminal.
• pymodbus: a Python library with a client, a server and a simulator, under the BSD licence. In pymodbus 3.10 and later the keyword for the unit ID is device_id (it was slave before), so older examples online need a small change. Our Python for automation engineers post is a starting point.
• Modbus Poll and Modbus Slave: popular commercial tools. Their trials stop each connection after 10 minutes and stop connecting after 30 days, which is enough for a quick test like this one.
• ModScan, as used in the video, is a commercial Windows scanner; the free tools above do the same job for learning.

Common mistakes

• Off by one. 40001 is address 0. When a reading looks like the neighbouring value, this is why.
• Mixing up holding and input registers. Function code 3 and function code 4 read different tables.
• Byte or word order on 32-bit values. A float spans two registers and devices disagree on which comes first.
• Exposing port 502. Modbus has no authentication; keep it on a segmented control network, never on the internet.

Learn it free

The free Industrial Communication course takes Modbus from RS-485 wiring through RTU and TCP, MB_CLIENT and MB_SERVER on the S7-1200, Modbus remote I/O and other PLCs, then PROFINET, EtherNet/IP and OPC UA. Its practice task for this module is the video's job done properly: a 10-word holding register DB read from a free scanner, done when a value written in the DB appears at the register you predicted and a write from the scanner arrives in the DB.

From there, Node-RED for Industrial IoT puts Modbus values on a live dashboard (see our Node-RED PLC dashboard walkthrough), Industrial Data with Python reads them in code, and Variable Frequency Drives controls a drive over Modbus RTU. All are in the industrial networks list.

The certificate is optional. If you pass the final assessment and want one, it costs from US$2.99 for a beginner course, with intermediate courses a little more. It is an EDWartens Certificate of Completion with a verification code, not a vendor qualification.

Take the free course

Industrial networks · Intermediate · Free

Industrial Communication: Serial, Fieldbus, Ethernet, Modbus, PROFINET and OPC UA

IIoT · Beginner · Free

Node-RED for Industrial IoT

AI and machine learning · Intermediate · Free

Industrial Data with Python

Drives · Beginner · Free

Variable Frequency Drives: Wiring, Programming, PLC and Network Control