Every CIP I/O connection has a transport class — a single nibble in the Forward_Open Transport Class Trigger byte that decides how the connection behaves. Class 0, Class 1, Class 2, Class 3 — engineers see these terms in Studio 5000, in Wireshark captures, in product documentation — but rarely with a clear explanation of what each one… Read More: CIP Connection Types Explained: Transport Class 0, 1, 2, and… »

Every CIP device has one. Every browse of an EtherNet/IP network reads from it. Every Forward_Open validates against it. Every “what is this device” query touches it. The Identity Object (Class 0x01) is the most-accessed object on every CIP device — yet most articles barely cover it. This article fixes that. If you have ever wondered where Studio… Read More: CIP Identity Object Explained: How Every EtherNet/IP Device Identifies Itself »

An EDS file is a device’s résumé. It is plain text, it ships with the hardware, and your configuration software reads it so it does not have to know anything about your device in advance. Two industrial worlds use the same three letters for completely different files. CANopen has one EDS format. EtherNet/IP has another. They share an… Read More: EDS File Explained: CANopen and EtherNet/IP Device Files »

When a ControlLogix PLC reads inputs from a 1734-AENT Point I/O block, it does not read each input one by one. It reads one big block of bytes that contains every input in a defined order. That block is an Assembly Object instance. The Assembly Object is the mechanism CIP uses to bundle scattered data — input bits,… Read More: CIP Assembly Object Explained: How EtherNet/IP Devices Bundle I/O Data »

Every CIP I/O connection in the world starts with one service: Forward_Open. The PLC sends it to a remote drop, the drop validates it, and if everything checks out, the cyclic exchange begins. If something does not check out, the Forward_Open returns an error and the connection never opens — the device is invisible to the PLC until… Read More: CIP Forward_Open Service Explained: How Every EtherNet/IP Connection Starts »

When you read an attribute from a CIP device, the bytes you get back have a type. When you write a value, you must encode it in the right type or the device returns an error. This page is the complete reference for every CIP data type defined by ODVA’s CIP Networks Library Volume 1, Appendix C. CIP’s… Read More: CIP Data Types Complete Reference: Elementary, String, Time, and Structured… »

Every CIP message starts with a one-byte service code. That byte tells the target device what to do — read an attribute, write an attribute, open a connection, reset, save configuration. This page is the authoritative reference for every CIP service code defined by ODVA’s CIP Networks Library Volume 1, Appendix A. If services are the verbs of… Read More: CIP Service Codes Complete Reference: Common Services and Object-Specific Codes »

When a CIP service fails, the device returns an error response with a one-byte General Status Code that tells you why. This page is the complete reference for every code defined by the official CIP specification — what each one means, what usually causes it, and how to fix it. The codes come straight from ODVA’s CIP Networks… Read More: CIP General Status Codes Reference: Complete List with Troubleshooting »

Open Wireshark on an EtherNet/IP network and the first thing you see is not CIP. You see TCP. Then a strange 24-byte header. Then more bytes inside that look like CIP. The 24-byte header is the EtherNet/IP Encapsulation Protocol — the layer that wraps every CIP message onto a TCP/IP network. Nobody talks about it because everyone calls… Read More: EtherNet/IP Encapsulation Protocol Explained: The 24-Byte Header That Carries CIP »