Mitsubishi PLC Modbus Communication Setup (FX5U, Q Series)

Mitsubishi's Modbus story is split across two very different product lines: the newer iQ-F FX5U handles Modbus TCP natively through software configuration but only as a client, while the MELSEC-Q series needs a dedicated intelligent module to speak Modbus at all. This guide covers configuring both, plus adding Modbus RTU where the built-in ports don't support it, and validating your setup against a Modbus simulator before field devices arrive.

FX5U: Modbus TCP Client via Predefined Protocol Support

Feature	FX5U Built-In Ethernet
Modbus TCP client (master)	Yes — via Predefined Protocol Support, up to 8 simultaneous connections
Modbus TCP server (slave)	Not supported — the FX5U cannot accept incoming Modbus TCP connections
Default port	502 (configurable, 1–65535)
Configuration tool	GX Works3 → Parameter → FX5U CPU Module Parameter → Ethernet Port → Basic Settings → Modbus TCP Settings

This client-only limitation is the single most important fact to know before designing an integration around an FX5U: if your architecture needs the PLC to respond to Modbus TCP polls from a SCADA system or another master, the FX5U's built-in port can't do it. You'd need a third-party gateway or a different Mitsubishi product for that role — the FX5U can only be the one initiating requests.

Configuring FX5U Modbus TCP in GX Works3

1. Open your project's CPU parameters and navigate to the Ethernet Port → Basic Settings → Modbus TCP Settings section
2. Enable Modbus TCP and set the port (502 by default)
3. Add each target device's IP address and the specific Modbus function code / register range to poll — the FX5U treats each as a client request, similar to how the Predefined Protocol handles other Ethernet protocols
4. Download the parameters and confirm the connection status in GX Works3's diagnostics before relying on the polled data in your program logic

Adding Modbus RTU: FX5-485ADP and FX3U-485ADP-MB

Neither the FX5U nor FX3U speaks Modbus RTU over their built-in ports out of the box. To add it:

• FX5U: add an FX5-485ADP adapter, which supports Modbus RTU/ASCII in both master and slave modes over RS-485
• FX3U: add an FX3U-485ADP-MB (RS-485) or FX3U-232ADP-MB (RS-232), both with the same master/slave Modbus RTU/ASCII support

This is the opposite trade-off from Delta's DVP series (see our Delta PLC Modbus RTU guide), where RTU is built into the CPU and TCP is the newer AS-series addition — for Mitsubishi's FX line, TCP is the CPU-native option and RTU is the add-on.

MELSEC-Q Series: QJ71MB91 Module

Q-series CPUs have no native Modbus support at all — communication requires the QJ71MB91 intelligent communication module, configured with GX Configurator-MB:

• Supports Modbus RTU and Modbus ASCII over RS-232 (CH1) and RS-422/485 (CH2)
• Can run as master, slave, or both simultaneously — the module's synchronization function lets CH1 poll downstream devices as a master while CH2 answers an upstream SCADA/DCS master on the same module
• Configuration (station numbers, baud rate, register mapping) is done through GX Configurator-MB's parameter screens, separate from the main GX Works2 ladder project

This module-based approach is closer in spirit to Allen-Bradley's MVI56(E)-MCM serial module for ControlLogix (covered in our Allen-Bradley Modbus setup guide) than to the CPU-native support found on Modicon or newer Mitsubishi FX5 hardware.

Testing Against a Simulator Before Field Devices Arrive

1. For FX5U: since it's Modbus TCP client-only, run ModbusSimulator in Slave mode (TCP) on a PC, then point the FX5U's Predefined Protocol Modbus request at the simulator's IP and port 502
2. For Q-series QJ71MB91 or FX3U/FX5 RTU adapters in master mode, run the simulator in Slave mode over RTU (virtual/USB COM port) instead
3. Load the target device's real register map into the simulator so values line up with what the actual sensor, drive, or meter will return
4. Force test values and check for scaling/byte-order issues — see our byte order guide for common word-swap pitfalls
5. Stop the simulator mid-poll to confirm your program correctly detects a lost connection rather than continuing to use stale data

This follows the same validation pattern described in our PLC Modbus testing tool guide — confirm the client/master side of your logic against a simulated device first, which matters even more here given the FX5U's client-only constraint means the simulator must always play the slave role in that scenario.

Common Mitsubishi Modbus Issues

FX5U "communication timeout" on a Modbus TCP request

• Remember the FX5U can only be the client — confirm the target device (or simulator) is actually running in server/slave mode and listening on the configured port
• Check the polling interval isn't faster than the target device can respond

QJ71MB91 not responding on either channel

• Verify GX Configurator-MB's parameters were actually written to the module (a separate step from the main CPU program download) and that the module's mode switch/parameters match master or slave as intended

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 cause — test with a known value like 0x0102/0x0304 in the simulator before trusting real hardware