Arduino + MAX485 Timeout? DE/RE Control Fix

Here’s the classic maker trap: your Arduino Modbus slave sketch answers perfectly when the PC talks to it over a USB-to-TTL cable — every read in QModMaster succeeds. Then you swap in a MAX485 module for real RS485, and QModMaster just says timeout, no response. The sketch didn’t change. The slave ID didn’t change. What changed is the physics of the bus — and the fix is two wires. This exact failure was reported on the Arduino Forum (a user’s slave worked via USB but timed out over a MAX485 module), and the diagnosis there is still the right one: it’s the MAX485 transceiver direction control — the DE/RE pins.

Why USB works and MAX485 doesn’t

A USB-to-TTL cable is full-duplex: transmit and receive have their own wires, so the Arduino can listen and talk at the same time. RS485 is half-duplex: the A/B pair is shared, and the MAX485 chip needs to be told which direction it’s going. That’s what the DE (Driver Enable, transmit) and RE (Receiver Enable, receive) pins do:

  • DE = HIGH: the MAX485 drives the bus — the Arduino is transmitting.
  • DE = LOW (RE = LOW): the MAX485 listens — the Arduino is receiving.

If DE/RE are left floating, tied to the wrong level, or toggled by a library that doesn’t wait for transmission to finish, the Arduino’s reply never actually makes it onto the bus — and QModMaster sees a timeout. Per the forum diagnosis, the library must hold the MAX485 in transmit mode for the whole time the reply is being sent; simply pushing bytes into the serial buffer and flipping back to receive too early is enough to break it.

The wiring (text diagram)

Wire DE and RE together to one Arduino digital pin (D2 is the common choice). One pin then controls the direction: HIGH = transmit, LOW = receive.

MAX485 module          Arduino
-----------          -------
  VCC        ----    5V
  GND        ----    GND
  DI         ----    TX  (Arduino transmit → MAX485 data in)
  RO         ----    RX  (MAX485 data out → Arduino receive)
  DE + RE    ----    D2  (tied together; direction control pin)
  A          ----    RS485 bus A
  B          ----    RS485 bus B

  120 Ω resistor across A–B at EACH END of the bus (termination)

Two practical notes: on an Arduino Uno the hardware serial port is shared with USB, so use a software serial port for the MAX485 side and keep hardware serial free for USB debugging. And A/B are differential — if everything is wired right but you still get timeouts, try swapping A and B once (a reversed pair fails silently).

The code fix: drive the direction pin properly

Your Modbus library must know about the direction pin and hold it HIGH for the entire reply transmission — including waiting for the last byte to physically leave the UART — before dropping back to receive. Libraries built for RS485 expose this as a “TX enable pin” setting or pre/post-transmission callbacks. If your current library has no direction-pin support at all, that’s your answer: switch to one that does, set the TX enable pin to D2 (or whichever pin you wired), and retest. Don’t try to toggle the pin manually around library calls — the timing (waiting for the transmit buffer to fully drain) is exactly what goes wrong.

QModMaster-side checklist

Once DE/RE is wired and the library handles it, verify from the PC side:

  • Slave ID in QModMaster must match the ID in the sketch.
  • 9600 8N1 on both ends — QModMaster’s serial options and the sketch’s baud rate must agree.
  • Read one register first. A single-register read is the smallest possible transaction; get that working before scanning ranges.
  • No duplicate slave IDs on the bus — two devices answering the same ID produces intermittent garbage, not clean timeouts, but rule it out anyway.
  • Termination: 120 Ω across A–B at both bus ends. Missing termination mostly bites on longer runs.

The adapter for the PC side

USB-to-RS485 adapter (Amazon) — your PC needs one to join the RS485 bus at all. Pick an FTDI-based adapter; this is the page where a flaky adapter will waste the most of your time, because its symptoms look exactly like the DE/RE problem above.

FAQ

My Arduino Modbus slave works over USB-to-TTL but times out with MAX485. What’s wrong?
The DE/RE direction pins. USB-to-TTL is full-duplex and needs no direction control; RS485 is half-duplex, and if the MAX485 isn’t held in transmit mode for the whole reply, the response never reaches the bus.

Can I just tie DE high and RE low permanently?
No — then the module transmits constantly and can never receive the master’s request. DE and RE must be tied together to a GPIO and driven HIGH only while transmitting, LOW while receiving.

I fixed DE/RE and still get timeouts. What next?
Verify the slave ID matches the sketch, 9600 8N1 on both sides, try swapping A/B once, and confirm the library waits for the UART transmit buffer to drain before dropping DE back to receive. Then try a single-register read in QModMaster.

Related Guides

The USB-works/MAX485-times-out symptom and the transceiver-control diagnosis come from a real Arduino Forum thread (“MODBUS Slaves with Arduino”). Pin choices (D2) and wiring conventions are standard maker practice — adapt to your board and library. qmodmaster.com is an independent community resource for the upstream QModMaster project (LGPLv3) and is not affiliated with Arduino.

Similar Posts