CANopen协议介绍
CANopen协议讲解
CANopen协议讲解一、引言CANopen是一种基于CAN总线的通信协议，用于实现分布式控制系统中的设备之间的通信。
本协议旨在详细介绍CANopen协议的基本原理、通信机制、数据结构和应用领域。
二、协议概述1. 协议定义：CANopen是一种开放的、标准化的通信协议，用于实现CAN总线上的设备之间的通信和数据交换。
2. 协议特点：a. 灵活性：CANopen协议支持多种数据类型和通信方式，适用于不同的应用场景。
b. 可扩展性：协议定义了一系列标准对象和服务，可以根据实际需求进行扩展和定制。
c. 实时性：CANopen协议采用基于事件驱动的通信机制，支持实时数据传输和处理。
d. 可靠性：协议提供了错误检测和纠正机制，保证通信的可靠性和稳定性。
三、通信机制1. 帧格式：CANopen协议使用标准的CAN数据帧格式进行通信，包括标识符、数据长度码和数据域等字段。
2. 节点地址：每个CANopen设备都有一个唯一的节点地址，用于识别和寻址设备。
3. 通信对象：CANopen协议定义了一系列标准对象，包括数据对象、远程对象和服务对象等，用于实现设备之间的数据交换和控制。
4. 状态机：CANopen设备通过状态机进行通信管理，包括节点状态、网络状态和通信状态等。
四、数据结构1. 数据类型：CANopen协议支持多种数据类型，包括布尔型、整型、浮点型、字符串型等。
2. 对象字典：CANopen设备使用对象字典来管理和存储数据对象，包括输入对象、输出对象和配置对象等。
3. PDO：PDO（Process Data Object）用于实现实时数据传输和同步控制，包括TPDO（Transmit PDO）和RPDO（Receive PDO）两种类型。
五、应用领域1. 工业自动化：CANopen协议广泛应用于工业自动化领域，用于实现分布式控制系统中的设备之间的通信和数据交换。
2. 汽车电子：CANopen协议被用于汽车电子系统中，如发动机控制、车身控制、底盘控制等。
CANopen协议讲解
根据DS301的内容进行介绍1、CAN总线CAN标准报文2、CANopen应用层协议CANopen 协议不针对某种特别的应用对象，具有较高的配置灵活性，高数据传输能力，较低的实现复杂度。
同时，CANopen 完全基于CAN 标准报文格式，而无需扩展报文的支持，最多支持127个节点，并且协议开源。
一个标准的CANopen 节点（下图），在数据链路层之上，添加了应用层。
该应用层一般由软件实现，和控制算法共同运行在实时处理单元内。
一个标准的CANopen 节点CANopen 应用层协议细化了CAN 总线协议中关于标识符的定义。
定义标准报文的11 比特标识符中高4 比特为功能码，后7 比特为节点号，重命名为通讯对象标识符（COB-ID）。
功能码将所有的报文分为7个优先级，按照优先级从高至低依次为：网络命令报文（NMT）同步报文（SYNC）紧急报文（EMERGENCY）时间戳（TIME）过程数据对象（PDO）服务数据对象（SDO）节点状态报文（NMT Err Control）7 位的节点号则表明CANopen 网络最多可支持127个节点共存（0 号节点为主站）。
下表给出了各报文的COB-ID 范围。
NMT 命令为最高优先级报文，由CANopen 主站发出，用以更改从节点的运行状态。
SYNC 报文定期由CANopen 主站发出，所有的同步PDO 根据SYNC报文发送。
EMERGENCY报文由出现紧急状态的从节点发出，任何具备紧急事件监控与处理能力的节点会接收并处理紧急报文。
TIME 报文由CANopen 主站发出，用于同步所有从站的内部时钟。
PDO 分为4 对发送和接收PDO，每一个节点默认拥有4对发送PDO 和接收PDO，用于过程数据的传递。
SDO 分为发送SDO 和接收SDO，用于读写对象字典。
MT Error Control报文由从节点发出，用以监测从节点的运行状态。
状态机CANopen 的每一个节点都维护了一个状态机。
CANopen协议
CANopen协议一、引言CANopen是一种基于CAN总线的通信协议，用于在工业自动化和控制领域中实现设备之间的通信和数据交换。
本协议旨在确保不同厂家的设备能够互相兼容和交互操作，提供一种统一的通信标准。
二、范围本协议适用于使用CANopen协议的设备和系统，包括但不限于工业自动化、机械控制、医疗设备等领域。
三、术语和定义1. CAN总线：控制器局域网（Controller Area Network），一种广泛应用于工业领域的串行通信总线标准。
2. 节点：连接到CAN总线上的设备或系统。
3. PDO（Process Data Object）：过程数据对象，用于在CANopen网络中传输实时数据。
4. SDO（Service Data Object）：服务数据对象，用于在CANopen网络中传输配置和管理数据。
5. NMT（Network Management）：网络管理，用于控制和管理CANopen网络中的节点。
四、协议规范1. 物理层a. CAN总线采用2线制，包括CAN_H和CAN_L两根线。
b. CAN总线的通信速率应符合ISO 11898标准。
c. CAN总线的电气特性应符合ISO 11898-2标准。
2. 数据链路层a. 数据链路层使用CAN帧进行数据传输。
b. CAN帧分为标准帧和扩展帧，标准帧的标识符为11位，扩展帧的标识符为29位。
c. 数据链路层使用基于优先级的帧发送机制，具有抢占性。
3. 网络管理a. NMT功能应支持节点的启动、停止、重置和状态监测等操作。
b. NMT功能应支持节点之间的心跳监测和通信质量检测。
c. NMT功能应支持节点的配置和参数设置。
4. PDO传输a. PDO传输应支持实时数据的传输，具有低延迟和高可靠性。
b. PDO传输应支持双向数据交换，可以进行数据的读取和写入操作。
c. PDO传输应支持数据的映射和过滤，以满足不同应用场景的需求。
5. SDO传输a. SDO传输应支持节点之间的配置和管理数据的传输。
canopen参数
canopen参数摘要：一、CanOpen协议简介二、CanOpen参数的分类与作用1.通信参数2.节点识别参数3.报文传输参数4.错误处理与诊断参数5.电源管理参数三、CanOpen参数的配置方法四、CanOpen参数在实际应用中的案例分析五、总结与展望正文：一、CanOpen协议简介CanOpen是一种基于CAN总线的通信协议，主要用于工业自动化和嵌入式系统中。
它是一种高性能、高可靠性的通信协议，能够实现设备间的高效、稳定、安全的数据传输。
CanOpen协议在全球范围内得到了广泛的应用，已经成为工业自动化领域的通信标准之一。
二、CanOpen参数的分类与作用1.通信参数：主要包括波特率、数据位、停止位、校验位等，这些参数决定了通信的速率、数据格式以及是否进行奇偶校验等。
2.节点识别参数：包括设备ID、子地址等，用于标识不同的设备节点，实现设备间的差异化。
3.报文传输参数：包括报文长度、发送间隔、发送次数等，用于控制报文的传输速率、传输次数等。
4.错误处理与诊断参数：包括错误检测与处理方式、诊断报文周期等，用于实现故障诊断与处理。
5.电源管理参数：包括电源模式、电源电压范围等，用于确保设备在不同电源环境下的稳定运行。
三、CanOpen参数的配置方法配置CanOpen参数时，需要根据实际应用需求，合理设置各个参数。
配置过程主要包括以下几个步骤：1.确定通信参数：根据通信速率、波特率等需求，设置相应的通信参数。
2.设置节点识别参数：根据设备ID、子地址等需求，设置相应的节点识别参数。
3.设置报文传输参数：根据通信需求，设置报文长度、发送间隔、发送次数等。
4.设置错误处理与诊断参数：根据故障诊断需求，设置错误检测与处理方式、诊断报文周期等。
5.设置电源管理参数：根据电源需求，设置电源模式、电源电压范围等。
四、CanOpen参数在实际应用中的案例分析以一个智能工厂为例，生产线上的设备通过CanOpen协议进行通信。
CANopen协议讲解
CANopen协议讲解CANopen是一种基于CAN总线的通信协议，用于工业自动化领域中设备之间的数据交换和控制。
它是由CAN in Automation (CiA)组织开发和维护的，目前已成为工业领域最常用的开放式通信协议之一。
本文将详细介绍CANopen协议的基本原理、通信结构、数据通信方式以及应用领域等内容。
1. CANopen协议的基本原理CANopen协议基于CAN总线，采用了面向对象的通信模型。
它将设备抽象为对象，每个对象具有唯一的标识符，通过读写对象字典中的数据来实现设备之间的通信。
CANopen协议还定义了一套标准的通信服务和对象类型，使得不同厂商的设备可以互相兼容和交互。
2. CANopen协议的通信结构CANopen协议采用了主从式的通信结构，其中一个节点作为主节点，其他节点作为从节点。
主节点负责控制总线的访问和数据传输，从节点负责接收和响应主节点的指令。
主节点和从节点之间的通信通过报文进行，包括数据报文和远程帧。
3. CANopen协议的数据通信方式CANopen协议支持多种数据通信方式，包括点对点通信、广播通信和组播通信。
点对点通信是指主节点与特定从节点之间的通信，广播通信是指主节点向所有从节点发送相同的指令，组播通信是指主节点向特定组内的从节点发送指令。
4. CANopen协议的对象字典CANopen协议使用对象字典来存储设备的数据和配置信息。
对象字典是一个由多个对象组成的数据结构，每个对象包含了标识符、数据类型、访问权限等信息。
通过读写对象字典中的数据，可以实现设备之间的数据交换和控制。
5. CANopen协议的应用领域CANopen协议广泛应用于工业自动化领域，包括机械设备、工厂自动化、物流系统等。
它提供了可靠的数据传输和实时性能，适用于各种复杂的控制和监测应用。
CANopen协议还支持设备的配置和诊断功能，使得系统维护和故障排除更加方便。
总结：CANopen协议是一种基于CAN总线的通信协议，用于工业自动化领域中设备之间的数据交换和控制。
CANopen协议
CANopen协议⼀、CANOpen总线结构⼴播命令⼆、通信类型CANOpen有三种通信⽅式：主/从通信⽅式服务器/客户端通信⽅式⽣产商/顾客通信⽅式2.1主/从通信⽅式（NMT）对某⼀特点功能⽽⾔，⼀个⽹络中只有⼀个主机，其他全为从机。
由主机发送请求信号，从机发送相应信号（如果需要）主机发出命令，从机作出响应，但不回送数据主机发出命令，从机作出响应，同时回送数据确认2.2服务器/客户端通信⽅式（SDO）这种关系指发⽣在⼀个服务器和⼀个客户端之间，客户端发送命令，服务器执⾏后，回答客户端2.3⽣产商/顾客通信⽅式（SYNC、Time Stamp、EMCY）这种通信⽅式有Push和pull两种模式，⽹络中在这⼀个⽣产⼚，0或多个顾客。
2.3.1push模式⼚商发送命令，顾客执⾏，不需回送数据2.3.2 pull模式⼚商发送命令，顾客执⾏，回送证实数据三PDO传送模式PDO分为TPDO（发送PDO）与RPDO（接收PDO）两种，PDO的传送模式有两种：同步传送与异步传送。
同步传送⼜分为周期传送与⾮周期传送3.1同步传送由某⼀个同步应⽤在⽹路上周期性的发送同步对象，及发送SYNC帧，该同步应⽤可以是主机也可以是从机PDO通信参数中的传输类型说明传送模式与触发⽅式，TPDO：传送类型同时说明其传送率，以基本传送周期的倍数表⽰。
传送类型为0时，表⽰当某事件发⽣后，收到⼀个同步对象帧（SYNC）时，⽴刻进⾏数据传输。
（⾮周期传送）传送类型为1时，表⽰当每收到⼀次同步对象帧（SYNC）时，传送⼀次数据。
（周期传送）传送类型为n时，表⽰当每收到n次同步对象帧（SYNC）时，传送⼀次数据。
（周期传送）RPDO：接收是在收到SYNC信号后，运⾏接收，独⽴于传输参数定义的传送率。
传输类型 252 为⾮周期传输，在接收到同步对象后进⾏采样但不发送，在接收到请求该数据的远程帧后发送。
3.2异步传送TPDO: 异步传送与SYNC⽆关，传输类型 253-255 为异步传输，定义为此三种类型的 TPDO在接收到远程帧或规定的事件发⽣后进⾏传输。
CANopen通讯协议介绍
CANopen通讯协议介绍CANopen是一种现场总线通信协议，它基于CAN（Controller Area Network）总线，用于在工业自动化和机器控制领域的设备之间进行通信。
它提供了一种标准化的通信和数据传输方式，具有高可靠性和实时性的特点。
CANopen协议在1994年首次发布，由CAN in Automation（CiA）组织负责制定和推广。
它采用基于对象的通信模型，通过定义不同类型的对象和对象字典来进行数据传输和设备之间的交互。
CANopen协议定义了不同的设备和功能模块之间的消息结构、通信规则和参数设置等。
CANopen协议提供了一种灵活且可扩展的通信方式，可以支持多种不同类型的设备和功能模块。
它可以用于各种应用领域，例如工业机器人、自动化生产线、电动机控制、安全系统和智能家居等。
CANopen协议适用于小型设备和大型系统，可以通过简单的点对点连接或复杂的网络结构进行通信。
1. 对象导向：CANopen协议采用面向对象的通信模型，通过定义对象和对象字典来进行数据传输和设备之间的交互。
对象可以是实际的物理设备、功能模块或数据结构。
对象字典是一个集合，用于存储和管理不同类型的对象。
2. 报文结构：CANopen协议定义了不同类型的报文结构，包括同步报文、时间戳报文、心跳报文、PDO（Process Data Object）报文和SDO （Service Data Object）报文等。
这些报文用于不同的通信任务和数据传输需求。
3. 设备配置：CANopen协议支持动态设备配置，可以自动检测和配置新加入的设备。
设备可以通过网络管理工具或主控设备进行配置和监控。
设备的参数设置和功能扩展可以通过SDO报文进行远程配置。
4. 网络管理：CANopen协议支持多种网络拓扑结构，包括主从结构、多主结构和对等结构等。
它提供了网络节点的自动发现、节点状态监测、网络同步和错误诊断等功能。
可以通过网络管理工具进行网络配置和监控。
CANopen协议详情讲解
根据DS301的内容进行介绍1、CAN总线CAN标准报文2、CANopen应用层协议CANopen 协议不针对某种特别的应用对象，具有较高的配置灵活性，高数据传输能力，较低的实现复杂度。
同时，CANopen 完全基于CAN 标准报文格式，而无需扩展报文的支持，最多支持127个节点，并且协议开源。
一个标准的CANopen 节点（下图），在数据链路层之上，添加了应用层。
该应用层一般由软件实现，和控制算法共同运行在实时处理单元内。
一个标准的CANopen 节点CANopen 应用层协议细化了CAN 总线协议中关于标识符的定义。
定义标准报文的11 比特标识符中高4 比特为功能码，后7 比特为节点号，重命名为通讯对象标识符（COB-ID）。
功能码将所有的报文分为7个优先级，按照优先级从高至低依次为：网络命令报文（NMT）同步报文（SYNC）紧急报文（EMERGENCY）时间戳（TIME）过程数据对象（PDO）服务数据对象（SDO）节点状态报文（NMT Err Control）7 位的节点号则表明CANopen 网络最多可支持127个节点共存（0 号节点为主站）。
下表给出了各报文的COB-ID 范围。
NMT 命令为最高优先级报文，由CANopen 主站发出，用以更改从节点的运行状态。
SYNC 报文定期由CANopen 主站发出，所有的同步PDO 根据SYNC报文发送。
EMERGENCY报文由出现紧急状态的从节点发出，任何具备紧急事件监控与处理能力的节点会接收并处理紧急报文。
TIME 报文由CANopen 主站发出，用于同步所有从站的内部时钟。
PDO 分为4 对发送和接收PDO，每一个节点默认拥有4对发送PDO 和接收PDO，用于过程数据的传递。
SDO 分为发送SDO 和接收SDO，用于读写对象字典。
MT Error Control报文由从节点发出，用以监测从节点的运行状态。
状态机CANopen 的每一个节点都维护了一个状态机。
CANopen通讯协议介绍
CANopen通讯协议介绍CANopen是一种架构在控制局域网路(Control Area Network, CAN)上的高层通讯协定，包括通讯子协定及设备子协定常在嵌入式系统中使用，也是工业控制常用到的一种现场总线。
CANopen 实作了OSI模型中的网络层以上(包括网络层)的协定。
CANopen 标准包括寻址方案、数个小的通讯子协定及由设备子协定所定义的应用层。
CANopen 支援网络管理、设备监控及节点间的通讯，其中包括一个简易的传输层，可处理资料的分段传送及其组合。
一般而言资料链结层及实体层会用CAN来实作。
除了 CANopen 外，也有其他的通讯协定(如EtherCAT)实作 CANopen 的设备子协定。
基本的 CANopen 设备及通讯子协定定义在 CAN in Automation (CiA) draft standard 301. 中。
针对个别设备的子协定以 CiA 301 为基础再进行扩充。
如针对 I/O 模组的 CiA401 及针对运动控制的CiA402。
设备模型以下是所有 CANopen 设备都要具备的功能：通讯单元处理和网络上其他模组通讯所需要的通讯协定。
设备的启动及重置由状态机 (state machine)控制。
状态机需包括以下的几个状态：Initialization, Pre-operational, Operational 及Stopped。
当接收到网络管理 (NMT) 通讯对象，状态机会转换到对应的状态。
对象字典 (Object Dictionary) 是一个有 16 位元索引 (Index) 的变量阵列。
每个变量可以(但非必须)有 8 位元的子索引(Subindex)。
变量可用来调整设备的组态，也可以对应设备量测的资料或设备的输出。
当状态机设定为operational 之后，设备的应用 (application) 部份就会实现设备预期的机能。
此部份可以由对象字典中的变量调整其设定，而资料由通讯层传收或接收。
CANopen协议
CANopen协议协议名称：CANopen协议一、引言CANopen协议是一种基于CAN总线的通信协议，旨在提供一种标准化的通信方式，用于在工业自动化和控制系统中实现设备之间的数据交换和控制。
本协议旨在确保设备之间的互操作性，并提供一套通用的通信规范，以便各种设备能够无缝地集成到CANopen网络中。
二、范围本协议适用于使用CAN总线作为通信介质的设备和系统，包括但不限于工业控制器、传感器、执行器、驱动器等。
本协议规定了设备之间的通信方式、数据结构、对象字典以及网络管理等方面的规范。
三、术语和定义在本协议中，以下术语和定义适用：1. CAN总线：指控制器局域网（Controller Area Network），一种用于实时应用的串行通信总线。
2. 设备：指CANopen网络中的任何节点，包括控制器、传感器、执行器等。
3. 节点：指连接到CAN总线上的设备。
4. 对象字典：指CANopen设备中存储的对象集合，用于存储设备的参数、状态和控制信息。
5. PDO：指过程数据对象（Process Data Object），用于在设备之间传输实时数据。
6. SDO：指服务数据对象（Service Data Object），用于在设备之间传输配置和管理信息。
四、通信规范1. 通信速率：CANopen网络的通信速率应根据具体应用需求进行配置，常见的通信速率包括125Kbps、250Kbps、500Kbps和1Mbps。
2. 帧格式：CANopen网络中的通信帧应符合CAN 2.0A或CAN 2.0B的标准格式。
3. 网络拓扑：CANopen网络支持多种拓扑结构，包括总线、星形、树形等。
4. 节点ID：每个CANopen节点应具有唯一的节点ID，范围为1到127。
节点ID应根据网络拓扑和设备功能进行分配。
5. 网络管理：CANopen网络应支持网络配置、节点识别、节点状态监测和错误处理等功能。
五、对象字典规范1. 对象字典结构：对象字典应按照以下结构组织：- 索引（Index）：用于唯一标识对象字典中的每个对象。
CANopen协议
CANopen协议协议名称：CANopen协议一、介绍CANopen协议是一种基于CAN总线的通信协议，用于在工业自动化领域中实现设备之间的通信。
该协议定义了一套标准的通信对象和通信机制，使得不同厂家的设备可以相互交互和通信，实现数据的传输和控制。
二、协议结构CANopen协议由以下几个主要组成部分构成：1. 网络管理（NMT）：负责网络的初始化、启动和停止，以及节点的管理和配置。
2. 数据通信（SDO）：用于节点之间的数据传输，支持读取和写入操作。
3. 远程过程调用（RPC）：允许节点之间进行远程过程调用，实现对远程节点的控制和操作。
4. 紧急消息（EMCY）：用于传输设备故障和错误信息。
5. 时间同步（SYNC）：用于同步网络中的各个节点的时间。
6. 节点配置（NMT配置）：用于配置和管理节点的参数和功能。
7. 心跳（Heartbeat）：用于监测节点的状态和活动性。
三、通信对象CANopen协议定义了一系列的通信对象，包括以下几种主要类型：1. 输入和输出（I/O）：用于传输数字量和模拟量数据。
2. 字典对象（Dictionary Object）：用于存储和传输设备的参数和配置信息。
3. 状态机（State Machine）：用于控制设备的状态和行为。
4. 网络管理（NMT）：用于管理和控制网络中的节点。
5. 紧急消息（EMCY）：用于传输设备故障和错误信息。
6. 时间戳（Timestamp）：用于记录事件的发生时间。
四、协议通信机制CANopen协议采用基于事件驱动的通信机制，使用COB（Communication Object Identifier）来标识和区分不同的通信对象。
通信对象可以通过SDO（Service Data Object）进行读取和写入操作，也可以通过RPC（Remote Procedure Call）进行远程过程调用。
1. SDO（Service Data Object）：SDO用于节点之间的数据传输，支持读取和写入操作。
CANopen协议讲解
CANopen协议讲解CANopen是一种基于CAN总线的通信协议，广泛应用于工业自动化领域。
该协议定义了一套标准的通信和设备管理机制，使得不同厂商的设备可以互相通信和协同工作。
本文将详细讲解CANopen协议的基本原理、通信结构、数据格式以及常用的设备配置和管理方式。
一、基本原理：CANopen协议是基于CAN（Controller Area Network）总线的，CAN总线是一种广泛应用于汽车和工业领域的串行通信协议。
CAN总线具有高可靠性、实时性和抗干扰能力，适用于多节点分布式控制系统。
CANopen协议在CAN总线上定义了一套通信和设备管理机制，包括数据传输、节点配置、网络管理等。
它采用了基于对象的通信模型，将设备的功能和参数抽象为对象，通过读写对象字典来实现数据的交换和配置。
二、通信结构：CANopen协议中的通信结构由节点、对象字典和通信对象组成。
1. 节点（Node）：每个CANopen设备都是一个节点，每个节点都有一个唯一的节点ID，用于在总线上进行识别和寻址。
2. 对象字典（Object Dictionary）：对象字典是一个存储设备功能和参数的数据结构，由多个对象索引组成。
每个对象索引对应一个对象字典项，包括对象类型、数据类型、访问权限等信息。
3. 通信对象（Communication Object）：通信对象是CANopen协议中的最小通信单位，用于在节点之间传输数据。
通信对象可以是PDO（Process Data Object）或者SDO（Service Data Object）。
- PDO：用于实时数据传输，支持广播和点对点通信，可以配置为发送和接收模式。
PDO具有固定的数据格式，包括索引、子索引和数据内容。
- SDO：用于配置和管理节点的对象字典，支持点对点通信。
SDO具有灵活的数据格式，包括索引、子索引、命令字和数据内容。
三、数据格式：CANopen协议中的数据格式包括CAN帧和通信对象的数据结构。
CANOpen协议介绍
CANOpen协议介绍CANopen内部设备结构内部设备结构CANopen设备的结构从逻辑上可分为三部分。
一部分提供CAN接口，而另一部分提供设备的应用程序，如果为I/O模块，该应用程序控制设备的输入/输出(I/O)线路。
应用程序与CAN接口之间的接口在对象字典中实现。
对象字典对任何CANopen设备都是唯一的。
它相当于参数列表，可提供对受支持配置和过程数据的访问。
若要访问对象字典，每个CANopen设备都必须执行CANopen协议堆栈。
此CANopen协议堆栈是一种软件，通常在设备应用程序软件所使用的同一微控制器上实现。
CANopen对象字典对象字典布局对象字典是所有CANopen设备的核心。
实际上是一个对象(?卥)组，可通过网络以事先安排的预定义方式访问。
可使用6位索引和8位子索引对对象字典内的每个对象进行寻址。
对象字典的结构可分为几个索引范围。
索引范围1000至1FFFhh中的对象用于描述设备的通讯行为。
索引范围2000至5FFF和6000至9FFF 中hhhh的对象以制造商特定方式或CANopen设备子协议或应用子协议的标准化方式描述应用程序行为。
由于标准化的CANopen设备和应用子协议的索引范围被分成八设备内提供最多八个设备/应用子协议执行过个部分，因此可以在一个CANope?程。
根据相关的CiA接口规范，网络变量和系统变量被安排在索引范围A000至hBFFFF之间。
h设备设计人员的可能选择在对象字典中，设备设计人员通过执行相关的对象指出支持的设备功能。
通讯行为可在索引范围1xxx中的合适对象中调整。
制造商特定设备功能所需要或生成h的参数和结果可在索引范围2000至5FFF中指出。
此外，制造商特定状态信息hh和过程数据可在该索引范围中显示到网络。
如果设备设计人员希望在CANopen设备子协议的层面上通过标准化的CANopen 接口为客户提供舒适的设备控制，可在相关CANopen子协议中的预定义索引范围6000至9FFF内提供相应的参数和状态信息。
canopen协议详解
CanOpen协议详解简介CanOpen是一种基于CAN总线的通信协议，它是一种轻量级的、高效的、可靠的通信协议，广泛应用于工业控制领域。
CanOpen协议的设计目标是提供一种标准化的通信方式，便于不同厂家的设备之间进行数据交换和控制命令的传输。
CanOpen协议的特点包括： - 基于CAN总线的通信方式，具有高可靠性和抗干扰能力； - 支持多种数据类型，包括布尔型、整数型、浮点型等； - 提供了一套完整的对象字典，用于存储设备的配置参数和状态信息； - 支持主从模式和点对点模式，可以实现多个设备之间的协同工作； - 支持远程过程调用（RPC）和事件驱动。
协议结构CanOpen协议的数据通信是基于CAN帧进行的，每个CanOpen设备在CAN总线上有一个唯一的节点ID。
CanOpen协议定义了一组标准的CAN帧格式，其中包括了设备的节点ID、数据类型、数据长度等信息。
在CanOpen协议中，数据的传输是通过对象字典来完成的。
对象字典是一个由索引和子索引组成的树形结构，用于存储设备的配置参数和状态信息。
每个对象字典条目都有一个唯一的索引和子索引，用于标识该条目的位置和内容。
CanOpen协议定义了一些基本的对象字典条目，包括设备的状态、配置参数、控制命令等。
同时，CanOpen协议也允许用户定义自己的对象字典条目，以满足特定的应用需求。
通信方式CanOpen协议支持两种通信方式：主从模式和点对点模式。
在主从模式下，一个设备（主节点）负责发送控制命令，其他设备（从节点）接收并执行命令。
主节点可以通过发送PDO（Process Data Object）来实现数据的实时传输，也可以通过发送SDO（Service Data Object）来实现对从节点的配置和状态查询。
在点对点模式下，两个设备直接进行数据交换，无需主节点的介入。
点对点通信可以使用PDO或者SDO来实现。
通信协议CanOpen协议定义了一套标准的通信协议，用于设备之间的数据交换和命令传输。
CANOPEN协议详细讲解
一、CAN-BUS介绍1．CAN的基本概念、特点CAN 是 Controller Area Network的缩写（以下称为 CAN），是 ISO*1国际标准化的串行通信协议。
CAN 协议如表 3 所示涵盖了 ISO 规定的 OSI 基本参照模型中的传输层、数据链路层及物理层。
CAN 协议中关于 ISO/OSI 基本参照模型中的传输层、数据链路层及物理层，具体有哪些定义如图所示。
. ISO/OSI 基本参照模型【注】 *1 OSI：Open Systems Interconnection （开放式系统间互联）CAN的特点CAN 协议具有以下特点。
(1) 多主控制在总线空闲时，所有的单元都可开始发送消息（多主控制）。
最先访问总线的单元可获得发送权。
(2) 消息的发送在 CAN 协议中，所有的消息都以固定的格式发送。
总线空闲时，所有与总线相连的单元都可以开始发送新消息。
两个以上的单元同时开始发送消息时，根据标识符（Identifier 以下称为 ID）决定优先级。
ID 并不是表示发送的目的地址，而是表示访问总线的消息的优先级。
两个以上的单元同时开始发送消息时，对各消息 ID 的每个位进行逐个仲裁比较。
仲裁获胜（被判定为优先级最高）的单元可继续发送消息，仲裁失利的单元则立刻停止发送而进行接收工作。
(3) 系统的柔软性与总线相连的单元没有类似于“地址”的信息。
因此在总线上增加单元时，连接在总线上的其它单元的软硬件及应用层都不需要改变。
(4) 通信速度根据整个网络的规模，可设定适合的通信速度。
在同一网络中，所有单元必须设定成统一的通信速度。
即使有一个单元的通信速度与其它的不一样，此单元也会输出错误信号，妨碍整个网络的通信。
不同网络间则可以有不同的通信速度。
(5) 远程数据请求可通过发送“遥控帧”请求其他单元发送数据。
(6) 错误检测功能·错误通知功能·错误恢复功能所有的单元都可以检测错误（错误检测功能）。
CANopen协议介绍（精辟准确）
CANopen协议介绍（精辟准确）1.CANopen协议简介从OSI ⽹络模型的⾓度来看，CAN总线只定义了OSI⽹络模型的第⼀层（物理层）和第⼆层（数据链路层），⽽在实际设计中，这两层完全由硬件实现，设计⼈员⽆需再为此开发相关软件或固件。
同时，CAN只定义物理层和数据链路层，没有规定应⽤层，本⾝并不完整，因此需要⼀个⾼层协议来定义CAN报⽂中的11/29位标识符和8字节数据的使⽤。
⽽且，基于CAN总线的⼯业⾃动化应⽤中，越来越需要⼀个开放的、标准化的⾼层协议：这个协议⽀持各种CAN⼚商设备的互⽤性、互换性，能够实现在CAN⽹络中提供标准的、统⼀的系统通讯模式，提供设备功能描述⽅式，执⾏⽹络管理功能。
CANopen协议是CAN-in-Automation(CiA) 定义的标准之⼀，并且在发布后不久就获得了⼴泛的承认。
尤其是在欧洲， CANopen 协议被认为是在基于CAN 的⼯业系统中占领导地位的标准。
⼤多数重要的设备类型，例如数字和模拟的输⼊输出模块、驱动设备、操作设备、控制器、可编程控制器或编码器，都在称为“设备描述”的协议中进⾏描述；“设备描述”定义了不同类型的标准设备及其相应的功能。
依靠CANopen协议的⽀持，可以对不同⼚商的设备通过总线进⾏配置。
在OSI 模型中， CAN标准、CANopen协议之间的关系如图 1-1所⽰。
图1-1 CAN标准、CANopen协议在OSI⽹络模型中的位置框图CANopen和CAN报⽂的关系如图 1-2所⽰。
图1-2 CANopen和CAN报⽂的关系如所⽰。
CAN 报⽂由7个不同的位域组成，⽽CANopen就是规定其中的仲裁域(11 位标识符) 和数据域(8 字节数据) 的使⽤情况。
2.CANopen设备结构CANopen是⼀个基于CAN串⾏总线系统和CAL（CAN应⽤层）的⾼层协议。
CANopen的核⼼概念是设备对象字典（OD： ObjectDictionary），CANopen通讯通过对象字典（OD）能够访问驱动器的所有参数。
CANopen协议
CANopen协议协议名称：CANopen协议一、引言CANopen协议是一种用于控制器局域网络（Controller Area Network，CAN）的通信协议。
它定义了在CAN总线上进行通信的规则和数据结构，使得不同设备之间可以进行可靠的数据交换和通信。
本协议旨在提供一套标准化的通信协议，以便在CAN总线上实现设备之间的互操作性。
二、范围本协议适合于所有基于CAN总线的设备和系统，包括但不限于工业自动化、汽车电子、机器人技术、医疗设备等领域。
它定义了通信的物理层、数据链路层、网络层和应用层的规范。
三、术语和定义在本协议中，以下术语和定义适合：1. CAN总线：指控制器局域网络（Controller Area Network），一种串行通信协议，用于在不同设备之间传输数据。
2. 节点：指连接到CAN总线上的设备，每一个节点都有一个惟一的标识符。
3. 帧：指CAN总线上传输的数据单元，包含数据和控制信息。
4. 数据对象（Data Object）：指CANopen协议中用于存储和传输数据的基本单元。
5. 服务数据对象（Service Data Object）：指用于请求和响应CANopen服务的数据对象。
6. 状态机：指CANopen设备的工作状态转换图，定义了设备在不同状态下的行为和响应。
四、物理层规范1. CAN总线的物理层采用标准的CAN物理层规范，包括电气特性、传输速率和线缆连接等。
2. 设备之间的连接必须符合CAN总线的物理层规范，并使用合适的线缆和连接器。
五、数据链路层规范1. CANopen协议使用标准的CAN数据链路层协议，包括帧格式、帧类型和错误检测等。
2. 数据链路层必须支持CAN帧的发送和接收，并能够正确处理错误帧和冲突。
六、网络层规范1. CANopen协议定义了一套基于网络层的通信机制，用于节点之间的消息传递和数据交换。
2. 网络层提供了节点之间的数据传输服务，包括数据对象的读取、写入和定阅等功能。
canopen协议
canopen协议CANopen是一种用于工业自动化领域的通信协议，它基于控制器局域网（CAN）总线，并提供了一种标准的通信和网络管理方法。
它广泛应用于机械设备、工艺控制系统、自动化工厂和机器人等领域，以实现设备之间的数据交换和控制。
CANopen协议建立在ISO-11898标准之上，这是一种低成本和可靠的实时通信协议。
它仅需两根导线即可实现数据传输，无需任何额外的设备或硬件，节约了成本和空间。
通过使用CANopen协议，不同的设备和组件可以通过CAN总线相互通信，并实现数据交换和控制。
CANopen协议提供了一种灵活的通信模式，能够满足不同的应用需求。
它支持点对点通信、多点广播和组播通信。
其中，点对点通信是最常见的模式，其中一个设备主动请求另一个设备的数据，实现数据交换。
多点广播是将数据同时发送到多台设备，用于实现全局广播或统一的配置命令。
组播通信是将数据发送给特定的设备组，实现组内通信和联动控制。
除了通信模式，CANopen协议还提供了一套完整的网络管理方法，方便用户管理和配置所有的节点设备。
CANopen网络由一个主节点和多个从节点组成。
主节点负责管理整个网络，并控制从节点的活动。
从节点是网络中的被动设备，接收主节点的指令和请求，并将数据返回给主节点。
CANopen协议定义了一套标准的对象字典，用于存储和管理所有的数据和参数。
主节点可以通过访问对象字典来读取和写入从节点的数据，实现数据交换和控制。
CANopen协议还提供了一套标准的设备配置和诊断方法，方便用户对网络中的设备进行配置和故障排除。
用户可以通过CANopen协议实现设备的初始化、配置参数的读写、设备状态的检测和错误报告等功能。
此外，CANopen协议还支持心跳和守护机制，保证网络的稳定性和可靠性。
CANopen协议具有很多的优点，例如：通信速度快、实时性强、通信距离远、数据传输可靠、可扩展性好等。
它已经成为工业自动化领域的标准协议，并得到了广泛的应用和推广。
CANopen协议讲解
CANopen协议讲解协议背景：CANopen是一种基于CAN总线的通信协议，用于实现工业自动化设备之间的通信和数据交换。
它是由CAN in Automation（CiA）组织开发和维护的，被广泛应用于机械、汽车、医疗设备等领域。
协议目的：CANopen协议的目的是提供一种标准化的通信方式，使不同厂家的设备能够互联互通，并且能够方便地进行配置、监控和控制。
通过CANopen协议，用户可以实现设备之间的高效通信，提高系统的可靠性和灵活性。
协议特点：1. 灵活性：CANopen协议支持多种通信速率和通信模式，能够适应不同应用场景的需求。
2. 可扩展性：CANopen协议定义了一套丰富的对象字典，用户可以根据自己的需求进行扩展和定制。
3. 可靠性：CANopen协议采用了错误检测和纠正机制，能够保证数据的可靠传输。
4. 实时性：CANopen协议支持实时通信和事件驱动机制，能够满足对实时性要求较高的应用场景。
5. 简单性：CANopen协议的数据帧格式和通信规则相对简单，易于理解和实现。
协议结构：CANopen协议由两个主要部分组成：对象字典和通信过程。
1. 对象字典：对象字典是CANopen协议的核心概念，它定义了设备支持的各种对象和参数。
对象字典以16位的索引和8位的子索引进行标识，包括了数据类型、访问权限、默认值等信息。
用户可以通过读写对象字典中的对象来实现对设备的配置和控制。
2. 通信过程：CANopen协议使用基于事件的通信机制，通过发送和接收数据帧来实现设备之间的通信。
通信过程包括以下几个步骤：- NMT（网络管理）：用于启动、停止、重启和同步网络中的设备。
- SDO（服务数据对象）：用于读写对象字典中的对象。
- PDO（过程数据对象）：用于实时传输设备的过程数据。
- SYNC（同步）：用于同步网络中的设备，实现精确的时间控制。
- EMCY（紧急）：用于向网络中的设备发送紧急事件信息。
协议应用：CANopen协议广泛应用于工业自动化领域，包括机械、汽车、医疗设备等。
canopen协议详解
canopen协议详解CANopen协议详解。
CANopen是一种基于CAN总线的高层通信协议，它广泛应用于工业控制、汽车电子、医疗设备等领域。
本文将详细介绍CANopen协议的相关内容，包括其基本原理、通信对象、数据传输方式以及应用范围等方面的内容。
首先，我们来了解一下CANopen协议的基本原理。
CANopen协议是建立在CAN总线之上的一种通信协议，它采用了基于对象字典的通信模型，通过定义不同的通信对象来实现设备之间的数据交换。
CANopen协议还采用了一种灵活的网络管理机制，可以实现设备的自动识别和配置。
这种基于对象字典的通信模型和灵活的网络管理机制，使得CANopen协议在工业控制领域得到了广泛的应用。
其次，我们将介绍CANopen协议中的通信对象。
CANopen协议定义了许多不同类型的通信对象，包括PDO（过程数据对象）、SDO（服务数据对象）、NMT （网络管理对象）等。
这些通信对象可以实现设备之间的数据交换、参数配置、网络管理等功能。
通过对这些通信对象的灵活应用，可以实现复杂的控制系统，满足不同应用场景的需求。
接下来，我们将详细介绍CANopen协议的数据传输方式。
CANopen协议采用了基于事件驱动的数据传输方式，通过PDO和SDO等通信对象来实现数据的传输和交换。
PDO是一种实时数据传输方式，可以实现设备之间的实时数据交换；而SDO则是一种参数配置和管理方式，可以实现设备参数的读写和配置。
通过这些数据传输方式，CANopen协议可以实现设备之间的高效通信和数据交换。
最后，我们将介绍CANopen协议在不同领域的应用范围。
由于CANopen协议具有灵活的通信模型、丰富的通信对象和高效的数据传输方式，它在工业控制、汽车电子、医疗设备等领域得到了广泛的应用。
在工业控制领域，CANopen协议可以实现设备之间的实时数据交换和控制，满足复杂控制系统的需求；在汽车电子领域，CANopen协议可以实现车载电子设备之间的通信和数据交换；在医疗设备领域，CANopen协议可以实现医疗设备之间的数据交换和控制。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CANopen णᩲҟඑ⌕ᜐ⌆ՈCAN-busʌሖणᩲֲᔩ1ǃҟඑ (1)2ǃCAL णᩲ (2)3ǃCANopen (3)3ˊ1 ᇍᬥᄫOD (3)3ˊ2 CANopenỞᩳ (4)3ˊ3 CANopen8ᅮНẢ▊ (6)3ˊ4 CANopenᷛ৪ߚ‑ (8)3ˊ5 CANopen boot-upẋ࣏ (8)3ˊ6 CANopen⍜ᙃ᪱⊩ඊᅆ (9)4ǃᘏ (18)5ǃ᪸ᯢ (19)1ǃҟඑҢOSIตචൟՈᢖᑺᴹৠˈɴഎᘏඃตචϔჰাᅲɴњৰ1ሖ˄ĭˊሖ˅ǃৰ2ሖ˄᭄⏂Ჳሖ˅ǃৰ7ሖ˄ᑨϬሖ˅DŽЎɴഎᘏඃỞᐌাࣙᣀϔϾต↉ˈℸϡ◄ᡅৰ3ሖ˄Ӵṗሖ˅ৰ4ሖ˄ตචሖ˅ˈгϡ◄ᡅৰ5ሖ˄Ӯ᪡ሖ˅ৰ6ሖ˄ᦣẴሖ˅ՈϬDŽCAN˄Controller Area Network˅ɴഎᘏඃҙҙᅮНњৰ1ሖǃৰ2ሖ˄ᢅISO11898ᷛޚ˅˗ᅲ┉᪂ᩥЁˈẝϸሖᅠܼϵܰӊᅲɴˈ᪂ᩥҎਬ᮴◄ݡЎℸᓔথּ݇ḳӊ˄Software˅ӊ˄Firmware˅DŽẝϸሖᅠܼϵܰӊᅲɴˈৠᯊˈCANাᅮНĭˊሖ᭄⏂Ჳሖˈ≵᳝ᢈᅮᑨϬሖˈᴀᵯᑊϡᅠᭈˈ◄ᡅϔϾʌሖणᩲᴹᅮНCAN᭛ЁՈ11/29ԡᷛ৪ǃ8ᄫᅆ᭄ՈՓϬDŽ໐ϨˈѢCANᘏඃՈᎹϮႮࡼ࣪ᑨϬЁˈᱎᴹᱎ◄ᡅϔϾᓔᬒՈǃᷛޚ࣪Ոʌሖणᩲ˖ẝϾणᩲᬃᣕCANॖଚ᪂ՈѦϬᗻǃѦᤶᗻˈ࿁ᅲɴCAN ตචЁᦤկᷛޚՈǃඣϔՈிඣỞᩳᓣˈᦤկ᪂ࡳ࿁ᦣẴᮍᓣˈᠻᜐตචˊࡳ࿁DŽz ᑨϬሖ˄Application layer˅˖ЎตචЁ↣ϔϾ᳝ᬜ᪂῁࿁ᦤկϔඈ᳝ϬՈ᳡ࡵϢणᩲDŽz ỞᩳᦣẴ˄Communication profile˅˖ᦤկ‑า᪂ǃỞᩳ᭄ՈНˈᅮН᭄ỞᩳᮍᓣDŽz ᪂ᦣẴ˄Device proflile˅˖Ў᪂˄ି˅ࡴ৪ড়ᢈᇇՈᜐЎDŽϟ☦ՈতᅆᇚҟඑѢCANՈʌሖणᩲ˖CALणᩲѢCALणᩲᠽሩՈCANopenणᩲDŽCANopen णᩲᰃCAN-in-Automation(CiA)ᅮНՈᷛޚПϔˈᑊϨথᏗৢϡЙህቻᕫњᑓ⊯ՈᡓᩨDŽᇸ݊ᰃ⌆ˈCANopenणᩲᝯᩨЎᰃѢCANՈᎹϮிඣЁऴ:ᇐഄԡՈᷛޚDŽ᭄ₑᡅՈ᪂ିൟˈ՟བ᭄ᄫᢳՈṗܹṗߎഫǃȥࡼ᪂ǃ᪡᪂ǃࠊ఼ǃৃේ࣏ࠊ఼ේۅ఼ˈ῁ࢴЎĀ᪂ᦣẴāՈणᩲЁẟᜐᦣẴ˗Ā᪂ᦣẴāᅮНњϡৠିൟՈᷛޚ᪂ঞּ݊ᑨՈࡳ࿁DŽձ☤CANopenणᩲՈᬃᣕˈৃҹᇍϡৠॖଚՈ᪂Ởẋᘏඃẟᜐ‑าDŽOSIൟЁˈCANᷛޚǃCANopenणᩲПⒸՈ݇ிབϟ᠔߾˖C iA DS P-401C iA DS P-404 CiA DSP-xxxApplicationC hipData LinkPhysical Layer1.1 CANǃCANopenᷛޚOSIตචൟЁՈԡาḚ2ǃCAL णᩲCAL˄CAN Application Layer˅णᩲᰃֲࠡѢCANՈʌሖỞᩳणᩲЁՈϔˈ᳔ᮽϵPhilipsएћ᪂ᾬ⒬ࠊᅮDŽɴCALϵưএՈCANϬ᠋ࠊỤଚ▊ಶCiA˄CAN in Automation˅णӮᯣᯧˊǃথሩᑓDŽCALᦤկњ4ᑨϬሖ᳡ࡵࡳ࿁˖z CMS (CAN-based Message Specification)CMSᦤկњϔϾᓔᬒՈǃ☦ᇍᬥՈɳ๗ˈϬѢᅲɴϬ᠋ՈᑨϬDŽCMSᦤկѢবₓǃџӊǃඳିൟՈᇍᬥˈҹ᪂ᩥᢈᅮϔϾ᪂˄ᅆ⚍˅Ոࡳ࿁བԩᝯ᪃⒲˄՟བˈབԩϞṁϟṁ᱉ẋ8ᄫᅆՈϔඈ᭄˄ඳ˅ˈᑊϨ᳝ඌℶӴṗՈࡳ࿁˅DŽCMSҢMMS (Manufacturing Message Specification)ණᡓ໐ᴹDŽMMSᰃOSIЎᎹϮ᪂ՈẠ࣏ࠊ֕໐ࠊᅮՈᑨϬሖᢈᇇDŽz NMT (Network ManagemenT)ᦤկตචˊ˄བ߱ྟ࣪ǃਃࡼذℶᅆ⚍ˈպ⌟༅ᬜᅆ⚍˅᳡ࡵDŽẝ᳡ࡵᰃ₋ϬЏҢỞᩳᓣ˄᠔ҹা᳝ϔϾNMTЏᅆ⚍˅ᴹᅲɴՈDŽz DBT (DistriBuTor)ᦤկࡼᗕߚ‑CAN ID˄ℷᓣৡࢴЎCOB-IDˈCommunication Object Identifier˅᳡ࡵDŽẝ᳡ࡵᰃ₋ϬЏҢỞᩳᓣ˄᠔ҹা᳝ϔϾDBTЏᅆ⚍˅ᴹᅲɴՈDŽz LMT (Layer ManagemenT)LMTᦤկׂᬍሖখ᭄Ո᳡ࡵ˖ϔϾᅆ⚍˄LMT Master˅ৃҹ᪂าϔϾᅆ⚍˄LMT Slave˅Ոᶤሖখ᭄˄བᬍবϔϾᅆ⚍ՈNMTഄഔˈᬍবCANষՈԡᅮᯊ⊶Ľɋ˅DŽCMSЎᅗՈ⍜ᙃᅮНњ8ϾӬܜ൫ˈ↣ϾӬܜ൫ᢹ᳝220ϾCOB-IDˈᇇೈҢ1ࠄ1760DŽ࠽ԭՈᷛᖫ˄0ˈ1761-2031˅ֱНඝNMTˈDBTLMTˈᢅᜬ2-1DŽᜬ2-1 ᇘࠄCAL᳡ࡵᇍᬥՈCOB-ID(11ԡCANᷛ৪)COB-ID ᳡ࡵᇍᬥ0 NMT ਃࡼ/ذℶ᳡ࡵ1 - 220 CMSᇍᬥ Ӭܜ൫0221 - 440 CMSᇍᬥ Ӭܜ൫1441 - 660 CMSᇍᬥ Ӭܜ൫2661 - 880 CMSᇍᬥ Ӭܜ൫3881 - 1100 CMSᇍᬥ Ӭܜ൫41101 - 1320 CMSᇍᬥ Ӭܜ൫51321 - 1540 CMSᇍᬥ Ӭܜ൫61541 - 1760 CMSᇍᬥ Ӭܜ൫71761 - 2015 NMT ᅆ⚍ֱᡸ2016 - 2031 NMTˈLMTˈDBT᳡ࡵ⊼ᛣẝᰃCAN2.0Aᷛޚˈ11ԡIDᇇೈ[0ˈ2047]ˈϵѢग़ॳ└ࠊ[0ˈ2031]DŽབᵰՓϬCAN2.0B ᷛޚˈ29ԡIDᑊϡᬍবẝϾᦣẴ˗ᜬЁՈ11ԡᇘࠄ29ԡCOB-IDЁՈ᳔ʌ11ԡˈҹႷѢᜬЁՈCOB-ID ᇇೈবᕫ᩼DŽ3ǃCANopenCALᦤկњ᠔᳝Ոตචˊ᳡ࡵ᭛ӴễणᩲˈԚᑊ≵᳝ᅮНCMSᇍᬥՈݙᆍ້ℷỞᩳՈᇍᬥՈିൟ˄ᅗাᅮНњhowˈ≵᳝ᅮНwhat˅DŽ໐ẝℷᰃCANopenߛܹ⚍DŽCANopenᰃCAL܄ϞᓔথՈˈՓϬњCALỞᩳ᳡ࡵणᩲᄤ▊ˈᦤկњߚᏗᓣࠊிඣՈϔᅲɴᮍḜDŽCANopenֱ᪅ตචᅆ⚍ѦϬᗻՈৠᯊܕ᩼ᅆ⚍Ոࡳ࿁╓ᛣᠽሩ˖ऩᴖDŽCANopenՈḌᖗὖᗉᰃ᪂ᇍᬥᄫ˄OD˖Object Dictionary˅ˈ݊ᅗɴഎᘏඃ˄ProfibusˈInterbus-S˅ிඣЁгՓϬẝ᪂ᦣẴᔶᓣDŽ⊼ᛣ˖ᇍᬥᄫϡᰃCALՈϔᾬߚˈ໐ᰃCANopenЁᅲɴՈDŽϟ☦ܜҟඑᇍᬥᄫ˄OD˖Object Dictionary˅ˈ✊ৢݡҟඑCANopenỞᩳᴎࠊDŽ3.1 ᇍᬥᄫODᇍᬥᄫ˄OD˖Object Dictionary˅ᰃϔϾ᳝ᑣՈᇍᬥඈ˗↣Ͼᇍᬥ₋ϬϔϾ16ԡՈ௦ᓩؐᴹᇏഔˈЎњܕ᩼᪃⒲᭄ᵘЁՈऩϾܗˈৠᯊᅮНњϔϾ8ԡՈᄤ௦ᓩˈᇍᬥᄫՈᵘখ+ᜬ3-1DŽϡᡅᝯᇍᬥᄫЁ௦ᓩؐԢѢ0x0FFFՈþdata typesÿ-᠔ẻᚥˈᅗӀҙҙᰃϔѯ᭄ିൟᅮНDŽϔϾᅆ⚍ՈᇍᬥᄫՈ᳝݇ᇇೈ0x1000ࠄ0x9FFFПⒸDŽᜬ3-1 CANopenᇍᬥᄫỞϬᵘ௦ᓩᇍᬥ0000 Notused0001 - 001F ☝ᗕ᭄ିൟ˄ᷛޚ᭄ିൟˈབBooleanˈInteger 16˅0020 - 003F ᴖ᭄ିൟ˄8ᅮНϵऩିൟඈড়៤ՈᵘབPDOCommParˈSDOParameter˅0040 - 005F ࠊỤଚᢈᅮՈᴖ᭄ିൟ0060 - 007F ᪂ᄤणᩲᢈᅮՈ☝ᗕ᭄ିൟ0080 - 009F ᪂ᄤणᩲᢈᅮՈᴖ᭄ିൟ00A0 - 0FFF Reserved1000 - 1FFF Ởᩳᄤणᩲऎඳ(བ᪂ିൟˈ⏝᪳ᆘᄬ఼ˈᬃᣕՈPDO᭄ₓ)2000 - 5FFF ࠊỤଚĽᅮᄤणᩲऎඳ6000 - 9FFF ᷛޚՈ᪂ᄤणᩲऎඳ(՟བĀDSP-401 I/O ഫ᪂ᄤणᩲā˖Read State 8 Input Lines)A000 - FFFF ReservedCANopenตචЁ↣Ͼᅆ⚍῁᳝ϔϾᇍᬥᄫDŽᇍᬥᄫࣙњᦣẴẝϾ᪂ᅗՈตචᜐЎՈ᠔᳝খ᭄DŽϔϾᅆ⚍ՈᇍᬥᄫᰃϹᄤ᭄᭛ḷ˄EDS˖Electronic Data Sheet˅ЁᦣẴ້ᩴᔩർϞDŽϡᖙᡅгϡ◄ᡅỞẋCAN-busĀᅵ⒲āϔϾᅆ⚍ՈᇍᬥᄫЁՈ᠔᳝খ᭄DŽབᵰϔϾᅆ⚍ϹḐᣝ+ർϞՈᇍᬥᄫẟᜐᦣẴ݊ᜐЎˈгᰃৃҹՈDŽᅆ⚍ᴀᵯা◄ᡅ࿁ᦤկᇍᬥᄫЁᖙ◄Ոᇍᬥ˄໐CANopen ᢈᅮЁᖙ◄Ո-ᅲ┉ϞᰃᕜᇥՈ˅ˈҹঞ݊ᅗৃọᢽՈǃᵘ៤ᅆ⚍ᾬߚৃ‑าࡳ࿁ՈᇍᬥDŽCANopenϵϔி߫ࢴЎᄤणᩲՈ᭛ḷඈ៤DŽỞᩳᄤणᩲ˄communication profile˅ˈᦣẴᇍᬥᄫՈЏᡅᔶᓣᇍᬥᄫЁՈỞᩳᄤणᩲऎඳЁՈᇍᬥˈỞᩳখ᭄DŽৠᯊᦣẴCANopenỞᩳᇍᬥDŽẝϾᄤणᩲỆϬѢ᠔᳝ՈCANopen᪂DŽẜ᳝᪂ᄤणᩲ˄device profile˅ˈЎϡৠିൟ᪂ᅮНᇍᬥᄫЁՈᇍᬥDŽֲࠡᏆ᳝5ϡৠՈ᪂ᄤणᩲˈᑊ᳝ℷথሩDŽ᪂ᄤणᩲЎᇍᬥᄫЁՈ↣ϾᇍᬥᦣẴњᅗՈࡳ࿁ǃৡᄫǃ௦ᓩᄤ௦ᓩǃ᭄ିൟˈҹঞẝϾᇍᬥᰃᖙ◄ՈẜᰃৃọՈˈẝϾᇍᬥᰃাᪿǃাݭ້ৃᪿݭDŽ⊼ᛣ˖ϔϾ᪂ՈỞᩳࡳ࿁ǃỞᩳᇍᬥǃϢ᪂ּ݇ՈᇍᬥҹঞᇍᬥՈׅؐϵϹᄤ᭄᭛ḷ˄EDS ˖Electronic Data Sheet ˅ЁᦤկDŽऩϾ᪂Ոᇍᬥ‑าՈᦣẴ᭛ӊࢴ᪂‑า᭛ӊ˄DCF ˖Device Configuration File ˅ˈᅗEDS ּ᳝ৠՈᵘDŽѠ້᭛ӊିൟ῁CANopen ᢈᇇЁᅮНDŽ᪂ᄤणᩲᅮНњᇍᬥᄫЁાѯOD ᇍᬥᰃᖙ◄ՈˈાѯᰃৃọՈ˗ᖙ◄Ոᇍᬥᑨ᪩ֱᣕ᳔ᇥ᭄ֲҹޣᇣᅲɴՈᎹₓDŽৃọ-̣̣ỞᩳᾬߚϢ᪂ּ݇ᾬߚ̣̣ৃҹḍ◄ᡅࡴҹᠽሩCANopen ᪂Ոࡳ࿁DŽབᵰ◄ᡅՈ-᱉ẋњ᪂ᄤणᩲЁৃҹᦤկՈˈ᪂ᄤणᩲЁᏆ8НϵᱷाⒸᦤկඝॖଚՈĽᅮࡳ࿁ՓϬDŽᇍᬥᄫЁᦣẴỞᩳখ᭄ᾬߚᇍ᠔᳝CANopen ᪂˄՟བOD ЁՈᇍᬥᰃּৠՈˈᇍᬥؐϡᖙϔᅮּৠ˅῁ᰃϔḋՈDŽᇍᬥᄫЁ᪂ּ݇ᾬߚᇍѢϡৠିՈ᪂ᰃϡৠՈDŽ3ˊ2 CANopen Ởᩳࠡ☦᪸ᯢњCANopen ЁᇍᬥᄫՈὖᗉˈɴ៥ӀᴹҟඑCANopen ตචЁՈỞᩳ⍜ᙃˈᅗӀՈݙᆍࡳ࿁ˈᤶহ᪡˖CANopen ỞᩳᓣDŽ⊼ᛣ˖᪻ऎߚᇍᬥᄫЁՈᇍᬥ˄ՓϬᇍᬥᄫ௦ᓩᄤ௦ᓩ˅Ởᩳᇍᬥ˄້⍜ᙃˈՓϬCOB-ID ˅DŽCANopen ỞᩳൟᅮНњ4᭛˄Ởᩳᇍᬥ˅˖ 1ˊ ˊ᭛z ሖˊˈตචˊID ߚ‑᳡ࡵ˖བ߱ྟ࣪ˈ‑าตචˊ˄ࣙᣀ˖ᅆ⚍ֱᡸ˅DŽz ᳡ࡵणᩲ৪ড়CAL ЁՈLMT ˈNMT DBT ᳡ࡵᾬߚDŽẝѯ᳡ࡵ῁ᰃѢЏҢỞᩳᓣ˖CAN ตචЁˈা࿁᳝ϔϾLMT ˈNMT DBT Џᅆ⚍ҹঞϔϾϾҢᅆ⚍DŽ2ˊ ᳡ࡵ᭄ᇍᬥSDO(Service Data Object)z ỞẋՓϬ௦ᓩᄤ௦ᓩ˄CAN ᭛ՈࠡϾᄫᅆ˅ˈSDO Փᅶ᠋ᴎ࿁᪃⒲᪂˄᳡ࡵ఼˅ᇍᬥᄫЁՈ-˄ᇍᬥ˅DŽz SDO ỞẋCAL ЁܗඳՈCMS ᇍᬥᴹᅲɴˈܕ᩼Ӵễӏԩ⑃ᑺՈ᭄˄ᔧ᭄᱉ẋ4Ͼᄫᅆᯊߚᢚ៤Ͼ᭛˅DŽz णᩲᰃܲᩨ᳡ࡵିൟ˖Ў↣Ͼ⍜ᙃϣ៤ϔϾᑨਘ˄ϔϾSDO ◄ᡅϸϾID ˅DŽSDO ᪻∖ᑨਘ᭛ᘏᰃࣙ8Ͼᄫᅆ˄≵᳝ᛣНՈ᭄⑃ᑺৰϔϾᄫᅆЁᜬ߾ˈৰϔϾᄫᅆᨎᏺणᩲֵᙃ˅DŽSDO Ởᩳ᳝ṇՈणᩲᢈᅮDŽ3ˊ ẋ᭄࣏ᇍᬥPDO ˄Process Data Object ˅z ϬᴹӴṗᅲᯊ᭄ˈ ᭄ҢϔϾϣѻ້ӴࠄϔϾϾ⍜᯽້DŽ᭄Ӵễ└ࠊ1ࠄ8Ͼᄫᅆ˄՟བˈϔϾPDO ৃҹӴṗ᳔64Ͼ᭄ᄫI/O ؐˈ້4Ͼ16ԡՈAD ؐ˅DŽz PDO Ởᩳ≵᳝णᩲᢈᅮDŽPDO ᭄ݙᆍাϵᅗՈCAN ID ᅮНˈ؛ᅮϣѻ້⍜᯽້کẝϾPDO Ո᭄ݙᆍDŽz ↣ϾPDO ᇍᬥᄫЁϬ2ϾᇍᬥᦣẴ˖PDO Ởᩳখ᭄˖ࣙાϾCOB-ID ᇚᝯPDO ՓϬˈӴṗିൟˈࡅℶᯊⒸᅮᯊ఼਼ᳳDŽ PDO ᇘখ᭄˖ࣙϔϾᇍᬥᄫЁᇍᬥՈ߫ᜬˈẝѯᇍᬥᇘࠄPDO ₐˈࣙᣀᅗӀՈ᭄⑃ᑺ˄in bits ˅DŽϣѻ້⍜᯽້ᖙ/کẝϾᇘˈҹᢧ₎PDO ݙᆍDŽz PDO ⍜ᙃՈݙᆍᰃ8ᅮНՈ˄້ตචਃࡼᯊ‑าՈ˅˖ᇘᑨϬᇍᬥࠄPDO Ёᰃ᪂ᇍᬥᄫЁᦣẴՈDŽབᵰ᪂˄ϣѻ້⍜᯽້˅ᬃᣕৃবPDO ᇘˈὧМՓϬSDO ᭛ৃҹ‑าPDO ᇘখ᭄DŽ z ৃҹ᳝Ӵễᮍᓣ˖ᩨ᳡ࡵିൟṗᅲᯊ᭄PDOৠℹ˄ỞẋᬊSYNC ᇍᬥᅲɴৠℹ˅☢਼ᳳ˖ϵẠ࣏ᏻ8ᢪথӴễˈ້ϵ᪂ᄤणᩲЁᢈᅮՈᇍᬥĽᅮџӊ8ᢪথӴễDŽ ਼ᳳ˖Ӵễ↣1ࠄ240ϾSYNC ⍜ᙃৢᢪথDŽ ᓖℹϵẠ࣏ᏻᢪথӴễDŽϵ᪂ᄤणᩲЁᢈᅮՈᇍᬥĽᅮџӊᢪথӴễDŽᜬ3-2ඝߎᴹњϵӴṗିൟᅮНՈϡৠPDO ӴṗᓣˈӴṗିൟЎPDO Ởᩳখ᭄ᇍᬥՈϔᾬߚˈϵ8ԡ᮴৪োᭈ᭄ᅮНDŽᜬ3-2 PDO ӴṗିൟᅮНᢪথPDO Ոᴵӊ(B = both needed O = one or both) ӴṗିൟSYNCRTREventPDO Ӵṗ0 B - B ৠℹˈ☢ᕾɳ 1-240 O - - ৠℹˈᕾɳ 241-251 - -- Reserved252 B B - ৠℹˈRTR Пৢ 253 - O - ᓖℹˈRTR Пৢ 254 - O O ᓖℹˈࠊỤଚĽᅮџӊ 255 - O O ᓖℹˈ᪂ᄤणᩲĽᅮџӊ ᪸ᯢ˖z SYNC –ᬊࠄSYNC-object DŽ z RTR ˉᬊࠄẠ࣏ᏻDŽz Event –՟བ᭄ؐᬍব້ᅮᯊ఼ЁᮁDŽz ӴṗିൟЎ˖1ࠄ240ᯊˈ᪩᭄ᄫҷᜬϸϾPDO ПⒸՈSYNC ᇍᬥՈ᭄ֲ˅DŽz ϔϾPDO ৃҹᣛᅮϔϾࡅℶᯊⒸˈेᅮНϸϾẢනPDO ӴṗՈ᳔ᇣⒸ╘ᯊⒸˈὃܡϵѢʌӬܜ൫ֵᙃՈ᭄ₓˈྟඌऴᘏඃˈ໐Փ݊ᅗӬܜ൫ṇԢՈ᭄᮴ঢѝᘏඃՈ⒲L DŽࡅℶᯊⒸϵ16ԡ᮴৪োᭈ᭄ᅮНˈऩԡ100us DŽ z ϔϾPDO ৃҹᣛᅮϔϾџӊᅮᯊ਼ᳳˈᔧ᱉ẋᅮᯊᯊⒸৢˈϔϾPDO Ӵṗৃҹᝯᢪথ˄ϡ◄ᡅᢪথԡ˅DŽџӊᅮᯊ਼ᳳϵ16ԡ᮴৪োᭈ᭄ᅮНˈऩԡ1ms DŽ z PDO ỞẋCAL ЁᄬټџӊିൟՈCMS ᇍᬥᅲɴDŽPDO ᭄Ӵễ≵᳝Ϟሖणᩲˈ໐ϨPDO ᩨ˄ϔϾPDO ◄ᡅϔϾCAN-ID ˅DŽ↣ϾPDO ᭛Ӵễ᳔8Ͼᄫᅆ˄64ԡ˅᭄DŽ4ˊ 8ᅮН᭛້Ľ⅞ࡳ࿁ᇍᬥz ৠℹ˄SYNC ˅ตචᇇೈݙৠℹ˄ᇸ݊ȥࡼᑨϬЁ˅˖ᭈϾตචᇇೈݙᔧࠡṗܹؐޚৠᯊֱᄬˈ╓ৢӴễ˄བᵰ◄ᡅ˅ˈḍࠡϔϾSYNC ৢᬊࠄՈ᭛ᮄṗߎؐDŽЏҢᓣ˖SYNC Џᅆ⚍ᅮᯊথễSYNC ᇍᬥˈSYNC Ңᅆ⚍ᬊࠄৢৠℹᠻᜐӏࡵDŽ SYNC ᭛ӴễৢˈඝᅮՈᯊⒸज़ষݙӴễϔϾৠℹPDO DŽ ϬCAL ЁᴀবₓିൟՈCMS ᇍᬥᅲɴDŽDŽSYNC ᭛ৃҹϡz ᯊⒸᷛᩴᇍᬥ˄Time Stamp ˅ЎᑨϬ᪂ᦤկ݀݅ՈᯊⒸᏻখDŽ ϬCAL ЁᄬټџӊିൟՈCMS ᇍᬥᅲɴDŽϔϾऩԡऩԡϾџӊᅮᯊ਼᭛≵᳝ܲᩨӴễ᭄ҹՓ᭛ሑৃ࿁ڱDŽCANopen COB-ID ᓎᩲϬϔϾ᳔ʌӬܜ൫Ոҹֱ᪅ৠℹֵোℷᐌӴễz ௫ᗹџӊ˄Emergency˅᪂ݙᾬ⏝᪳ᢪথDŽϬCALЁᄬټџӊିൟՈCMSᇍᬥᅲɴDŽz ᅆ⚍/ᇓੑֱᡸ˄Node/Life guarding˅DŽЏҢỞᩳᓣNMTЏᅆ⚍֕ᅆ⚍źᗕ˖ࢴᅆ⚍ֱᡸ˄Node guarding˅DŽᅆ⚍гৃҹ˄ৃọᢽ˅֕NMTЏᅆ⚍Ոźᗕ˖ࢴᇓੑֱᡸ˄Life guarding˅DŽᔧNMT Ңᅆ⚍ᬊࠄNMTЏᅆ⚍থễՈৰϔϾNode Guard᭛ৢਃࡼᇓੑֱᡸDŽ Ẕ⌟᪂Ոตචষ⏝᪳˄ϡᰃ᪂ႮᵯՈ⏝᪳˅˖Ởẋᑨᗹᣛ߾ਞDŽḍNMTᅆ⚍ֱᡸणᩲᅲɴ˖ NMTЏᅆ⚍থễẠ࣏᪻∖ࠄϔϾĽᅮᅆ⚍ˈᅆ⚍ඝߎᑨਘˈᑨਘ᭛ЁࣙњẝϾᅆ⚍ՈźᗕDŽz Boot-UPЏҢỞᩳᓣNMTҢᅆ⚍ỞẋথễẝϾ᭛ˈNMTЏᅆ⚍᪸ᯢ᪩ᅆ⚍Ꮖඓϵ߱ྟ࣪źᗕẟܹ8᪡źᗕDŽ3-1 CANopen ᪂Ϟ☦ᦤࠄՈỞᩳᇍᬥିൟЁ᳝ѠϾᇍᬥϬѢ᭄ӴṗDŽᅗӀ₋ϬѠϡৠՈ᭄Ӵṗᴎࠊᅲɴ˖z SDO Ϭᴹ᪂ПⒸӴṗՈԢӬܜ൫᭄ˈൟՈᰃϬᴹ‑าCANopenตචϞՈ᪂DŽz PDO ϬᴹӴṗ8ᄫᅆᇥ᭄ˈ≵᳝݊ᅗणᩲ8᪂ᅮ˄ᛣੇ᭄ݙᆍᏆ8ܜᅮН˅DŽϔϾCANopen᪂ᖙ/ᬃᣕϔᅮ᭄ₓՈตචˊ᳡ࡵ˄ˊ᭛ˈadministrative messages˅ˈ◄ᡅႷᇥϔϾSDODŽ↣Ͼϣѻ⍜᯽ẋ᭄࣏Ո᪂◄ᡅႷᇥϔϾPDODŽ᠔᳝݊ᅗՈỞᩳᇍᬥᰃৃọՈDŽϔϾCANopen᪂ЁCANỞᩳষǃᇍᬥᄫᑨϬ࣏ᑣПⒸՈ༘ிབ3-1᠔߾DŽ3ˊ3 CANopen8ᅮНẢ▊ЎњޣᇣऩตචՈඈᗕᎹₓˈCANopenᅮНњᔎࠊᗻՈׅᷛ৪˄CAN-ID˅ߚ‑ᜬDŽẝѯᷛᖫ৪8᪡źᗕϟৃϬˈỞẋࡼᗕߚ‑ẜৃׂᬍҪӀDŽCANopen᪂ᖙ/ᅗ᠔ᬃᣕՈỞᩳᇍᬥՈᦤկּᑨՈᷛ৪DŽׅIDߚ‑ᜬᰃѢ11ԡCANˉIDˈࣙϔϾ4ԡՈࡳ࿁ۅᾬߚϔϾ7ԡՈᅆ⚍ID(Node-ID)ᾬߚDŽབ3-2᠔߾DŽ3-2 8ᅮНẢ▊IDNode-ID ϵிඣ▊៤ଚᅮНˈ՟བỞẋ᪂ϞՈᢼۅᓔ݇᪂าDŽNode-ID ᇇೈᰃ1~127˄0ϡܕ᩼ᝯՓϬ˅DŽ8ᅮНՈẢ▊ᅮНњ4ϾᬊPDO ˄Receive ˉPDO ˅ˈ4ϾথễPDO ˄Transmit ˉPDO ˅ˈ1ϾSDO ˄ऴϬ2ϾCAN-ID ˅ˈ1Ͼ௫ᗹᇍᬥ1Ͼᅆ⚍⏝᪳ࠊ(Node-Error-Control)ID DŽгᬃᣕϡ◄ܲᩨՈNMT-Module-Control ᳡ࡵˈSYNC Time Stamp ᇍᬥՈᑓ᪁DŽׅID ߚ‑ᜬབᜬ3-3᠔߾DŽᜬḐ 3-3 CANopen 8ᅮНЏ/ҢẢ▊CAN ᷛ৪ߚ‑ᜬCANopen 8ᅮНЏ/ҢẢ▊Ոᑓ᪁ᇍᬥᇍᬥࡳ࿁ۅ ˄ID-bits 10-7˅COB-ID Ởᩳখ᭄OD ЁՈ௦ᓩNMT Module Control 0000 000H -SYNC 0001 080H 1005H ˈ1006H ˈ1007HTIME SSTAMP0010100H1012H ˈ1013HCANopen Џ/ҢẢ▊Ոᇍᇍᬥ ᇍᬥ ࡳ࿁ۅࡳ࿁ۅ ˄ID-bits 10-7˅COB-IDỞᩳখ᭄OD ЁՈ௦ᓩ௫ᗹ 0001 081H-0FFH 1024H ˈ1015H PDO1(থễ) 0011 181H-1FFH 1800H PDO1(ᬊ) 0100 201H-27FH 1400H PDO2(থễ) 0101 281H-2FFH 1801H PDO2(ᬊ) 0110 301H-37FH 1401H PDO3(থễ) 0111 381H-3FFH 1802H PDO3(ᬊ) 1000 401H-47FH 1402H PDO4(থễ) 1001 481H-4FFH 1803H PDO4(ᬊ) 1010 501H-57FH 1403H SDO(থễ/᳡ࡵ఼) 1011 581H-5FFH 1200H SDO(ᬊ/ᅶ᠋) 1100 601H-67FH 1200HNMT Error Control 1110701H-77FH1016H-1017H⊼ᛣ˖z PDO/SDO থễ/ᬊᰃϵ˄slave ˅CAN ᅆ⚍ᮍᢆᆳՈDŽz ࠊࣙᣀᅆ⚍ֱᡸ˄Node Guarding ˅ˈᖗᲷ᭛˄Heartbeat ˅Boot-up णᩲDŽ ՈᑓՈᇍNMT ⏝᪳ࠊࣙᣀᅆ⚍N ˅H3ˊ4 CANopenᷛ৪ߚ‑IDഄഔߚ‑ᜬϢ8ᅮНՈЏҢẢ▊˄set˅ּᇍᑨˈЎ᠔᳝ՈᇍIDᰃϡৠՈˈ᠔ҹᅲ┉Ϟা᳝ϔϾЏ᪂(ک᠔᳝ẢՈᅆ⚍ID)࿁ẢՈ↣ϾҢᅆ⚍˄᳔127Ͼ˅ҹᇍᮍᓣỞᩳDŽϸϾẢϔ᰻ՈҢᅆ⚍ϡ࿁ỞᩳˈЎᅗӀᕐℸϡکᇍᮍՈᅆ⚍IDDŽ↨ṇϞᜬՈIDᇘCALՈᇘˈᰒ߾њ᳝Ľᅮࡳ࿁ՈCANopenᇍᬥབԩᇘࠄCALЁϔჰՈCMSᇍᬥDŽCANopenตචЁCAN ᷛ৪˄COB-ID˅ߚ‑3ϡৠᮍ⊩˖z ՓϬ8ᅮНՈЏҢẢ▊DŽIDᰃׅՈˈϡ◄ᡅ‑าDŽབᵰᅆ⚍ᬃᣕˈPDO᭄ݙᆍгৃҹ‑าDŽz ϞϹৢׂᬍPDOՈID˄8᪡źᗕ˅ˈՓϬ˄8ᅮНՈ˅SDOᅆ⚍ՈᇍᬥᄫЁỆᔧԡาẟᜐׂᬍDŽz ՓϬCAL DBT᳡ࡵ˖ᅆ⚍Ңᅆ⚍᳔߱ϵᅗӀՈ‑าIDᣛࢴDŽᅆ⚍IDৃҹϵ᪂ϞՈᢼۅᓔ݇‑าˈՓϬCAL LMT᳡ࡵẟᜐ‑าDŽᔧตච߱ྟ࣪ᅠ↩ˈᑊϨਃࡼৢˈЏᅆ⚍ŊܜỞẋ”Connect_Remote_Node”᭛˄ᰃϔϾCAL NMT᳡ࡵ˅↣ϾẢՈҢ᪂ᓎএϔϾᇍ᪡DŽϔᮺẝϾᇍ᪡ᓎএˈCANỞᩳID˄SDOPDO˅ϬCAL DBT᳡ࡵߚ‑དˈẝ◄ᡅᅆ⚍ᬃᣕᠽሩՈboot-upDŽ3ˊ5 CANopen boot-upẋ࣏ตච߱ྟ࣪ẋ࣏ЁˈCANopenᬃᣕᠽሩՈboot-upˈгᬃᣕ᳔ᇣ࣪boot-upẋ࣏DŽᠽሩboot-upᰃৃọՈˈ᳔ᇣboot-up߭ᖙ/ᝯ↣Ͼᅆ⚍ᬃᣕDŽϸିᅆ⚍ৃҹৠϔϾตචЁৠᯊᄬDŽབᵰՓϬCALՈDBT᳡ࡵẟᜐIDߚ‑ˈ߭ᅆ⚍ᖙ/ᬃᣕᠽሩboot-upẋ࣏DŽৃҹϬᅆ⚍źᗕḰᤶᜬ߾ẝϸ߱ྟ࣪ẋ࣏ˈབ3-3᠔߾DŽᠽሩboot-upՈźᗕ8᪡᪡źᗕПⒸ↨᳔ᇣ࣪boot-upњϔѯźᗕDŽ3-3 CANopen᳔ᇣ࣪boot-upᅆ⚍źᗕḰᤶ⊼ᛣ˖z 3-3ЁᣀোݙՈᄫ↡ᜬ߾໘ѢϡৠźᗕὧѯỞᩳᇍᬥৃҹՓϬDŽa. NMT ˈb. Node Guard ˈc. SDO ˈd. Emergency ˈe. PDO ˈf. Boot-upz źᗕḰࢿ˄1ˉ5ϵNMT᳡ࡵথ᰻˅ˈNMTੑҸᄫ˄ᣀোЁ˅˖1˖ Start_Remote_node (0x01)2˖Stop_Remote_Node (0x02)3˖ Enter_Pre-Operational_State (0x80) 4˖ Reset_Node (0x81) 5˖Reset_Communication (0x82)6˖᪂߱ྟ࣪ᴳˈႮࡼẟܹPre_Operational źᗕˈথễBoot-up ⍜ᙃӏԩᯊNMT ᳡ࡵ῁ৃՓ᠔້᳝ᾬߚᅆ⚍ẟܹϡৠՈᎹźᗕDŽNMT ᳡ࡵՈCAN ᭛ϵCAN ༈(COB-ID=0)ϸᄫᅆ᭄ඈ៤˗ৰϔϾᄫᅆᜬ߾᪻∖Ո᳡ࡵିൟ(‘NMT command specifier’)ˈৰѠϾᄫᅆᰃᅆ⚍ID ˈ້0˄ℸᯊᇏഔ᠔᳝ᅆ⚍˅DŽҙᬃᣕ᳔ᇣ࣪boot-up Ո᪂ি᳔ᇣ࿁᪂DŽ᳔ᇣ࿁᪂᪂߱ྟ࣪ᴳৢႮࡼẟܹ8᪡l źᗕDŽẝϾźᗕˈৃҹỞẋSDO ẟᜐখ᭄‑าẟᜐCOB-ID ߚ‑DŽ᪂ẟܹޚźᗕњNMT ᳡ࡵᅆ⚍ֱᡸ᳡ࡵ˄བᵰᬃᣕᑊϨ▔⌏Ո᪡˅ˈᇚذℶỞᩳDŽ˄ℸþStopped ÿᰃᦣẴẝϾźᗕՈϔϾདৡᄫ˅3ˊ6 CANopen ⍜ᙃ᪱⊩ඊᅆҹϟᾬߚЁCOB ˉID ՓϬՈᰃCANopen 8ᅮНẢ▊ЁᏆᅮНՈׅᷛᖫ৪DŽ3ˊ6ˊ1 NMT ഫࠊ˄NMT Module Control ˅া᳝ᅆ⚍࿁ӴễNMT Module Control ᭛DŽ᠔᳝Ң᪂ᖙ/ᬃᣕNMT ഫࠊ᳡ࡵDŽNMT Module Control ⍜ᙃNMT ⍜ᙃḐᓣབϟ˖NMT-Master Î NMT-Slave(s)COB-IDByte 0Byte 10x000 CS Node-IDNode-ID=0ˈ߭᠔᳝ՈNMT Ң᪂ᝯᇏഔDŽCS ᰃੑҸᄫˈৃҹপབϟؐ˖ੑҸᄫ NMT ᳡ࡵ1 Start Remote Node2 Stop Remote Node Enter Pre-operational State129 Reset Node130 Reset Communication3ˊ6ˊ2 MNT ᅆ⚍ֱᡸ˄NMT Node Guarding ˅NMT-Master ᅆ⚍থễẠ࣏ᏻ˄᮴᭄˅བϟ˖NMT-Master Î NMT-Slave COB-ID 0x700+Node_IDNMT-Slave ᅆ⚍থễབϟ᭛ᑨਘ˖NMT-Master Í NMT-Slave COB-ID Byte00x700 + Node_IDBit 7 : toggle Bit6-0 : źᗕ᭄ᾬߚࣙᣀϔϾᢪথԡ˄bit7˅ˈᢪথԡᖙ/↣ᅆ⚍ֱᡸᑨਘЁѸ᳓าĀ0ā້Ā1āDŽᢪথԡৰϔᅆ⚍ֱᡸ᪻∖ᯊาЎĀ0āDŽԡ0ࠄԡ6˄bits0̚6˅ᜬ߾ᅆ⚍źᗕˈৃЎϟᜬЁՈ᭄ؐDŽNMT-Master ᅆ⚍࿁ᙃϡ◄ᡅᑨਘDŽৢˈ┨128129130 MNT Ởẋᅆ⚍ֱᡸ᳡ࡵˈM Џᅆ⚍ৃҹẔᶹ↣Ͼᅆ⚍Ոᔧࠡźᗕˈᔧẝѯᅆ⚍≵᭄᳝Ӵễᯊẝ᳡ࡵᇸ᳝݊ᛣНDŽ᭛ᑨഫࠊ᳡ᔧValueźᗕ0 Initialising 1 Disconnected * 2 Connecting * 3Preparing *4 Stopped5 Operational 127 Pre-operationalboot-up Ոᅆ⚍ᠡᦤկDŽ⊼ᛣźᗕ0Ңϡᅆ⚍ֱᡸᑨਘЁߎɴˈ້ˈϔϾᅆ⚍ৃᝯ‑าЎѻϣ਼ᳳᗻՈᝯࢴᖗᲷ᭛˄Heartbeat ˅Ո᭛DŽHeartbeat Producer Î Consumer(s)COB-ID Byte 0 0x700 + Node_IDźᗕźᗕৃЎϟᜬՈ᭄ؐ˖źᗕᛣН0 Boot-up 4 Stopped 5 Operational 127 Pre-operationalHeartbeat ᅆ⚍ਃࡼৢᅗՈBoot-up ᭛ᰃ݊ৰϔϾHeartbeat ᭛DŽHeartbeat ⍜᯽້ỞᐌᰃNMT-Master ᅆ⚍ˈᅗЎ↣ϾHeartbeat ᅆ⚍᪂ᅮϔϾ᱉ᯊؐˈᔧ᱉ᯊথϣᯊ₋পּᑨࡼDŽϔϾᅆ⚍ϡ࿁ৠᯊᬃᣕNode Guarding Heartbeat णᩲDŽ3ˊ6ˊ3 NMT Boot-upᅆ⚍থᏗBoot-up ᭛ỞکNMT-Master ᅆ⚍ᅗᏆඓҢinitialising źᗕẟܹpre-operationalNMT-Master Í NMT-SlaveCOB-ID Byte 0 0x700 + Node_ID0 3ˊ6ˊ4 ẋ᭄࣏ᇍᬥ˄PDO ˅ЎϔϾ՟ᄤˈ؛ᅮৰѠϾtransmit-PDO ᇘབϟ˄CANopen ЁϬᇍᬥᄫ௦ᓩ0x1A01ᦣẴ˅˖ᇍᬥ0x1A01 : ৰѠϾTransmit-PDO ᇘᄤ௦ᓩؐᛣН0 22ϾᇍᬥᇘࠄPDO Ё1 0x60000208 ᇍᬥ0x6000ˈᄤ௦ᓩ0x02ˈϵ8ԡඈ៤2 0x64010110 ᇍᬥ0x6401ˈᄤ௦ᓩ0x01ˈϵ16ԡඈ៤ CANopen I/O ഫՈ᪂ᄤणᩲ˄CiA DSP-401˅ᅮНЁˈᇍᬥ0x6000ᄤ௦ᓩ2ᰃᅆ⚍Ոৰ2ඈ8ԡ᭄ᄫₓṗܹˈᇍᬥ0x6401ᄤ௦ᓩ0x01ᰃᅆ⚍Ոৰ1ඈ16ԡᢳₓṗܹDŽẝϾPDO ᭛བᵰᝯথễ(ৃ࿁ϵṗܹᬍবˈᅮᯊ఼Ёᮁ້Ạ࣏᪻∖ᏻᮍᓣᢪথˈPDO ՈӴṗିൟּϔႸˈৃҹᇍᬥ0x1801ᄤ௦ᓩ2Ёᶹᡒ)ˈ߭ϵ3ᄫᅆ᭄ඈ៤ˈḐᓣབϟ˖⊼ᛣ˖ᏺˆোՈźᗕা᳝ᬃᣕᠽሩЎϔϾᅆ⚍ẝϾźᗕᯊᑊϡᑨਘᅆ⚍ֱᡸ᭛DŽH ᔧϔϾ᭛᭛DŽNMT-slave źᗕDŽPDO-producer Î PDO-consumer(s)COB-ID Byte 0Byte 1 Byte 2 0x280+Node_ID8ԡ᭄ₓṗܹ 16ԡᢳₓṗܹ˄Ԣ8ԡ˅16ԡഫₓṗܹ ˄ʌ8ԡ˅Ởẋᬍবᇍᬥ0x1A01ՈݙᆍˈPDO Ոݙᆍৃᝯᬍব˄བᵰᅆ⚍ᬃᣕ˄ৃবPDO ᇘ˅˅DŽ⊼ᛣCANopen Ёᄫᅆখ᭄ᘏᰃܜথễLSB ˄little endian ˅DŽ ϡܕ᩼᱉ẋ8ϾᄫᅆՈ᭄ᇘࠄᶤϔϾPDO ЁDŽCANopen Application Layer and Communication Profile ˄CiA DS 301 V 4.02 ˅ЁᅮНњMPDO(multiplexor PDO)ˈܕ᩼ϔϾPDO ӴṗₓবₓˈỞẋ᭛᭄ᄫᅆЁࣙ⑤ֲՈᅆ⚍ID ǃOD ЁՈ௦ᓩᄤ௦ᓩᴹᅲɴDŽВϾ՟ᄤ˖བᵰ≵᳝ẝϾᴎࠊˈᔧϔϾᅆ⚍᳝64Ͼ16ԡՈᢳỞᯊˈህ◄ᡅ16ϾϡৠՈTransmit-PDOs ᴹӴễ᭄ˈ3ˊ6ˊ5 ᳡ࡵ᭄ᇍᬥ˄SDO ˅SDO Ϭᴹ᪃⒲ϔϾ᪂ՈᇍᬥᄫDŽ᪃⒲້ᝯࢴᅶ᠋ (client)ˈᇍᬥᄫᝯ᪃⒲Ϩᦤկ᠔᪻∖᳡ࡵՈCANopen ᪂߿ࢴ᳡ࡵ఼(server)DŽᅶ᠋ՈCAN ᭛᳡ࡵ఼ՈᑨਘCAN ᭛ᘏᰃࣙ8ᄫᅆ᭄ᛣН˅DŽϔϾᅶ᠋Ո᪻∖ϔᅮ᳝ᴹႮ᳡ࡵ఼ՈᑨਘDŽSDO ᳝2Ӵễᴎࠊ˖z ࡴợӴễ˄Expedited transfer ˅ ˖ ᳔Ӵṗ4ᄫᅆ᭄ z ߚ↉Ӵễ˄Segmented transfer ˅ ˖ Ӵṗ᭄⑃ᑺѢ4ᄫᅆSDO Ոᴀᵘབϟ˖ Client Î Server / Server Î ClientByte 0 Byte 1-2 Byte 3 Byte 4-7 SDOCommand Specifier ᇍᬥ௦ᓩᇍᬥᄤ௦ᓩ** ˄**᳔4ᄫᅆ᭄(expedited transfer)4ᄫᅆᄫᅆᩥ఼᭄˄segmented transfer ˅݇Ѣblock transfer খ᭄)້Client Î Server / Server Î ClientByte 0 Byte 1-70SDO ੑҸᄫ᳔7ᄫᅆ᭄˄segmented transfer ˅SDO ੑҸᄫࣙབϟֵᙃ˖ z ϟṁ/ϞӴ˄Download / upload ˅ z ᪻∖/ᑨਘ˄Request /response ˅z ߚ↉/ࡴợӴễ˄Segmented / expedited transfer ˅ z CAN ᏻ᭄ᄫᅆ⑃ᑺz ϬѢৢන↣Ͼߚ↉ՈѸ᳓⏙►าԡՈᢪথԡ˄toggle bit ˅SDO Ёᅲɴњ5Ͼ᪻∖/ᑨਘणᩲ˖ਃࡼඳϟṁ ˄Initiate Domain Download ˅ˈඳߚ↉ϟṁ˄Download Domain Segment ˅ˈ ਃࡼඳϞӴ ˄Initiate Domain Upload ˅ˈඳߚ↉ϞӴ ˄Upload Domain Segment ˅ ඳӴễЁℶ˄Abort Domain Transfer ˅DŽCANopen ỞᩳणᩲՈ᳔ᮄČᴀЁˈᓩܹњϔᮄՈSDO Ӵễᴎࠊ˖ഫӴễ˄Block transfer ˅˖ᔧӴễ᭄⑃ᑺѢ4ᄫᅆᯊˈϾߚ↉াϵ1Ͼܲᩨ᭛ᑨਘ˄བᵰᰃϟṁˈ߭ϵ᳡ࡵ఼ਃࡼӴễˈབᵰᰃϞӴˈ߭ϵᅶ᠋ਃࡼӴễ˅ҹࡴᘏඃ৲ₓDŽּᑨՈणᩲЎ˖ਃࡼഫϟṁ ˄Initiate Block Download ˅ˈഫߚ↉ϟṁ ˄Download Block Segment ˅ˈഫϟṁᴳ˄End Block Download ˅ˈਃࡼഫϞӴ ˄Initiate Block Upload ˅ˈഫߚ↉ϞӴ˄Upload BlockᛣϔϾB ˄ሑϡᰃ᠔᳝Ո᭄ᄫᅆ῁ϔᅮ᳝Segment ˅ ഫϞӴᴳ˄End Block Upload ˅DŽ˅ᰃUpload ˅ᣛᇍᇍᬥᄫẟᜐᪿ᪡DŽ ẝѯणᩲՈSDO ੑҸᄫ˄SDO CAN ᭛ՈৰϔϾᄫᅆ˅᪱⊩ඊᅆϟ☦ᾬߚ᪸ᯢ˖ ˄þˉÿᜬ߾ϡּ݇ˈᑨЎ0˅DŽਃࡼඳϟṁ˄Initiate Domain Download ˅Bit765432 1Client Î 0 0 1 - ne sÍServer 0 1 1 - - - - -᪸ᯢ˖z n ˖ བᵰe=1ˈϨs=1ˈ᳝߭ᬜˈ৺߭Ў0˗ᜬ߾᭄ᾬߚЁ᮴ᛣН᭄Ոᄫᅆ᭄˄ᄫᅆ8ˉnࠄ7᭄᮴ᛣН˅DŽz e ˖ 0 = ℷᐌӴễˈ1 = ࡴợӴễDŽz s ˖ ᰃ৺ᣛᯢ᭄⑃ᑺˈ0 = ᭄⑃ᑺᣛᯢˈ1 = ᭄⑃ᑺᣛᯢDŽ z e = 0ˈ s = 0˖ ϵCiA ֱНDŽz e = 0ˈ s = 1 ˖ ᭄ᄫᅆЎᄫᅆᩥ఼᭄ˈbyte 4ᰃ᭄Ԣԡᾬߚ˄LSB ˅ˈbyte 7ᰃ᭄ʌԡᾬߚ˄MSB ˅DŽz e = 1 ˖ ᭄ᄫᅆЎᇚᡅϟṁ˄download ˅Ո᭄DŽඳߚ↉ϟṁ˄Download Domain Segment ˅Bit765432 10 Client Î 0 0 0 t ncÍServer 0 0 1 t - - - -᪸ᯢ˖z n ˖᮴ᛣНՈ᭄ᄫᅆ᭄DŽབᵰ≵᳝ᣛᯢ↉⑃ᑺˈ߭Ў0DŽ z c ˖ 0 = ᳝ৢනߚ↉◄ᡅdownload ˈ1 = ᳔ৢϔϾ↉DŽz t ˖ ᢪথԡˈৢන↣Ͼߚ↉Ѹ᳓⏙►าԡ˄ৰϔӴễЎ0ˈᬜѢrequest/response ˅DŽਃࡼඳϞӴ˄Initiate Domain Upload ˅Bit765432 1Client Î 0 1 0 - - - - - ÍServer 0 1 0 - ne s ᪸ᯢ˖n ˈe ˈs ˖ ϢਃࡼඳϟṁּৠDŽඳߚ↉ϞӴ˄Upload Domain Segment ˅Bit765432 10 Client Î 0 1 1 t - - - - ÍServer 0 0 0 t nc᪸ᯢ˖n ˈc ˈt ˖ Ϣඳߚ↉ϟṁּৠDŽSDO ᅶ᠋᳡ࡵ఼ỞẋথߎབϟḐᓣՈ᭛ᴹЁℶSDO Ӵễ˖ඳӴễЁℶ˄Abort Domain Transfer ˅Bit7654321C Î/ÍS 1 0 0 - - - - -Download ˅ϟṁ˄D ᰃᣛᇍᇍᬥᄫẟᜐݭ᪡ˈϞӴ˄UඳӴễЁℶ᭛Ёˈ᭄ᄫᅆ01ᜬ߾ᇍᬥ௦ᓩˈᄫᅆ2ᜬ߾ᄤ௦ᓩˈᄫᅆ4ࠄ7ࣙ32ԡЁℶۅˈᦣẴЁℶ᭛Ӵễॳˈᢅᜬ3-4᠔߾DŽᜬ3-4 ඳӴễЁℶSDO˖16ẟࠊЁℶҷۅᜬ˄ᄫᅆ4ࠄ7˅Ёℶҷۅҷۅࡳ࿁ᦣẴ0503 0000 ᢪথԡ≵᳝Ѹ᳓ᬍব0504 0000 SDOणᩲ᱉ᯊ0504 0001 ☢⊩کՈClient/Server ੑҸᄫ0504 0002 ᮴ᬜՈഫᇣ˄ҙBlock Transferᓣ˅0504 0003 ᮴ᬜՈᑣো˄ҙBlock Transferᓣ˅0503 0004 CRC⏝᪳˄ҙBlock Transferᓣ˅0503 0005 ݙᄬ⑶ߎ0601 0000 ᇍᬥϡᬃᣕ᪃⒲0601 0001 ᪙ᪿাݭᇍᬥ0601 0002 ᪙ݭাᪿᇍᬥ0602 0000 ᇍᬥᄫЁᇍᬥϡᄬ0604 0041 ᇍᬥϡ࿁ᇘࠄPDO0604 0042 ᇘՈᇍᬥՈ᭄ֲ⑃ᑺ᱉ߎPDO⑃ᑺ0604 0043 ϔჰᗻখ᭄ϡݐᆍ0604 0047 ϔჰᗻ᪂ݙᾬϡݐᆍ0606 0000 ܰӊ⏝᪳ᇐႸᇍᬥ᪃⒲༅ᯩ0606 0010 ᭄ିൟϡऍ‑ˈ᳡ࡵখ᭄⑃ᑺϡऍ‑0606 0012 ᭄ିൟϡऍ‑ˈ᳡ࡵখ᭄⑃ᑺ0606 0013 ᭄ିൟϡऍ‑ˈ᳡ࡵখ᭄⑃ᑺڱ0609 0011 ᄤ௦ᓩϡᄬ0609 0030 ᱉ߎখ᭄Ոؐᇇೈ(ݭ᪃⒲ᯊ)0609 0031 ݭܹখ᭄᭄ؐ0609 0032 ݭܹখ᭄᭄ؐᇣ0609 0036 ᳔ؐᇣѢ᳔ᇣؐ0800 0000 ϔჰᗻ⏝᪳0800 0020 ᭄ϡ࿁ӴễֱᄬࠄᑨϬ0800 0021 ϵѢᴀഄࠊᇐႸ᭄ϡ࿁ӴễֱᄬࠄᑨϬ0800 0022 ϵѢᔧࠡ᪂źᗕᇐႸ᭄ϡ࿁ӴễֱᄬࠄᑨϬ0800 0023ᇍᬥᄫࡼᗕѻϣ⏝᪳ᇍᬥᄫϡᄬ˄՟བˈỞẋ᭛ӊϣ៤ᇍᬥᄫˈԚϵѢ᭛ӊᤳണᇐႸ⏝᪳ѻϣ˅ਃࡼഫϟṁ˄Initiate Block Download˅Bit 7 6 5 4 3 2 1 0 ClientÎ 1 1 0 - - cc s 0 ÍServer 1 0 1 - - sc - 0 ᪸ᯢ˖z cc ˖ᅶ᠋᭄ᰃ৺ՓϬCRC᷵ɀˈ0 = noˈ1 = yesDŽz sc ˖᳡ࡵ఼᭄ᰃ৺ՓϬCRC᷵ɀˈ0 = noˈ1 = yesDŽz s ˖ᰃ৺ᣛᯢ᭄▊⑃ᑺˈ0=᭄▊⑃ᑺᣛᯢˈ1˙᭄▊⑃ᑺᣛᯢDŽz s=0 ˖ϵCiAֱНDŽz s=1 ˖᭄ᄫᅆЎᄫᅆᩥ఼᭄ˈᄫᅆ4˖LSBˈᄫᅆ7˖MSBDŽz ᳡ࡵ఼ᄫᅆ4ᜬ߾blksizeˈे↣ഫЁߚ↉Ո᭄ֲˈ0<blksize<128DŽഫߚ↉ϟṁ˄Download Block Segment˅Bit 7 6 5 4 3 2 1 0ClientÎ c 0ClientÎ c 1…etc… c seqnoÍServer 1 0 1 - - - 1 0 ᪸ᯢ˖z c ˖ᰃ৺᳝ৢනߚ↉◄ᡅdownloadˈ0˙yesˈ1=noDŽz seqno ˖ߚ↉োˈ0<seqno<128DŽz ᅶ᠋᭄ᄫᅆ˖↣ߚ↉Ⴗࣙᣀ7ᄫᅆ᭄ᝯdownloadDŽz ᳡ࡵ఼ᄫᅆ1˖ᜬ߾᳔ৢϔϾᝯ៤ࡳᬊՈߚ↉ো˗བᵰЎ0ˈᜬ߾ߚ↉োЎ1Ոߚ↉ℷܲᬊˈ᠔᳝↉ᖙ/ₑӴDŽz ᳡ࡵ఼ᄫᅆ2˖ࣙblksizeˈ↣ϾഫЁߚ↉Ո᭄ֲˈᅶ᠋ᴎᖙ/ՓϬᅗẟᜐϟϔഫϟṁˈ0<blksize<128DŽഫϟṁᴳ˄End Block Download˅Bit 7 6 5 4 3 2 1 0ClientÎ 1 1 0 n - 1 ÍServer 1 0 1 - - - - 1 ᪸ᯢ˖z n ˖ᣛ߾᳔ৢϔϾഫՈ᳔ৢϔϾ↉Ё᮴ᛣН᭄Ոᄫᅆ᭄DŽz ᅶ᠋᭄bytes1+2 ЎᭈϾ᭄▊Ո16ԡCRC˗া᳝ᔧਃࡼഫϟṁ᭛Ё ccscৠᯊЎ1ᯊCRCᠡ᳝ᬜDŽਃࡼഫϞӴ˄Initiate Block Upload˅Bit 7 6 5 4 3 2 1 0ClientÎ 1 0 1 - - cc 0 0 ÍServer 1 1 0 - - sc 0 ClientÎ 1 0 1 - - - 1 1 ᪸ᯢ˖z cc ˖ᅶ᠋᭄ᰃ৺ՓϬCRC᷵ɀˈ 0˙no ˈ1=yesDŽz sc ˖᳡ࡵ఼᭄ᰃ৺ՓϬCRC᷵ɀˈ 0=noˈ 1=yesDŽz s ˖ᰃ৺ᣛᯢ᭄▊⑃ᑺˈ0=᭄▊⑃ᑺᣛᯢˈ1˙᭄▊⑃ᑺᣛᯢDŽz s=0˖ϵCiAֱНDŽz s=1˖᭄ᄫᅆЎᄫᅆᩥ఼᭄ˈᄫᅆ4˖LSBˈᄫᅆ7˖MSBDŽz ᅶ᠋᭄ᄫᅆ4˖ᜬ߾blksizeˈे↣ഫЁߚ↉Ո᭄ֲˈ0<blksize<128DŽz ᅶ᠋᭄ᄫᅆ5˖ᜬ߾णᩲḰᤶᄫ˄pst˖Protocol Switch Threshold˅ˈϬѢᰃ৺ܕ᩼ᬍবSDO Ӵễणᩲˈ0=ϡܕ᩼ᬍবˈ1=ܕ᩼ᬍব˄བᵰᡅuploadՈ᭄ᄫᅆ᭄ᇥѢѢpstˈServerৃҹỞẋInitiate Domain UploadणᩲᑨਘᬍবࠄUpload Domainणᩲ˅DŽഫߚ↉ϞӴ˄Upload Block Segment˅Bit 7 6 5 4 3 2 1 0ÍServer c 0ÍServer c 1..etc… c seqnoClientÎ 1 1 0 - - - 1 0 ᪸ᯢ˖z c ˖ᰃ৺᳝ৢනߚ↉◄ᡅdownloadˈ0˙yesˈ1=noDŽz seqno ˖ߚ↉োˈ0<seqno<128DŽz ᳡ࡵ఼᭄ᄫᅆ˖↣ߚ↉Ⴗࣙᣀ7ᄫᅆ᭄ᝯdownloadDŽz ᅶ᠋ᄫᅆ1˖ᜬ߾᳔ৢϔϾᝯ៤ࡳᬊՈߚ↉ো˗བᵰЎ0ˈᜬ߾ߚ↉োЎ1Ոߚ↉ℷܲᬊˈ᠔᳝↉ᖙ/ₑӴDŽz ᅶ᠋ᄫᅆ2˖ࣙblksizeˈ↣ϾഫЁߚ↉Ո᭄ֲˈᅶ᠋ᴎᖙ/ՓϬᅗẟᜐϟϔഫϟṁˈ0<blksize<128DŽഫϞӴᴳ˄End Block Upload˅Bit 7 6 5 4 3 2 1 0ÍServer 1 1 0 n - 1 ClientÎ 1 0 1 - - - - 1 ᪸ᯢ˖z n ˖ᣛ߾᳔ৢϔϾഫՈ᳔ৢϔϾ↉Ё᮴ᛣН᭄Ոᄫᅆ᭄DŽz ᳡ࡵ఼᭄bytes1+2 ЎᭈϾ᭄▊Ո16ԡCRC˗া᳝ᔧਃࡼഫϞӴ᭛Ё ccscৠᯊЎ1ᯊCRCᠡ᳝ᬜDŽϟ☦ඝߎϾ՟ᄤ᪸ᯢབԩՓϬSDOᴹ᪃⒲ϔϾᅆ⚍ՈᇍᬥᄫDŽՓϬϟ☦ՈSDO⍜ᙃˈؐ0x3FEᇚݭࠄᅆ⚍IDЎ2ՈᇍᬥᄫЁ௦ᓩЎ0x1801ˈᄤ௦ᓩЎ3ՈᇍᬥЁএˈՓϬਃࡼඳϟṁणᩲˈࡴợӴṗ˄2ᄫᅆ᭄˅˖Client Î Server (ᅆ⚍#2)COB-IDByte0 1 2 3 4 5 6-7602 2B 01 18 03 FE 03 - Client Í Server(ᅆ⚍ʿ2)582 60 01 18 03 - - - ՓϬϟ☦ՈSDO⍜ᙃˈৠḋՈᇍᬥᄫЁ௦ᓩЎ0x1801ˈᄤ௦ᓩЎ3ՈᇍᬥᇚᝯᪿߎˈՓϬਃࡼඳϞӴणᩲˈ᳡ࡵ఼ՓϬࡴợӴṗᮍᓣᑨਘ˄2ᄫᅆ᭄˅˖Client Î Server(ᅆ⚍ʿ2)COB-IDByte0 1 2 3 4 5 6-7602 40 01 18 03 - - - Client Í Server(ᅆ⚍ʿ2)582 4B 01 18 03 FE 03 - 3ˊ6ˊ6 ᑨᗹᣛ߾ᇍᬥ(Emergency Object)ᑨᗹᣛ߾᭛ϵ᪂ݙᾬߎɴՈႸੑ⏝᪳ᢪথˈϵּ݇ᑨϬ᪂݊ᅗ᪂DŽỆϬѢЁᮁିൟՈ⏝᪳ᨪֵোDŽ8ᄫᅆඈ៤ˈḐᓣབϟ˖ sender Î receiver(s)COB-ID Byte 0-1 Byte 2 Byte 3-70x080+Node_IDᑨᗹ⏝᪳ҷۅ⏝᪳ᆘᄬ఼ (ᇍᬥ0x1001)ࠊỤଚĽᅮՈ⏝᪳ऎඳ16ẟࠊՈᑨᗹ⏝᪳ҷۅབϟᜬ3-5᠔߾DŽᑨᗹ⏝᪳ҷۅЁþxx ÿᾬߚϵּᑨՈ᪂ᄤणᩲᅮНDŽᜬ3-5 ᑨᗹ⏝᪳ҷۅ˄16ẟࠊ˅ᑨᗹ⏝᪳ҷۅҷۅࡳ࿁ᦣẴ00xxError Reset No Error10xx Generic Error 20xx Current 21xx Current ˈdevice input side 22xx Current ˈinside the device 23xxCurrent ˈdevice output side30xx V oltage31xx Mains voltage 32xxV oltage inside the device33xx Output voltage 40xx Temperature41xx Ambient temperature 42xx Device tempearture 50xx Device hardware 60xx Device software61xx Internal software 62xx User software 63xx Data set 70xx Additional modules 80xx Monitoring81xx communication 8110 CAN overrun 8120 Error Passive 8130 Life Guard Error Heartbeat Error 8140Recovered from Bus-Off82xx Protocol Error 8210PDO no processed Due to length error8220 Length exceedd 90xx External error F0xx Additional functions FFxx Device specificᏆ᳔ʌӬܜ൫থễࠄϔϾᑨᗹ᭛ϵ⏝᪳ᆘᄬ఼(Error Register)᪂Ոᇍᬥᄫ˄௦ᓩ0x1001˅Ёˈᜬ3-6᪸ᯢњ⏝᪳ᆘᄬ఼ՈԡᅮНDŽ᪂ৃҹᇚݙᾬ⏝᪳ᇘࠄẝϾźᗕᄫᅆЁˈᑊৃҹᖿợᶹᔧࠡ⏝᪳DŽᜬ3-6 8ԡ⏝᪳ᆘᄬ఼ԡᅮНBit⏝᪳ିൟ0 Generic1 Current2 V oltage3 Temperature4 Communication5 Device profile specific6 Reserved(=0)7 ManufacturerspecificࠊỤଚĽᅮ⏝᪳ऎඳৃ࿁ࣙϢ᪂ּ݇Ո݊ᅗՈ⏝ֵ᪳ᙃDŽ4ǃᘏѢCANᘏඃՈCANopenตචỞᩳ᳝ҹϟĽ⚍˖z ՓϬᇍᬥᄫ˄OD˖Object Dictionary˅ᇍ᪂ࡳ࿁ẟᜐᷛޚ࣪ՈᦣẴDŽz ՓϬASCII᭛ḷ˖Ϲᄤ᭄᭛ḷ˄EDS˅᪂‑า᭛ӊ˄DCF˅ᇍ᪂ঞ݊‑าẟᜐᷛޚ࣪ՈᦣẴDŽz CANopenตචՈ᭄ѸᤶிඣˊѢCALЁCMS᳡ࡵDŽz ிඣboot-upᅆ⚍ֱᡸ˄Node Guarding˅ՈᷛޚѢCALЁNMT᳡ࡵDŽz ᅮНњᭈϾிඣՈৠℹ᪡DŽz ᅮНњᅆ⚍ĽᅮՈᑨᗹ᭛DŽЎϢCANopenỞᩳणᩲּᑨՈ᪂ᄤणᩲֱᣕϔႸˈҹՓࠊỤଚՈѻક࿁ϬѢӏԩCANopenตචˈҹϟ3ሖՈݐᆍᗻᡅ∖◄ᡅ⒵ᱷ˄ᇍ᮹֎⑃Ո᪂ݐᆍᗻՈᡅ∖˅˖z ϔႸᗻ˖᪂ẢࠄCANopenตචৢϡ࿁ᕅડ݊Ҫ᪂ՈỞᩳ˖ᑨϬሖՈϔႸᗻDŽz ѦϬᗻ˖᪂࿁ৠตචϞՈ݊ᅗᅆ⚍Ѹᤶ᭄˖ỞᩳणᩲՈϔႸᗻDŽz Ѧᤶᗻ˖᪂࿁ҷ᳓ϔϾৠି᪂˖᪂ᄤणᩲՈϔႸᗻDŽϔϾCANopen᪂Ⴗᇥᑨ᪩᳝˄᳔ᇣ࿁᪂˅˖z ϔϾᅆ⚍IDˈz ϔϾᇍᬥᄫ˄ݙᆍϵ᪂ࡳ࿁އᅮ˅ˈz ϔϾSDOˈ࿁᪃⒲ᇍᬥᄫЁᖙ◄Ոᇍᬥ˄াᪿ˅ˈz ᬃᣕϟ߫NMTҢ᪂᳡ࡵ˖Reset_Nodeˈ Enter_Preoperational_Stateˈ Start_Remote_NodeˈStop_Remote_Nodeˈ Reset_Communicationˈz ׅՈᷛ৪ߚ‑DŽᑓᎲ਼এࡳऩċᴎথሩ᳝└݀ৌ5ǃ᪸ᯢᴀ᭛তՈᾬߚݙᆍ᪕ႮҟඑCANopenणᩲՈϔઋ᭛তljCANopen˖high-level protocol for CAN-busNJˈ᪩᭛ত↨ṇܼ☦ഄҟඑњCANopenणᩲDŽCANopenणᩲᰃѢCAN-busՈϔʌሖणᩲˈ⌆ᑨϬṇЎᑓ⊯ˈỆড়ѢϹẃϹ⇨ǃᱎₒ≑Ḫǃხ⍋ϹᄤǃएћϹ఼ǃᎹ࣏ᴎẄǃ⎅ᲳᴎḪ:ඳˈϨणᩲ⍌ᇍᜐϮᑨϬˈᅲɴ↨ṇ⋕DŽ᪕ℸ᭛ՈֲՈѢϔѯĽᅮᜐϮՈCAN-busϬ᠋ᦤկ݇ѢCANopenणᩲՈ᳝ϬֵᙃˈᏠᳯ࿁ᇍẝѯᜐϮՈCANopenणᩲѻક᪂ᩥ᰻ϔᅮՈᣛᇐϬˈҢ໐Փ៥ՈCAN-busᑨϬঞᮽϢ┉ḬDŽॳ᭛ᴹႮሻ݄NIKHEF݀ৌตঝˈ້Ў˖H. BoterenbroodDŽ19。