Chapter 196: Ethernet/IP Protocol Basics

Chapter Objectives

By the end of this chapter, you will be able to:

• Understand the fundamental concepts of the Ethernet/IP protocol.
• Describe the relationship between Ethernet/IP, CIP, TCP/IP, and Ethernet.
• Identify key Ethernet/IP components like Objects, Instances, Attributes, and Services.
• Differentiate between Explicit and Implicit messaging in Ethernet/IP.
• Recognize the roles of Scanner and Adapter devices in an Ethernet/IP network.
• Understand the Ethernet capabilities of various ESP32 variants in the context of Ethernet/IP.
• Appreciate the complexity involved in implementing a full Ethernet/IP stack on an embedded device.

Introduction

Welcome to the world of industrial automation! As manufacturing and industrial processes become increasingly interconnected, the need for robust and standardized communication protocols is paramount. Ethernet/IP (EtherNet/Industrial Protocol) is a leading industrial network protocol that adapts the Common Industrial Protocol (CIP) to standard Ethernet (IEEE 802.3). It allows devices from different vendors to exchange information for control, configuration, and data collection purposes.

You’ve learned about basic Ethernet connectivity and TCP/IP networking with the ESP32 in previous chapters. This chapter builds upon that knowledge by introducing you to Ethernet/IP, a higher-level protocol that leverages these underlying technologies for industrial applications. Understanding Ethernet/IP basics is crucial if you aim to integrate your ESP32-based devices into industrial control systems, enabling them to communicate with Programmable Logic Controllers (PLCs), Human-Machine Interfaces (HMIs), robots, and other industrial equipment.

While implementing a full Ethernet/IP stack on an ESP32 is an advanced task, this chapter will provide you with the foundational knowledge required to understand its principles and how an ESP32 might participate in such a network.

Theory

Ethernet/IP is an application layer protocol and is part of a larger suite of network protocols called CIP (Common Industrial Protocol), managed by ODVA (Open DeviceNet Vendors Association). CIP provides a common object-oriented framework for organizing and exchanging data in industrial automation systems. Other networks based on CIP include DeviceNet, ControlNet, and CompoNet.

Ethernet/IP in the OSI Model

Ethernet/IP leverages the standard Ethernet and TCP/IP suite. Its relationship with the OSI model can be visualized as follows:

• Application Layer: CIP (Ethernet/IP application objects and services)
• Presentation Layer: (Handled by CIP’s object-oriented nature and data encoding)
• Session Layer: (Managed by CIP connections)
• Transport Layer: TCP (for explicit messaging) and UDP (for implicit/I/O messaging)
• Network Layer: IP (Internet Protocol)
• Data Link Layer: Ethernet (IEEE 802.3)
• Physical Layer: Ethernet (e.g., twisted pair copper, fiber optic)

This layered approach means Ethernet/IP can coexist with other standard internet protocols (like HTTP, FTP) on the same Ethernet network infrastructure, which is a significant advantage.

Core CIP Concepts

Since Ethernet/IP is CIP on Ethernet, understanding core CIP concepts is essential:

1. Objects: CIP defines a collection of standard, predefined objects that represent common functionalities and data in industrial devices. Examples include the Identity Object, TCP/IP Interface Object, Assembly Object, and Connection Manager Object. Vendors can also define custom objects for device-specific features. Each object is a template or class.
2. Instances: An instance is a specific realization of an object class. For example, if a device has two Ethernet ports, there might be two instances of the “Ethernet Link Object,” one for each port.
3. Attributes: Attributes are the data items or characteristics associated with an object instance. For example, the Identity Object has attributes like Vendor ID, Device Type, Product Code, and Serial Number. Attributes can be read-only or read-write.
4. Services: Services are actions that can be performed on objects or their attributes. Common services include Get_Attribute_Single, Set_Attribute_Single, Get_Attribute_All, etc. These services define how devices interact with the objects and their data.
5. Connections: CIP uses the concept of connections for exchanging data. There are two main types:
   • Unconnected Messages (UCMM): Used for non-real-time, request/response interactions, typically for configuration, diagnostics, or infrequent data exchange. These are often peer-to-peer messages.
   • Connected Messages: Used for real-time, cyclic data exchange, often referred to as I/O data. These messages are established through the Connection Manager object.

Ethernet/IP Device Types

In an Ethernet/IP network, devices typically fall into one of two roles:

1. Scanner (Client/Originator): A scanner device initiates communication by requesting data from or sending data to adapter devices. PLCs often act as scanners, polling I/O devices and sending control commands. The scanner “originates” the connection for I/O data.
2. Adapter (Server/Target): An adapter device responds to requests from scanners and provides data or accepts commands. Sensors, actuators, variable frequency drives (VFDs), and I/O blocks are typically adapters. The adapter is the “target” of the connection for I/O data.

An ESP32 device could potentially be programmed to act as an adapter (e.g., a smart sensor providing data to a PLC) or, in more complex scenarios, even a simple scanner.

graph TD
    subgraph Industrial Network
        %% Node Definitions
        PLC["<b>Scanner (PLC)</b><br><i>Originator</i><br>Initiates Connections"]

        subgraph "Adapters (Targets)"
            direction LR
            ESP32_Sensor(<b>Adapter:</b><br>ESP32-based Sensor)
            VFD(<b>Adapter:</b><br>Variable Frequency Drive)
            IO_Block(<b>Adapter:</b><br>Remote I/O Block)
        end

        %% Styling
        classDef scanner fill:#EDE9FE,stroke:#5B21B6,stroke-width:2px,color:#5B21B6
        classDef adapter fill:#DBEAFE,stroke:#2563EB,stroke-width:1px,color:#1E40AF

        class PLC scanner
        class ESP32_Sensor,VFD,IO_Block adapter

        %% Connections with labels
        PLC -- "Sends Commands<br>Requests Data" --> ESP32_Sensor
        PLC -- "Controls Speed" --> VFD
        PLC -- "Reads Inputs<br>Writes Outputs" --> IO_Block
        ESP32_Sensor -- "Provides Sensor Readings" --> PLC
        VFD -- "Reports Status" --> PLC
        IO_Block -- "Provides Input Status" --> PLC
    end

Communication Mechanisms

Ethernet/IP utilizes two primary communication mechanisms, both built on top of CIP:

1. Explicit Messaging:
   • Used for information that is not time-critical, such as configuration parameters, device status, or diagnostic data.
   • It employs a request/response model. A client sends a request to access an object’s attribute or execute a service, and the server responds.
   • Explicit messages are typically transported over TCP/IP, using well-known port 44818. This ensures reliable delivery.
   • These messages encapsulate CIP service requests and responses.
2. Implicit Messaging (I/O Messaging):
   • Used for time-critical, real-time data exchange between a scanner and an adapter (e.g., sensor readings, control outputs). This is often referred to as I/O data.
   • Data is exchanged cyclically at a pre-configured rate, known as the Requested Packet Interval (RPI).
   • Implicit messages are typically transported over UDP/IP, using well-known port 2222. UDP is chosen for its low overhead and speed, though it doesn’t guarantee delivery (reliability is often handled at the application or CIP layer through timeouts and sequence numbers).
   • The data exchanged is typically a predefined block of bytes representing specific inputs and outputs, defined by Assembly Objects.

Electronic Data Sheets (EDS Files)

EDS (Electronic Data Sheet) files are simple text files provided by device manufacturers. They describe the device’s Ethernet/IP capabilities, including its supported objects, attributes, services, and connection configuration parameters. Configuration tools and scanners use EDS files to understand how to communicate with a specific adapter device, making integration easier.

ESP-IDF and Implementing Ethernet/IP

The ESP-IDF (Espressif IoT Development Framework) provides robust support for Ethernet connectivity (via the Ethernet MAC in some ESP32 variants or external SPI Ethernet controllers) and a full TCP/IP stack (lwIP). These are essential prerequisites for any Ethernet/IP implementation. You’ve learned about setting up Ethernet in Chapter 76 and TCP/IP socket programming in Volume 4.

However, ESP-IDF does not include a native, built-in Ethernet/IP stack. Implementing the CIP protocol, with its object model, services, and connection management, is a significant undertaking.

To implement Ethernet/IP on an ESP32, you would typically need to:

1. Utilize a third-party Ethernet/IP library: Several open-source or commercial libraries provide CIP and Ethernet/IP functionality. Examples include:
   • OpENer: A popular open-source Ethernet/IP adapter stack (github.com/EIPStackGroup/OpENer). Porting and integrating such a stack into an ESP-IDF project requires careful handling of its dependencies, memory management, and adaptation to the ESP32’s RTOS and networking APIs.
   • Other commercial stacks or custom developments.
2. Develop a custom lightweight implementation: For very specific and limited functionality (e.g., supporting only a few attributes of the Identity Object), a custom implementation might be feasible but is generally not recommended for full compliance or complex applications due to the protocol’s intricacy.

For this “Basics” chapter, we focus on understanding the protocol rather than implementing a stack. The exercises will guide you through exploring the underlying network setup and researching the structure of an existing open-source stack.

Variant Notes

The ability of an ESP32 variant to support Ethernet/IP is primarily determined by its capability to establish a stable Ethernet connection and run a TCP/IP stack. The application-layer Ethernet/IP protocol itself is software-defined.

• ESP32: Features an integrated 10/100 Mbps Ethernet MAC. It requires an external PHY (e.g., LAN8720, TLK110) and appropriate connections (RMII interface). This makes it a good candidate for Ethernet/IP applications requiring wired connectivity, assuming sufficient processing power and memory for the Ethernet/IP stack.
• ESP32-S2: Does not have a built-in Ethernet MAC. To use Ethernet, you would need an external SPI-to-Ethernet module (e.g., W5500, ENC28J60). Performance might be limited by the SPI bus speed compared to the integrated MAC on other variants, but it’s viable for less demanding Ethernet/IP applications.
• ESP32-S3: Similar to the original ESP32, the ESP32-S3 includes an integrated 10/100 Mbps Ethernet MAC requiring an external PHY. Its dual-core processing power and larger memory capacity make it a strong candidate for more demanding Ethernet/IP applications, including potentially running more complex object models or faster RPIs.
• ESP32-C3: Does not have a built-in Ethernet MAC. Like the ESP32-S2, it requires an external SPI-to-Ethernet module. As a single-core RISC-V MCU, resource constraints (CPU, memory) should be carefully considered when planning to run an Ethernet/IP stack.
• ESP32-C6: Some ESP32-C6 SoCs and modules do feature an integrated 10/100 Mbps Ethernet MAC (requiring an external PHY), similar to the ESP32 and ESP32-S3. This makes it suitable for wired Ethernet/IP applications. Always check the specific datasheet of your ESP32-C6 module. Its RISC-V architecture and feature set offer another option for industrial connectivity.
• ESP32-H2: Does not have a built-in Ethernet MAC. It would require an external SPI-to-Ethernet module for wired Ethernet connectivity. Its primary focus is on IEEE 802.15.4 (Thread, Zigbee) and Bluetooth LE.

Key Consideration: Regardless of the variant, running an Ethernet/IP stack (especially a full-featured one) consumes processing power and memory (RAM for connection objects, buffers, and ROM for the code itself). Always evaluate these requirements against the chosen ESP32 variant’s capabilities. The ESP-IDF’s Ethernet and lwIP components provide the necessary foundation, but the Ethernet/IP layer is an add-on.

Common Mistakes & Troubleshooting Tips

Exercises

Exercise 1: Research CIP Objects

1. Task: Research the Common Industrial Protocol (CIP). Identify and list at least five common CIP objects that are fundamental to most Ethernet/IP devices.
2. Details: For each object, briefly describe its purpose and list two or three important attributes it typically contains.
3. Hint: Start by looking for the “Identity Object,” “Message Router Object,” “Assembly Object,” and “TCP/IP Interface Object.” The ODVA website is a good resource.

Exercise 2: Basic Ethernet TCP Communication Setup

This exercise reinforces the foundational networking required before attempting to layer Ethernet/IP.

1. Task: Create an ESP-IDF project for your ESP32 variant that has Ethernet capabilities (either built-in MAC + external PHY, or via an SPI Ethernet module like W5500).
2. Objective: Initialize the Ethernet interface, obtain an IP address (DHCP or static), and establish a simple TCP client connection to a TCP server running on your PC. Send a “Hello from ESP32!” message and receive a response.
3. Steps:
   • Refer to Chapter 76 (Ethernet Interface on ESP32 Variants) for setting up the Ethernet connection. You’ll need to configure the PHY, MAC, and event handlers.
   • Use the BSD Sockets API (Chapter 85: TCP Socket Programming Basics) to create a TCP client.
   • On your PC, use a tool like netcat (Linux/macOS) or a simple Python TCP server script to act as the server. <!– end list –>
   Bash# Example using netcat to listen on port 1234 nc -l -p 1234
   • Or a simple Python server: <!– end list –> “`python import socket
   HOST = ‘0.0.0.0’ # Listen on all available interfaces PORT = 1234 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.bind((HOST, PORT)) s.listen() print(f”Listening on port {PORT}…”) conn, addr = s.accept() with conn: print(f”Connected by {addr}”) data = conn.recv(1024) if data: print(f”Received: {data.decode()}”) conn.sendall(b”Hello from PC Server!”)
4. Code Snippet (Conceptual – main logic for TCP client):

// Placeholder for necessary includes for Ethernet and Sockets
#include "esp_netif.h"
#include "esp_eth.h"
#include "esp_event.h"
#include "esp_log.h"
#include "lwip/sockets.h"

#define SERVER_IP_ADDR "YOUR_PC_IP_ADDRESS" // Replace with your PC's IP
#define SERVER_PORT 1234

// ... (Ethernet initialization code from Chapter 76) ...

static void tcp_client_task(void *pvParameters) {
    char rx_buffer[128];
    char addr_str[128];
    int addr_family = AF_INET;
    int ip_protocol = IPPROTO_IP;
    struct sockaddr_in dest_addr;

    dest_addr.sin_addr.s_addr = inet_addr(SERVER_IP_ADDR);
    dest_addr.sin_family = AF_INET;
    dest_addr.sin_port = htons(SERVER_PORT);

    int sock = socket(addr_family, SOCK_STREAM, ip_protocol);
    if (sock < 0) {
        ESP_LOGE("TCP_CLIENT", "Unable to create socket: errno %d", errno);
        vTaskDelete(NULL);
        return;
    }
    ESP_LOGI("TCP_CLIENT", "Socket created, connecting to %s:%d", SERVER_IP_ADDR, SERVER_PORT);

    int err = connect(sock, (struct sockaddr *)&dest_addr, sizeof(dest_addr));
    if (err != 0) {
        ESP_LOGE("TCP_CLIENT", "Socket unable to connect: errno %d", errno);
        close(sock);
        vTaskDelete(NULL);
        return;
    }
    ESP_LOGI("TCP_CLIENT", "Successfully connected");

    const char *payload = "Hello from ESP32!";
    err = send(sock, payload, strlen(payload), 0);
    if (err < 0) {
        ESP_LOGE("TCP_CLIENT", "Error occurred during sending: errno %d", errno);
    }

    int len = recv(sock, rx_buffer, sizeof(rx_buffer) - 1, 0);
    if (len < 0) {
        ESP_LOGE("TCP_CLIENT", "recv failed: errno %d", errno);
    } else {
        rx_buffer[len] = 0; // Null-terminate whatever we received
        ESP_LOGI("TCP_CLIENT", "Received %d bytes from %s:", len, addr_str);
        ESP_LOGI("TCP_CLIENT", "%s", rx_buffer);
    }

    shutdown(sock, 0);
    close(sock);
    vTaskDelete(NULL);
}

// In your app_main:
// ... Initialize Ethernet ...
// xTaskCreate(tcp_client_task, "tcp_client", 4096, NULL, 5, NULL);

Tip: Ensure your ESP32 and PC are on the same network. You might need to adjust firewall settings on your PC to allow incoming connections on the chosen port.

Exercise 3: Explore an Open-Source Ethernet/IP Stack

1. Task: Explore the OpENer GitHub repository (EIPStackGroup/OpENer) or another open-source Ethernet/IP adapter stack.
2. Objective: Get a high-level understanding of the structure and components of an Ethernet/IP stack. You are not required to compile or run it, just to explore the source code and documentation.
3. Points to Investigate:
   • Locate the main source files related to CIP object implementation (e.g., Identity Object, Assembly Object).
   • Find where explicit messages (TCP) and implicit messages (UDP) are handled.
   • Identify configuration files or #defines that set up device parameters (like Vendor ID, Product Code, initial IP settings).
   • Look for examples of how to define application-specific data that would be exchanged over Ethernet/IP.
4. Outcome: Write a short paragraph summarizing your findings on how such a stack is structured and what seems to be the most complex parts to integrate into an embedded project like one for an ESP32.

Summary

• Ethernet/IP is an industrial application layer protocol that adapts the Common Industrial Protocol (CIP) for use over standard Ethernet and TCP/IP (UDP/IP).
• It enables interoperability between industrial devices from various manufacturers.
• Key CIP concepts include an object-oriented model with Objects, Instances, Attributes, and Services.
• Explicit Messaging uses TCP/IP (port 44818) for non-real-time, request/response communication like configuration and diagnostics.
• Implicit Messaging (I/O Messaging) uses UDP/IP (port 2222) for real-time, cyclic exchange of I/O data.
• Devices are typically Scanners (clients, e.g., PLCs) or Adapters (servers, e.g., sensors, actuators).
• EDS files describe a device’s Ethernet/IP capabilities.
• ESP-IDF provides Ethernet and TCP/IP foundations, but a full Ethernet/IP stack requires a third-party library (e.g., OpENer) or significant custom development.
• ESP32 variants with built-in Ethernet MACs (ESP32, ESP32-S3, some ESP32-C6) are well-suited, while others (ESP32-S2, ESP32-C3, ESP32-H2) require external SPI Ethernet modules.
• Implementing Ethernet/IP is complex; thorough understanding of networking and the CIP specification is crucial.

Further Reading

• ODVA, Inc.: The official standards development organization for CIP and Ethernet/IP.
  • Website: https://www.odva.org/
  • Publications (Specifications): https://www.odva.org/know-how-standards/specifications/ (Access to full specifications often requires membership or purchase, but general information and overviews are available).
• ESP-IDF Ethernet Documentation: For configuring the underlying Ethernet connectivity on ESP32.
  • https://docs.espressif.com/projects/esp-idf/en/v5.4/esp32/api-reference/network/esp_eth.html (Replace esp32 with esp32s3, esp32c6 as appropriate for variant-specific details if they exist, though the general API is similar).
• OpENer Project: An open-source Ethernet/IP adapter stack in C.
  • GitHub: https://github.com/EIPStackGroup/OpENer
• lwIP TCP/IP Stack Documentation: (Used by ESP-IDF)
  • https://www.nongnu.org/lwip/2_1_x/index.html (General lwIP docs)
  • ESP-IDF Sockets API: https://docs.espressif.com/projects/esp-idf/en/v5.x/esp32/api-reference/network/esp_netif_stack.html#bsd-sockets-api