ethernet/ip
cip
rockwell
EtherNet/IP Scanner vs Adapter: How It Works
If you have ever added an EtherNet/IP device in Studio 5000 and wondered why you pick 'Input' and 'Output' assembly instances rather than just typing a register address, this post will clear that up. The scanner/adapter model is the thing that makes EtherNet/IP fundamentally different from Modbus TCP, and once you understand it you will configure drives, remote I/O and third-party sensors a lot faster.
EtherNet/IP Is CIP Running on Standard Ethernet
EtherNet/IP is not a separate physical layer or a proprietary cable. It is the Common Industrial Protocol (CIP) transported over standard IEEE 802.3 Ethernet using TCP and UDP. ODVA owns the spec, and it is the same CIP object model that runs on DeviceNet and ControlNet, which is why the three protocols share a lot of tooling and terminology.
CIP defines two classes of messaging that matter most in day-to-day PLC work: Class 1 (implicit / I/O messaging) and Class 3 (explicit messaging). Almost everything you do with remote I/O and drives uses Class 1. Explicit messaging is for reading/writing individual attributes on demand, things like reading a drive's fault code or changing a parameter from ladder logic.
Scanner and Adapter: The Two Roles
Every EtherNet/IP device is either a scanner (also called originator in the CIP spec) or an adapter (also called target). A CompactLogix or ControlLogix CPU is always the scanner. Remote I/O blocks, drives, valve manifolds and smart sensors are adapters. The scanner initiates all connections; adapters sit and wait for a connection request.
One scanner can maintain connections to many adapters simultaneously, limited by the controller's connection budget. A 1769-L33ER CompactLogix supports 256 CIP connections. A 1756-L84E ControlLogix goes to 4000. Exceed that budget and the next device you try to add will simply refuse to connect, which is a fun commissioning surprise if you haven't checked.
Class 1 I/O Messaging: The Cyclic Heartbeat
Class 1 is the workhorse. The scanner opens a Forward Open request to the adapter, negotiating the connection parameters: assembly instance numbers, data size, and the Requested Packet Interval (RPI). Once the connection is established, the adapter sends its input data to the scanner and the scanner sends output data to the adapter on every RPI tick, whether anything changed or not. It is a heartbeat model, not a poll-response model like Modbus.
RPI is your primary tuning knob. It runs over UDP, not TCP, specifically because UDP is lower overhead and there is no connection-setup handshake per packet. Typical RPI values: 10 ms for a drive you need fast torque response from, 20 ms for a remote I/O block controlling pneumatics, 100 ms for a barcode reader you only care about once per pallet. Setting everything to 1 ms is a common mistake that chews through network bandwidth and CPU time with no real benefit.
| Application | Typical RPI | Note |
|---|---|---|
| Servo/drive torque loop | 2 to 5 ms | Match to drive's own task rate |
| Remote discrete I/O (1734 POINT I/O) | 10 to 20 ms | Most applications are fine at 20 ms |
| Remote analog I/O | 20 to 50 ms | Signal rarely changes faster than 20 ms |
| Valve manifold (DeviceNet bridge) | 20 ms | Pneumatics don't benefit below 20 ms |
| Smart camera / vision sensor | 50 to 100 ms | Result is valid for many scan cycles |
Assembly Objects: What You Actually Map
The data that flows over a Class 1 connection lives in assembly objects inside the adapter. An assembly object is just a block of bytes, packed according to the device vendor's spec, with a fixed instance number. Input assembly (data flowing from device to PLC) and output assembly (data from PLC to device) each get their own instance number.
When you add a device in Studio 5000 manually (without an EDS file), you type these numbers in yourself. For a PowerFlex 525 drive on EtherNet/IP, the default Input assembly is instance 21 (4 words: status, output frequency, output current, fault code) and the Output assembly is instance 1 (2 words: control word and speed reference). If you want more data, you switch to a larger assembly instance: instance 27 gives you 16 words in and instance 3 gives you 16 words out. These numbers come from the drive manual and they are not guesswork.
EDS Files: Why They Save You From Guessing
An Electronic Data Sheet (EDS) file is a plain-text description of every assembly the device supports, the valid instance numbers, data sizes, and parameter definitions. When you install an EDS file in Studio 5000 via the EDS Hardware Installation Tool, the software fills in the assembly instances and sizes automatically. You get a drop-down list of assembly configurations instead of blank boxes to type numbers into.
Get the EDS from the device manufacturer's website, never from a third-party aggregator. A stale or wrong EDS file for an older firmware version will give you incorrect assembly sizes, and the connection will either fail or map the wrong bytes. Firmware version and EDS version need to match, especially for Rockwell drives where the assembly layout changed between firmware generations.
Class 3 Explicit Messaging: Reading Parameters on Demand
Explicit messaging runs over TCP and is request/response. You use it when you need to read or write a specific CIP attribute that is not in the cyclic assembly, like reading a drive's DC bus voltage for a maintenance display, or writing a new acceleration ramp value based on a recipe. In Studio 5000, the MSG instruction handles explicit messaging. You configure it with the service code (0x0E for Get Attribute Single, 0x10 for Set Attribute Single), the class, instance, and attribute numbers from the device manual.
Explicit messages are not real-time. They complete in one scan cycle or span several, depending on network load and device response time. Never use explicit messaging for anything that needs to happen within your normal I/O scan window. And do not trigger an explicit MSG every scan cycle without a one-shot; that will flood the network and may cause the device to drop the connection.
Step-by-Step: Adding a Generic EtherNet/IP Device in Studio 5000
Here is the actual process for adding a device without an EDS file, which is the skill that gets you out of trouble when you are on-site with an unfamiliar third-party device.
- In the I/O Configuration tree, right-click the Ethernet module and select New Module.
- Filter by ETHERNET-MODULE (the generic profile). Select it and click OK.
- Give it a name (no spaces, 40 chars max). This becomes the tag prefix in your program.
- Enter the IP address of the adapter device.
- Set the Comm Format: Input Data, Output Data, or Input/Output. Match this to what the device actually supports.
- Enter the Input Assembly Instance, Input Size (in 16-bit words or 32-bit DINT depending on comm format), Output Assembly Instance, and Output Size. These come from the device manual.
- Enter the Configuration Assembly Instance (often 0x04 or 0x66). Size is usually 0 unless the device requires a startup configuration block.
- Set the RPI in milliseconds. Start conservatively at 20 ms and tighten if needed.
- Click OK. The module goes into the tree. Download and go online. A green checkmark means the Forward Open succeeded. A red X means a connection error, check the error code in the module properties.
Reading the Connection Status in Your PLC Program
Every generic Ethernet module in Studio 5000 creates a tag of type AB:ETHERNET_MODULE:C:0 with a .CommStatus member. More practically, each module has a Module Fault bit at [ModuleName]:I.ConnectionFaulted. Use this in your ladder logic to inhibit outputs if the remote I/O drops. If you don't, and the drive link goes down, your output assembly freezes at its last state and the drive may keep running or may trip depending on its configured fault action.
EtherNet/IP Connection Fault Inhibit and HMI Alarm (Studio 5000). Ladder logic (3 rungs): Rung 0: examine if Drive_EIP:I.ConnectionFaulted is off (XIO), then examine if Drive_RunCmd is on (XIC), then energize output Drive_EIP:O.Data[0].0 (OTE). Rung 1: examine if Drive_EIP:I.ConnectionFaulted is on (XIC), then examine if EIP_Fault_OS is on (XIC), then latch output EIP_Fault_Alarm (OTL). Rung 2: examine if EIP_Fault_Alarm is on (XIC), then examine if HMI_AlarmAck is on (XIC), then examine if Drive_EIP:I.ConnectionFaulted is off (XIO), then unlatch output EIP_Fault_Alarm (OTU). Rung 1: The Run command only passes to the drive's output assembly word 0, bit 0 (the CIP Run/Stop bit) when the EtherNet/IP connection is healthy. If ConnectionFaulted is set, the output is forced off. Rung 2: A rising-edge one-shot latches an HMI alarm on the first scan of a connection fault. Rung 3: The operator can acknowledge and clear the alarm only after the connection recovers.
EtherNet/IP vs Modbus TCP: The Practical Difference
Both protocols run on standard Ethernet, but they work very differently. Modbus TCP is poll-response: your PLC asks, the device answers. EtherNet/IP Class 1 is producer-consumer: once the connection is open, data flows on every RPI without any polling. This means EtherNet/IP latency is bounded and predictable, while Modbus TCP latency depends on how often your scan loop gets to that poll request. For a drive or remote I/O you need sub-20 ms response, EtherNet/IP is the right tool. For reading a meter or a temperature controller once a second, Modbus TCP is simpler and you probably already have an existing post on it: Modbus RTU Protocol Explained covers the framing fundamentals that carry over to the TCP variant.
| Feature | EtherNet/IP (CIP) | Modbus TCP |
|---|---|---|
| Transport | UDP (Class 1), TCP (Class 3) | TCP only |
| Data model | CIP object/assembly | Register map (coils, holdings) |
| Timing model | Producer-consumer, fixed RPI | Poll-response, software-dependent |
| Real-time I/O | Yes, Class 1 down to 1 ms RPI | Not natively; depends on poll rate |
| Configuration effort | Medium (EDS file or manual assembly config) | Low (just register address and count) |
| Device discovery | ODVA EtherNet/IP tools, Wireshark | Modbus client scan tools |
| Typical use | Drives, remote I/O, robots, smart sensors | Power meters, PLCs from other vendors, simple sensors |
Common Commissioning Gotchas
- Wrong subnet mask: The scanner and adapter must be on the same subnet or routed correctly. A CompactLogix at 192.168.1.10/24 cannot reach a drive at 192.168.2.20/24 without a router. Use the /tools/ip-subnet-calculator if you are unsure about subnet boundaries.
- Duplicate IP address: EtherNet/IP devices use ARP to detect duplicates, but only at power-up. Two devices can silently share an IP if one was powered on before the other. The BOOTP/DHCP server tool from Rockwell (or any ARP scan) will expose this.
- Connection timeout with no error: Usually caused by a firewall or managed switch ACL blocking UDP port 2222 (CIP I/O) or TCP port 44818 (CIP explicit). Check switch port security settings.
- Output assembly size mismatch: If your configured output size is larger than what the adapter expects, you get Status 0x13 (Not Enough Data) or 0x15 (Too Much Data). Always verify size in words against the device manual.
- RPI too fast for the device: Some older devices cannot sustain 2 ms RPI and will drop the connection under load. Start at 20 ms, verify stable operation, then reduce if needed.
