toolfora
Home / Debug / Modbus Tools / RTU Serial Debugger

RTU Serial Debugger

All-in-one Modbus RTU debugger running in your browser: connect a serial device via Web Serial, monitor HEX/TEXT traffic, send Modbus frames with cyclic polling, and parse register data into tables and charts with export.

Serial configuration

Not connected. Select a port to begin.

Log information

Serial traffic will appear here (TX / RX).

Modbus send

Modbus data parser

IndexTimeMessage

How to use the RTU serial debugger

Requirements

This tool uses the Web Serial API (Chrome / Edge 89+). Click Connect port and choose your serial device in the browser picker.

Serial configuration

Set baud rate, data bits, stop bits and parity to match the device (commonly 9600 / 8 / 1 / none), then connect. The port opens in binary mode, so any terminal/ASCII emulation on the device side will interfere.

Log information

Choose HEX or TEXT display. Auto clean trims the log once it exceeds Max lines. Incoming RTU frames are detected by function code and validated with the Modbus CRC-16 before being shown.

Modbus send

Build a request with slave, function, start address and quantity (HEX or DEC), then click Example to load the full frame into the send box, or type raw hex/text yourself. Cyclic send repeats the frame at the set interval (ms). Standard examples: read 10 registers 01 03 00 00 00 0A C5 CD; write 1 register 01 10 00 00 00 01 02 00 01 67 90.

Data parser

Add one or more parsing rules (rule name, start byte, data type, byte order, coefficient, constant, decimals). With Enable parsing on and source Serial data, every received frame is parsed live. Use Manual text to parse a pasted frame instead. Results appear as Raw messages, a Data table and a Data chart; Export CSV downloads the parsed table.

Protocol note: RTU frames are separated by a silent gap of at least 3.5 character times. If data looks garbled or split, lower the baud rate, disable flow control, and double-check the device's data bits / parity / stop bits. Register data types and byte order must match the device register table — a wrong order gives wrong values, especially for 32-bit and float data.