Blog › Delta PLC Modbus RTU

Delta PLC Modbus RTU Configuration Guide (DVP Series & AS Series)

Published on August 3, 2026

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

  1. Open your project in WPLSoft (older ladder-only projects) or ISPSoft (newer IEC 61131-3 projects, required for AS series)
  2. Set COM2's communication protocol to Modbus RTU slave mode in the PLC's communication settings
  3. 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)
  4. Set the station (slave) address, also via a special register
  5. 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

  1. 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)
  2. 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
  3. 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
  4. 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 tier

Related Articles

Also from ModbusSimulator: