Modbus Protocol: RTU, ASCII and TCP Basics
1. What is Modbus?
Modbus is an application-layer messaging protocol for exchanging data between controllers and devices. RS-485 and RS-232 are electrical interfaces; Modbus RTU, ASCII and TCP define corresponding message and transport formats. An RS-485 interface does not automatically imply Modbus support.
In fluid control it may read status or transmit control parameters. Support, function codes and registers must be confirmed in the communication manual of the exact controller. This article does not claim that every FOREACH product supports these interfaces.
2. How do RTU, ASCII and TCP differ?
A connector alone cannot identify the mode. Serial devices must match transmission mode, baud rate and frame format; TCP requires compatible network and device-service settings.
| Mode | Message structure | Check |
|---|---|---|
| Modbus RTU | Address + Function code + Data + CRC | Serial settings, device address and frame timing |
| Modbus ASCII | ASCII encoding with LRC and defined start/end characters | Serial settings, encoding and LRC |
| Modbus TCP | MBAP header + Function code + Data; no additional RTU CRC | IP address, port, transaction identifier and Unit Identifier |
3. Serial addresses and request–response
Serial unicast device addresses are 1–247; 0 is broadcast and 248–255 are reserved. The controller normally initiates a unicast request and the addressed device responds. Broadcast write requests receive no response. An 8-bit address field does not make every value from 0 to 255 a valid individual address.
These rules concern serial links. Modbus TCP has a Unit Identifier in the MBAP header; its gateway routing meaning depends on the implementation. Do not apply serial addressing rules blindly to every TCP configuration.
4. Read function codes together with the register map
The function code identifies the data type and read/write operation; the data field contains addresses, quantities or values. Two Modbus devices do not necessarily share register definitions.
Check whether manual register numbers and message starting addresses have an offset. Confirm width, signedness, scaling, units and word order for multi-register values. Speed, position and liquid-volume values are not interchangeable.
| Direction | Normal serial unicast message |
|---|---|
| Controller → Device | Address | Function code | Data | CRC (RTU) / LRC (ASCII) |
| Device → Controller | Address | Function code | Data | CRC (RTU) / LRC (ASCII) |
| Function code (hex) | Operation |
|---|---|
| 01 | Read coils |
| 02 | Read discrete inputs |
| 03 | Read holding registers |
| 04 | Read input registers |
| 05 | Write single coil |
| 06 | Write single register |
| 0F | Write multiple coils |
| 10 | Write multiple registers |
5. Commissioning a fluid-control device
Confirm wiring and power first, then match the communication settings to the manual. Start by reading a known status and checking device address, function code and data meaning, before testing permitted parameter writes and motion commands.
Verify communication success, command acceptance, completed motion and delivered volume separately. A write acknowledgment does not prove that the pump has finished. After a timeout, query status before repeating a dispensing command to avoid duplicate dosing.
Record requests, replies, exception codes and timeout conditions. Use limits, homing, valve state and sequence timing to locate problems. Exact commands, addresses and counting units come from the device communication manual.