CANOPEN协议详解.pdf
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协议浅析(一)
CANopen通信对象 通信对象
Type 0：非周期同步,只有当节点 只有当节点PDO数据发生改变后,节点 收到SYNC时,才会更新并传送一笔 才会更新并传送一笔PDO数据信息. 在异步模式中,若从站中的Event timer 为0ms,则只有当从站的数 Event 据发生变化时,才会向主站回传数据 才会向主站回传数据;若为非0值,则每隔一个event timer时间,即向主站回传一笔数据 即向主站回传一笔数据.
Consumer(s
Remote Frame Remotely requested Producer
Consumer(s
Sync Synchronous transmission (cyclic,acyclic) Producer
Consumer(s
CANopen通信对象 通信对象
PDO 的传输类型:
CANopen协议是由CiA（ （CAN-in-Automation）定义并 维护的协议之一,它是在CAL CAL（CAN Application Layer）协 议基础上开发的,使用了CAL CAL通信和服务协议子集.
CANopen在发布后不久就获得了广泛的承认 在发布后不久就获得了广泛的承认,尤其在欧 洲, CANopen被认为是在基于 被认为是在基于CAN的工业系统中领导地位 的标准.目前被广泛地用于智能楼宇 目前被广泛地用于智能楼宇，嵌入式系统,车载设备, 医疗装置等应用领域中.
CANopen通信对象 通信对象
CANopen 网络中信息传输采用的三种通信模式 网络中信息传输采用的三种通信模式:
Producer/Consumer Model Client/Server Model Master/Slave Model
CANopen协议介绍
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。
IXL-Ⅱ_CANopen协议及使用说明1.0
IXL-II CANOpen通信协议及使用说明(2019-12 V1.0)同毅自动化技术有限公司目录一、通信方式选择以及配置 (4)二、CANopen通信简介 (6)三、总线管理NMT报文 (9)四、心跳报文与节点保护 (10)4.1 Heartbeat心跳报文 (10)4.2 节点保护功能 (10)4.3 通信中断自动停机保护功能 (11)五、制造商设备标志报文 (12)六、CANopen设备控制和模式控制 (13)6.1 控制字 Controlword(0x6040) (16)6.2 状态字 Statusword(0x6041) (18)6.3 模式控制 Modes_of_operation (0x6060) (20)6.4 错误代码 Error_code (0x603F) (20)七、SDO通信 (23)7.1 SDO读操作 (23)7.2 SDO写操作 (23)八、PDO通信 (25)8.1 PDO通信方式 (25)8.2 PDO参数映射 (26)8.3 驱动器默认PDO映射 (27)8.4 转矩模式使用默认PDO映射参数 (29)8.5 速度模式使用默认PDO映射参数 (31)8.6 位置模式使用默认PDO映射参数 (33)九、回零模式（Home） (37)十、位置控制模式（Profiled Position） (45)十一、位置插补模式（Interpolated Position） (46)十二、循环同步位置模式（CSP） (48)十三、循环同步速度模式（CSV） (49)十四、循环同步力矩模式（CST） (50)十五、速度控制模式（Profiled Velocity） (51)十六、力矩控制模式（Profiled Torque ） (52)十七、用Cockpit动态配置PDO映射参数 (53)附录一：CANOPEN设备对象字典 (55)版本修改记录一、通信方式选择以及配置CANopen 波特率设置驱动器支持10kbps ~1Mbps 范围内波特率，对于CANopen 的波特率是通过Modbus 协议接口利用Cockpit 调试软件设置can_Para_CHANGED.BAUDRATE 参数来改变驱动器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有三种通信方式：主/从通信方式服务器/客户端通信方式生产商/顾客通信方式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总线结构⼴播命令⼆、通信类型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协议浅析
PDO Consumer
CANopen通信对象
▪ PDO 的三种触发机制:
✓ Event or Timer driven
Internal event
Producer
Consumer(s)
✓ Remotely requested
Producer
Remote Frame
Consumer(s)
✓ Synchronous transmission
▪ With Service Data Objects (SDOs) protocols the read and write access to entries of a device object dictionary is provided.
▪ Special Function Object protocols provide applicationspecific network synchronization, time stamping and emergency message transmissions.
▪ The Network Management (NMT) protocols provide services for network initialization, error control and device status control.
CANopen通信对象
CANopen 网络中信息传输采用的三种通信模式:
Application Layer
CAN Data Link Layer
CAN Physical Layer
ID+Data ID+Data
CAN-L
CAN-L
CAN-H
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协议介绍(中文)
CMS 提供了一个开放的、面向对象的环境，用于实现用户的应用。CMS 提供基于变量、事件、 域类型的对象，以设计和规定一个设备（节点）的功能如何被访问（例如，如何上载下载超过 8 字节 的一组数据（域），并且有终止传输的功能）。
提供动态分配 CAN ID（正式名称为 COB-ID，Communication Object Identifier）服务。这种服务 是采用主从通讯模式（所以只有一个 DBT 主节点）来实现的。 LMT (Layer ManagemenT)
LMT 提供修改层参数的服务：一个节点（LMT Master）可以设置另外一个节点（LMT Slave）的 某层参数（如改变一个节点的 NMT 地址，或改变 CAN 接口的位定时和波特率）。
1541 - 1760
CMS 对象 优先级 7
1761 - 2015
NMT 节点保护
2016 - 2031
NMT，LMT，DBT 服务
注意这是 CAN2.0A 标准，11 位 ID 范围[0，2047]，由于历史原因限制在[0，2031]。如果使用 CAN2.0B 标准，29 位 ID 并不改变这个描述；表中的 11 位映射到 29 位 COB-ID 中的最高 11 位，以至于表中的 COB-ID 范围变得增大许多。
CMS 从 MMS (Manufacturing Message Specification)继承而来。MMS 是 OSI 为工业设备的远程控 制和监控而制定的应用层规范。 NMT (Network ManagemenT)
提供网络管理（如初始化、启动和停止节点，侦测失效节点）服务。这种服务是采用主从通讯模 式（所以只有一个 NMT 主节点）来实现的。 DBT (DistriBuTor)
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是一种基于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协议介绍-周立功
w w w. z l g m c u . c o m
CANopen 协议介绍
流行欧洲的 CAN-bus 高层协议
1Байду номын сангаас
广州周立功单片机发展有限公司
w w w. z l g m c u . c o m
目录
1、介绍 ..................................................................................................................................................................... 1 2、CAL 协议............................................................................................................................................................ 2 3、CANopen ............................................................................................................................................................. 3
3.1 对象字典 OD
对象字典（OD：Object Dictionary）是一个有序的对象组；每个对象采用一个 16 位的索引值来寻址， 为了允许访问数据结构中的单个元素，同时定义了一个 8 位的子索引，对象字典的结构参照表 3-1。不要被 对象字典中索引值低于 0x0FFF 的‘data types’项所迷惑，它们仅仅是一些数据类型定义。一个节点的对 象字典的有关范围在 0x1000 到 0x9FFF 之间。
最新CAN与CANopen详解
PDF 文件使用 "pdfFactory Pro" 试用版本创建
为全球客户提供中国人的自动化解决方案
行网络管理功能。 a) 应用层（Application layer）：为网络中每一个有效设备都能够提供一组有用的服 务与协议。 b) 通讯描述（Communication profile）：提供配置设备、通讯数据的含义，定义数据 通讯方式。 c) 设备描述（Device proflile）：为设备（类）增加符合规范的行为。
称作对象辞典，这种对象辞典的设计方式基于 CANopen 国际标准，所有的对象有明确的功
能定义。这里说的对象（Objects）类似我们常说的内存地址，有些对象如速度和位置等可
以由外部控制器修改，有些对象却只能由驱动器本身修改，如状态、错误信息。这些对象
如下：
Index Sub Bits
属性 含义
例如： 6040 00
驱动器、变频器、传感器等放置到现场的话，可以节省大量的电缆费用）； n 减小施工难度，缩短施工周期 n 降低系统总成本（从安装、系统维护、升级方面大幅降低系统成本）
PDF 文件使用 "pdfFactory Pro" 试用版本创建
为全球客户提供中国人的自动化解决方案
HMI
伺服
伺服
变频器 远程I/O 伺服
第二部分：协议介绍
1、模型介绍
从OSI网络模型的角度来看同，现场总线网络一般只实现了第1层（物理层）、第2层（数据 链路层）、第7层（应用层）。因为现场总线通常只包括一个网段，因此不需要第3层（传输层） 和第4层（网络层），也不需要第5层（会话层）第6层（描述层）的作用。
ü 可选择对网络进行三种操作：无处理、停止故障从站、停止整个网络 ü CAN 节点在错误严重的情况下，具有自动关闭总线的功能，切断它与总线
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协议详解35180
一、 ✌☠✞介绍． ✌☠的基本概念、特点✌☠ 是 ☐⏹♦❒☐●●♏❒ ✌❒♏♋ ☠♏♦♦☐❒的缩写（以下称为 ✌☠），是 ✋✉国际标准化的串行通信协议。
✌☠ 协议如表 所示涵盖了 ✋ 规定的 ✋ 基本参照模型中的传输层、数据链路层及物理层。
✌☠ 协议中关于 ✋✋ 基本参照模型中的传输层、数据链路层及物理层，具体有哪些定义如图所示。
✋✋ 基本参照模型【注】 ✉ ✋： ☐♏⏹ ⍓♦♦♏❍♦ ✋⏹♦♏❒♍☐⏹⏹♏♍♦♓☐⏹ （开放式系统间互联）✌☠的特点✌☠ 协议具有以下特点。
☎✆ 多主控制在总线空闲时，所有的单元都可开始发送消息（多主控制）。
最先访问总线的单元可获得发送权。
☎✆ 消息的发送在 ✌☠ 协议中，所有的消息都以固定的格式发送。
总线空闲时，所有与总线相连的单元都可以开始发送新消息。
两个以上的单元同时开始发送消息时，根据标识符（✋♎♏⏹♦♓♐♓♏❒ 以下称为 ✋）决定优先级。
✋ 并不是表示发送的目的地址，而是表示访问总线的消息的优先级。
两个以上的单元同时开始发送消息时，对各消息 ✋ 的每个位进行逐个仲裁比较。
仲裁获胜（被判定为优先级最高）的单元可继续发送消息，仲裁失利的单元则立刻停止发送而进行接收工作。
☎✆ 系统的柔软性与总线相连的单元没有类似于“地址”的信息。
因此在总线上增加单元时，连接在总线上的其它单元的软硬件及应用层都不需要改变。
☎✆ 通信速度根据整个网络的规模，可设定适合的通信速度。
在同一网络中，所有单元必须设定成统一的通信速度。
即使有一个单元的通信速度与其它的不一样，此单元也会输出错误信号，妨碍整个网络的通信。
不同网络间则可以有不同的通信速度。
☎✆ 远程数据请求可通过发送“遥控帧” 请求其他单元发送数据。
☎✆ 错误检测功能·错误通知功能·错误恢复功能所有的单元都可以检测错误（错误检测功能）。
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 协议介绍流行欧洲的CAN-bus高层协议目录1、介绍 (1)2、CAL 协议 (2)3、CANopen (3)3．1 对象字典OD (3)3．2 CANopen通讯 (4)3．3 CANopen预定义连接集 (6)3．4 CANopen标识符分配 (8)3．5 CANopen boot-up过程 (8)3．6 CANopen消息语法细节 (9)4、总结 (18)5、说明 (19)北京博控自动化技术有限公司 ｗｗｗ．ｂｏｃｏｎ．ｃｏｍ．ｃｎ1、介绍从OSI网络模型的角度来看同，现场总线网络一般只实现了第1层（物理层）、第2层（数据链路层）、第7层（应用层）。
因为现场总线通常只包括一个网段，因此不需要第3层（传输层）和第4层（网络层），也不需要第5层（会话层）第6层（描述层）的作用。
CAN（Controller Area Network）现场总线仅仅定义了第1层、第2层（见ISO11898标准）；实际设计中，这两层完全由硬件实现，设计人员无需再为此开发相关软件（Software）或固件（Firmware）。
同时，CAN只定义物理层和数据链路层，没有规定应用层，本身并不完整，需要一个高层协议来定义CAN报文中的11/29位标识符、8字节数据的使用。
而且，基于CAN总线的工业自动化应用中，越来越需要一个开放的、标准化的高层协议：这个协议支持各种CAN厂商设备的互用性、互换性，能够实现在CAN 网络中提供标准的、统一的系统通讯模式，提供设备功能描述方式，执行网络管理功能。
应用层（Application layer）：为网络中每一个有效设备都能够提供一组有用的服务与协议。
通讯描述（Communication profile）：提供配置设备、通讯数据的含义，定义数据通讯方式。
设备描述（Device proflile）：为设备（类）增加符合规范的行为。
下面的章节将介绍基于CAN的高层协议：CAL协议和基于CAL协议扩展的CANopen协议。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
(3) 控制段 控制段由 6 个位构成，表示数据段的字节数。 标准格式和扩展格式的构成有所不同。
数据帧（控制段）
【注】 *1 保留位（ r0、 r1） 保留位必须全部以显性电平发送。但接收方可以接收显性、隐性及其任意组合的电 平。 *2 数据长度码（ DLC） 数据长度码与数据的字节数的对应关系如表 8 所示。 数据的字节数必须为 0～8 字节。但接收方对 DLC = 9～15 的情况并不视为错误。
下。 3.4 错误帧 用于在接收和发送消息时检测出错误通知错误的帧。错误帧由错误标志和错误界定
符构成。 错误帧的构成如图所示。 (1) 错误标志 错误标志包括主动错误标志和被动错误标志两种。 主动错误标志： 6 个位的显性位。 被动错误标志： 6 个位的隐性位。 (2) 错误界定符 错误界定符由 8 个位的隐性位构成。
(4) 通信速度
根据整个网络的规模，可设定适合的通信速度。
在同一网络中，所有单元必须设定成统一的通信速度。即使有一个单元的通信速度 与其它的不一样，此单元也会输出错误信号，妨碍整个网络的通信。不同网络间则可以 有不同的通信速度。
(5) 远程数据请求 可通过发送“遥控帧”请求其他单元发送数据。
(6) 错误检测功能·错误通知功能·错误恢复功能
总线的消息的优先级。两个以上的单元同时开始被判定为优先级最高）的单元可继续发送消息，仲裁失利
的单元则立刻停止发送而进行接收工作。
(3) 系统的柔软性
与总线相连的单元没有类似于“地址”的信息。因此在总线上增加单元时，连接在 总线上的其它单元的软硬件及应用层都不需要改变。
1 层：物理层
规定了通信时使用的电缆、连接器等的媒体、电气信号规格等，以实 现
设备间的信号传送。 如： 信号电平、 收发器、 电缆、 连接器等的形态。
【注】 * 1 OSI ： Open Systems Interconnection
（开放式系统间互联）
CAN的特点
CAN 协议具有以下特点。
(1) 多主控制
在总线空闲时， 所有的单元都可开始发送消息 （多主控制）。最先访问总线的单元可 获得发送权。
(2) 消息的发送
在 CAN 协议中，所有的消息都以固定的格式发送。总线空闲时，所有与总线相连
的单元都可以开始发送新消息。两个以上的单元同时开始发送消息时，根据标识符
（ Identifier 以下称为 ID）决定优先级。 ID 并不是表示发送的目的地址， 而是表示访问
一、 CAN-BUS介绍
1． CAN的基本概念、特点
CAN 是 Controller Area Network 的缩写（以下称为 CAN），是 ISO*1 国际标准化 的串行通信协议。
CAN 协议如表 3 所示涵盖了 ISO 规定的 OSI 基本参照模型中的传输层、 数据链路 层及物理层。
CAN 协议中关于 ISO/OSI 基本参照模型中的传输层、 数据链路层及物理层， 具体有 哪些定义如图所示。
卡车、大客车 农用机械
汽车 （高速：动力、传动系 统） 汽车 （低速：车身系统） 船舶
工业设备
工业设备
工业设备
3. CAN协议帧发送细节
3.1 帧的种类 通信是通过以下 5 种类型的帧进行的。 ? 数据帧 ? 遥控帧 ? 错误帧 ? 过载帧 ? 帧间隔
另外，数据帧和遥控帧有标准格式和扩展格式两种格式。标准格式有 识符（ Identifier: 以下称 ID），
3.5 过载帧 过载帧是用于接收单元通知其尚未完成接收准备的帧。过载帧由过载标志和过载界 定符构成。 过载帧的构成如图所示。 (1) 过载标志
6 个位的显性位。 过载标志的构成与主动错误标志的构成相同。 (2) 过载界定符 8 个位的隐性位。 过载界定符的构成与错误界定符的构成相同。
3.6 帧间隔 帧间隔是用于分隔数据帧和遥控帧的帧。数据帧和遥控帧可通过插入帧间隔将本帧 与前面的任何帧（数据帧、遥控帧、错误帧、过载帧）分开。 过载帧和错误帧前不能插入帧间隔。 帧间隔的构成如图所示。
遥控帧的构成
? 数据帧和遥控帧的不同 遥控帧的 RTR 位为隐性位，没有数据段。
没有数据段的数据帧和遥控帧可通过 RTR 位区别开来。
? 遥控帧没有数据段，数据长度码该如何表示？ 遥控帧的数据长度码以所请求数据帧的数据长度码表示。
? 没有数据段的数据帧有何用途？ 例如，可用于各单元的定期连接确认 / 应答、或仲裁段本身带有实质性信息的情况
(2) 仲裁段 表示数据的优先级的段。 标准格式和扩展格式在此的构成有所不同。
数据帧（仲裁段）
【注】 ID 标准格式的 ID 有 11 个位。从 ID28 到 ID18 被依次发送。 禁止高 7 位都为隐性。 （禁止设定： ID=1111111XXXX） 扩展格式的 ID 有 29 个位。基本 ID 从 ID28 到 ID18，扩展 ID 由 ID17 到 ID0 表示。基本 ID 和 标准格式的 ID 相同。禁止高 7 位都为隐性。（禁止设定：基本 ID=1111111XXXX）
数据长度码和字节数的关系
(4) 数据段（标准、扩展格式相同） 数据段可包含 0～ 8 个字节的数据。从 MSB（最高位）开始输出。
(5) CRC段（标准 / 扩展格式相同） CRC段是检查帧传输错误的帧。 由 15 个位的 CRC 顺序和 1 个位的 CRC界定符（用 于分隔的位）构成。
【注】 CRC顺序 CRC顺序是根据多项式生成的 CRC 值， CRC 的计算范围包括帧起始、仲裁段、控 制段、数据段。 接收方以同样的算法计算 CRC值并进行比较，不一致时会通报错误。 (6) ACK段 ACK 段用来确认是否正常接收。由 ACK 槽 (ACK Slot和) ACK 界定符 2 个位构成。
11 个位的标
3.2 数据帧 数据帧由 7 个段构成。 数据帧的构成如图所示。 (1) 帧起始 表示数据帧开始的段。 (2) 仲裁段 表示该帧优先级的段。 (3) 控制段 表示数据的字节数及保留位的段。
(4) 数据段 数据的内容，可发送 0～8 个字节的数据。 (5) CRC段 检查帧的传输错误的段。 (6) ACK段 表示确认正常接收的段。 (7) 帧结束 表示数据帧结束的段。 下面对帧的构成进行说明。
错误的消息。 3.3 遥控帧 接收单元向发送单元请求发送数据所用的帧。 遥控帧由 6 个段组成。 遥控帧没有数
据帧的数据段。 遥控帧的构成如图所示。 (1) 帧起始（ SOF） 表示帧开始的段。 (2) 仲裁段 表示该帧优先级的段。可请求具有相同 ID 的数据帧。 (3) 控制段 表示数据的字节数及保留位的段。 (4) CRC段 检查帧的传输错误的段。 (5) ACK段 表示确认正常接收的段。 (6) 帧结束 表示遥控帧结束的段。
(8) 连接
CAN 总线是可同时连接多个单元的总线。可连接的单元总数理论上是没有限制的。 但实际上可连接的单元数受总线上的时间延迟及电气负载的限制。降低通信速度，可连 接的单元数增加；提高通信速度，则可连接的单元数减少。
2. CAN协议及标准规格
2.1 ISO 标准化的 CAN协议 CAN 协议经 ISO 标准化后有 ISO11898 标准和 ISO11519-2 标准两种。ISO11898和 ISO11519-2 标准对于数据链路层的定义相同，但物理层不同。 (1) 关于 ISO11898 ISO11898 是通信速度为 125kbps-1Mbps 的 CAN 高速通信标准。 目前， ISO11898 追加新规约后，成为 ISO11898-1 新标准。 (2) 关于 ISO11519 ISO11519 是通信速度为 125kbps 以下的 CAN 低速通信标准。 ISO11519-2 是 ISO11519-1 追加新规约后的版本。
所有的单元都可以检测错误（错误检测功能） 。
检测出错误的单元会立即同时通知其他所有单元（错误通知功能） 。
正在发送消息的单元一旦检测出错误，会强制结束当前的发送。强制结束发送的单 元会不断反复地重新发送此消息直到成功发送为止（错误恢复功能） 。
(7) 故障封闭
CAN 可以判断出错误的类型是总线上暂时的数据错误（如外部噪声等）还是持续的 数据错误（如单元内部故障、驱动器故障、断线等） 。由此功能，当总线上发生持续数据 错误时，可将引起此故障的单元从总线上隔离出去。
数据帧的构成
(1) 帧起始（标准、扩展格式相同） 表示帧开始的段。 1 个位的显性位。
数据帧（帧起始）
总线上的电平有显性电平和隐性电平两种。 总线上执行逻辑上的线“与”时，显性电平的逻辑值为“ 0”，隐性电平 为“1”。
“显性”具有“优先”的意味，只要有一个单元输出显性电平，总线上 即为显性电平。并且，“隐性”具有“包容”的意味，只有所有的单元都输 出隐性电平，总线上才为隐性电平。（显性电平比隐性电平更强。）
【注】 *1 通信速度 通信速度根据系统设定。
*2 总线长度 总线的长度根据系统设定。 通信速度和最大总线长度的关系如下图所示。
CAN 收发器根据两根总线（ CAN_High 和 CAN_Low）的电位差来判断总线电平。 总线电平分为显性电平和隐性电平两种。总线必须处于两种电平之一。总线上执行 逻辑上的线“与”时，显性电平为“ 0”，隐性电平为“ 1”。物理层的特征如下图所示。
扩展格式有 29 个位的 ID。 各种帧的用途如表所示。
帧的种类及用途
帧 数据帧 遥控帧 错误帧 过载帧 帧间隔