How to Connect a Modbus RTU PLC to SCADA Desktop

Modbus RTU still runs a huge share of the installed base — older PLCs, VFDs, and remote I/O modules that only speak serial. Connecting one to SCADA Desktop is a different process from a Modbus TCP setup: instead of an IP address and port, you're dealing with a physical COM port, wiring, and serial parameters that all have to match exactly. This guide walks through wiring, configuration, and troubleshooting for a clean RTU connection.

Modbus RTU vs Modbus TCP: What's Different for SCADA

If you've already connected a Modbus TCP PLC to SCADA Desktop, the tag mapping and dashboard steps will feel familiar — but the connection layer is completely different. TCP uses Ethernet, an IP address, and a port (typically 502), with no wiring or serial parameters to worry about. RTU uses a physical serial link (RS-485 for multi-drop networks, RS-232 for point-to-point), requires a COM port, and every serial parameter — baud rate, parity, data bits, stop bits — must match exactly between SCADA Desktop and the device. RTU is also inherently single-master: only one connection at a time can poll a given serial bus.

Step 1 — Wire the Serial Connection

Step 2 — Identify the COM Port

Plug in your USB-to-serial adapter and open Windows Device Manager (devmgmt.msc). Expand Ports (COM & LPT) to find the assigned COM port number (e.g. COM4). If the adapter doesn't appear, install the manufacturer's driver first — most common USB-serial chipsets (FTDI, CH340, CP2102) have their driver available from the adapter vendor's site.

Step 3 — Add the Modbus RTU Device in SCADA Desktop

Step 4 — Test the Connection

Use SCADA Desktop's built-in connection test before adding any tags. A successful test confirms wiring, COM port, and all serial parameters are correct. If it fails, work through the troubleshooting section below before moving on.

Step 5 — Map Registers to Tags

Once connected, add tags for the registers you need — Coils, Discrete Inputs, Input Registers, and Holding Registers — matching your device's documented register map. Name each tag clearly (e.g. Line2_VFD_Speed) and set the correct data type (integer, float, etc.) so values display properly.

Step 6 — Build a Dashboard and Alarms

Drag gauge, number, chart, and status widgets onto a dashboard canvas and bind each to a mapped tag, then configure threshold alarms on any tag that needs monitoring. This part of the workflow is identical whether the underlying connection is RTU or TCP.

Troubleshooting Common RTU Connection Issues

No response / connection times out

• Double-check baud rate, parity, data bits, and stop bits match the device exactly.
• Confirm the correct COM port is selected — USB adapters can shift port numbers after a reboot or when plugged into a different USB port.
• Verify the slave/unit ID matches the device's configured address.

Intermittent or garbled data on RS-485

• Check bus termination — a 120Ω resistor at each end of a long or multi-drop RS-485 run prevents signal reflection.
• Verify A/B (or D+/D−) polarity isn't reversed — some devices are tolerant of this, others aren't.
• Keep serial cable runs away from high-voltage or VFD power cabling to reduce electrical noise.

Only one device responds on a multi-drop bus

• Confirm every device on the bus has a unique slave/unit ID — duplicate IDs cause response collisions.
• Add each device as a separate entry in SCADA Desktop under the same COM port, with its own unit ID.

Testing Without Real Hardware

If your PLC or serial device isn't on-site yet, you can validate the entire RTU workflow — wiring logic aside — using a Modbus slave simulator over a virtual COM port pair (via free software like com0com). Point SCADA Desktop's RTU connection at one virtual port and the simulator at the paired port to confirm tags, dashboards, and alarms all work before any physical device arrives. The same simulator also supports Modbus TCP if you need to validate an Ethernet connection alongside your serial one.