CiA 301 CANopen应用层与通信规范（V4.2.0）详解

301;canopen

5星 · 超过95%的资源需积分: 5 55 浏览量更新于2024-07-19 收藏 3.41MB PDF 举报

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

30元优惠券

CANopen CIA 301 是一个专为自动化领域设计的应用层（Application Layer）和通信协议规范，由CAN in Automation (CiA) 负责制定和维护。该标准的版本发展历经多年，从最初的草案提案到正式的公共规范，不断迭代和完善，以适应工业自动化环境中的设备通信需求。 CIA 301 标准于 1994 年 11 月首次发布为1.0版草案标准，随着技术的发展和市场需求的变化，随后在1995年、1996年、1999年和2000年分别发布了1.1、2.0、3.0和4.0/4.0.1/4.0.2版本，直到2006年推出4.1版，再到2007年的4.2版草案，最终在2011年2月21日确认为4.2.0版并作为正式的公共规格发布。该标准的核心目标是提供一种开放、统一的通信框架，使得设备制造商可以轻松地将他们的产品与CANopen网络集成，实现设备间的可靠数据交换，支持设备的配置、诊断和状态监控等功能。其应用层定义了服务和数据对象（PDOs, Process Data Objects），这些PDOs用于高效传输生产过程控制相关的数据，如传感器读取、命令发送等。 CIA 301 的历史变迁反映了工业自动化技术的进步，每一次更新都可能包含对网络安全、性能优化、功能扩展或兼容性改进等方面的重要改进。例如，从4.0版开始，可能引入了更强大的错误检测机制，确保数据的准确性，而4.1版和4.2版可能着重于增强安全性、增强对时间敏感应用的支持，以及更好地与其他标准如IEC 61131-3进行整合。关于版权，CIA强调所有关于CIA 301 4.2.0的标准文档，尽管已经转换成.docx格式，但其内容保持了与原文档技术上的一致性，只是在布局上存在细微差异。任何使用这个标准的个人或组织都需要遵守CiA的相应授权条款，以确保合规性和标准化实践的延续。总结来说，CANopen CIA 301 是工业自动化领域的一个重要标准，它通过不断演进，为设备间通信提供了强大的工具，促进了自动化系统的集成和互操作性。了解和遵循这个标准对于开发者和工程师来说，意味着能够参与到一个全球范围内广泛采用的通信架构中，提升产品的竞争力和可靠性。

资源详情

资源推荐

CANopen application layer and communication profile

4 Modeling

4.1 Field device model

The field device shown in Figure 1 shall have at least one CANopen device. Each CANopen device

within the field device shall have at least one associated network interface comprising a data link layer

protocol (see clause 6) and a physical layer definition (see clause 5), one node-ID, and at least one

communication FSA. The first communication FSA contains the NMT slave state machine (see sub-

clause 7.3.2). Additional communication FSAs contain an emergency state machine (see sub-clause

7.2.7) and others. The definition of additional communication FSAs does not fall into the scope of this

specification. The definition is made in so-called frameworks. A CANopen device shall have at least

one and up to eight logical devices and shall not be distributed to several field devices. Each logical

device may contain a number of virtual devices and optionally a logical device FSA. A logical device

shall not be distributed to several CANopen devices. The definition of a logical device does not fall into

the scope of this specification. The definition is made in so-called device profiles (see sub-clause

4.5.1). A virtual device contains a virtual device FSA and is not distributed to several logical devices.

The definition of a virtual device does not fall into the scope of this specification. The definition is made

in so-called application profiles (see sub-clause 4.5.2). The minimum field device is shown in Figure 2.

Figure 1: Field device model

CANopen application layer and communication profile

• A confirmation is issued by the application layer to the application to report the result of a

previously issued request.

4.2.2.3 Application layer services

Figure 4: Application layer services

An application layer service defines the primitives that are exchanged between the application layer

and the co-operating applications for a particular service of a service object. The application layer

services supported by CANopen are shown in Figure 4.

• A local service involves only the local service object. The application issues a request to its local

service object that executes the requested service without communicating with (a) peer service

object(s).

• A provider-initiated service involves only the local service object. The service object (being the

service provider) detects an event not solicited by a requested service. This event is then

indicated to the application.

• An unconfirmed service involves one or more peer service objects. The application issues a

request to its local service object. This request is transferred to the peer service object(s) that

each passes it to their application as an indication. The result is not confirmed back.

• A confirmed service involves only one peer service object. The application issues a request to its

local service object. This request is transferred to the peer service object that passes it to the

other application as an indication. The other application issues a response that is transferred to

the originating service object that passes it as a confirmation to the requesting application.

Unconfirmed and confirmed services are collectively called remote services.

4.3 CANopen device model

4.3.1 General

A CANopen device is structured like the following (shown in Figure 5):

• Communication – This function unit provides the communication objects and the appropriate

functionality to transport data items via the underlying network structure.

• Object dictionary – The object dictionary is a collection of all the data items which have an

influence on the behavior of the application objects, the communication objects and the state

machine used on this device.

• Application – The application comprises the functionality of the device with respect to the

interaction with the process environment.

Thus the object dictionary serves as an interface between the communication and the application.

CANopen application layer and communication profile

Figure 5: CANopen device model

4.4 Communication protocol sequences

4.4.1 General

The communication protocol sequences describe the different communication protocol principles and

the available modes of message transmission triggering.

The CANopen communication protocol sequences support the transmission of synchronous and

event-driven messages. By means of synchronous message transmission a network wide coordinated

data acquisition and actuation is possible. The synchronous transmission of messages is supported by

pre-defined communication objects. Synchronous messages are transmitted with respect to a pre-

defined synchronization message; event-driven messages are transmitted at any time.

Due to the event character of the underlying communication mechanism it is possible to define inhibit

times for the communication. To guarantee that no starvation on the network occurs for

communication objects with low priorities, it is possible to assign an inhibit time to the communication

object. The inhibit-time of a communication object defines the minimum time that elapses between two

consecutive invocations of a transmission service for that communication object.

With respect to their functionality, three types of communication protocol models are distinguished

• Master/Slave protocol (see sub-clause 4.4.2)

• Client/Server protocol (see sub-clause 4.4.3)

• Producer/Consumer protocol (see sub-clause 4.4.4)

4.4.2 Master/slave protocol

At any time there is exactly one CANopen device in the network serving as a master for a specific

functionality. All other CANopen devices in the network are considered as slaves. The master issues a

request and the addressed slave(s) responds(respond) if the protocol requires this behavior. Figure 6

defines the unconfirmed master/slave communication protocol. Figure 7 defines the confirmed

master/slave communication protocol.

Figure 6: Unconfirmed master/slave communication protocol

剩余157页未读，继续阅读

rhdlilj

粉丝: 0
资源: 2

CiA 301 CANopen应用层与通信规范（V4.2.0）详解

CANopen CiA 301 version 4.2.0 官方最新标准

CANopen应用层和通信协议（中文版）_CiA301

CAN301协议中文版

canopen cia301下载

canopen设备子协议cia 401

基于canfestival的canopen主站开发,包含cia402

基于canfestival的canopen主站开发,cia402伺服电机控制

NXP CANopen

CiA-301 V4.02

如何写一份CANopen的通讯协议，基于CiA 402

stm32移植canopen

请告诉我目前开源的canopen协议栈有哪些

canopen协议详解 pdf

CANOPEN通讯详细介绍

canopen协议详解文库

CiA DS402下载

跟我介绍一下CANopen通讯

canopen和canuds

canopen轻松入门

Cia402 状态机

最新资源