Match the master exactly. Modbus RTU is always 8 data bits; the settings are locked while connected — disconnect to change them.
Frames for any other unit id are ignored, as on a real bus. Id 0 is a broadcast: writes are applied and never answered.
The master works on the simulator. Now watch the real device.
When the meter or drive arrives, Synacl reads it every few seconds from an ESP32 gateway: live charts, history and alerts when a value drifts. Five devices free, no card.
- Test the real slave too. The Modbus RTU tester scans ids and finds the baud rate.
- A gateway in minutes. Flash an ESP32 from the browser flasher.
- Alerts when it drifts. Email, webhook or MQTT on a threshold.
- Five devices free. Compare the plans.
How to simulate a Modbus RTU slave
A Modbus master only ever needs something on the bus that answers the way a device would. This page is that something: it listens on the serial port, recognises every request addressed to its unit id, and answers from the register map below.
- Wire the adapter to the master's RS485 pair. A to A, B to B. If nothing arrives, swap A and B — the labelling is not consistent between vendors and swapping them does no harm.
- Match the serial settings. Baud rate, parity and stop bits must be the master's.
9600 8N1and9600 8E1are the usual two. - Set the unit id the master polls, and fill in the registers it expects. The address column shows the wire address and the
4xxxxform side by side, so a datasheet's40002is easy to find: it is wire address1. - Start the master. Every request and reply appears in the traffic log; every value the master writes lands in the table and flashes.
No PLC on the desk? Plug a second USB-RS485 adapter into the same laptop, wire the two together, and open the Modbus RTU tester in another tab as the master. That is a complete Modbus bench for two cheap adapters.
Why there is no online Modbus TCP simulator
A Modbus TCP slave is a server: it listens on port 502 and the master connects to it. Web pages cannot listen for incoming connections — no browser API allows it, for good security reasons — so a Modbus TCP slave simulator that runs in a browser is impossible, whoever builds it. Serial is different: Web Serial lets a page open a USB serial port, and on an RS485 bus a slave is simply the device that answers. That is why this simulator is RTU only.
For Modbus TCP, use a desktop tool such as diagslave, ModbusPal or a pymodbus server. Or keep this page and put a Modbus TCP-to-RTU gateway in front of it: the master talks TCP to the gateway, and the gateway talks RTU to the simulator.
Testing how a master handles faults
A master that only ever sees perfect replies has not been tested. Each fault below should produce a different, specific error in a well-written master — if two of them look the same in its log, that is worth knowing before a real device does it at 3am.
| Fault | What the master should report |
|---|---|
| No reply | A timeout — and a retry, if it retries. The write still lands, as when a reply is lost on the wire. |
| Corrupt the CRC | A CRC or checksum error, not a timeout. Many masters discard the frame and time out instead. |
| Wrong unit id | A reply from an unexpected slave. The frame is otherwise perfect, so this checks the master looks at the address. |
| Cut short | An incomplete frame, then a timeout. |
| Delay | A timeout if the delay beats its timeout, and then no confusion when the late reply arrives during the next request. |
| Exception | The exception code by name. Nothing is read or written. |
Questions this page gets asked
Mostly about wiring, and about what a browser can and cannot do.
What hardware do I need?
A USB-to-RS485 adapter on the laptop running this page, wired to the same RS485 pair as the master you are testing: A to A, B to B, and a ground wire if the run is more than a desk long. Any adapter with automatic direction control works; the common CH340, CP2102 and FTDI ones do. With no PLC to hand, a second adapter on the same laptop and the Modbus RTU tester in another tab make a complete bench.
Can I simulate a Modbus TCP slave here?
No, and no web page can. A Modbus TCP slave has to listen on port 502 for the master to connect to it, and browsers do not let a page accept incoming TCP connections at all. That is why every online Modbus simulator you find is either a download or RTU only. For TCP, use a desktop simulator such as diagslave or pymodbus. Or put a Modbus TCP to RTU gateway in front of this page: the master talks TCP to the gateway, and the gateway talks RTU to the simulator.
Which function codes does it answer?
Read coils (01), read discrete inputs (02), read holding registers (03), read input registers (04), write single coil (05), write single register (06), write multiple coils (15) and write multiple registers (16). Any other function gets exception 01, Illegal Function, exactly as a real device that does not implement it would answer. Addresses outside the map get exception 02 and bad quantities exception 03. Frames with a bad CRC or for another unit id get no answer at all.
My master times out. What should I check?
Watch the traffic log first. If nothing arrives, the problem is the wiring or the serial settings: A and B swapped, or a different baud rate or parity from the master's. If requests arrive but are logged as CRC errors, the baud rate or parity is close but wrong. If requests arrive for another unit id, change the unit id here. If they arrive and are answered but the master still times out, raise its timeout to 200 ms or more: a browser and a USB adapter add a few milliseconds that a hardware slave does not.
How do I test how my master handles errors?
Use the fault injection panel. It can skip the reply, corrupt the CRC, answer from the wrong unit id, cut the reply three bytes short, delay it, or answer with any exception code, either on the next reply only or on every reply until you switch it off. These are the same faults the hardware test slave we use for our own gateway firmware injects, so each one should produce a distinct, specific error in a well-written master.
Can I save the register map?
Yes. The map, the names and the data types are kept in this browser between visits, and you can export them as JSON, to load back later exactly as they were, or as CSV, to edit in a spreadsheet and import again. Nothing is stored on a server.
Is anything uploaded?
No. The requests your master sends and the values you set never leave your browser. The only network request the tool makes is one anonymous ping (a GET to /tools/_/…, no cookies, no identifiers) the first time something happens, such as a request being answered, so we know the tool is used.
Why does it not work in Firefox or Safari?
Talking to a serial port from a web page needs the Web Serial API, which only Chromium-based desktop browsers implement: Chrome, Edge, Opera, Arc and Brave. Firefox and Safari have declined to ship it, and no mobile browser has it. Keep the simulator's tab visible while you test, too: browsers slow down timers in background tabs, which can delay a reply.