Modbus RTU Serial Port Troubleshooting on Windows 10/11

Getting a COM port to appear in Device Manager is only step one. Plenty of Modbus RTU setups have a perfectly visible, driver-installed COM port and still refuse to communicate. If your adapter isn't showing up at all, start with our USB to serial COM port not showing guide. This guide covers everything after the port exists — the configuration and wiring issues that cause silence, timeouts, or garbled frames once Windows already sees the hardware.

Step 1: Confirm the Port Opens Without Conflict

Before touching baud rate or wiring, make sure nothing else has the port locked. Only one application can hold a Windows serial port open at a time — a second Modbus tool, a terminal emulator, or even a PLC programming suite that didn't release the port on exit will block every other program with a generic "access denied" or "port already in use" error. Check Task Manager for orphaned processes and close any other serial tool before retrying.

Step 2: Match Serial Parameters on Both Ends

Modbus RTU has no auto-negotiation — baud rate, data bits, parity, and stop bits must match exactly on master and slave. A mismatch here is the single most common cause of "no response" or CRC failures once the port itself is confirmed open.

Symptom	Likely Setting Mismatch
Complete silence, no response at all	Baud rate mismatch, or wrong slave/unit ID
Response arrives but fails CRC / looks like garbage	Parity or stop-bit mismatch (e.g. 8N1 configured, device expects 8E1)
Works at short distance, fails over longer cable runs	Baud rate too high for cable length/quality; try stepping down
First byte of every frame looks corrupted	Framing/parity error at connection start — verify stop bits

Common industrial defaults worth trying first: 9600 or 19200 baud, 8 data bits, even parity, 1 stop bit (8E1), or 8N1 with no parity if the device documentation doesn't specify. Always confirm against the device's actual manual — guessing wastes more time than checking the datasheet up front.

Step 3: Check the Physical Layer (RS-485/RS-232 Wiring)

Once software settings match and the port still won't talk, the fault is almost always physical:

• Reversed A/B (or D+/D-) polarity — the single most common RS-485 wiring fault. It typically produces total silence with no error, not a clear "wrong wiring" message. Swap the two wires at one end and retest.
• Missing common ground — RS-485 needs a shared reference between devices on longer runs; a floating ground can cause intermittent corruption that looks like a software bug.
• Missing or incorrect termination resistors — on longer or noisier RS-485 buses, missing 120Ω termination at the bus ends causes reflections that show up as sporadic CRC errors under load.
• TX/RX swapped on RS-232 — point-to-point RS-232 links need TX on one end wired to RX on the other; a straight-through cable where a null-modem was needed (or vice versa) produces the same "port opens, nothing happens" symptom.

Isolate Software From Wiring With a Simulator

The fastest way to know whether you're chasing a settings bug or a wiring bug is to remove the real hardware from the equation entirely:

1. Install a virtual COM port pair (e.g. com0com) — no physical hardware involved.
2. Run ModbusSimulator's RTU slave mode on one virtual port and your master application on the other.
3. If communication succeeds on the virtual pair with the same baud/parity settings, your software stack and configuration are correct — any remaining failure against the real device is wiring, termination, or the physical adapter, not your settings.

ModbusSimulator shows every raw frame it sends and receives, so you can compare byte-for-byte against what your real device returns, and it auto-detects COM port, baud rate, and slave ID on the master side to speed up matching settings. If your adapter isn't appearing as a COM port at all yet, that's a separate, earlier problem — covered step by step in the USB to serial COM port not showing guide.

Related Guides

See the Modbus RTU vs TCP comparison for framing differences, or Modbus slave not responding for a broader checklist that also covers TCP-side causes. If you're evaluating simulator options generally, see the free download guide.

Frequently Asked Questions

My Modbus RTU COM port shows up in Device Manager but I still get no response. Why?

A visible COM port only confirms the driver is installed. Communication also needs matching baud rate, parity, data bits, and stop bits on both ends, correct slave/unit ID, and correct A/B (or TX/RX) wiring. Any mismatch produces silence or garbled frames even though the port itself opens fine.

How do I know if my baud rate or parity setting is wrong?

Symptoms include timeouts with no response at all, or responses that fail CRC checks and appear as garbage bytes. Common industrial defaults are 9600 or 19200 baud, 8 data bits, even parity, 1 stop bit (8E1) or no parity (8N1) — try both if the device documentation is unclear.

What does "port already in use" mean and how do I fix it?

Only one application can hold a serial port open at a time. Close any other Modbus tool, terminal program, or background service (some PLC programming suites keep a port open after closing their main window) and check Task Manager for a lingering process before retrying.

How do I fix reversed A/B wiring on RS-485?

If communication fails entirely or is intermittent on an RS-485 link, swap the A and B (sometimes labeled D+/D- or +/-) terminals at one end of the cable. Reversed A/B is one of the most common physical-layer Modbus RTU faults and produces no error message — just silence or timeouts.

How can I test Modbus RTU wiring and settings without the real PLC?

Use a virtual COM port pair (such as com0com) with a Modbus simulator acting as both master and slave to confirm your software stack and settings are correct first. If that works, any remaining failure against the real device points to wiring, termination, or the adapter itself.