Arduino Modbus RTU Slave — Setup and Testing Guide

Turning an Arduino into a Modbus RTU slave is a common way to bridge cheap sensors or actuators into an existing PLC/SCADA network without buying a dedicated field device. It takes one extra piece of hardware — an RS-485 transceiver — and a library that handles the RTU framing and direction-pin timing for you. This guide covers wiring, library choice, register mapping, and how to test the result against a simulated Modbus master before it ever touches a real PLC.

Hardware: RS-485 Transceiver and Wiring

Arduino has no native RS-485 port, so Modbus RTU requires a small transceiver module — almost always built around a MAX485 or MAX3485 chip:

• Module's RO (receiver output) → Arduino RX
• Module's DI (driver input) → Arduino TX
• Module's DE and RE pins — normally jumpered together — wired to one spare Arduino digital pin for direction control
• Module's A/B terminals → the RS-485 bus (twisted pair) to the master

The DE/RE pin is what makes RS-485 half-duplex work on a microcontroller: drive it high right before transmitting a response, then low again immediately after the last byte clears the UART so the module goes back to listening. Getting this timing wrong is the single most common source of corrupted Modbus frames on Arduino builds.

Choosing a Library

Library	Role	Notes
ArduinoModbus (official)	RTU (RS-485) and TCP (Ethernet/WiFi)	Maintained by the Arduino team; general-purpose, covers both transports
ModbusRTUSlave / ArduinoModbusSlave	RTU slave/server only	Purpose-built for slave behavior — function codes 1-6, 15, 16 with built-in DE/RE handling via preTransmission()/postTransmission()
SimpleModbusSlave (legacy)	RTU slave	Still appears in older tutorials; less actively maintained than the two above

Basic Slave Setup Pattern

1. Wire the DE/RE pin and choose a baud rate that matches the master — 9600, 19200, or 38400 are the most common
2. Set a unique slave/unit ID that the master will address
3. Map your data into holding registers (read/write, for setpoints) and input registers (read-only, for sensor values) as arrays your sketch updates in the main loop
4. Initialize the library on the Serial object you're using, registering the DE/RE pin before calling begin()
5. In the main loop, call the library's poll/task function so it can respond to incoming Modbus requests between your own sensor-reading code

Serial Port Gotcha: Uno/Nano vs Mega

An Uno or Nano has exactly one hardware UART, on pins 0/1 — the same port used for USB programming and Serial Monitor debugging. Wiring RS-485 directly to those pins means you lose your debug console and can interfere with sketch uploads. Most Uno/Nano builds instead run the RS-485 module on a SoftwareSerial port on two other pins (reliable up to roughly 38400 baud), while boards with multiple independent hardware UARTs, like the Mega, can dedicate a real hardware serial port to Modbus and keep USB Serial free for debugging.

Testing Against a Simulator Before a Real Master Arrives

Before wiring your Arduino into a live PLC or SCADA network, it's worth confirming the register map and function-code support independently:

1. Connect the Arduino's RS-485 bus to a PC via a USB-to-RS485 adapter
2. Run ModbusSimulator in Master mode, matching the Arduino's baud rate and slave ID
3. Poll the Arduino's holding and input registers directly and confirm the values match what your sketch is writing
4. Write to a holding register from the simulator and confirm the Arduino picks up the change on its next loop iteration
5. Deliberately disconnect the bus mid-poll to confirm the master side correctly reports a timeout rather than stale data — the same class of check covered in our Modbus timeout guide

This is the same simulate-before-you-wire-it-up approach covered for other constrained hardware in our Raspberry Pi Modbus slave guide, just adapted to RS-485/RTU instead of Ethernet/TCP.

Common Arduino Modbus RTU Errors

Garbled or missing responses

• Almost always a DE/RE timing issue — confirm the direction pin drops low only after the transmit buffer is fully flushed, not immediately after the last write() call returns

No response at all

• Double-check the slave ID matches what the master is polling, and that A/B wiring isn't reversed
• Confirm baud rate matches exactly on both ends — Modbus RTU has no auto-baud negotiation

Uploads fail or debug output disappears

• On Uno/Nano, this means RS-485 is wired to the hardware Serial pins (0/1) — move to SoftwareSerial or a board with a spare hardware UART