The short answer
How to Configure a Modbus Connection
To configure a Modbus connection, get the register map from the device manual, set the physical layer (serial parameters and wiring for RTU, IP address and port 502 for TCP), set the unit identifier, build read requests that cover the registers you need in as few polls as possible, decode the data types the device uses, resolve the one-based versus zero-based addressing offset, add a write for each command, and verify every value against the device display with a Modbus test tool before the controller uses it.
Key points
- The register map is the specification. Nothing works without it.
- Function code, address, and count per request; group registers to minimize polls.
- Resolve the addressing offset once, on the first register, and apply it to all.
- Decode data types deliberately: 16-bit, 32-bit with word order, floats, scaled integers, bit fields.
- Verify with a protocol tool against the device display, then set poll rate and timeout for the link.
What you need
- The device manual with its Modbus register map and communication settings
- A Modbus master test tool on a laptop, serial or TCP as appropriate
- For RTU: an RS-485 adapter, shielded twisted pair, and termination resistors
- For TCP: the IP addressing plan and access to the switch
- The controller programming software and its Modbus configuration or instruction manual
- A signal list of the values and commands the controller needs from the device
Procedure
- 1
Get the register map
From the device manual, the section usually called Modbus register map, holding registers, or communication. It lists each value with its register number or address, function code or register type, data type, scaling, and read-write access. Print it; you will annotate it.
- 2
Decide what the controller needs
From the signal list: the process values to read, the status words, the commands and setpoints to write. Mark them on the map. Do not read the whole map; read what is needed, grouped.
- 3
Set the physical layer
RTU: baud rate, data bits, parity, and stop bits identical on both ends, commonly 9600 or 19200, 8, none or even, 1. Two-wire RS-485 with A to A and B to B, a signal common, and 120 ohm termination at both ends of the bus only. TCP: a static IP on the device in the control subnet, port 502 unless the manual says otherwise, and a switch port it can reach.
- 4
Set the unit identifier
RTU: the slave address, unique on the bus, 1 to 247. TCP: the unit ID, often 1 or 255, and required by gateways that front several serial devices. The manual says what the device expects.
- 5
Resolve the addressing offset
Modbus addresses on the wire are zero-based; register maps are often written one-based, and some use the traditional 40001 style for holding registers. Pick the first register, read it with the test tool at the documented number and at the number minus one, and see which returns the value the display shows. Apply that offset to every register in the map.
- 6
Build the read requests
Group contiguous registers into single requests of up to 125 holding registers or 2000 coils. A device that reports ten values in registers 100 to 119 is one request, not ten. Separate requests for different register types: coils and discrete inputs with function codes 1 and 2, input registers with 4, holding registers with 3.
- 7
Decode the data types
From the map: a 16-bit signed or unsigned integer, a 32-bit integer or float in two registers with the word order the device uses, a scaled integer with a documented multiplier, a bit-packed status word. Configure the controller conversion for each and note it on the map. Word order is the item most often wrong on 32-bit values.
- 8
Build the writes
One request per command or setpoint, with function code 6 or 16 for holding registers and 5 or 15 for coils, written only on change or on operator action, never every scan. Confirm the device accepts the function code; some accept only 16 even for a single register.
- 9
Verify with the test tool
Before the controller is involved, read every configured register with the test tool and compare with the device display or a known state. Change a value on the device and confirm the register changes. Write a harmless register and confirm it took.
- 10
Configure the controller
Enter the same requests in the controller Modbus configuration or instructions, with the poll rate, the timeout, and the retry count. Map the results to tags with descriptive names and the decoded engineering units.
- 11
Verify from the controller
Compare every tag with the device display. Confirm the communication status tag goes bad when the cable is pulled and good when it is restored. Confirm the controller logic treats a bad status as bad data, not as zero.
- 12
Record
The annotated register map, the serial or IP settings, the unit ID, the request list with function codes and addresses, the data type decoding, the poll rate and timeout, and the date, in the project documentation and on the network drawing.
Poll rate and timeout
| Setting | Typical value | Note |
|---|---|---|
| Poll rate | 500 ms to 5 s per device | As slow as the process allows; a serial bus with many devices shares the time, and each request takes tens of milliseconds at 9600 baud |
| Timeout | 1 s serial, 1 to 3 s TCP | Longer than the slowest device response including a radio hop; shorter than the poll rate |
| Retries | 2 or 3 | A device declared offline after retries fail, with a communication alarm |
| Inter-frame delay | 3.5 character times minimum on RTU | Some devices need more; a device that answers the previous request while the next is sent corrupts both |
Verification
- Every configured register reads correctly against the device display with the test tool and from the controller.
- A 32-bit value reads correctly at a value that would reveal a word order error, such as one above 65535.
- Each write changes the intended value on the device and nothing else.
- Pulling the cable produces a communication alarm within the timeout and retry period, and reconnecting clears it.
- The controller uses the communication status to invalidate the data.
- The register map annotations and the settings are in the project record.
Frequently asked questions
- The device returns values but they are wrong. What is the most likely cause?
- The addressing offset, the word order on 32-bit values, or a scaling factor from the map that was not applied. Read a register whose value you know from the display, and work through those three in that order.
- The device does not answer at all. Where do I start?
- On RTU: serial settings, A and B polarity, the unit address, and termination. Swap A and B and try again before anything else. On TCP: ping the device, then confirm port 502 with the test tool, then the unit ID. A gateway in front of a serial device often needs the unit ID of the serial device, not 1.
- How many devices can share an RS-485 bus?
- Electrically, 32 unit loads without a repeater, and more with modern low-load transceivers. Practically, the poll time per device times the device count sets the update rate, and a bus of a dozen devices at 9600 baud updates each every few seconds. Use a second port or a higher baud rate before it gets slow.
- Should the controller be the master or the device?
- The controller is the master and the device is the slave in nearly every case; the controller polls and writes. A device that must initiate, such as one that reports on exception, is not Modbus in the usual sense and needs a different protocol.
Related topics
- Modbus RTUSerial Modbus over RS-485: function codes, register addressing, the off-by-one that catches everyone, and the physical layer details that decide whether a bus is stable.
- Modbus TCPModbus over Ethernet: what the MBAP header changes, why the CRC disappears, how the unit identifier works, and what does not get easier just because it is on Ethernet.
- 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.
- Modbus Device Intermittently OfflineA device that answers most of the time. Termination, bias, timing, and the physical layer details that produce a bus which almost works.
- Signal ValidationCatching a failed analog input in logic before it runs a pump on a dead transmitter: range checks, module status bits, frozen-value detection, rate checks, and what the program does with a bad value.
- How to Scale a 4-20 mA Input in a PLCTurn raw analog counts into engineering units, verify at three points, and add the validity checks that stop a failed transmitter from producing a believable number.
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.