EtherNet/IP与CIP协议详解

cip协议

3星 · 超过75%的资源需积分: 50 146 浏览量更新于2024-07-22 1 收藏 935KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"cip协议 ab" 本文档详细介绍了 EtherNet/IP 协议，它是 Control and Information Protocol (CIP) 在 Ethernet 上的应用版本。CIP 是一种工业网络协议，由 ControlNet International 和 Open DeviceNet Vendor Association 共同制定，用于实现设备间的通信。EtherNet/IP 规范是 CIP 的一个关键组成部分，它允许工业设备通过标准的以太网技术进行通信，提高了网络的互操作性和效率。在第二版的 EtherNet/IP Adaptation of CIP Specification 中，包含了多个关键章节，这些章节详细阐述了协议的各种方面： 1. **Chapter 1 - Introduction to EtherNet/IP**：这一章引入了 EtherNet/IP 协议的基本概念，解释了其设计目标、工作原理以及如何在工业自动化环境中集成以太网技术。 2. **Chapter 2 - Encapsulation Protocol**：封装协议章节讨论了如何将 CIP 数据包封装到 TCP/IP 帧中，以便在以太网上传输。这涉及到网络层和传输层的协议交互，如 IP 和 TCP 的使用。 3. **Chapter 3 - Mapping of Explicit and I/O Messaging to TCP/IP**：此章节详细说明了显式消息（Explicit Messaging）和服务数据单元（SDU）如何映射到 TCP/IP 协议栈，以及输入/输出（I/O）消息如何通过网络进行处理。 4. **Chapter 4 - Object Model**：对象模型章节介绍了 EtherNet/IP 中的对象结构，这些对象定义了设备的功能和通信接口，是设备之间交换信息的基础。 5. **Chapter 5 - Object Library**：对象库章节列出了可用的 CIP 对象，包括它们的属性、服务和数据类型，这对于开发者理解如何与 EtherNet/IP 设备交互至关重要。 6. **Chapter 6 - Device Profiles**：设备配置文件章节规定了不同类型的工业设备如何遵循特定的配置文件，以确保兼容性和一致性。 7. **Chapter 7 - Electronic Data Sheets**：电子数据表章节详细说明了设备如何通过 EDS 文件提供自我描述信息，便于网络配置和诊断。 8. **Chapter 8 - Physical Layer**：物理层章节涵盖了 EtherNet/IP 使用的物理媒介和接口标准，如 IEEE 802.3。 9. **Chapter 9 - Indicators and Middle Layers**：指示器和中间层章节探讨了网络管理和诊断工具，以及它们如何与 EtherNet/IP 的其他层交互。 10. **Chapter 10 - Bridging and Routing**：桥接和路由章节描述了在 EtherNet/IP 网络中如何实现数据包的转发和寻址，以支持多跳通信。此外，文档还包括了多个附录，如： - **Appendix A - Explicit Messaging Services**：详细介绍了显式消息服务，这是 CIP 通信的一个重要部分，用于设备之间的点对点通信。 - **Appendix B - Status Codes**：提供了 CIP 消息的响应状态代码，帮助开发者理解和处理错误条件。 - **Appendix C - Data Management**：讨论了数据管理机制，包括数据的存储、更新和同步。 - **Appendix D - Engineering Units**：这部分可能涉及工程单位的表示和转换，对于处理测量和控制应用的数据至关重要。通过这些章节，读者可以全面了解 EtherNet/IP 协议如何在工业自动化环境中实现高效、可靠的设备通信，从而为设备制造商、系统集成商和最终用户提供强大而灵活的网络解决方案。

资源详情

资源推荐

Chapter 2: Encapsulation Protocol Volume 2: EtherNet/IP Adaptation of CIP

2-4 Open DeviceNet Vendor Assoc. & ControlNet International

Release 1.0

Ethernet header

(14 bytes)

CRC

IP header

(20 bytes)

TCP header

(20 bytes)

Encapsulation

message #1

Encapsulation

message #2

Two back-to-back encapsulated messages could be

sent in many different ways by the TCP/IP stack. Two

examples are given here:

Ethernet header

(14 bytes)

CRC

IP header

(20 bytes)

TCP header

(20 bytes)

Start of encapsulation

message #1

Rest of encapsulation

message #1

Ethernet header

(14 bytes)

IP header

(20 bytes)

TCP header

(20 bytes)

Encapsulation

message #2

CRC

Figure 2-3.1 – Usage of TCP to encapsulate two messages

NOTE: It is not the intention of this specification to document the details of the TCP, UDP and IP transport mechanisms.

Many excellent resources including the RFCs referenced throughout this specification should be used to obtain this

information.

The encapsulation protocol also defines a reserved UDP port number that shall be supported by

all EtherNet/IP devices. All devices shall accept UDP packets on UDP port number 0xAF12.

Since UDP, unlike TCP, does not have an ability to reorder packets, whenever UDP is used to

send an encapsulated message, the entire message shall be sent in a single UDP packet. Only

one encapsulated message shall be present in a single UDP packet destined to UDP port

0xAF12.

Some encapsulated messages shall only be sent via TCP. Other may be sent via either UDP or

TCP. See “Table 2-4.2 – Encapsulation commands” for details about which commands are

restricted to TCP.

2-4 Encapsulation messages

2-4.1 Encapsulation packet structure

All encapsulation messages, sent via TCP or sent to UDP port 0xAF12, shall be composed of a

fixed-length header of 24 bytes followed by an optional data portion. The total encapsulation

message length (including header) shall be limited to 65535 bytes. Its structure shall be as

follows:

Volume 2: EtherNet/IP Adaptation of CIP Chapter 2: Encapsulation Protocol

Release 1.0

Open DeviceNet Vendor Assoc. & ControlNet International 2-5

Table 2-4.1 – Encapsulation packet

Structure Field Name Data Type Field Value

Command UINT Encapsulation command

Length UINT

Length, in bytes, of the data portion of the

message, i.e., the number of bytes following the

header

Session handle UDINT Session identification (application dependent)

Status UDINT Status code

Sender Context ARRAY of octet Information pertinent only to the sender of an

encapsulation command. Length of 8.

Encapsulation

header

Options UDINT Options flags

Command

specific data

Encapsulated data ARRAY of 0 to

65511 USINT

The encapsulation data portion of the message

is required only for certain commands

The encapsulation message length shall not override length restrictions imposed by the

encapsulated protocol.

NOTE: For example, a CIP UCMM message is still limited to 504 bytes even when encapsulated. See chapter 3 of the CIP

Common Specification.

Multi-byte integer fields in the encapsulation messages shall be transmitted in little-endian byte

order.

NOTE: This is different from the byte ordering used in standard Internet network protocols, which is big-endian.

Although the header contains no explicit information to distinguish between a request and a

reply, this information shall be determined in either of two ways:

• implicitly, by the command and the context in which the message is

generated. (For example, in the case of the RegisterSession command,

the request is generated by an originator and the target generates the

reply);

• explicitly, by the contents of an encapsulated protocol packet in the data

part of the message.

2-4.2 Command field

The allocation of command codes shall be as follows:

Table 2-4.2 – Encapsulation commands

Code Name Comment

0x0000 NOP (may be sent only using TCP)

0x0001 Reserved for legacy (RA)

0x0002

and

0x0003

Reserved for legacy (RA)

0x0004 ListServices (may be sent using either UDP or TCP)

0x0005 Reserved for legacy (RA)

Chapter 2: Encapsulation Protocol Volume 2: EtherNet/IP Adaptation of CIP

2-6 Open DeviceNet Vendor Assoc. & ControlNet International

Release 1.0

Code Name Comment

0x0006

through

0x0062

Reserved for future expansion of this specification

(Products compliant with this specification shall

not use command codes in this range)

0x0063 ListIdentity (may be sent using either UDP or TCP)

0x0064 ListInterfaces optional (may be sent using either UDP or

TCP)

0x0065 RegisterSession (may be sent only using TCP)

0x0066 UnRegisterSession (may be sent only using TCP)

0x0067

through

0x006E

Reserved for legacy (RA)

0x006F SendRRData (may be sent only using TCP)

0x0070 SendUnitData (may be sent only using TCP)

0x0071 Reserved for legacy (RA)

0x0072 IndicateStatus optional (may be sent only using TCP)

0x0073 Cancel optional (may be sent only using TCP)

0x0074

through

0x00C7

Reserved for legacy (RA)

0x00C8

through

0xFFFF

Reserved for future expansion of this specification

(Products compliant with this specification shall

not used command codes in this range)

A device shall accept commands that it does not support without breaking the session or

underlying TCP connection. A status code indicating that an unsupported command was

received shall be returned to the sender of the message.

NOTE: The establishment of a session is defined in section 2-6. In short, a session makes a TCP/IP connection between

originator and target over which encapsulated commands may be sent. Since TCP/IP connections are modeled as a

stream of bytes, the encapsulation header is prepended to each encapsulated packet so that the receiving device can

know where packets begin and end.

2-4.3 Length field

The length field in the header shall specify the size in bytes of the data portion of the message.

The field shall contain zero for messages that contain no data. The total length of a message

shall be the sum of the number contained in the length field plus the 24-byte size of the

encapsulation header.

The entire encapsulation message shall be read from the TCP/IP connection even if the length

is invalid for a particular command or exceeds the target's internal buffers.

NOTE: Failure to read the entire message can result in losing track of the message boundaries in the TCP byte stream.

2-4.4 Session handle

The Session Handle shall be generated by the target and returned to the originator in response

to a RegisterSession request. The originator shall insert it in all subsequent encapsulated

packets (sent using the commands listed in Table 2-4.2) to that particular target. In the case

where the target initiates and sends a command to the originator, the target shall include this

field in the request that it sends to the originator.

Volume 2: EtherNet/IP Adaptation of CIP Chapter 2: Encapsulation Protocol

Release 1.0

Open DeviceNet Vendor Assoc. & ControlNet International 2-7

NOTE: Some commands (i.e., NOP) do not require a session handle even if a session has been established. Whether or not a

particular command requires a session is noted in the description of that command.

2-4.5 Status field

The value in the Status field shall indicate whether or not the receiver was able to execute the

requested encapsulation command. A value of zero in a reply shall indicate successful

execution of the command. In all requests issued by the sender, the Status field shall contain

zero. If the receiver receives a request with a non-zero Status field, the request shall be ignored

and no reply shall be generated.

NOTE: This field does not reflect errors that are generated by an encapsulated protocol packet contained within the data

portion of the message. For example, an error encountered during an end node's processing of a Set Attributes

service would be returned via the CIP specified error mechanism (see chapter 3 of the CIP Common specification)..

The status codes shall be as follows:

Table 2-4.3 – Error codes

Status Code Description

0x0000 Success

0x0001 The sender issued an invalid or unsupported encapsulation command.

0x0002 Insufficient memory resources in the receiver to handle the command. This is not an

application error. Instead, it only results if the encapsulation layer cannot obtain memory

resources that it needs.

0x0003 Poorly formed or incorrect data in the data portion of the encapsulation message.

0x0004 – 0x0063 Reserved for legacy (RA)

0x0064 An originator used an invalid session handle when sending an encapsulation message to the

target.

0x0065 The target received a message of invalid length

0x0066 – 0x0068 Reserved for legacy (RA)

0x0069 Unsupported encapsulation protocol revision.

0x006A – 0xFFFF Reserved for future expansion (Products compliant with this specification shall not use

command codes in this range)

2-4.6 Sender context field

The sender of the command shall assign the value in the Sender Context field of the header.

The receiver shall return this value without modification in its reply. Commands with no

expected reply may ignore this field.

NOTE: The sender of a command may place any value in this field. It could be used to match requests with their associated

replies.

2-4.7 Options field

The sender of an encapsulated packet shall set the options field to zero. The receiver of an

encapsulated packet shall verify that the option field is zero. The receiver shall discard

encapsulated packets with a non-zero option field.

NOTE: The intent of this field is to provide bits that modify the meaning of the various encapsulation commands. No

particular use for this field has not yet been specified.

剩余121页未读，继续阅读

zhangm_tt

粉丝: 0
资源: 10

EtherNet/IP与CIP协议详解

AB PLC CIP协议_abplccip连接_ABPLC_ABplcCIP协议_cipab_CIP

CIP通讯协议规范

Ethernet/IP汇总

AB PLC CIP协议_abplccip连接_ABPLC_ABplcCIP协议_cipab_CIP.zip

EIP-CIP协议规范.zip_CIP协议_EIP-CIP_EIP协议解析_eip通讯协议

AB PLC系统间通讯实现与CIP协议解析

abplc cip通讯协议

罗克韦尔、欧姆龙的CIP协议、OPC UA的标签数据转发到PLC寄存器

EthernetIP(CIP)转ModbusTCP/RTU-罗克韦尔AB的PLC与Modbus设备之间通讯

ethernet-ip协议的C语言库包含源码(可用于与PLC交互)zip.zip 可用于AB的PLC交互，实现各种通信

ABPLC协议.pdf

ABPLC协议书范本.doc

简单CIP通信实现.rar

EtherNet_IP协议在施耐德M580 PLC上的应用.pdf

欧姆龙PLC CIP通信 C#实例源码

CIP通信协议基础

EtherNet/IP协议下的ABPLC通信详解

AB PLC以太网通讯详解：物理连接与 EtherNet/IP协议

ab cip编程tcp

最新资源