Allen-Bradley PLC Modbus Setup Guide (ControlLogix, CompactLogix, Micro800)

Allen-Bradley is one of the most common PLC brands engineers pair with a Modbus PLC simulator — but unlike Siemens or Schneider, ControlLogix and CompactLogix don't speak Modbus at all out of the box. Their native protocol is EtherNet/IP, which means Modbus TCP and RTU both require an extra piece: a free Add-On Instruction for TCP, or a third-party serial module for RTU. Micro800 is the one exception, with genuinely built-in Modbus support. This guide covers all three paths, then how to test the result against a simulated Modbus device before any field hardware shows up.

ControlLogix / CompactLogix: No Native Modbus

The MSG instruction in Studio 5000 / RSLogix 5000 has no built-in Modbus data type. To speak Modbus, you need one of these:

Protocol	What You Need	Hardware
Modbus TCP	Rockwell's free Modbus TCP AOI (wraps MSG's socket communication method)	1756-EN2T / EN2TR / EN3TR Ethernet module (firmware v20+). The older 1756-ENBT lacks socket services and won't work.
Modbus RTU (serial)	Third-party module — ProSoft MVI56(E)-MCM (ControlLogix) or 3100-MBP (CompactLogix chassis card)	Dedicated Modbus RTU/ASCII serial ports on the module, independent of the controller's own comms

Setting Up Modbus TCP with the AOI

1. Confirm the Ethernet module is a 1756-EN2T, EN2TR, or EN3TR — the AOI needs socket services the older EN2/ENBT modules don't provide
2. Import Rockwell's free Modbus TCP AOI into your Studio 5000 project
3. Configure the AOI instance with the target device's IP, port 502, and the Modbus function code (read holding registers, write coils, etc.)
4. Point the AOI's data parameters at the tags you want to read into or write from
5. Run the AOI in a Periodic task, not Continuous — on a long scan, Continuous tasks can queue up overlapping MSG requests and stall

Modbus RTU Serial with an MVI56(E)-MCM / 3100-MBP Module

Since ControlLogix/CompactLogix have no native RTU port, a ProSoft (or equivalent) module handles the Modbus RTU/ASCII conversation on its own independent serial ports and exposes the resulting data to the backplane as normal controller tags. Configuration lives in the module's own utility, not in ladder logic — you map Modbus registers to backplane data blocks, then read/write those blocks like any other I/O in your program.

Micro800: Native Modbus, No Add-Ons

Micro820 and Micro850 controllers are the exception in the Allen-Bradley lineup: Modbus RTU Master/Slave over serial and Modbus TCP Client/Server over Ethernet are built directly into Connected Components Workbench, with no AOI or add-on module required. If your project has flexibility on which controller to use, Micro800 is by far the simpler path to Modbus.

Testing Against a Simulator Before Field Devices Arrive

Because ControlLogix/CompactLogix Modbus setups involve an extra AOI or module layer, it's especially useful to validate the logic before real meters or VFDs are on site:

1. Run ModbusSimulator in Slave mode (TCP or RTU, matching your setup) on a PC
2. Point the AOI's IP/port, the MVI56(E)-MCM's serial settings, or the Micro800's native Modbus instruction at the simulator
3. Load the target device's real register map into the simulator so the values your PLC reads match what the actual field device will return
4. Force test values and step through your program's scaling/byte-order logic — see our byte order guide for the common word-swap pitfalls
5. Stop the simulator mid-poll to confirm your MSG/AOI timeout logic (error 0x0005) correctly flags the fault instead of holding stale data

This mirrors the general workflow in our PLC Modbus testing tool guide, and the same AOI-timeout troubleshooting steps as our Siemens Modbus TCP guide, adapted to Allen-Bradley's socket-based Modbus TCP AOI instead of Siemens' native MB_CLIENT/MB_SERVER.

Common Allen-Bradley Modbus Errors

MSG/AOI returns error 0x0005

• This is a timeout — confirm the target IP and port 502 are reachable and not blocked by a firewall
• Move the AOI to a Periodic task if it's currently in Continuous, so requests don't overlap on a long scan

MSG/AOI returns error 0x0001

• Invalid communication path — double-check the IP address, port, and that the Ethernet module supports socket services (1756-EN2T/EN2TR/EN3TR, not 1756-ENBT)

Values read back wrong, huge, or negative

• Byte/word-order mismatch is the most common cause — use a SWAPB instruction or the AOI's swap configuration, and test with a known register value like 0x0102/0x0304 to confirm the order