How to Configure CIP (EtherNet/IP) on Allen-Bradley Controllers

By | July 2, 2026

On an Allen-Bradley controller, “CIP” and “EtherNet/IP” are the same conversation. CIP is the protocol — the object model, the services, the way data is named. EtherNet/IP is CIP running on top of standard Ethernet. When you configure a Rockwell PLC to talk to a drive, a remote I/O block, a camera, or another controller, you’re configuring EtherNet/IP, and CIP is what’s moving underneath.

The whole job comes down to one decision made early: implicit or explicit. Get that right and the rest is filling in forms. Get it wrong and you’ll spend an afternoon fighting a connection that was never going to work the way you set it up.

This walks through both paths in Studio 5000 (the same steps apply to older RSLogix 5000, with different menu names here and there). We’ll start with the CIP model — just enough to make the config screens make sense — then the two messaging types, then the fault codes you’ll actually hit.

First, the one decision: implicit or explicit

EtherNet/IP moves data two ways. Everything you configure depends on which one you need.

Implicit messaging is cyclic. The controller and the device swap the same block of data over and over, at a fixed rate you set. It’s real-time, connected, and runs on UDP. This is how you bring a device into the I/O tree so its data shows up as tags you can use in logic. Drive feedback, remote I/O, sensor values — implicit. Also called Class 1, or just “I/O.”

Explicit messaging is on-demand. You ask for one specific thing when you want it — read a parameter, write a setpoint, pull a diagnostic. It’s request/response, runs on TCP, and in Studio 5000 it’s the MSG instruction. Configuration reads, one-off writes, controller-to-controller transfers — explicit. Also called Class 3 or UCMM.

The quick test: if you need the data every scan, use implicit. If you need it now and then, use explicit. Many machines use both — a drive brought in as I/O for speed and status, plus a MSG now and then to change a parameter.

Ports, if you’re checking a firewall: implicit I/O uses UDP 2222, explicit messaging uses TCP 44818. Both need to be open end to end.

The CIP model in 60 seconds

You don’t need the full spec, but explicit messaging asks you for four numbers and they’ll look like nonsense without this.

CIP treats every device as a collection of objects. Each object is one class — a numbered type. An Identity object (class 0x01) holds vendor and device info. An Assembly object (class 0x04) holds blocks of I/O data. A device can have several objects of the same class, and each one is an instance. Inside an instance, each value is an attribute.

So to read one value over explicit messaging, you name four things: the service (read or write), the class, the instance, and the attribute. That’s the “class / instance / attribute” the MSG screen keeps asking for. The two services you’ll use most:

  • 0x0E — Get_Attribute_Single (read one attribute)
  • 0x10 — Set_Attribute_Single (write one attribute)

The Assembly object matters for implicit too. When you set up an I/O connection, the “assembly instances” you type in are pointing at that device’s Assembly object — one instance for the data coming in, one for the data going out, one for config. Hold that thought; it comes up in a minute.

Where do the actual numbers come from? The device’s manual or its EDS file. Not from guessing, and not from another device’s manual. This is the single biggest source of connections that won’t come up.

Set the IP address before anything else

Skipped-step number one. The device needs an IP on the same subnet as the controller’s Ethernet port before Studio 5000 can reach it. Three common ways to set it:

  • BOOTP/DHCP tool — the classic Rockwell utility. Catch the device’s MAC on the network, assign an IP, then disable BOOTP so it keeps the address.
  • RSLinx Classic — browse to the device and set the IP through its module configuration.
  • Studio 5000 — set it in the module properties once the device is in the tree, or with the controller’s built-in tools.

Ping it before you go further. If it doesn’t ping, no amount of CIP config will help.

Path A — Implicit messaging (bring a device into the I/O tree)

This is the Generic Ethernet Module workflow. Use it when the device is a Class 1 EtherNet/IP server — a drive, a remote I/O adapter, a smart sensor — and you want its data as live tags.

Add-On Profile or Generic Ethernet Module

First check whether the device has an Add-On Profile (AOP) or an EDS file. If it does — and most Rockwell drives and many third-party devices do — use it. Register the EDS through Tools → EDS Hardware Installation Tool, then add the device by name. The profile fills in the assembly instances and sizes for you and gives you named tags. Fewer mistakes, cleaner tags. Always the better route when it exists.

If there’s no profile, you fall back to the Generic Ethernet Module (in the module list as ETHERNET-MODULE). This is the manual route, and it’s where the assembly numbers come back to bite people.

The Generic Ethernet Module steps

  1. In the Controller Organizer, find the Ethernet port under I/O Configuration. If there’s no Ethernet module there yet, add the controller’s Ethernet port first.
  2. Right-click the Ethernet port → New Module.
  3. Pick Generic Ethernet Module (ETHERNET-MODULE).
  4. Give it a name and the device’s IP address.
  5. Set the Comm Format. This decides how the data is sized. Data - INT is 16-bit words and the safe default for most devices. Data - DINT is 32-bit, Data - SINT is bytes. Get this wrong and every value lands in the wrong place.
  6. Fill in the Connection Parameters — the part everyone gets stuck on:
ParameterWhat it is
Input — Assembly InstanceThe device’s assembly instance that holds the data it sends to the controller
Input — SizeHow many elements (in the Comm Format’s units) that input holds
Output — Assembly InstanceThe assembly instance for data the controller sends to the device
Output — SizeHow many elements the output holds
Configuration — Assembly InstanceThe config assembly; often size 0
Configuration — SizeUsually 0 for simple devices

Every one of those numbers comes from the device’s manual or EDS. There is no universal default. A camera, a drive, and an I/O block all use different instances and sizes. If the manual lists an assembly table, that’s your source. If it doesn’t, the vendor’s support line does.

  1. Set the RPI (Requested Packet Interval) on the Connection tab — how often the data refreshes, often 20 ms to start. Don’t set it lower than the device allows.
  2. Download.

Where the data lands

Once the connection is running, Studio 5000 creates tags named after the module:

  • ModuleName:I — input data (from the device)
  • ModuleName:O — output data (to the device)
  • ModuleName:C — config data

Inside each is a .Data array. That’s what you read and write in logic. The input tag also carries a connection-fault bit, so you can trip an alarm if the link drops.

A running I/O connection shows a solid green icon in the tree. Flashing, or a yellow triangle, means it’s not there yet — jump to the fault codes below.

Path B — Explicit messaging (the MSG instruction)

Use MSG when you want one value on demand, not a cyclic stream. There are two flavors, and picking the right one saves a lot of grief.

CIP Data Table Read / Write — for Logix-to-Logix

If you’re moving data between two Logix controllers (ControlLogix, CompactLogix), use CIP Data Table Read or CIP Data Table Write. You work with tag names, not object numbers. No class, no instance, no attribute.

  1. Add a MSG instruction on a rung, gated by a trigger.
  2. Create a MESSAGE tag for it.
  3. Message Type: CIP Data Table Read (pull from the remote controller) or Write (push to it).
  4. Source element and destination — the local tag and the remote tag name.
  5. Set the Communication Path to the remote controller (browse to it, or type the route).

This is the clean way for PLC-to-PLC. Both controllers just need to be reachable on the same network.

CIP Generic — for everything else

For a third-party device, a drive parameter, or a specific CIP object, use CIP Generic. Now you’re back to the four numbers from the CIP model:

  1. Message Type: CIP Generic.
  2. Service Code: 0x0E to read one attribute, 0x10 to write one.
  3. Class / Instance / Attribute: straight from the device manual.
  4. Source / Destination: the local tag, sized to match the data.
  5. Path: to the target. For a device in the same chassis this is often something like 1, 0 (backplane, slot); for an Ethernet device you browse to it or route through the Ethernet module.

The MSG rule that trips everyone

The MSG instruction is edge-driven and it manages its own status bits: .EN (enabled), .DN (done), .ER (error), .TO (timeout).

Two habits to keep:

  • Wait for .EN to clear before you re-fire or change parameters. Editing a MSG’s fields while .EN is still set gives you fault 16#0206 (path unavailable) and unpredictable behavior.
  • Don’t self-retrigger a MSG as fast as the scan allows. Many device adapters run a modest processor and choke on rapid-fire requests, which shows up as a 16#0204 timeout that looks like a network problem but isn’t. Space requests out with a timer — 200 ms to 1 s between them is normal for a slow adapter — and run multiple messages in sequence, not all at once.

One more limit: a ControlLogix controller supports up to 128 CIP connections, but in practice keep concurrent MSG traffic to a handful. And you can’t make an array of MESSAGE tags — Studio 5000 won’t allow it — so a message queue with indirect addressing is the usual pattern when you need many.

The third option: Produced / Consumed tags

Between Logix controllers there’s a middle path. A Produced tag on one controller is shared cyclically with a Consumed tag on another, over a real CIP connection — implicit-style, but tag-based and set up in the tag editor rather than the I/O tree. It’s lower overhead than repeated MSG reads when two controllers need to trade the same data continuously. Worth knowing exists; for most “read a value now and then” jobs, a CIP Data Table MSG is simpler.

Fault codes you’ll actually see

When a connection won’t come up or a MSG errors, the code tells you where to look. These are the common ones.

CodeMeaningWhere to look
16#0204Connection timed outDevice not reachable at that IP, or the adapter is being flooded with too many requests. Ping it; slow the MSG rate.
16#0005Bad class / profile mismatchThe controller and device disagree on the profile or object. Check the class number and the selected profile.
16#0109Invalid connection (input) sizeInput size doesn’t match what the device sends. Fix the size against the manual.
16#0127Invalid output sizeOutput size is wrong for the device.
16#0111RPI out of rangeRPI is faster than the device allows. Raise it.
16#012AInvalid application pathAssembly instance points somewhere the device doesn’t have.
16#0206Path to destination unavailableUsually a MSG being edited or re-fired while .EN is still set. Wait for .EN = 0.
16#0311Bad pathThe Communication Path is wrong — check the route to the target.

The pattern: size and instance errors (0109, 0127, 012A, 0005) mean the numbers you typed don’t match the device — go back to its manual. Timeout and path errors (0204, 0311, 0206) mean the controller can’t reach or hasn’t finished with the target — check the network and your trigger logic.

Verify it

When status and data both look off, stop guessing and check the connection directly.

  • Ping the device. No ping, no CIP.
  • Module icon in the I/O tree — solid green means the implicit connection is running.
  • GSV on EntryStatus — read the module object’s EntryStatus attribute into a DINT. Divide by 4096; a result of 4 means the connection is established and running. Handy when you want the status in logic, not just the tree.
  • Wireshark with the CIP dissector — filter on the device IP and watch the actual CIP traffic. You’ll see the connection open (or fail), the service codes going out, and any error responses coming back. An exception response with a status byte points straight at a wrong class, instance, or size.

Frequently asked questions

Is CIP the same as EtherNet/IP on an Allen-Bradley PLC? Effectively, yes, for configuration purposes. CIP is the protocol — the objects, services, and data model. EtherNet/IP is CIP carried over standard Ethernet. When you configure EtherNet/IP in Studio 5000, CIP is what’s actually moving.

What’s the difference between implicit and explicit messaging? Implicit (I/O, Class 1) is cyclic, real-time data set up in the I/O tree — you get live tags. Explicit (MSG, Class 3) is on-demand read/write using the MSG instruction. Use implicit for data you need every scan, explicit for occasional reads and writes.

What assembly instance and size do I enter in the Generic Ethernet Module? Whatever the device’s manual or EDS file specifies — there’s no universal value. Input and output each have their own instance number and size, and config is often size 0. Wrong numbers give a connection fault like 16#0109 or 16#012A.

Why do I get error 16#0204? Connection timeout. Either the device isn’t reachable at that IP (ping it, check the subnet and cabling), or a MSG is firing too fast and overwhelming a low-power adapter. Space MSG requests out with a timer.

Data – INT or Data – DINT for Comm Format? Data - INT (16-bit words) fits most devices and is the safe default. Data - DINT (32-bit) shifts the address mapping, so only use it if the device’s manual calls for it. Mismatched Comm Format is a classic cause of data landing in the wrong registers.

Do I need an EDS file? Not always, but use one when it exists. An EDS or Add-On Profile fills in the assembly instances and sizes and gives you named tags, which is cleaner and less error-prone than the Generic Ethernet Module. Register it through Tools → EDS Hardware Installation Tool.

How many CIP connections can a controller handle? A ControlLogix controller supports up to 128 CIP connections, but keep concurrent explicit messages to a handful to protect scan time. For many messages, use a sequenced queue rather than firing them all at once.

Which ports does EtherNet/IP use? Explicit messaging runs on TCP 44818. Implicit I/O runs on UDP 2222. Both must be open across any firewall between the controller and the device.

Quick reference

  • CIP = the protocol, EtherNet/IP = CIP on Ethernet. Same job on Allen-Bradley.
  • Implicit = cyclic I/O, in the I/O tree, live tags, UDP 2222.
  • Explicit = MSG on demand, TCP 44818.
  • Generic Ethernet Module = manual I/O setup; assembly instances and sizes come from the device manual.
  • CIP Data Table MSG for Logix-to-Logix, CIP Generic MSG for everything else.
  • Wait for .EN = 0 before re-firing a MSG; don’t self-retrigger fast.
  • Faults: size/class errors = wrong numbers; timeout/path errors = can’t reach it.

Pick the right messaging type up front, pull the assembly numbers or the class/instance/attribute from the real device manual, and set the IP before you start. Do those three things and EtherNet/IP on Allen-Bradley is routine. Almost every failed connection traces back to one of them.

Author: Zakaria El Intissar

I've spent 13 years in power system automation, electrical protection, and SCADA communication, as an automation and industrial computing engineer. ScadaProtocols.com is where I turn what I've learned on site into plain guides and working tools — so other engineers can decode, analyze, and troubleshoot industrial communication protocols without the guesswork.