Delta PLC Modbus RTU Configuration Guide (DVP Series & AS Series)
Delta's DVP-series PLCs are common on packaging, textile, and machine-builder lines across Asia and increasingly worldwide, and nearly every model has Modbus RTU built into its RS-485 port — no serial add-on card required. This guide covers configuring Modbus RTU slave mode in WPLSoft/ISPSoft, how D and M registers map onto the Modbus address space, what the newer AS series adds, and how to validate your program against a simulated device before real hardware shows up.
Native Modbus RTU on the Built-In RS-485 Port
Most DVP-series CPUs — ES2, SS2, SX2, SE, SA, SC, and EH3 — have a Modbus RTU-capable RS-485 port built directly into the CPU, usually labeled COM2:
| Series | Modbus RTU Port | Default Settings | Configuration Needed |
|---|---|---|---|
| DVP (ES2/SS2/SX2/SE/SA/SC/EH3) | Built-in RS-485 (COM2) | 9600 bps, 8E1, station 1 | Set COM2 to Modbus RTU slave mode via WPLSoft/ISPSoft; write comm format + station number to special registers, then power-cycle |
| AS series (AS200/AS300) | Built-in RS-485 + built-in Ethernet | Ethernet: Modbus TCP on port 502 by default | RS-485 configured the same way as DVP; Ethernet port needs Modbus TCP enabled in the network configuration |
This is one of the reasons Delta shows up so often in retrofit projects: adding Modbus RTU communication to an existing machine usually means wiring a two-wire RS-485 cable to a port that's already there, not sourcing and licensing an extra communication module.
Configuring Modbus RTU Slave Mode in WPLSoft / ISPSoft
- Open your project in WPLSoft (older ladder-only projects) or ISPSoft (newer IEC 61131-3 projects, required for AS series)
- Set COM2's communication protocol to Modbus RTU slave mode in the PLC's communication settings
- Write the desired baud rate, parity, and stop bits into the special data registers that control COM2's communication format (consult your specific CPU's manual for the exact register numbers — they differ slightly between DVP sub-series)
- Set the station (slave) address, also via a special register
- Download the project and power-cycle the CPU — communication format changes on Delta PLCs typically only take effect after a full power cycle, not just a program download
D and M Register Mapping to Modbus Addresses
Delta's native memory areas don't use Modbus terminology directly, so a mapping step is required:
- D registers (data registers) are exposed as Modbus holding registers. A common generic-HEX-mode formula is Modbus address = D register number + 4096 (so D0 lands around holding register 4096) — but treat this as a starting point, not a universal constant. The exact offset can vary by firmware version and by whether the port is running a combined mode (e.g., AS-series Ethernet ports that also support EtherNet/IP alongside Modbus TCP). Always cross-check against the mapping table in WPLSoft/ISPSoft before wiring anything external to it.
- M devices (internal relay/coils) map to Modbus coils, following a similar offset pattern.
This D-register-to-holding-register model is conceptually similar to Modicon's %MW-to-holding-register mapping covered in our Schneider Modicon Modbus TCP guide — both vendors expose a native memory area directly as Modbus registers rather than requiring an explicit tag-mapping table like Allen-Bradley's AOI approach (see our Allen-Bradley Modbus setup guide).
Testing Against a Simulator Before Field Devices Arrive
- Run ModbusSimulator in Slave mode (RTU over a virtual/USB-to-serial COM port, matching your Delta PLC's baud/parity/stop-bit settings and station address)
- Load the target device's real register map into the simulator so the D/M values your PLC reads line up with what the actual sensor, meter, or drive will return
- Force test values in the simulator and confirm your ladder/ST logic scales them correctly — see our byte order guide if 16-bit/32-bit values come back swapped
- Disconnect the simulator mid-poll to confirm your program's timeout/fault handling correctly flags a lost connection instead of holding the last-good D-register value silently
This mirrors the general validation workflow in our PLC Modbus testing tool guide — get the register mapping and scaling right against a simulated device first, since re-wiring and re-testing against real field hardware is far more time-consuming once a machine is on the shop floor.
Common Delta Modbus RTU Issues
No response from the PLC over Modbus RTU
- Confirm COM2 was actually switched to Modbus RTU mode (it's easy to leave it on Delta's proprietary point-to-point protocol by mistake) and that the CPU was power-cycled after the change
- Double-check baud rate, parity, and stop bits match on both ends — Delta's 8E1 default catches people who assume 8N1
D-register values don't match the expected holding register
- Re-verify the offset formula against your specific CPU's manual rather than assuming +4096 universally applies — AS-series combined-protocol modes in particular can shift it
Values read back scaled wrong or byte-swapped
- As with every PLC brand, byte/word-order mismatches on 32-bit values are the most common root cause — test with a known value like 0x0102/0x0304 in the simulator before trusting real sensor readings
Test Your Delta Modbus RTU Program Without Field Hardware
ModbusSimulator runs as a Modbus RTU or TCP slave (or master) on your PC, so you can validate your Delta DVP or AS-series D/M register mapping, scaling, and timeout logic before a single sensor or drive is wired up. Free 30-day trial.
Download Free tierRelated Articles
- Mitsubishi PLC Modbus Communication Setup (FX5U, Q Series)
- Schneider Modicon Modbus TCP Configuration Guide
- Allen-Bradley PLC Modbus Setup Guide
- Siemens S7-1200/S7-1500 Modbus TCP Setup Guide
- WinCC SCADA Modbus Integration and Testing Guide
- Ignition SCADA Modbus Driver Testing Guide
- PLC Modbus Testing Tool: Test Communication Without Field Devices
- Modbus Byte Order Explained: Big-Endian vs Little-Endian